9 ms·

Let's face it, procedural is just plain easier to debug because you can more easily split it into digestible and dissect-able chunks: divide-and-conquer. Perhap

by tabtab 8y ago

Let's face it, procedural is just plain easier to debug because you can more easily split it into digestible and dissect-able chunks: divide-and-conquer. Perhaps functional and logical CAN readily have such features, but nobody either figured how, or have not figured out how to explain how to do dissection to normal people. (This is sometimes a criticism of SQL also, but the added WITH clause helps break up big queries into multiple smaller ones.) For example, with a procedural loop you can stick a debug statement in the middle to look at just about anything: while (x=foo(y,z)) { a = doStuff(x, z); console.write("x={?},y={?},z={?},a={?}", x, y, z, a); }

tom_mellior 8y ago
Prolog has print statements you can stick anywhere. (It also has proper debuggers that allow you to go forward and backward and all that.) Also, Prolog code is often "split into digestible chunks". Even more than other languages, in fact, because it's rather hard to write nested loops or nested predicates or nested many other things. If you were ever taught Prolog, it seems that you weren't taught well. You might want to risk a second look.
- YeGoblynQueenne 8y ago
  >> Also, Prolog code is often "split into digestible chunks". Even more than other languages, in fact, because it's rather hard to write nested loops or nested predicates or nested many other things. I find it very easy to write nested loops in Prolog: findall(A ,findall(B ,findall(D ,findall(...) ,G) ,E) ,C) To paraphrase the old saying, a good Python programmer can write Python in any language.
  - tabtab 8y ago
    and correspondingly, a good Prolog programmer can write Prolog in any language. Limerick: "Some rascal wrote Pascal in Haskell."
    - YeGoblynQueenne 8y ago
      >> and correspondingly, a good Prolog programmer can write Prolog in any language. And a really good one can even write it in Prolog.
      - nickpsecurity 8y ago
        And on a Prolog CPU developed with Prolog... http://hps.ece.utexas.edu/pub/singhal_isca16.pdf http://hps.ece.utexas.edu/pub/singhal_isca16.pdf https://www.researchgate.net/publication/220760154_A_Prolog-Based_Hardware_Development_Environment https://www.researchgate.net/publication/220760154_A_Prolog-...
simion314 8y ago
I am curious if you used a visual debugger for prolog? (or for a procedural language) printing things to the console is the poor man debugger.
- tabtab 8y ago
  A big problem with visual debuggers is that they are too blunt of an instrument. Often I wish to examine specific things under specific conditions and thus use conditionals to narrow down what's being explored instead of bajillion breakpoints and/or log records. Debuggers could add conditional expressions, but then they'd be re-inventing WRITE statements anyhow. As far as the nearby statement that maybe I didn't learn dissection correctly, that may indeed be the case, but was also my original point: perhaps the real problem is that nobody knows how to TEACH functional/logical programming right, and that's why they have not caught on in the mainstream despite being around several decades. I'd love to "get" the benefits, but it just won't click. Sometimes you have to teach programmers how to think, not just what to think.
  - tom_mellior 8y ago
    > Debuggers could add conditional expressions, but then they'd be re-inventing WRITE statements anyhow. SWI-Prolog's debugger can be invoked conditionally whenever you want from inside your running application. I've used it many times, and the code is simply: (Condition -> gtrace ; true) It's true that you could stick a write there, but you would have to think about what pieces of data you will need. Your mileage may vary. I've found this style a lot more useful than "traditional" debuggers where you set breakpoints beforehand and hope you hit them, as you say. > As far as the nearby statement that maybe I didn't learn dissection correctly, that may indeed be the case The point was more specifically that you didn't learn Prolog properly (or at all) and don't realize that it forces you to dissect your code. As I said, in Prolog you cannot nest loops. You cannot nest loops. It's hard to write a big non-dissected piece of code if you cannot nest loops. > perhaps the real problem is that nobody knows how to TEACH functional/logical programming right I agree with regards to logic programming. We need better free tutorials. I don't particularly like the linked one, it feels like it doesn't start at a beginner's level. I would be interested if anyone who didn't know any Prolog before has managed to learn Prolog from it.
