3 ms·

> 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 i

> 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...

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...