4 ms·

The difference being that if you expend the effort you can write a heterogenous collection that does is guaranteed to run for any input, whereas with Lisp or Py

The difference being that if you expend the effort you can write a heterogenous collection that does is guaranteed to run for any input, whereas with Lisp or Python you must be very very careful about that because one false step and your program will blow up.

kazinator 12y ago
This doesn't jive with the observation that some Lisp programmers stay in the same REPL for weeks while experimenting with all kinds of new or undebugged code.
- AnimalMuppet 12y ago
  And it probably blows up on them somewhat often. That is, the code blows up - the REPL doesn't. Also, the REPL tells them why it blew up. So I don't think your observation answers the GP's point at all.
  - kazinator 12y ago
    So by "blow up", you don't literally mean "explode", like BSOD, hard lock up, "Segmentation Fault (core dumped)", etc. There was some computation which produced a wrong result, which was detected, handled and diagnosed. In what development tool does this never happen?
- dasil003 12y ago
  You are utterly missing the point. Of course any code that can be written in a type-safe manner in Haskell can be written in another language to perform the exact some machine operations. The point is that the compiler guarantees that this code will never break as long as the code compiles. In less type-safe languages you simply don't have these guarantees, no matter how careful you are, eventually someone will come along and break an assumption that kept the original code working.
  - kazinator 12y ago
    "Code will never break if it compiles?" So just compile and ship; no testing?
    - dasil003 12y ago
      I'm talking about maintenance, obviously you must make sure the code does the correct thing initially. I have maintained a 100k LOC Rails app for 7 years with near 100% test coverage. And guess what? Stuff breaks. 99% of the stupid breakages I have experienced would have been impossible in Haskell. What's the longest you've maintained something?
  - dragonwriter 12y ago
    > The point is that the compiler guarantees that this code will never break as long as the code compiles. A program that compiles in Haskell can still break, consider: main = do print $ head []
    - yawaramin 12y ago
      You shouldn't consider this to be a break. Sure, it's crappy API design--lots of people have pointed out that `head` should return a `Maybe` because an empty list doesn't have a head--but triggering an error in a partial function is not a break. Taking the head of an empty list is no more a break than dividing something by zero.
      - dragonwriter 12y ago
        > You shouldn't consider this to be a break. I can't see any reasonable definition of "break" for this context for which that is valid; its exactly the same kind of breakage that strong type checking reduces the incidence of in Haskell compared to dynamic languages -- runtime errors resulting from a function call not being able to complete without error for all inputs that the language will allow to be passed to it. > Taking the head of an empty list is no more a break than dividing something by zero. I agree; both are clearly examples of things that can cause a program to break.

kazinator 12y ago

This doesn't jive with the observation that some Lisp programmers stay in the same REPL for weeks while experimenting with all kinds of new or undebugged code.

AnimalMuppet 12y ago
And it probably blows up on them somewhat often. That is, the code blows up - the REPL doesn't. Also, the REPL tells them why it blew up. So I don't think your observation answers the GP's point at all.
- kazinator 12y ago
  So by "blow up", you don't literally mean "explode", like BSOD, hard lock up, "Segmentation Fault (core dumped)", etc. There was some computation which produced a wrong result, which was detected, handled and diagnosed. In what development tool does this never happen?
dasil003 12y ago
You are utterly missing the point. Of course any code that can be written in a type-safe manner in Haskell can be written in another language to perform the exact some machine operations. The point is that the compiler guarantees that this code will never break as long as the code compiles. In less type-safe languages you simply don't have these guarantees, no matter how careful you are, eventually someone will come along and break an assumption that kept the original code working.
- kazinator 12y ago
  "Code will never break if it compiles?" So just compile and ship; no testing?
  - dasil003 12y ago
    I'm talking about maintenance, obviously you must make sure the code does the correct thing initially. I have maintained a 100k LOC Rails app for 7 years with near 100% test coverage. And guess what? Stuff breaks. 99% of the stupid breakages I have experienced would have been impossible in Haskell. What's the longest you've maintained something?
- dragonwriter 12y ago
  > The point is that the compiler guarantees that this code will never break as long as the code compiles. A program that compiles in Haskell can still break, consider: main = do print $ head []
  - yawaramin 12y ago
    You shouldn't consider this to be a break. Sure, it's crappy API design--lots of people have pointed out that `head` should return a `Maybe` because an empty list doesn't have a head--but triggering an error in a partial function is not a break. Taking the head of an empty list is no more a break than dividing something by zero.
    - dragonwriter 12y ago
      > You shouldn't consider this to be a break. I can't see any reasonable definition of "break" for this context for which that is valid; its exactly the same kind of breakage that strong type checking reduces the incidence of in Haskell compared to dynamic languages -- runtime errors resulting from a function call not being able to complete without error for all inputs that the language will allow to be passed to it. > Taking the head of an empty list is no more a break than dividing something by zero. I agree; both are clearly examples of things that can cause a program to break.