The original C was readable by an infant. I need an encyclopedia of the history of programming methodologies to understand his C++ refactor.

You don't have to debug Haskell because either a) you didn't use it in the first place b) you git everything right because you wrote it in Haskell and you are a genius

7:47 “it avoids the possibility of off-by-one errors”, he says while adding 1 to the end of his range to make it inclusive

That c++ refactor was the most ridiculous and hilarious thing I've seen in a while. I burst into laughter at the exact same time Primagen did.

It's amazing how C++ allows you to turn straightforward programs into something very close to APL programs.

what i've learned: C is evergreen, can look really nice and is super readable, but will spontaneously transmute into a nuclear bomb if you look away for an instant. rust is the new kid on the block with fancy hair, but is still just C's cousin on mood stabilisers. haskell is an eldritch horror that will annihilate your mind but in return allows you to astrally project your code into a pocket dimension were it runs optimally. c++ is a hulking, grotesque abomination enslaved by sadists to run the entire world at our peril and would benefit from being taken round the back of the shed and shot squarely in the base of the skull.

7:50 "avoids off by one errors" Shows a loop that requires a + 1 to avoid being off by one. 😂

Haskell does require you to pretty much throw away everything you know about imperative programming. It's a completely different paradigm, but once you do learn how it works the code here is very readable. I recommend learning a bit of Haskell just because it requires you to think so differently about solutions.

"readability is a function of experience" this is the truest thing I've heard this week. how have I been programming for 30+ years and never, ever heard any dev say this? I say it all the time, and everyone just smiles and nods when I do, and acts like I need to get back to my fucking nursing home.

Prime: “c++ Longest way to say the shortest thing” Java: hold my beer!

"iota avoids off by one errors.... Oh, by the way, don't forget to add one to top if you want an inclusive range" I like the code report channel but he's definitely more into arcane programming aesthetics than pragmatism. No idea why he decides to compare number of assembly instructions produced, its just as easy to benchmark the run time.

Expanding a bit on the haskell syntax, indeed haskell is a language that requires you to think very differently about programming, and as such, its syntax tends to look ugly, but once you start using it and understanding it, you can see that it is actually quite clean in haskell, functions are king, and as such, the syntax is worked around clean composition and use of functions ( to various degrees of success ) ignoring type signatures, functions are defined by naming them first, then listing the parameters calculate top bottom then, to apply it, you do the same calculate 1 100 this does cause a problem, filter takes a function to use as a filter, and the list you're gonna filter, if you tried to just list all of the arguments sum filter even list the parser thinks you're trying to apply sum to three arguments, in c-like terms: sum(filter, even, list) to solve this, you could just use parentheses sum (filter even list) but we also have the $ operator, which is simple function application (f $ x = f (x)) sum $ filter even list since $ is an operator, the parser now knows that filter is a function, and even and list are the arguments, and now it type checks neatly this does map directly to the rust solution: [bottom..top] = (bottom..=top) filter even [bottom..top] = (bottom..=top).filter(even) sum $ filter even [bottom..top] = (bottom..=top).filter(even).sum() as an extra note, the type system in haskell also tends to have an intimidating syntax, but is is because the type system is very rich and expressive for example, epressing filter in rust would look something like this (ignoring whatever complications might arise from lifetimes and such) fn filter (f: T -> bool, vect: Vect) -> Vect { … } while in haskell it would be: filter :: (t -> Bool) -> [t] -> [t] filter f list = ... (yes there is a reason for the arrows but this comment is very, very long as is) which one you prefer is up to you, but imo when you move functions left and right, haskell's syntax is quite ergonomic, while the parentheses of c-like languages gets in the way

I can't believe there was a clean C++ program with LITERALLY a "for" and an "if" and the dude turned it into a program with functions which you gotta search what the parameters mean, passed functions as arguments to the said functions, declared a namespace (which you also gotta see what exactly it is) and brought a lot of new syntax that only works on the last versions of C++. It also takes 10x more to understand the "upgraded" version. Btw, love your videos, Prime (curly braces on new line lol) { }

