3 ms·

> I know and I don’t think these are always good things. Maps and folds do make structure explicit though. For example, it is very easy for a compiler to vecto

> I know and I don’t think these are always good things. 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).

Const-me 8y ago
> it is very easy for a compiler to vectorise a "map" operation 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.
- willtim 8y ago
  Wow that's fantastic that Microsoft have extended the debugger to understand streams and async/await code, this of course only works because they develop both the abstractions and the debugger. It's probably not so easy for the rest of us to extend it for our own abstractions.
  - Const-me 8y ago
    > It's probably not so easy for the rest of us to extend it for our own abstractions. 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/create-custom-visualizers-of-data https://docs.microsoft.com/en-us/visualstudio/debugger/creat...

Const-me 8y ago

> it is very easy for a compiler to vectorise a "map" operation 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.

willtim 8y ago
Wow that's fantastic that Microsoft have extended the debugger to understand streams and async/await code, this of course only works because they develop both the abstractions and the debugger. It's probably not so easy for the rest of us to extend it for our own abstractions.
- Const-me 8y ago
  > It's probably not so easy for the rest of us to extend it for our own abstractions. 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/create-custom-visualizers-of-data https://docs.microsoft.com/en-us/visualstudio/debugger/creat...