5 ms·

My observation is that functional languages which are REPL-focused (such as Haskell and Mathematica) generally empower the author to well understand/test/"debug

by ktpsns 9y ago

My observation is that functional languages which are REPL-focused (such as Haskell and Mathematica) generally empower the author to well understand/test/"debug" smaller pieces of her code. In contrast, in traditional non-REPL languages such as Java and C(++), this requires writing special testing code within the actual code. Similarly, at least in imperative languages, I made the experience that people who develop with a debugger write less testable code then people who do the debugging in their code, for instance with assertions or test frameworks. Sometimes I feel these two groups are disjoint.

seanmcdirmid 9y ago
It’s weird because these are totally different concepts, and catch different things: the debugger is about inspecting how your code executes, assertions allow you to detect when invariants are broken (and provide points that need inspection in the debugger), tests ensure that your code doesn’t break by accident, etc...good developers should be, no, they probably are using all three tools. That functional languages sometimes lack decent debuggers says more about community investment choices than need (e.g. Lisp machines actually had the best debuggers ever). Repls can only give you feedback one code line at a time (and if you type a procedure/function into a REPL, you get no feedback at all until it’s called in the main loop), it’s ironic they are found more commonly in in expression-based rather than statement-based language.
- taeric 9y ago
  To be fair, repls can do much more than one line at a time. You just need a more capable editor than a line oriented prompt. This is not to detract from your point. I have gone further and lamented the death of debuggers. Primarily because I have seen them used so rarely in the wild. That combined with the somewhat ironic rise of functional idioms in java that are actually difficult to debug. (My understanding from last time I asserted this, is just that I don't see them used much.)
  - seanmcdirmid 9y ago
    My experience is that when the debuggers are bad, they aren't used much, and when they are good, they are used all the time. The web browsers offer poor debugging experiences ATM, so for Javascript they aren't as useful as say debugging C# in Visual Studio or even Java in Eclipse. I agree that functional programming idioms in practice makes debugging harder, but only because debuggers lack the right UI to deal with the buried control flow of things like functional orgami. I've heard F# with its Visual Studio plugin is doing better in this regard.
    - taeric 9y ago
      My apologies, my point in "functional being harder to debug," was purely on some of the new idioms in Java. JavaScript has the advantage of the debugger keyword. Has the disadvantage of the execution engine not being hooked up to the editor for most folks. I have seen some changes to that. And I am still enamored with skewer mode. (Haven't used it much.) Java debugging blows my mind. It was trivial to do and I recall tons of people doing it in school. I have yet to see anyone at the last few offices I've worked in do it. Worse, many common designs and practices make it much more difficult than it needs to be.
    - Sacho 9y ago
      Uh, what makes you say web browsers offer poor debugging experiences? I'd put them about on par with Visual Studio's C# debugging, even better in some areas(Immediate Mode in VS breaks down often, the debugger craps out on some LINQ-to-X expressions, etc, whereas web browsers offer all the malleability of JS right there at the debug breakpoint).
      - seanmcdirmid 9y ago
        Chrome and Firefox devtools are very very behind in modern debug features, it’s like programming in the early 90s again! Not just that, but debugging is also extremely fragile, crashing often on small programs for no good reason. It can’t even call tostring automatically in the watch windows because JavaScript VMs have no easy way of quickly sandboxing those fine grained calls.
- MrLeap 9y ago
  I've worked a lot of high growth companies. Not a single one had test coverage requirements at the start of my employment there. Three that bolted on test coverage requirements at some point did so after the same catalyst. An unharmonious developer joining the team and subjects old, stable code to his opinions. "JQuery is the devil!" The developer cries, as he slashes and burns all the script tags into dust. From there, he installs <his opinion> into the toolchain and spends a tireless 5 hours getting things to sort of work. "That's so much better." he remarks to no one as he scissor claps the dust off his hands. The next day, users wake to a world in tatters. -- they submit tickets, pleas to an angry god to return the serenity of the benign that existed a mere day ago. Rarely at this stage is time simply rewound - though it would be easy to do, someone will remark once. The conquerer of the old tech campaigns hard for hearts and minds. He's baffled that he is not greeted as a liberator! "Spaces are superior to tabs, the fact that the code broke after I ran a regex replace is mostly python's fault. Stack overflow said that people who prefer spaces earn more so it's basically a good business decision to move on from here." For some reason it's easier to be righteously indignant about destruction than maintenance. The strength and intensity of the usurper tends to triumph. Besides, client side validation should be easy to fix -- and there it is. The rest of the pantheon has been cowed. Cowed by the illusion of a few softball one point tickets ahead of them. Unfortunately, glass shelled ecosystems created amidst the layers of code sediment don't fair well against the tremors of sed. Each softball one point ticket begets two 3 pointers, and so it snowballs. When the unharmonious one is summoned by the pantheon to help fight back the cascade, he almost always bravely calls for a complete rewrite. "This is due to the fragility of the legacy system." he always reasons. This is about the time that the descent into madness is halted by a call for test coverage. "We've experienced a lot of regressions recently, we should probably start writing tests." This is also about the time our regicide leaves for another company.
  - chrononaut 9y ago
    This is a very well-written, normalized anecdote (serious). I hope you have or start a blog, and add it into your profile at some point down the road.
  - boubiyeah 9y ago
    Funny piece :) I'm getting the impression the underlying message is that in most common situations a high test coverage is often overrated? This would also be my impression after working on dozens of projects
- crdoconnor 9y ago
  Debuggers, REPLs, assertions, tests and REPLs all perform slightly different functions and have different strengths but they are somewhat fungible. E.g. Linus Torvalds doesn't use a debugger whereas John Carmack relies heavily upon a debugger.
  - seanmcdirmid 9y ago
    OS programming makes it hard to mount a decent debugger directly. You are often stuck with interrupts and serial port interfaces, it isn't the same as writing an application. When I was young, I interned for the OS/2 device driver team, really a different experience. I'm sure Linus at least uses a kernel debugger. But looking at https://en.wikipedia.org/wiki/Kernel_debugger https://en.wikipedia.org/wiki/Kernel_debugger, I guess not.
- hyperpape 9y ago
  Lisp isn't non-strict by default, though, right? I always thought that it was pervasive non-strictness that made it painful for some languages.
  - taeric 9y ago
    My understanding is macros can make debugging in lisp painful. It has the major advantage of the system evaluating the code is easily understood when stepping around, though.
- dustingetz 9y ago
  the irony resolved into something simpler. statement languages are about state - the fundamental primitive is about mutating a state, so it make sense that the preferred debug tool is going to let you inspect the state of the program. Expression oriented languages really encourage and/or force you to write stateless code, you don’t need to pause a program and inspect its state if you code it as an expression because it has none. that’s the theory at least, i am a clojure and clojurescript developer and i spend enough time in my debuggers (probably because real programs do in fact have state) but not nearly so much as i did in java and javascript.
- Tarean 9y ago
  Ghci has a built in debugger with the expected features (breakpoints, single step, inspect local variables, tracing execution and time travel) but it isn't very useful because haskell is lazy. Execution can just pinball around seemingly at random making it hard to figure out what is happening. It is possible to go lower level and just throw gdb at it but a lot of compiled functional code depends on multiple source locations and dwarf can't represent that. On the other hand, for pure code the distinction between repl, debugger and test suite kinda blur anyway.
barrkel 9y ago
Whether the average developer uses a debugger or not is much more correlated with the tools at hand than anything else. People who unit test or don't is more correlated with age and commercial experience / maturity level. Although those correlation curves aren't monotonic either.
- hinkley 9y ago
  I spend a lot of my time helping people get unstuck and I notice patterns. People who don’t use the tools seem to trust their own eyeballs more than they trust code. Even as someone who spots bits of code that nobody else sees, I don’t trust my eyes that much. It’s not a matter of if I can spot things, because I can, but it’s not a reliable skill. It’s a matter of reliability and a matter of saving that energy for the next step.
  - barrkel 9y ago
    I'd agree with you, but with a caveat: that the degree to which you trust tools vs your eyes depends on the quality of your tools. I, personally, don't trust source-level debugging with gdb, for example.
twic 9y ago
Smalltalkers, who pretty much invented unit testing, do most of their programming in the debugger. The technique i was taught was to write a test, run it in the debugger, then when it fails at a missing method, the debugger stops, and you write the code to make the test pass, then restart the debugger.
- kuwze 9y ago
  I've tried playing around with Pharo but I never could figure out how to practice that development model of using tests and depending on the debugger. Is there a tutorial you would recommend that focused on that tactic?
  - pjmlp 9y ago
    "TDD in Smalltalk" https://www.youtube.com/watch?v=pkjFTdq2q2g https://www.youtube.com/watch?v=pkjFTdq2q2g It makes use of Cincom.
- hinkley 9y ago
  Well that explains the genesis of Red Green Refactor.

by ktpsns 9y ago

seanmcdirmid 9y ago

It’s weird because these are totally different concepts, and catch different things: the debugger is about inspecting how your code executes, assertions allow you to detect when invariants are broken (and provide points that need inspection in the debugger), tests ensure that your code doesn’t break by accident, etc...good developers should be, no, they probably are using all three tools. That functional languages sometimes lack decent debuggers says more about community investment choices than need (e.g. Lisp machines actually had the best debuggers ever). Repls can only give you feedback one code line at a time (and if you type a procedure/function into a REPL, you get no feedback at all until it’s called in the main loop), it’s ironic they are found more commonly in in expression-based rather than statement-based language.

taeric 9y ago
To be fair, repls can do much more than one line at a time. You just need a more capable editor than a line oriented prompt. This is not to detract from your point. I have gone further and lamented the death of debuggers. Primarily because I have seen them used so rarely in the wild. That combined with the somewhat ironic rise of functional idioms in java that are actually difficult to debug. (My understanding from last time I asserted this, is just that I don't see them used much.)
- seanmcdirmid 9y ago
  My experience is that when the debuggers are bad, they aren't used much, and when they are good, they are used all the time. The web browsers offer poor debugging experiences ATM, so for Javascript they aren't as useful as say debugging C# in Visual Studio or even Java in Eclipse. I agree that functional programming idioms in practice makes debugging harder, but only because debuggers lack the right UI to deal with the buried control flow of things like functional orgami. I've heard F# with its Visual Studio plugin is doing better in this regard.
  - taeric 9y ago
    My apologies, my point in "functional being harder to debug," was purely on some of the new idioms in Java. JavaScript has the advantage of the debugger keyword. Has the disadvantage of the execution engine not being hooked up to the editor for most folks. I have seen some changes to that. And I am still enamored with skewer mode. (Haven't used it much.) Java debugging blows my mind. It was trivial to do and I recall tons of people doing it in school. I have yet to see anyone at the last few offices I've worked in do it. Worse, many common designs and practices make it much more difficult than it needs to be.
  - Sacho 9y ago
    Uh, what makes you say web browsers offer poor debugging experiences? I'd put them about on par with Visual Studio's C# debugging, even better in some areas(Immediate Mode in VS breaks down often, the debugger craps out on some LINQ-to-X expressions, etc, whereas web browsers offer all the malleability of JS right there at the debug breakpoint).
    - seanmcdirmid 9y ago
      Chrome and Firefox devtools are very very behind in modern debug features, it’s like programming in the early 90s again! Not just that, but debugging is also extremely fragile, crashing often on small programs for no good reason. It can’t even call tostring automatically in the watch windows because JavaScript VMs have no easy way of quickly sandboxing those fine grained calls.
MrLeap 9y ago
I've worked a lot of high growth companies. Not a single one had test coverage requirements at the start of my employment there. Three that bolted on test coverage requirements at some point did so after the same catalyst. An unharmonious developer joining the team and subjects old, stable code to his opinions. "JQuery is the devil!" The developer cries, as he slashes and burns all the script tags into dust. From there, he installs <his opinion> into the toolchain and spends a tireless 5 hours getting things to sort of work. "That's so much better." he remarks to no one as he scissor claps the dust off his hands. The next day, users wake to a world in tatters. -- they submit tickets, pleas to an angry god to return the serenity of the benign that existed a mere day ago. Rarely at this stage is time simply rewound - though it would be easy to do, someone will remark once. The conquerer of the old tech campaigns hard for hearts and minds. He's baffled that he is not greeted as a liberator! "Spaces are superior to tabs, the fact that the code broke after I ran a regex replace is mostly python's fault. Stack overflow said that people who prefer spaces earn more so it's basically a good business decision to move on from here." For some reason it's easier to be righteously indignant about destruction than maintenance. The strength and intensity of the usurper tends to triumph. Besides, client side validation should be easy to fix -- and there it is. The rest of the pantheon has been cowed. Cowed by the illusion of a few softball one point tickets ahead of them. Unfortunately, glass shelled ecosystems created amidst the layers of code sediment don't fair well against the tremors of sed. Each softball one point ticket begets two 3 pointers, and so it snowballs. When the unharmonious one is summoned by the pantheon to help fight back the cascade, he almost always bravely calls for a complete rewrite. "This is due to the fragility of the legacy system." he always reasons. This is about the time that the descent into madness is halted by a call for test coverage. "We've experienced a lot of regressions recently, we should probably start writing tests." This is also about the time our regicide leaves for another company.
- chrononaut 9y ago
  This is a very well-written, normalized anecdote (serious). I hope you have or start a blog, and add it into your profile at some point down the road.
- boubiyeah 9y ago
  Funny piece :) I'm getting the impression the underlying message is that in most common situations a high test coverage is often overrated? This would also be my impression after working on dozens of projects
crdoconnor 9y ago
Debuggers, REPLs, assertions, tests and REPLs all perform slightly different functions and have different strengths but they are somewhat fungible. E.g. Linus Torvalds doesn't use a debugger whereas John Carmack relies heavily upon a debugger.
- seanmcdirmid 9y ago
  OS programming makes it hard to mount a decent debugger directly. You are often stuck with interrupts and serial port interfaces, it isn't the same as writing an application. When I was young, I interned for the OS/2 device driver team, really a different experience. I'm sure Linus at least uses a kernel debugger. But looking at https://en.wikipedia.org/wiki/Kernel_debugger https://en.wikipedia.org/wiki/Kernel_debugger, I guess not.
hyperpape 9y ago
Lisp isn't non-strict by default, though, right? I always thought that it was pervasive non-strictness that made it painful for some languages.
- taeric 9y ago
  My understanding is macros can make debugging in lisp painful. It has the major advantage of the system evaluating the code is easily understood when stepping around, though.
dustingetz 9y ago
the irony resolved into something simpler. statement languages are about state - the fundamental primitive is about mutating a state, so it make sense that the preferred debug tool is going to let you inspect the state of the program. Expression oriented languages really encourage and/or force you to write stateless code, you don’t need to pause a program and inspect its state if you code it as an expression because it has none. that’s the theory at least, i am a clojure and clojurescript developer and i spend enough time in my debuggers (probably because real programs do in fact have state) but not nearly so much as i did in java and javascript.
Tarean 9y ago
Ghci has a built in debugger with the expected features (breakpoints, single step, inspect local variables, tracing execution and time travel) but it isn't very useful because haskell is lazy. Execution can just pinball around seemingly at random making it hard to figure out what is happening. It is possible to go lower level and just throw gdb at it but a lot of compiled functional code depends on multiple source locations and dwarf can't represent that. On the other hand, for pure code the distinction between repl, debugger and test suite kinda blur anyway.

barrkel 9y ago

Whether the average developer uses a debugger or not is much more correlated with the tools at hand than anything else. People who unit test or don't is more correlated with age and commercial experience / maturity level. Although those correlation curves aren't monotonic either.

hinkley 9y ago
I spend a lot of my time helping people get unstuck and I notice patterns. People who don’t use the tools seem to trust their own eyeballs more than they trust code. Even as someone who spots bits of code that nobody else sees, I don’t trust my eyes that much. It’s not a matter of if I can spot things, because I can, but it’s not a reliable skill. It’s a matter of reliability and a matter of saving that energy for the next step.
- barrkel 9y ago
  I'd agree with you, but with a caveat: that the degree to which you trust tools vs your eyes depends on the quality of your tools. I, personally, don't trust source-level debugging with gdb, for example.

twic 9y ago

Smalltalkers, who pretty much invented unit testing, do most of their programming in the debugger. The technique i was taught was to write a test, run it in the debugger, then when it fails at a missing method, the debugger stops, and you write the code to make the test pass, then restart the debugger.

kuwze 9y ago
I've tried playing around with Pharo but I never could figure out how to practice that development model of using tests and depending on the debugger. Is there a tutorial you would recommend that focused on that tactic?
- pjmlp 9y ago
  "TDD in Smalltalk" https://www.youtube.com/watch?v=pkjFTdq2q2g https://www.youtube.com/watch?v=pkjFTdq2q2g It makes use of Cincom.
hinkley 9y ago
Well that explains the genesis of Red Green Refactor.