chriswarbo 8y ago
No idea why you think functional programming can't do printf debugging. Even pure languages like Haskell have `unsafePerformIO` (or wrappers like https://hackage.haskell.org/package/base-4.11.1.0/docs/Debug-Trace.html https://hackage.haskell.org/package/base-4.11.1.0/docs/Debug... ). Also functional programming heavily encourages splitting up code into digestible chunks (they're called functions ;) )
- tabtab 8y ago
  I did not say "can't do". I essentially said "not as well". Of course "well" can be subjective, but if enough people don't like way a given language/tool does it, they will ignore it, like they have been with FP/logical programming for several decades. Somebody needs to articulate in careful unambiguous detail how and why it's "better" and "easier", not just repeatedly claim it. That writer apparently hasn't been born yet.
  - the_af 8y ago
    At least some of your assumptions are wrong: no-one is ignoring FP anymore.
    - tabtab 8y ago
      They don't have a choice: the latest languages force it on you by not giving better alternatives. For example, their stiff object models. For instance, why the heck can't one easily attach an on-click method to a Java button, instead forced to use silly lambdas? It would be more natural and simpler. Over-focus on FP damaged the OOP improvements/designs. Each generation seems to over-do something, and then the pendulum swings the other way.
      - the_af 8y ago
        I don't understand your example (and I don't understand why you consider lambdas silly), but more importantly: if most of the world -- by which I mean, modern language designers and practitioners -- seems to be going one direction, and you insist in staying put, aren't you at least a bit worried you might be wrong about it? "It" being the partial adoption of FP idioms and features in this case.
Koshkin 8y ago
> easier to debug Incidentally, my impression has been that the use of a declarative (or pure functional) language leads to spending drastically less (if any at all) time debugging. If your code makes sense (to you), it will work. Or, as an old adage goes, "If it compiles, it works."
- triska 8y ago
  I can confirm this impression. In my opinion, there are several reasons for this: First, many types of mistakes that are common when working with lower-level languages cannot occur at all when you use a declarative language. For example, with a logic programming language, you cannot accidentally double-free a pointer or write into unintended portions of memory. Second, when working with a high-level language, the code is much shorter than if you had used a lower-level language. This makes it easier to debug, and also easier to get right already in the first few tries. Third, once there is a mistake, it can be found in ways that fit the overall paradigm nicely. For example, in pure Prolog, if your predicate terminates and has a mistake, then it is either too specific or too general (or both), and you can debug both cases very systematically and even automatically, using built-in mechanisms of the language. Declarative debugging methods for Prolog were pioneered by Ehud Shapiro in his 1982 PhD thesis, Algorithmic Program Debugging: https://cpsc.yale.edu/sites/default/files/files/tr237.pdf https://cpsc.yale.edu/sites/default/files/files/tr237.pdf I also highly recommend Ulrich Neumerkel's teleteaching environment GUPU for systematically finding mistakes in Prolog programs: https://www.complang.tuwien.ac.at/ulrich/gupu/ https://www.complang.tuwien.ac.at/ulrich/gupu/
  - YeGoblynQueenne 8y ago
    You guys must come from another planet, because I spend 90% of my time coding in Prolog debugging my code. My code sure makes sense to me- but the interpreter frequently disagrees. Additionally, there are some constructs that are pretty damn hard to debug. For example- deeply-nested recursive loops with multiple clauses and free backtracking; you never know which clause you're in or how deep in the recursion. Well- you do but it demands a great deal of concentration. Or take my personal tracing nightmare- DCGs. At some point, you inevitably end up with something like this: _24234 = _12734 Then you have to squint up the trace to find the two variables to figure out what's going on.
YeGoblynQueenne 8y ago
Do you know about the four-port Prolog debugger, a.k.a. the Prolog tracer? If not, it's used to actually step through your code, one call at a time. You can set breakpoints and everything. Swi-Prolog even has a graphical interface for it (though I personally prefer the textual interface). Bottom line- yes, you can add print statements etc, but you can also directly debug your Prolog code just like you'd do for an imperative language.
the_af 8y ago
> procedural is just plain easier to debug because you can more easily split it into digestible and dissect-able chunks: divide-and-conquer. That's how you think and program in FP as well. Not just debugging, I mean: FP is all about divide and conquer. In fact, Wadler's seminal paper "Why Functional Programming Matters" [1] is all about what he calls modularity, i.e. splitting a problem in parts and then gluing it back together. [1] https://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.pdf https://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.p...
marcosdumay 8y ago
> you can more easily split it into digestible and dissect-able chunks: divide-and-conquer Eh... What? It's procedural code that can change anything anywhere and thus can not be easily separated into independent pieces.
lmm 8y ago
This is backwards. Debugging is much easier in a functional language because you already have your program division done for you, and immutability makes it much easier to understand what's going on since you can compare function inputs and outputs really easily, and e.g. if you ever accidentally step past the part you were interested in it's always safe to "drop frame" and step forward again, with the same behaviour, whereas if your program is mutating state then that state mutation has now happened and you can't ever debug it without restarting the whole thing.

