Future of Coding is an online community with a welcoming, cooperative, and revolutionary spirit. We are unified in the belief that the common practice of programming is tragically less humane than it could be.

Future of Coding

<https://twitter.com/maxkreminski/status/1345108741713063936|https://twitter.com/maxkreminski/status/1345108741713063936>

Happy New year everyone! 
I found this interesting.I wonder how emotions can be thought about with regards to the future of programming

Very true. Most debuggers I used are a big source of frustration and the only reason to use them is having no other choice. My personal ranking is:
1. Smalltalk: debugger OK (but could be improved)
2. Python: a bit primitive in the base language, but OK with a GUI layer on top of it. But could be improved quite a bit.
3. Everything else: frustrating. I never seem to be able to get at the information I want, usually because too much meta-information has been thown away by some compiler.

Relatedly, I saw a super interesting launch on PH today: <https://www.producthunt.com/posts/slowbug> - I haven’t tried it yet but the concept seemed really powerful. Imagine just being able to watch your code execute slowly line by line as a way of debugging and even teaching how to code - almost like a video that you can pause anytime and inspect the contents of variables etc.

The people who decided to integrate debuggers into a source code editor changed everything about the experience.

<@UJBAJNFLK> Where would you put the Common Lisp condition system in that list?

<@U013ZLJARC7> It would have to open a second dimension I guess. It isn't really a debugging tool, but it's a mechanism that supports debugging tools (and more). As such it is among the best I have seen, even better than its Smalltalk equivalent (a more standard exception system). But the overall debugging experience in Common Lisp is less pleasant, partly because of the information overload created by compiler verbosity (at least in SBCL, the only Common Lisp I have used seriously), and partly because of the large distance between the source code and the debugged compiled code for macro-intensive code.

One of my long-term but low-priority to-dos is to check out the demo versions of commercial Common Lisp systems to explore their debugging experience.

Btw this was a good listen <https://hopeinsource.com/emotional/|https://hopeinsource.com/emotional/>