4 ms·

In my experience, currying using helper libraries also makes debugging more difficult, as you have to step though higher order functions and cannot always easil

In my experience, currying using helper libraries also makes debugging more difficult, as you have to step though higher order functions and cannot always easily tell how the argument values were calculated. This can be mitigated somewhat and the tools are improving but I generally found that, the more clean I made my JS code using functional programming concepts, the more difficult it was to debug when everything went wrong. And without a type system, I had to debug much more than in a lanague like scala

mattbierner 9y ago
This opinion comes from my experience developing Khepri ( http://khepri-lang.com http://khepri-lang.com ), which tried to rework the JS syntax to better support untyped functional programming. Even had a partial application operator: @ And the language’s implementation was beautiful: declarative, no mutation, and HOFs everywhere. It even used monad transformers. But the nightmare that was debugging also convinced me that I had actually been trying to solve the completely wrong problem
taeric 9y ago
It is funny, because this is the argument against most use of macros in lisp. To the point that everyone knows that macros make it harder to debug code. The lost part, is few people actually "debug" in the "interactive debugger" sense of the word anymore, such that many things that were frowned upon in lisp and related languages are now getting a lot of exposure. And I feel it is truly sad how few people know how to step through a program nowdays. (Obviously projecting some. Maybe I'm in an odd corner where nobody uses an interactive debugger, but it has been a long time since I found coworkers that were used to using one. And, in this, I'm including REPL based workflows. Yes, I know they are strictly different. I just feel they are in the same family for this discussion.)
- linkmotif 9y ago
  What do you mean few people know how to step through programs nowadays? Is it uncommon to open up dev tools and step through code? I step through code whenever I get lazy or tired and don’t want to think and am using a platform with a nice debugger. I’d think this was very common but I live in a hole.
  - taeric 9y ago
    Majority of my coworkers have not done this. With some of the newer stacks, it is not really possible, yet. And in a distributed world, it is genuinely not feasible, that often. I think this is an odd one. That the act of stepping through code hella build the skill to mentally simulate stepping through code. Which helps reason about it. I don't have data to back that claim. :(
- barrkel 9y ago
  When the abstraction stack gets high enough, stepping turns into a bit of a minefield - if you step into where you should have stepped over, you can get lost in irrelevant weeds. Microsoft and some others have tried to put step barriers in code that prevent accidental step into for this reason ("only my code"). But it's also a change in coding conceptualisation. Personally I understand things from the ground up, from composition of very low level components. I find it hard to reason about a system's performance and failure modes without doing so. But increasingly developers have only a surface area knowledge about the things they use, and instead know a lot in terms of breadth instead of depth. This approach is more effective for building something quickly by duct taping disparate things together, and this is the majority of modern commercial coding. These people don't need debuggers: it gives them too much information. They need examples, and they code by idiom and analogy instead. Things like event dispatchers and async also greatly diminish the power of the debugger.
  - taeric 9y ago
    Agreed. And I actually fully agree with this being a strong reason not to use macros in lisp. Made a bit more important there, because stepping through a macro involves not just being in other code, but jumping between phases. That said, my main point is that where many folks used to advise caution, such that instead of promoting lisp, they would create new languages where they could hide some of the magic, it seems that people are gung-ho on many of the higher abstractions now, regardless of the mental costs they bring.

mattbierner 9y ago

This opinion comes from my experience developing Khepri ( http://khepri-lang.com http://khepri-lang.com ), which tried to rework the JS syntax to better support untyped functional programming. Even had a partial application operator: @ And the language’s implementation was beautiful: declarative, no mutation, and HOFs everywhere. It even used monad transformers. But the nightmare that was debugging also convinced me that I had actually been trying to solve the completely wrong problem

taeric 9y ago

It is funny, because this is the argument against most use of macros in lisp. To the point that everyone knows that macros make it harder to debug code. The lost part, is few people actually "debug" in the "interactive debugger" sense of the word anymore, such that many things that were frowned upon in lisp and related languages are now getting a lot of exposure. And I feel it is truly sad how few people know how to step through a program nowdays. (Obviously projecting some. Maybe I'm in an odd corner where nobody uses an interactive debugger, but it has been a long time since I found coworkers that were used to using one. And, in this, I'm including REPL based workflows. Yes, I know they are strictly different. I just feel they are in the same family for this discussion.)

linkmotif 9y ago
What do you mean few people know how to step through programs nowadays? Is it uncommon to open up dev tools and step through code? I step through code whenever I get lazy or tired and don’t want to think and am using a platform with a nice debugger. I’d think this was very common but I live in a hole.
- taeric 9y ago
  Majority of my coworkers have not done this. With some of the newer stacks, it is not really possible, yet. And in a distributed world, it is genuinely not feasible, that often. I think this is an odd one. That the act of stepping through code hella build the skill to mentally simulate stepping through code. Which helps reason about it. I don't have data to back that claim. :(
barrkel 9y ago
When the abstraction stack gets high enough, stepping turns into a bit of a minefield - if you step into where you should have stepped over, you can get lost in irrelevant weeds. Microsoft and some others have tried to put step barriers in code that prevent accidental step into for this reason ("only my code"). But it's also a change in coding conceptualisation. Personally I understand things from the ground up, from composition of very low level components. I find it hard to reason about a system's performance and failure modes without doing so. But increasingly developers have only a surface area knowledge about the things they use, and instead know a lot in terms of breadth instead of depth. This approach is more effective for building something quickly by duct taping disparate things together, and this is the majority of modern commercial coding. These people don't need debuggers: it gives them too much information. They need examples, and they code by idiom and analogy instead. Things like event dispatchers and async also greatly diminish the power of the debugger.
- taeric 9y ago
  Agreed. And I actually fully agree with this being a strong reason not to use macros in lisp. Made a bit more important there, because stepping through a macro involves not just being in other code, but jumping between phases. That said, my main point is that where many folks used to advise caution, such that instead of promoting lisp, they would create new languages where they could hide some of the magic, it seems that people are gung-ho on many of the higher abstractions now, regardless of the mental costs they bring.