by tabtab 8y ago

tom_mellior 8y ago

Prolog has print statements you can stick anywhere. (It also has proper debuggers that allow you to go forward and backward and all that.) Also, Prolog code is often "split into digestible chunks". Even more than other languages, in fact, because it's rather hard to write nested loops or nested predicates or nested many other things. If you were ever taught Prolog, it seems that you weren't taught well. You might want to risk a second look.

YeGoblynQueenne 8y ago
>> Also, Prolog code is often "split into digestible chunks". Even more than other languages, in fact, because it's rather hard to write nested loops or nested predicates or nested many other things. I find it very easy to write nested loops in Prolog: findall(A ,findall(B ,findall(D ,findall(...) ,G) ,E) ,C) To paraphrase the old saying, a good Python programmer can write Python in any language.
- tabtab 8y ago
  and correspondingly, a good Prolog programmer can write Prolog in any language. Limerick: "Some rascal wrote Pascal in Haskell."
  - YeGoblynQueenne 8y ago
    >> and correspondingly, a good Prolog programmer can write Prolog in any language. And a really good one can even write it in Prolog.
    - nickpsecurity 8y ago
      And on a Prolog CPU developed with Prolog... http://hps.ece.utexas.edu/pub/singhal_isca16.pdf http://hps.ece.utexas.edu/pub/singhal_isca16.pdf https://www.researchgate.net/publication/220760154_A_Prolog-Based_Hardware_Development_Environment https://www.researchgate.net/publication/220760154_A_Prolog-...

simion314 8y ago

I am curious if you used a visual debugger for prolog? (or for a procedural language) printing things to the console is the poor man debugger.

tabtab 8y ago
A big problem with visual debuggers is that they are too blunt of an instrument. Often I wish to examine specific things under specific conditions and thus use conditionals to narrow down what's being explored instead of bajillion breakpoints and/or log records. Debuggers could add conditional expressions, but then they'd be re-inventing WRITE statements anyhow. As far as the nearby statement that maybe I didn't learn dissection correctly, that may indeed be the case, but was also my original point: perhaps the real problem is that nobody knows how to TEACH functional/logical programming right, and that's why they have not caught on in the mainstream despite being around several decades. I'd love to "get" the benefits, but it just won't click. Sometimes you have to teach programmers how to think, not just what to think.
- tom_mellior 8y ago
  > Debuggers could add conditional expressions, but then they'd be re-inventing WRITE statements anyhow. SWI-Prolog's debugger can be invoked conditionally whenever you want from inside your running application. I've used it many times, and the code is simply: (Condition -> gtrace ; true) It's true that you could stick a write there, but you would have to think about what pieces of data you will need. Your mileage may vary. I've found this style a lot more useful than "traditional" debuggers where you set breakpoints beforehand and hope you hit them, as you say. > As far as the nearby statement that maybe I didn't learn dissection correctly, that may indeed be the case The point was more specifically that you didn't learn Prolog properly (or at all) and don't realize that it forces you to dissect your code. As I said, in Prolog you cannot nest loops. You cannot nest loops. It's hard to write a big non-dissected piece of code if you cannot nest loops. > perhaps the real problem is that nobody knows how to TEACH functional/logical programming right I agree with regards to logic programming. We need better free tutorials. I don't particularly like the linked one, it feels like it doesn't start at a beginner's level. I would be interested if anyone who didn't know any Prolog before has managed to learn Prolog from it.

chriswarbo 8y ago

No idea why you think functional programming can't do printf debugging. Even pure languages like Haskell have `unsafePerformIO` (or wrappers like https://hackage.haskell.org/package/base-4.11.1.0/docs/Debug-Trace.html https://hackage.haskell.org/package/base-4.11.1.0/docs/Debug... ). Also functional programming heavily encourages splitting up code into digestible chunks (they're called functions ;) )

