
"In Haskell we think for quite a long time before starting typing" - fogus
http://hackage.haskell.org/trac/ghc/ticket/4864#comment:1
======
jbooth
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
"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
I'm not sure whether to make the haskell strongly-typed joke or the functional
programming snob joke :)

~~~
bartonfink
Just let lazy evaluation deal with the problem.

------
djcapelis
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
bzflag!!!! This is like seeing someone you kind of know at an airport far away
from home. please forgive the off-topic post.

------
mathgladiator
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.

------
chanux
That made me want to read a bit more about comments.

[http://www.gavilan.edu/csis/languages/comments.html#_Toc5371...](http://www.gavilan.edu/csis/languages/comments.html#_Toc53710127)

------
lsb
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.

------
tomjen3
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.

~~~
rtperson
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
_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
> 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
Ruby's method_missing, the equivalent of Smalltalk's doesNotUnderstand:, is a
plague on Ruby programmers. It might mean something returned nil, it might
mean the wrong type got passed or returned, it might just mean that you forgot
to include a module — but you will run into them more times than you can count
while you're developing a Ruby app. (Or at least I will. I don't know. Maybe
everybody else has better luck with their libraries or is just more studious
than I am.)

~~~
stcredzero
Do you have unit tests with good code coverage?

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

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

~~~
FrankenTan
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 --.

------
baguasquirrel
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.

