5 ms·

"In Haskell we think for quite a long time before starting typing"

64 points by fogus 16y ago

tomjen3 16y ago
That's no doubt true, but that can only get you so far. If you have to work with some buggy system over which you have little or no control, which is often the case, you are limited in how much you can think ahead. The more bugs in the system, the shorter you can think ahead. This may be why so many Haskell examples are math-centric: it allows you to look the farthest into the distance.
- locopati 16y ago
  Am I the only one who finds that diving in and exploring-through-doing is the best way to avoid thought-paralysis?
  - mhd 16y ago
    Which is why you wait for a long time until you introduce types. (Assuming that the pun was intended)
  - stcredzero 16y ago
    Yes, you can dive in and explore-through-doing as a precursor to actually your actual coding. In good Smalltalk environments, the best way to read (and write) code is often in your debugger. This way, you add some empiricism to double check your reading comprehension. Doing iPhone development in XCode, I find it's best to try out code with lots of NSLog statements and a breakpoint in the new routine, so I can explore what's happening at runtime. (The NSLog statements are mainly to get around annoying quirks in the inspectors when you have really long Strings.) This is probably just my taking my Smalltalk habits and trying to do analogous things in XCode/Objective-C.
- ericlavigne 16y ago
  It looks like you started with some important points, and then let them lead you to the most unproductive possible conclusion. > The more bugs in the system, the shorter you can think ahead. Very true. Too many bugs prevent me from thinking ahead, forcing me to program very slowly by trial-and-error. > If you have to work with some buggy system over which you have little or no control, which is often the case, you are limited in how much you can think ahead. There are many buggy systems over which I have little or no control. I often, however, can decide not to work with such systems in the first place. Since such buggy systems have so much effect on my productivity, it is worth putting a lot of effort into avoiding them. > This may be why so many Haskell examples are math-centric: it allows you to look the farthest into the distance. It may also explain why Haskell has so much built-in error checking, why Haskell programmers have been pioneers with respect to new testing strategies (Quickcheck), and why Haskell programmers try to separate `pure` and `impure` code so that as much of their program as possible can be math-centric. They are trying to spend as little time as possible with buggy code that slows them down. > That's no doubt true, but that can only get you so far Thinking ahead is great only under ideal conditions, as you pointed out. If you accept whatever conditions are there, thinking ahead can only get you so far. Taking responsibility for such conditions, and trying to change them, can get you much farther. -------------- I actually don't use Haskell very much, but Clojure has a lot of similarities. Like Haskell, Clojure has a lot of support for abstraction and allows you to do a lot with very little code. Perhaps even more importantly, Clojure libraries tend to be simpler, easier to understand, and less buggy than their Java counterparts.
- rtperson 16y ago
  I always thought that Haskell programmers provided so many math-centric examples because the language provides one of the cleanest mappings of math to code available in any language. You might as well code to the language's greatest strength. I'm curious as to what you have in mind as a credible example in Haskell of a "buggy system over which you have little or no control." Haskell is such a marginal little language right now that it hasn't attracted the same level of programmer mediocrity as, say, Java has. Also, the typing system tends to all but eliminate common errors in other languages -- your segfaults and NPEs and buffer overflows. Haskell tends to front-load the pain of development. If your code compiles, you can reasonably expect that any bugs in the code are due faults in your own reasoning rather than failing to accommodate some unplanned-for side-effect (like the uninitialized pointer in C). And unless you've made the mistake of locking up all your logic within the IO monad, finding and correcting these faults tends to be more straightforward, thanks to the math-like syntax. My experience with Haskell is that, as hard a language as it is to learn, it is remarkably easy, once learned, to think in.
  - stcredzero 16y ago
    common errors in other languages -- your segfaults and NPEs and buffer overflows I never see those in Smalltalk. I'd be surprised if that's an issue in Python, Ruby, or Lisp. (But the number of DoesNotUnderstand errors in Smalltalk is quite impressive. This is why XUnit unit testing was first developed in Smalltalk. Unit testing with good code coverage is the only way to reliably prevent those.)
    - rtperson 16y ago
      > I'd be surprised if that's an issue in Python, Ruby, or Lisp. I'd be very surprised if there weren't similar issues in these languages, since these are all duck-typed and the topic at hand is "bugs prevented by rigorous up-front type checking." I don't have extensive experience in any of the above, so I couldn't include any examples of errors they are prone to.
      - chc 16y ago
chanux 16y ago
That made me want to read a bit more about comments. http://www.gavilan.edu/csis/languages/comments.html#_Toc53710127 http://www.gavilan.edu/csis/languages/comments.html#_Toc5371...
yurifury 16y ago
Is this a pun on Haskell's strong static types? :)
jbooth 16y ago
A) It's kind of presumptuous to show up in an esoteric lisp community and ask them to adopt C-style comments for your sake. B) "We think for a while before typing" is the worst excuse ever for a hard-to-type construct. Why not just make it easy? Especially for comments. Make bad code hard to type.
- spooneybarger 16y ago
  "A) It's kind of presumptuous to show up in an esoteric lisp community and ask them to adopt C-style comments for your sake." haskell isn't a lisp.
  - jbooth 16y ago
    I'm not sure whether to make the haskell strongly-typed joke or the functional programming snob joke :)
    - bartonfink 16y ago
      Just let lazy evaluation deal with the problem.
