I dont find the argument convincing. By that assembly is closer to what CPU actually does, why not write code using goto (or binary)? We all can agree on its easy to write reasonably good code high-level languages. I think it because high-level languages are closer to the problem domain (or our thinking), hence it's easier to define the solution in these languages. same for recursion.
> It’s easier to use a debugger on procedural-style or OO code (step in/over/out, local variables) compared to recursive functional style advertised by SICP.
I feel exactly opposite. OO by definition have state bound to object outside the method (not actually local variable), so you have to watch all the objects method is affecting. Not pleasant experience when you have hundreds of objects. A recursive code on the other hand usually depends only on the local arguments so you can only focus on current step.
> In most runtimes, call stack is limited to a small size, a couple of megabytes. Stack overflow exception is hard to handle in a reasonable way. When instead using a loop with a stack container for the state, it can be much larger, also easier to handle overflows i.e. implement soft and hard limits.
Well, depends on the platform you are working on. For desktop at least it's definitely not "a couple of megabytes".
I feel that most of the time choice is between readability and performance. Sometimes maybe the solution is inherently iterative/recursive making choice easier. ymmv though.
Mostly agree.
> same for recursion
I don’t know about you, but in my problem domains loops are closer then recursion. Also loops are closer to my thinking. YMMV.
> Not pleasant experience when you have hundreds of objects
No one forces you to design your OO apps this way. When you only have a few objects, or when you only process them sequentially, there’s no need in complex OO model, a functional or procedural code will do fine.
However, there’re apps where there’re hundreds of interacting objects, such as a web browser.
> For desktop at least it's definitely not "a couple of megabytes".
On Windows it’s usually (=for apps linked with default settings) 1 megabyte.
Actually, the simplest example I can think of where this the case involves a sequence: binary search.
On the other hand, if you have to significantly rework the conceptual recursive solution to put it in tail-recursive form, an implementation using loops may end up being easier to understand.
* CPUs are dynamically scoped
* CPUs are weakly typed
* CPUs are dynamically typed
* CPUs only compare to zero
* CPUs have no way to represent OOP
and so on
All that said, tail calls are very close to how the CPU works. They are just GOTO with additional parameters. If you implement tail calls with dynamic scoping, the parameters would be registers and the tail call would be a change to the instruction pointer. That would be very close indeed.
Loops are not necessarily close to what a CPU actually does either, especially one supporting vector operations or out-of-order execution. Loops imply an ordering which may or may not be actually exist and many compilers are complicated by their presence.
Debuggers are a problem for any suitably high-level abstract code. Would a step-by-step word-at-a-time debugger help to debug a SQL query or even a complex arithmetical expression from Fortran? There is no getting away from the fact that high-level domain-specific code needs high-level domain-specific debuggers to be built alongside.
I know and I don’t think these are always good things.
> Loops are not necessarily close to what a CPU actually does either
Indeed, not necessarily, but very often. Unless automatic vectorization is involved, long loops are very often quite close to the machine code uploaded to CPU. Inside the CPU it’s free to do whatever, but on the public API, it’s still loop instructions.
> the fact that high-level domain-specific code needs high-level domain-specific debuggers to be built alongside.
That’s not a fact, that’s your opinion. I don’t code SQL nor Fortran, mostly C++ and C#, sometimes Python and others. The debuggers I have in corresponding IDEs are already built, they are sufficiently high-level for domain specific code, but the debuggers themselves aren’t domain specific, they are pretty general purpose.
Maps and folds do make structure explicit though. For example, it is very easy for a compiler to vectorise a "map" operation. Folds will always terminate.
> The debuggers I have in corresponding IDEs are already built, they are sufficiently high-level for domain specific code.
But does your debugger allow you to visualise the intermediate steps of an arithmetic expression? Does it understand Iterables/Enumerables and allow you to capture and inspect them? Can it handle concurrency and parallelism, or help you make sense of callbacks for non-blocking IO etc? My point is that the debugger is simply not as general purpose as most claim it to be. It sees the world word-at-a-time and only allows you to step statement-by-statement. It does not understand the composite data structures or control structures that you have built. This is less of a problem with low-level code, as typically there is limited abstraction. But it will be a problem for any sufficiently high-level abstract code (functional or otherwise).
For a general map function, it’s insanely hard problem. It’s only trivial if the map function is trivially simple e.g. `return x*2`.
> does your debugger allow you to visualise the intermediate steps of an arithmetic expression?
No, and I write my code in a way so the expressions aren’t too complex. When they grow to be that complex, I break them into multiple steps, keeping intermediate results in separate variables. BTW my primary motivation is readability, debugging is secondary.
> Does it understand Iterables/Enumerables and allow you to capture and inspect them?
I think so.
> Can it handle concurrency and parallelism, or help you make sense of callbacks for non-blocking IO etc?
Sure, debugging async-await code in .NET is almost as simple as old school non-scalable blocking IO code.
> But it will be a problem for any sufficiently high-level abstract code
Not a huge problem in practice. There’re simple ways to implement support for your custom composite data structures, e.g. natvis files in VC++. Also, in .NET you can run any code in debugger’s immediate window, while execution is paused. These simple methods aren’t effective in 100% cases, but often they are sufficient to debug, therefore saving a lot of time because no domain-specific debuggers are required.
Depends on the abstraction. For idiomatic stuff it’s relatively easy to extend the debugger, see e.g. [1] about writing custom debug visualizers for very complex objects (for reasonably complex there’re much simpler ways).
For non-idiomatic stuff such as extending the language by modifying the compiler, or e.g. post-processing the compiled output, I don’t know because I never needed debugger support.
https://docs.microsoft.com/en-us/visualstudio/debugger/creat...
That said, I love my for loops, too.
It only works if you are using recursion in place of a simple loop.
Many algorithms traditionally implemented with recursion (e.g. various tree searches) need that stack somewhere.
Technically it’s probably possible to “properly prepare” that, but practically both alternatives (recursion + built-in call stack, or loop + separate stack) are much easier to implement.
Loops are closer to what CPU actually does. A compiler is therefore simpler to implement and will likely contain less surprises.
It’s easier to use a debugger on procedural-style or OO code (step in/over/out, local variables) compared to recursive functional style advertised by SICP.
In most runtimes, call stack is limited to a small size, couple of megabytes. Stack overflow exception is hard to handle in reasonable way. When instead using a loop with a stack container for state, it can be much larger, also easier to handle overflows i.e. implement soft and hard limits.