5 ms·

My thoughts exactly, but I'd add this: I love and respect Lisp; I've written my fair share of it. There is absolutely nothing inherently magical in Lisp that pr

My thoughts exactly, but I'd add this: I love and respect Lisp; I've written my fair share of it. There is absolutely nothing inherently magical in Lisp that prevent you from introducing bugs. You can just as easily make a logic error in your code that results in a bug. Bugs happen. Bugs will happen. There is no silver bullet. The only way to reduce bugs is to test thoroughly. tl;dr: nice cartoon, "lisp means no bugs" == total BS, bugs can totally exist in Lisp code

S4M 14y ago
Yeah, I think the link posted here is doing little to make lisp popular, especially compared for example to a nice tutorial like the Seesaw example one to build GUIs in Clojure [0]. There, you can see how interactive Clojure is, and how fast it can be to develop stuff. Note that I took this example because it's on the top of my mind, but I am sure similar proves of interactivity can be made for other lisps. [0] https://gist.github.com/1441520 https://gist.github.com/1441520
- king_magic 14y ago
  Holy crap, Seesaw looks awesome! See, that's far more powerful - I had no idea that even existed, and now I'm excited to play around with it. This is great! I don't need a cartoon to sell me on something. I need to see how something can be used.
- disgruntledphd2 14y ago
  Thank you so much for that link!. I'd been meaning to check out Seesaw, and it really lives up to its promise of making Java GUI's less painful.
jeffdavis 14y ago
"The only way to reduce bugs is to test thoroughly." That is false.
- king_magic 14y ago
  No, it's not false, but I'll rephrase it to illustrate my point: "the only economically practical way to reduce bugs is to test thoroughly, unless you're NASA or you have some magnificent budget that somehow lets you hire people who can mathematically prove your code is bug free". I am aware that you can prove code is correct, from a math POV. That's about the only way you can write "bug free" code without extensive testing, and even then, I'd argue that's not good enough - code needs to be tested. Bugs don't exist just in code. They exist in CPUs. They exist in configuration. They exist in dependency version mishaps that somehow make your code work incorrectly. There is no silver bullet here. Sorry - there just isn't.
  - jeffdavis 14y ago
    I think what you mean is "any efficient engineering process will make good use of testing". But if you already have some tests in place, the most efficient way to reduce bugs is often something other than more testing, e.g. code review, design review/improvements, or static analysis (often provided by the language/compiler). All of those other methods can and will reduce bugs. So your statement that testing is the only way is obviously false in both a practical and theoretical sense.
    - king_magic 14y ago
      I see your point. Fair enough :) Though I'd argue those other methods really boil down to testing. Code review is a peer "test" of code. Design review is a peer test.
  - andolanra 14y ago
    Type systems are, in essence, automated mathematical theorem provers designed to prevent certain classes of bugs.[1] The functional style is also a bug-reducer in that you can reason more accurately about the state of your program, because you have limited state-changing code to particular places. Certain language features like Lisp's restarts or garbage collection are bug-reducing because they give you concise ways of expressing features you might otherwise have had to implement by hand, and every line of code you write is another line for a bug to hide in. Yes, testing is invaluable and should not be omitted. No, none of these are silver bullets that eliminate the need for testing. But it is false to say that "...the only economically practical way to reduce bugs is to test thoroughly." There are many ways to reduce bugs that can help alongside testing. [1]: If you've only ever used C++ or Java, this sounds hilariously weak, but in languages like the ML, the type system prevents null pointer exceptions, and in Haskell, the type system goes further and separates effectful and non-effectful code to ensure you don't cause side effects where you don't expect. Even more powerful are languages like ATS, which give you compile-time type errors when you've forgotten to allocate space for a null terminator for strings.

S4M 14y ago

Yeah, I think the link posted here is doing little to make lisp popular, especially compared for example to a nice tutorial like the Seesaw example one to build GUIs in Clojure [0]. There, you can see how interactive Clojure is, and how fast it can be to develop stuff. Note that I took this example because it's on the top of my mind, but I am sure similar proves of interactivity can be made for other lisps. [0] https://gist.github.com/1441520 https://gist.github.com/1441520

king_magic 14y ago
Holy crap, Seesaw looks awesome! See, that's far more powerful - I had no idea that even existed, and now I'm excited to play around with it. This is great! I don't need a cartoon to sell me on something. I need to see how something can be used.
disgruntledphd2 14y ago
Thank you so much for that link!. I'd been meaning to check out Seesaw, and it really lives up to its promise of making Java GUI's less painful.

jeffdavis 14y ago

"The only way to reduce bugs is to test thoroughly." That is false.

king_magic 14y ago
No, it's not false, but I'll rephrase it to illustrate my point: "the only economically practical way to reduce bugs is to test thoroughly, unless you're NASA or you have some magnificent budget that somehow lets you hire people who can mathematically prove your code is bug free". I am aware that you can prove code is correct, from a math POV. That's about the only way you can write "bug free" code without extensive testing, and even then, I'd argue that's not good enough - code needs to be tested. Bugs don't exist just in code. They exist in CPUs. They exist in configuration. They exist in dependency version mishaps that somehow make your code work incorrectly. There is no silver bullet here. Sorry - there just isn't.
- jeffdavis 14y ago
  I think what you mean is "any efficient engineering process will make good use of testing". But if you already have some tests in place, the most efficient way to reduce bugs is often something other than more testing, e.g. code review, design review/improvements, or static analysis (often provided by the language/compiler). All of those other methods can and will reduce bugs. So your statement that testing is the only way is obviously false in both a practical and theoretical sense.
  - king_magic 14y ago
    I see your point. Fair enough :) Though I'd argue those other methods really boil down to testing. Code review is a peer "test" of code. Design review is a peer test.
- andolanra 14y ago
  Type systems are, in essence, automated mathematical theorem provers designed to prevent certain classes of bugs.[1] The functional style is also a bug-reducer in that you can reason more accurately about the state of your program, because you have limited state-changing code to particular places. Certain language features like Lisp's restarts or garbage collection are bug-reducing because they give you concise ways of expressing features you might otherwise have had to implement by hand, and every line of code you write is another line for a bug to hide in. Yes, testing is invaluable and should not be omitted. No, none of these are silver bullets that eliminate the need for testing. But it is false to say that "...the only economically practical way to reduce bugs is to test thoroughly." There are many ways to reduce bugs that can help alongside testing. [1]: If you've only ever used C++ or Java, this sounds hilariously weak, but in languages like the ML, the type system prevents null pointer exceptions, and in Haskell, the type system goes further and separates effectful and non-effectful code to ensure you don't cause side effects where you don't expect. Even more powerful are languages like ATS, which give you compile-time type errors when you've forgotten to allocate space for a null terminator for strings.