- aplusbi 16y ago
  I read "We think for a while before typing" to be a snide remark as in, "Think about your feature request for awhile before typing it up."
- loup-vaillant 16y ago
  A) Agree, especially since we have syntax highlighting. B) Agree. I have a better excuse: "not everyone uses Qwerty". In my keyboard, for instance "-" is very accessible, and "/" a tiny bit less so.
mathgladiator 16y ago
did anyone else get a double meaning of typing? I was thinking: well, of course you have to think, you have types! You have to align the universe to a representation which is no easy feat.
aristidb 16y ago
On my German keyboard, -- is actually easier to type than //.
- jpr 16y ago
  Ditto for my Finnish keyboard.
- FrankenTan 16y ago
  And on my Swedish keyboard. It's right next to . and I don't need to hold in shift to type it. I even need to press shift+7 to write /, so I'd actually prefer --.
lsb 16y ago
Encoding system information into a string should be a last resort. That's why a good type system, where you can encode EscapedString [Char] versus UnescapedString [Char] as strings of different types, where you have to work hard to do a safe-to-unsafe cast, that good type system is vastly better than prepending esc and unesc to variable names, and hoping that you don't mess up. Making commenting easy is like spending a lot on orphanages; good in the short term, but causes problems in the long term. You want to document as much of your intent in code as you can, and Haskell makes that easier than, say, assembler.
baguasquirrel 16y ago
I used to have to think a great deal before typing, with Haskell and ML. Nowadays, I should think a great deal, but the thinking goes on at a higher level in the design than I'm used to. Of course, I could be prototyping. But the point is, there is light at the end of the tunnel. No one told me about that. These were languages that were supposed to discourage wild hacking. And they do. But that doesn't keep you from prototyping, or alternately, writing bad APIs.
djcapelis 16y ago
I was wondering how the waterfall model would be justified when the pendulum started to swing back from manic styles like XP and TDD. The idea that you can't play around with your code and experiment with it right away before thinking too hard is just silly. Many of the nice points about functional languages are precisely that iteration time can be really low. A dev should smack this person for messing with the bugtracker of a project that should be better than this.
- MrMan 16y ago
  bzflag!!!! This is like seeing someone you kind of know at an airport far away from home. please forgive the off-topic post.

64 points by fogus 16y ago

That's no doubt true, but that can only get you so far. If you have to work with some buggy system over which you have little or no control, which is often the case, you are limited in how much you can think ahead. The more bugs in the system, the shorter you can think ahead. This may be why so many Haskell examples are math-centric: it allows you to look the farthest into the distance.

locopati 16y ago
Am I the only one who finds that diving in and exploring-through-doing is the best way to avoid thought-paralysis?
- mhd 16y ago
  Which is why you wait for a long time until you introduce types. (Assuming that the pun was intended)
- stcredzero 16y ago
  Yes, you can dive in and explore-through-doing as a precursor to actually your actual coding. In good Smalltalk environments, the best way to read (and write) code is often in your debugger. This way, you add some empiricism to double check your reading comprehension. Doing iPhone development in XCode, I find it's best to try out code with lots of NSLog statements and a breakpoint in the new routine, so I can explore what's happening at runtime. (The NSLog statements are mainly to get around annoying quirks in the inspectors when you have really long Strings.) This is probably just my taking my Smalltalk habits and trying to do analogous things in XCode/Objective-C.
