[kachnuv_ocasek]

I agree with this. If it's not natural for you to think ahead, create the structure you need before writing it up, Haskell is not the right language for you. It's good there are languages that fit your needs, nonetheless.

[lelf]

> If it's not natural for you to think ahead, create the structure you need before writing it up, Haskell is not the right language for you.

No, Haskell is probably even more fit here. Haskell is a godsend for prototyping! Because you throw any crap into the editor and with Haskell you'll know immediately what's wrong with said crap. And then when you refactor it later the compiler will guide and help you.

I feel like people just haven't got balls to see many compilation errors and prefer buggy, non-working, but “see! no errors, not like in those haskells!” code.

[dang]

> I feel like people just haven't got balls

Please don't inject such language into technical discussions on Hacker News. The last thing we want is to swerve into low-quality flamewars.

Orangeduck, reikonomusha and others have posted fine comments in this thread. If they're wrong, the thing to do is show, not tell, that they're wrong. Then disagreement will make the discussion better instead of worse.

[the_af]

I think part of the problem is that buggy code that compiles produces instant gratification. You see results, even if incomplete. Maybe down the road you'll reach a dead-end due to a problem you didn't foresee, and the buggy code didn't help you find it because it compiled anyway, and you didn't have to think too hard about all cases or about the structure of the problem. And then it may be too late and you'll have to throw everything away and start from scratch.

But in the meantime, you get the feeling you're making progress, even if you're not. I think that's the psychology of the matter.

I'm a Haskell fan (and still a newbie, unfortunately) and I sometimes fall prey to this feeling.

[freyrs3]

There's a lot of study in psychology about how our mental models of our future selves result in the choices in we make in the present. I know quantifiably from having worked in a both ML family languages and the popular dynamic scripting languages that the amortized time I spend debugging the software is far less with the ML-style languages. Yet with the scripting languages there's definitely a psychological appeal of seeing something appear to "work" ( it really doesn't ) and then debugging it into existence, although the engineer in me knows that this is a really bad way to develop solid software in the long run.

[seanmcdirmid]

So perhaps rapid prototyping and exploration should be done in a worse-is-better language like Python, then when the elegant structure is thought of, the code can be recast in Haskell?

Do you think to program or program to think? It seems like Haskell is biased to the former.

[SkyMarshal]

It's not uncommon for C++ programmers to first prototype in a simpler language like Python, figure out the structure, then reimplement in C++ for performance. No reason that can't be a thing with Haskell too.