That C++ calculate function is an abomination. Here is a non-nested version that doesn't hurt my brain (and doesn't have an early return even though it really should): int calculate(int bottom, int top) { int acc = 0; for (int val = bottom; val

As a javascript developer I have never used rust before and I have gotta say, I understood the rust version of the sum function really quickly by just looking at it for 30 seconds. I've got to learn rust, such a neat looking language!

Kotlin is also very nice: fun calc(bottom :Int, top: Int) = (bottom..top).filter { it % 2 == 0 }.sum() Differences to Rust: Return type is inferred and you can leave out the braces if your function is just one statement 'it' is always the name of the first unnamed lambda parameter

I just learned the term "React Andys" from chat and I'm gonna use it to harass Theo and his audience!

Considering how much you love rust I really suggest at least giving Haskell a chance. On it's own it's not the most useful language but it is really elegant and fun when written properly. And for some use cases, such as compilers, it is crazy good

9:25 As a C++ dev; What the actual fuck is happening?

Watch the original: ukposts.info/have/v-deo/r3d0i6KAa3dm22g.html Amazing author: www.youtube.com/@code_report

For those wondering iota is a term borrowed from APL, where there is a glyph represented by iota which gives an exclusive range from 1 to n. It is used like ⍳5 and this would give the sequence 1 2 3 4. It is represented by iota because the proper name for this is interval or index generator, with iota being the equivalent to the English letter i in Greek

When he mentions that he would need to relearn programming to understand Haskell: well, indeed you kinda do, and that is actually the point. Not a big fan myself of functional programming but one must recognize it is such an interesting paradigm and worth knowing (specially its theoretical foundation).

This has been an emotional roller coaster as a mathematician (so haskell feels the most natural for me). Like first he gets mad of the type declaration thingy and I'm like "wtf programmers don't know currying?" but then he gets it an appreciates it which is nice. BUT THEN HE SAYS "I wOulD hAndS dOwN haTE debUGGinG haskell". Bruh everything is pure functions and type-safe. It is literally the debugging dream.

Because he uses assembly size as his metric, O3 in C and C++ optimizes for speed, the compiler will unroll your loop and inline aggressively if it thinks it can make it faster and won't really care about the size of the code. The reason adding the various library functions reduces code size in O3 is likely because it adds a lot of things that have to happen to now work with arrays instead of just a few stack variables and therefore can't unroll your loop to make it all that much faster. While I can't say for sure, this might be slower when not threaded. So who knows how the speed is actually affected, you would need to actually benchmark it to know.

30:39 It's semantically equivalent. Yes syntax is different, but semantically you're just composing functions. And yeah, as other commenters said, Haskell can be weird, but it can teach you *a lot* about programming and give you many "WHOA" moments, once you get through initial learning curve.

Love the steady stream of new videos on this channel ❤️

The Haskell code is beautiful, I wish you could appreciate it 😅

So, Haskell can be a bit of a brain bender. Every function in Haskell takes one parameter and returns one parameter. A function which takes more than one parameter is effectively a function which takes in one parameter, and returns a function which takes in all the other parameters (this happens recursively). So to use the example in the video, Int -> Int -> Int means that it takes an integer and returns a function that takes an integer and returns an integer. Higher order functions in Haskell are pretty nice for the simple reason that in order to deal with mutable state, you need to use monads (basically a means of passing the current state as a function parameter, and having the new state be returned). This means that if there's a bug involving mutable state, you automatically know which subset of functions it must be in, because you had to declare the use of the monad; much like how unsafe in rust reduces the surface area for memory or concurrency bugs.

To make the Haskell code more explicit, here it is: calculate :: Int -> (Int -> Int) calculate = \bottom -> \top -> sum (filter (\i -> even i) [bottom..top]) This is literally equivalent to the code in the video because all functions in Haskell are implicitly curried. I also removed the dollar operator and made the even check more obvious that it is a function used for a callback. Anyway one major reason high-order functions are is not the Hellish Nightmare they are in JS is because all variables in Haskell are immutable and all functions are pure. (Haskell is able to model state and impurity through its type system and some primitive language-given types such as IO and ST.)

As the official intern (and future CEO) of The Startup™I'm legally obligated to say I'm loving this channel. A chance to watch something I missed from my genius CEO??? Perfect way to try harder.

Heyyyyyyy this was my "Prime should react" video suggestion! I'm so happy that this was on yt now since I missed the stream due to other stuff I had to do. Awesome, had a blast watching it!

Wait, you *don't* like seeing 2 or 3 ternary operators nested together with a bunch of inline lambda expressions? Log debugging is in the past, just guess the problem correctly the first time

Honestly, the most cursed thing about the C++ example is the fact that *in C++20* they didn't even have a ranges overload for accumulate... or a general fold function

O3 inlines more functions into the call site, which increases instruction count but *almost always speeds execution

I would actually enjoy seeing Primeagen trying to learn Haskell. Or well, something smaller like Elm or Idris. (Both are basically Haskell but done from scratch, with the focus placed on a slightly different use)

i love haskel. It was one of the first langues i was taught. I am math person and it just makes sense to me. haskell programs read like proofs. i love rust too, been learning it for 6 years now lol. But I write cpp code for my telecom job, I must say that cpp code was just pp move. I work with deveopers that do this in real life, it just looks downright obscure and ugly to me. It is a nightmare to onboard new people if anyone in team write codes like that and doesnt write comments. that stood was awful as well. lol.

The big problem with `else` and `else if` statements is that the condition to execute the code block is not at the start of the statement like for `if`s, so you have to mentally juggle with negating the `if` condition and applying the extra conditions from the `else if`. tl;dr: else's have code which is run on an implicit condition, unlike `if`s where the condition is explicit.

In haskell the right to left reading is because of function application. It's like doing f(g(x)), the g function happens first.

What the assembly comparison tells is that the early things all compile just fine and the compiler understands exactly what is going on, so when you compile with -O2, it can make things tiny, and when you compile with -O3, it can unroll the fuck out of everything and makes things ~blazingly fast.~ On the other hand, the fancier stuff where there's less of a difference, the compiler no longer understands what is going on and so it can't make the optimizations you would want out of it.

For Prime listeners on the outside of the cpp community, this is CodeReports bread and butter. He works in big c++ codebases converting the math to this modern range / algorithm stuff per his podcast with Bryce.

You can manually reason about what constitutes the count of evens in a range, and find out that you do not need loops, just a few rithmetic steps. You calculate the half of the length of the even aligned subrange, and then correct it with the endpoints. Simple constant time goodness. int calculateCompact(int bottom, int top) {return !(bottom%2) + top/2-bottom/2;}

You could flip the first if statement and return early in the case (top

Love your content. After the first 10 minutes however, I had to call in sick for two weeks. keep up the good work my man.

About the C++ code: The initial for loop was perfectly fine! Easy to understand, easy to optimize by the compiler. Anyway, there is a problem with the C and C++ versions. The problem is when top is the maximum integer value. Assuming it is really running for that long the C version will overflow and never stop. Always cycling all the numbers. The C++ version starts by adding 1 to top and as such will immediately overflow and immediately stop (will do one loop if bottom is the minimum integer value). In reality that case might not happen, but maybe it can happen if user control the input and that situation would cause some security issue or something. So depending on your context it might be a good idea to handle that case. Hope I got that all right in my head. Rust ranges seem to be handling that case correctly when testing it on Rust Playground. And the difference between the Rust and Haskell version is just methods Vs functions. The -> syntax for the function type is maybe a bit weird when you see it the first time. In Haskell all functions are curried. Meaning if you pass in less parameters than possible you just get a function (closure) back that takes in the rest of the parameters. The -> basically means returning. As such the calculate function is a function that takes in an Int and returns a function that takes in another Int and returns an Int. A bit weird, yes, but handy if you like this high level stuff. E.g. IIRC you can define sum like this: sum = foldr (+) 0 Note that there is no parameter in the definition of sum because foldr takes 3 parameters, but I only pass 2 here. Meaning there is one remaining parameter: The list of numbers to sum. The product function would be: product = foldr (*) 1 foldr is usually called reduce in other languages. There is also foldl. It's about from what side the list is processed. Since addition and multiplication are commutative that is not important here, though I think foldr has better performance in Haskell because of lazy evaluation. Haven't touched Haskell since university, which was more than a decade ago. Btw. IIRC Haskell and currying is both named after the same person: Haskell Curry. So of course everything is curried in Haskell! XD

37:16 a call to a library function itself adds an overhead of a few instructions, like stack push/pops, call/jump instructions, returns etc. which can vary based on the calling convention

Literally was dying with you at 9:00, great video! :D

Optimisation typically will produce more instructions when dealing with loops (unrolling - essentially reduces the number of cmp and jmp instructions by making explicit instruction repetitions with the incremented pointer position or register[] value). If you're using library functions your assembly will be smaller as the looping is now reduced to a single call instruction (plus a few mov instructions for arguments) because the the loop work is done elsewhere - unless the functions are inlining the assembly. So the number of lines of assembly does not map to performance for a single function or executable. Furthermore, with CISC (e.g. x86) you can use the same complex instructions such as mul (multiply) and how you supplying the source and destination data can affect how well this performs. With modern CPUs how you supply data to certain instructions can affect how CPU graphs your instructions and this can affect execution speed. So again compilers may use a more verbose set of instructions because it helps the CPU firmware map your code more efficiently. How do I know this - because I code in C! Grrrrrrrr..........................

The comment section is always like having -Wall -Werror flags on.

I'm mostly with you on this. I really like C++ though. I don't care about iota or filter much. I do like lambdas and some of the helper functions if they make the code more clear. I don't like operator overloading when it changes meaning depending on the context, it's fine if it's consistent across C++. I guess it's good we're all a little different, find the flaws in each other. XD

I love these HR segments! super funny

About the curly braces in a new line... I feel you, bro!

I love Haskell so much, you should really give it a chance!! It's such a beautiful language

This brought back trauma of writing Haskell applications back in uni. Rust really looks like a practical implementation of functional concepts

I see the thumbnail and know it's Conor Hoekstra. His algorithm videos are just satisfying as hell. His convention talks are also just intense. And guy who does APL for fun must be pretty serious about languages. Sean Parent started it all, really in 2013. Then Baccara with 105 algorithms in 2018, and since then Hoekstra. They've been going on about how the STL has had algorithms that do things faster, more describingly and with less room for error since 98 and people still in 23 act like you spelled Voldemort if they see a single algorithm instead of bunch of indexed nested for loops. The message being: it's been 10-20 years, it's time you got more familiar with the STL algorithms so you didn't need to be a shocked assembly coder because it's not what you're used to. It's not at all that bad if you spend a little time to know the algorithms and becomes much more readable. Similar to the way Rust is often written with multiple methods ending up with something descriptive and pretty neat. Scary at first when you don't know it, but then rather satisfying. But I loved the whole chat going "this is not readable, it literally says accumulate, filter even while the previous code said for for if for which was painstakingly obvious to me what it was doing, personally I love messing up my for loops for trivial details". Like people don't get shocked when they see something like .reverse() or pow(a, b) or sqrt(). Or for god's sake a function call someone custom made that's all new to them. I would argue though that his reasoning is pretty solid about the bug, it's not just unclear intention if you write two loops contradicting in behavior, it's something you didn't pay attention to and make consistent. But I surrender that it's not guaranteed it was meant to do what he concludes. Basically every speaker in C++ says stud and it's weird. And I also wish everything convenient in C++ wasn't std::blahblah::yup::right::plus. For some reason they went with "iota" when they could've called it something like "range". It's literally just generating the range for you to iterate over. The beauty of Rust really is that no legacy to carry over and no need to follow ISO standard, it could just make this one so nice. But as long as you have to deal with C++, it's kinda nice to have some of the neat features implemented less nicely in C++ than not at all. Personally I'm still trying to understand the need for (|w| w.operation) and understand which and when does mutate the original and what makes a copy or something so I could intuitively write it correctly. And at some point I questioned why you have to always do the |w| manually when you don't have an option to not do it and it could just be done for you by the compiler, but I assume there's a good reason and exceptions. But Rust really doesn't allow you to do stupid things like manually configure iteration loops like you'd intuitively do, it allows you to do simpler and better things instead. Like I was really lost with rust vectors like vec.iter().map(|v| *v * *v).collect() or something, but it was also beautiful how .collect() just deduced the correct return type despite same syntax, different types. The closures were just unfamiliar and I didn't see the reason, but that's a lot of things with Rust: they're new and confusing because your previous language intuition might lead you astray if you don't read how to use the features. But the collect() with ints and strings, it just worked and once you got it into your head that with vector you use .iter() and you have to .map() it, you can even throw a function call inside the .map(). It was so nice even if a bit weird at first. I also saw something about enums in Rust and how they're rather different and powerful, almost like classes, but I haven't still really understood them. But people should be really scared if they don't like seeing this, Hoekstra is a research scientist at Nvidia. His work is quite literally in all of our computers sooner or later. You explained very well why the algorithms exist and are used, and what's the caveat of using them sometimes. Particularly on the Rust example about iterators.

Readable really is a case of what you're used to looking at. I'm fairly used to mapping and filtering over collections in the kind of manner shown around 18:31, so to me it is pretty readable. I find it nice to look at. I would prefer the return early approach to the branching too, but the rest reads easily for me. I read the accumulate body something like this: ACCUMULATE over a RANGE from bottom to top + 1, and then keep the entries that are even.

I'm learning Racket here at University, a functional language similar to Haskell, and debugging is a nightmare. Recursion is such a prominent feature of a functional language, and it is very efficient, but very also hard to debug. We have a stepper to step through the code and it always explodes in lines of code being executed on each recursive call, making it hard to read and actually debug lol.

You can't always just rename to cpp. Things like no implicit cast from void* breaks malloc, realloc, etc. There are some other oddities (with function pointers iirc) as well, but that's the primary one.

The cut at the end was perfect 👌

30:07 32:00 that top definition is for "haskell currying". ur instinct of "Int, Int -> Int" requires the fxn to get 2 ints right there. But with this currying, u can supply one int, and the other can be say a list of ints, and this fxn would apply calculate over each element in that list iirc. there is computerphile's video on haskell currying.

The Int -> Int -> Int stuff makes more sense when you learn currying. If we had, say myMultiply x y = x * y then myMultiply x would give you a function that took one parameter, y, and multiplied it by x. That is, it is equivalent to \y myMultiply x y In e.g. Python, we have to write something like lambda y: myMultiply(x,y) It comes from the maths roots of Haskell. Things like if f:X→Y is a function and g:Y→Z is a function, then (g.f) is a function (g.f)X→Z where (g.f)(x) = g(f(x)). Haskell is a bit of a 'programming language for mathematicians' at times.

Ah, C++; the language everyone loves to hate. True, there are a lot of things that come out of the standards commitee that make you go "what?!". On the other hand, it's ~sad~ funny to see how little people know about the language before criticizing it.

I confess that I watch Primeagen videos waiting for him to have one of those outburst of indignation about the use of curly braces or something like that. I love that he candidly admits that he is all rage about minor things... he is adorable.

There is actually a second "bug" connected to inclusive ranges. for(int i = bottom; i

I'm so happy that except from types and the range rust's example is pretty much js TODAY

ME TOO! I have the same reaction every time I see a curly brace on a new line. The worst was when I saw someones JS code doing that I almost died.

What a great insight "readability is a function of experience". When you first said you couldn't see the similarities between the Rust and Haskell versions I thought you were trolling, because for me they're basically identical (a function of experience), I had to see you struggle with it after to understand how they were even different.

7:04, The only change that needed to be done to that for header was to just iterate bottom prior to the loop if it's not a multiple of 2 like this: "bottom += bottom % 2;" then swap out the "number" variable for just "bottom" since bottom is never used after the loop, allowing to rip out the "int number = bottom" in favour of just a space character and the "number++" for "bottom += 2" which would quickly negate the need for the if statement in the loop, even allowing the "sum += number" to just be shifted to next to "bottom += 2" as "sum += bottom" resulting in a simple loop like this: "for ( ; bottom

Guy who calls it MySqueal making fun of a guy who calls it stood.

Looking at the generated assembly code he shows, there are some interesting observations I made. Due to the way he used godbolt the compiled rust code didn't even include the calculate function since the results were able to be calculated at compile time. The C and C++ code also calculated the result at compile time, but still included the calculate function. O3 produced more instructions than O2 because it made an attempt to vectorise the code. Using std::accumulate prevented the C++ compiler precomputing the result of calculate(5, 12) when using O2, although it still managed it when using O3. Trying to compare the speed of languages by looking at the number of generated instructions is flaky at best, but even worse when the code examples used can be trivially precomputed.

I use newline braces in all of my indented code longer than 2 lines. But if it's 1 or 2 lines of indented code, I'll do a same line curly brace.

I completely enjoy your no filter attitude!

I came here to see you're reaction to "stuud" - didn't disappoint. LOL

I learnt Haskell before learning rust and I don’t regret anything

Comparing number of asm instruction is as meaningful as comparing number of lines in indian code to number of lines in "normal" code.

As someone who doesn't know rust, but is rust curious that code looks easy to understand, only thing that is a bit of black box is the range, which is fairly straight forward to notice and think "It can't be that easy", but what the periods and equal sign are, but I'd hazard a guess that the period decides from where to so start after the bottom until top inclusive?

I didn't know the stream when you did this video but you are really an explicit return kinda guy? Boy.

Std::views::iota reaction killed me 😂

i think the iota comes from the fact that most range loops use i as the variable, for i in range(...), and i is basically iota

More assembly could lead to faster code actually. Say you have a slower general way of solving an algorithm that is quite slow, you could branch/match/switch depending on the actual input at runtime and choose an optimised algorithm based on the actual input. of course every branch needs it's own code leading to more lines but in the end you'll be executing quicker.

Tl; dr; good to see that a lot of this stuff is just syntactic sugar. Modern compilers are usually much smarter than their users and can optimize out a lot of unnecessary branching, so you can focus on writing readable and maintainable code. Putting this whole function in a single line of C++ code, make my stomach hurt.

once you learn haskell, the code reads almost like poetry, though, the problem is learning haskell… haha gotta say, it’s a bit difficult, but it expands your mind like you never thought it would

The content king milks a 14min video por 40min. Bravo, papa prime bravo! (it is actually pretty funny I'm a fan)

I just watched another Prime video re: clean code. Then YT sent me here… alphabet spillin’ some tea today 😂

25:09 I think this is just another example why early return is so good. It declares an edge case and clearly implements special handling for that.

I liked the cpp refactor, the iota naming is weird though, a `std::view::range` or something would be way better anyway I don't do cpp since school so whatever lol

This how you make code unreadable

I think the $ replaces brackets. So its equivalent to: calculate bottom top = sum (filter even [bottom..top]) but, not sure.

Great video, had lots of fun, prime!

new line braces are more readable and widely used in C#, i see it as a positive thing

I feel that Code aesthetics target audience is less experienced.

So the original video used syntax explicitly meant to be language agnostic. All Turing complete languages have control flow, functions, and loops. While the code happened to have been C, the original code snippet is also runnable Java code. So the advice in the original video was helpful for me when thinking about my spaghetti-code python script. It also works for refactoring React components. And for simplifying my MATLAB scripts. (Data-science/ChemE background) Or for finding a bug in Julia. Or for simplifying and refactoring CSS. The refactor using rust or cpp specific features does not do as good of job getting the core programming concepts across as the code becomes unreadable by somebody using an unrelated language. Or by somebody using a DSL. Most reasonably modern programming languages have inspiration from C. So C can often look like pseudo-code, and therefore can be used as an example to talk about a more fundamental concept. While refactoring using modern language specific tricks is cool, I think it misses the point and reduces the audience that can accept the lessons about a happy path, early returns, and using functions when a script gets too messy. The original video is closer to a moderate and useful distillation of the lessons learned from clean-code.

The funny thing about the C++ example is that new lines and tabs are just for our benefit anyway. You’ll notice he chose to just include a whole block in one line between the curly braces after the auto statement.

You have typo in title (react to rust)

I think kotlin is closer to rust in syntax than haskell fun calculate(bottom: Int, top: Int) = (bottom..top).filter{ it % 2 == 0 }.sum()

iota comes from APL, where it means "indices", and generates all the numbers from the index origin (0 or 1) up to the number of indices indicated by the argument.

36:34 yes… the branch predictor also can help with certain things, but in general; more instructions longer run time

If auto was not their in cpp, to get a iterator to a vector of string, I should have to write "std::vector::iterator"🤣🤣 But now I use "let it = arr.iter()" that's it ❤, Now I am learning rust because of this simplity and development environment without lossing much performance than with cpp, I have to shoot myself to setup project and library with cpp using cmake, but after a while I got familer with cmake and now in rust "cargo this" "cargo that", After learning much about build system and every thing I love rust for this reason. But I have love for cpp too because that made me learn more stuff

Don’t program in rust (want to learn) I’m a C# dev and that rust code is 100% readable. We have things in C# virtually the same so that helps, but any developer should be able to look at that and understand what it’s doing regardless if their primary language

17:43 I think the long way was better even though it was longer. It was very obvious what was happening, no object were allocated and c++ is compiled so it wouldn’t have affected runtime like in JavaScript. But I get the appeal of short code.

@ThePrimeTime You don't debug Haskell, Haskell debugs you!