tabtab 8y ago
I did not say "can't do". I essentially said "not as well". Of course "well" can be subjective, but if enough people don't like way a given language/tool does it, they will ignore it, like they have been with FP/logical programming for several decades. Somebody needs to articulate in careful unambiguous detail how and why it's "better" and "easier", not just repeatedly claim it. That writer apparently hasn't been born yet.
- the_af 8y ago
  At least some of your assumptions are wrong: no-one is ignoring FP anymore.
  - tabtab 8y ago
    They don't have a choice: the latest languages force it on you by not giving better alternatives. For example, their stiff object models. For instance, why the heck can't one easily attach an on-click method to a Java button, instead forced to use silly lambdas? It would be more natural and simpler. Over-focus on FP damaged the OOP improvements/designs. Each generation seems to over-do something, and then the pendulum swings the other way.
    - the_af 8y ago
      I don't understand your example (and I don't understand why you consider lambdas silly), but more importantly: if most of the world -- by which I mean, modern language designers and practitioners -- seems to be going one direction, and you insist in staying put, aren't you at least a bit worried you might be wrong about it? "It" being the partial adoption of FP idioms and features in this case.

Koshkin 8y ago

> easier to debug Incidentally, my impression has been that the use of a declarative (or pure functional) language leads to spending drastically less (if any at all) time debugging. If your code makes sense (to you), it will work. Or, as an old adage goes, "If it compiles, it works."

triska 8y ago
I can confirm this impression. In my opinion, there are several reasons for this: First, many types of mistakes that are common when working with lower-level languages cannot occur at all when you use a declarative language. For example, with a logic programming language, you cannot accidentally double-free a pointer or write into unintended portions of memory. Second, when working with a high-level language, the code is much shorter than if you had used a lower-level language. This makes it easier to debug, and also easier to get right already in the first few tries. Third, once there is a mistake, it can be found in ways that fit the overall paradigm nicely. For example, in pure Prolog, if your predicate terminates and has a mistake, then it is either too specific or too general (or both), and you can debug both cases very systematically and even automatically, using built-in mechanisms of the language. Declarative debugging methods for Prolog were pioneered by Ehud Shapiro in his 1982 PhD thesis, Algorithmic Program Debugging: https://cpsc.yale.edu/sites/default/files/files/tr237.pdf https://cpsc.yale.edu/sites/default/files/files/tr237.pdf I also highly recommend Ulrich Neumerkel's teleteaching environment GUPU for systematically finding mistakes in Prolog programs: https://www.complang.tuwien.ac.at/ulrich/gupu/ https://www.complang.tuwien.ac.at/ulrich/gupu/
- YeGoblynQueenne 8y ago
  You guys must come from another planet, because I spend 90% of my time coding in Prolog debugging my code. My code sure makes sense to me- but the interpreter frequently disagrees. Additionally, there are some constructs that are pretty damn hard to debug. For example- deeply-nested recursive loops with multiple clauses and free backtracking; you never know which clause you're in or how deep in the recursion. Well- you do but it demands a great deal of concentration. Or take my personal tracing nightmare- DCGs. At some point, you inevitably end up with something like this: _24234 = _12734 Then you have to squint up the trace to find the two variables to figure out what's going on.

YeGoblynQueenne 8y ago

Do you know about the four-port Prolog debugger, a.k.a. the Prolog tracer? If not, it's used to actually step through your code, one call at a time. You can set breakpoints and everything. Swi-Prolog even has a graphical interface for it (though I personally prefer the textual interface). Bottom line- yes, you can add print statements etc, but you can also directly debug your Prolog code just like you'd do for an imperative language.

the_af 8y ago

> procedural is just plain easier to debug because you can more easily split it into digestible and dissect-able chunks: divide-and-conquer. That's how you think and program in FP as well. Not just debugging, I mean: FP is all about divide and conquer. In fact, Wadler's seminal paper "Why Functional Programming Matters" [1] is all about what he calls modularity, i.e. splitting a problem in parts and then gluing it back together. [1] https://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.pdf https://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.p...

marcosdumay 8y ago

> you can more easily split it into digestible and dissect-able chunks: divide-and-conquer Eh... What? It's procedural code that can change anything anywhere and thus can not be easily separated into independent pieces.

lmm 8y ago

This is backwards. Debugging is much easier in a functional language because you already have your program division done for you, and immutability makes it much easier to understand what's going on since you can compare function inputs and outputs really easily, and e.g. if you ever accidentally step past the part you were interested in it's always safe to "drop frame" and step forward again, with the same behaviour, whereas if your program is mutating state then that state mutation has now happened and you can't ever debug it without restarting the whole thing.