ericlavigne 16y ago
It looks like you started with some important points, and then let them lead you to the most unproductive possible conclusion. > The more bugs in the system, the shorter you can think ahead. Very true. Too many bugs prevent me from thinking ahead, forcing me to program very slowly by trial-and-error. > If you have to work with some buggy system over which you have little or no control, which is often the case, you are limited in how much you can think ahead. There are many buggy systems over which I have little or no control. I often, however, can decide not to work with such systems in the first place. Since such buggy systems have so much effect on my productivity, it is worth putting a lot of effort into avoiding them. > This may be why so many Haskell examples are math-centric: it allows you to look the farthest into the distance. It may also explain why Haskell has so much built-in error checking, why Haskell programmers have been pioneers with respect to new testing strategies (Quickcheck), and why Haskell programmers try to separate `pure` and `impure` code so that as much of their program as possible can be math-centric. They are trying to spend as little time as possible with buggy code that slows them down. > That's no doubt true, but that can only get you so far Thinking ahead is great only under ideal conditions, as you pointed out. If you accept whatever conditions are there, thinking ahead can only get you so far. Taking responsibility for such conditions, and trying to change them, can get you much farther. -------------- I actually don't use Haskell very much, but Clojure has a lot of similarities. Like Haskell, Clojure has a lot of support for abstraction and allows you to do a lot with very little code. Perhaps even more importantly, Clojure libraries tend to be simpler, easier to understand, and less buggy than their Java counterparts.
rtperson 16y ago
I always thought that Haskell programmers provided so many math-centric examples because the language provides one of the cleanest mappings of math to code available in any language. You might as well code to the language's greatest strength. I'm curious as to what you have in mind as a credible example in Haskell of a "buggy system over which you have little or no control." Haskell is such a marginal little language right now that it hasn't attracted the same level of programmer mediocrity as, say, Java has. Also, the typing system tends to all but eliminate common errors in other languages -- your segfaults and NPEs and buffer overflows. Haskell tends to front-load the pain of development. If your code compiles, you can reasonably expect that any bugs in the code are due faults in your own reasoning rather than failing to accommodate some unplanned-for side-effect (like the uninitialized pointer in C). And unless you've made the mistake of locking up all your logic within the IO monad, finding and correcting these faults tends to be more straightforward, thanks to the math-like syntax. My experience with Haskell is that, as hard a language as it is to learn, it is remarkably easy, once learned, to think in.
- stcredzero 16y ago
  common errors in other languages -- your segfaults and NPEs and buffer overflows I never see those in Smalltalk. I'd be surprised if that's an issue in Python, Ruby, or Lisp. (But the number of DoesNotUnderstand errors in Smalltalk is quite impressive. This is why XUnit unit testing was first developed in Smalltalk. Unit testing with good code coverage is the only way to reliably prevent those.)
  - rtperson 16y ago
    > I'd be surprised if that's an issue in Python, Ruby, or Lisp. I'd be very surprised if there weren't similar issues in these languages, since these are all duck-typed and the topic at hand is "bugs prevented by rigorous up-front type checking." I don't have extensive experience in any of the above, so I couldn't include any examples of errors they are prone to.
    - chc 16y ago

chanux 16y ago

That made me want to read a bit more about comments. http://www.gavilan.edu/csis/languages/comments.html#_Toc53710127 http://www.gavilan.edu/csis/languages/comments.html#_Toc5371...

yurifury 16y ago

Is this a pun on Haskell's strong static types? :)

jbooth 16y ago

A) It's kind of presumptuous to show up in an esoteric lisp community and ask them to adopt C-style comments for your sake. B) "We think for a while before typing" is the worst excuse ever for a hard-to-type construct. Why not just make it easy? Especially for comments. Make bad code hard to type.

spooneybarger 16y ago
"A) It's kind of presumptuous to show up in an esoteric lisp community and ask them to adopt C-style comments for your sake." haskell isn't a lisp.
- jbooth 16y ago
  I'm not sure whether to make the haskell strongly-typed joke or the functional programming snob joke :)
  - bartonfink 16y ago
    Just let lazy evaluation deal with the problem.
aplusbi 16y ago
I read "We think for a while before typing" to be a snide remark as in, "Think about your feature request for awhile before typing it up."
loup-vaillant 16y ago
A) Agree, especially since we have syntax highlighting. B) Agree. I have a better excuse: "not everyone uses Qwerty". In my keyboard, for instance "-" is very accessible, and "/" a tiny bit less so.

mathgladiator 16y ago

did anyone else get a double meaning of typing? I was thinking: well, of course you have to think, you have types! You have to align the universe to a representation which is no easy feat.

aristidb 16y ago

On my German keyboard, -- is actually easier to type than //.

jpr 16y ago
Ditto for my Finnish keyboard.
FrankenTan 16y ago
And on my Swedish keyboard. It's right next to . and I don't need to hold in shift to type it. I even need to press shift+7 to write /, so I'd actually prefer --.

lsb 16y ago

Encoding system information into a string should be a last resort. That's why a good type system, where you can encode EscapedString [Char] versus UnescapedString [Char] as strings of different types, where you have to work hard to do a safe-to-unsafe cast, that good type system is vastly better than prepending esc and unesc to variable names, and hoping that you don't mess up. Making commenting easy is like spending a lot on orphanages; good in the short term, but causes problems in the long term. You want to document as much of your intent in code as you can, and Haskell makes that easier than, say, assembler.

baguasquirrel 16y ago

I used to have to think a great deal before typing, with Haskell and ML. Nowadays, I should think a great deal, but the thinking goes on at a higher level in the design than I'm used to. Of course, I could be prototyping. But the point is, there is light at the end of the tunnel. No one told me about that. These were languages that were supposed to discourage wild hacking. And they do. But that doesn't keep you from prototyping, or alternately, writing bad APIs.

djcapelis 16y ago

I was wondering how the waterfall model would be justified when the pendulum started to swing back from manic styles like XP and TDD. The idea that you can't play around with your code and experiment with it right away before thinking too hard is just silly. Many of the nice points about functional languages are precisely that iteration time can be really low. A dev should smack this person for messing with the bugtracker of a project that should be better than this.

MrMan 16y ago
bzflag!!!! This is like seeing someone you kind of know at an airport far away from home. please forgive the off-topic post.