I'll bet a choklate bar that 100% of all developers who spent 6 year using Haskell knows what a for-loop is.

"for" is not that complicated, it's just mapM with its arguments pre-flipped: http://hackage.haskell.org/package/base-4.12.0.0/docs/Contro...

I don't know why you want to call that a "loop", but, sure, you do you, you crazy imperative programmers.

Because it is a loop in any sane language ... you overheaded functional programmers ..

edit: Sigh. I was jockingly mocking.

Haskell just enforces iteration through recursion.

How did he solve the iteration problem? A for loop is just syntactic sugar for a while loop.

I doubt there are many Haskell developers (or one at all) without a academic background ..

I'm a self-taught developer with haskell in my arsenal, although that being said I have an MSc in theoretical physics which probably helps me appreciate the power of its paradigm.

So you do have a academic background (especially math)..

Hi. Not an academic. Currently fiddling around with OpenGL on Haskell, for reasons.

There definitely are! Eg Jezen Thomas. Hopefully in the future also myself :)

You are sure he was never at a university? And why are you drawn to Haskell? For me I only had to deal with it a bit at university and I found the concept interesting, but could not imagine non math people to use it for anything as a language of choice

I'm not sure he never was at university, I just assume not [1].

> why are you drawn to Haskell?

I just want my programs to work. I've seen too many null pointer exceptions and other runtime errors. Runtime errors = bad. Compile errors = good.

[1]: https://news.ycombinator.com/item?id=20112065

"I just want my programs to work"

Me too ...

And I think imperative languages are way more easy and clear to read and write.

I allways imagined that you have to be a math nerd to prefer Haskell, but apparently this guy is not a math guy, but loves Haskell .. so ok, good counterpoint.

> And I think imperative languages are way more easy and clear to read and write.

Because it's what you've had exposure to. Perhaps, they're even objectively easier to read and write, I don't know. It's also completely besides my point.

My point was that I want my programs to work as desired. That's orthogonal to how easy it is to read and write. I don't want runtime exceptions where I could've gotten a compile-time error.

But I had exposure to math functions much earlier. And I never liked their syntax. I did understood the math, but the math language made it harder for me.

And null pointer exceptions? They only happen to me very rarely, when I quickly hack something together and then it is a "oh forgot - and fixed" problem. The problems I do struggle with are non reproducable race condition fun etc. and I doubt haskell could help me with them. Or I struggle, because I do not really understand my problem, or a certain libary ... or, because I misunderstood existing code.

So how on earth are correct programms orthogonal to how easy it is to read and write them?!? Did you ever had to use someone else code? Or your own that you wrote 5 years ago (or sometimes 5 days)?

With any bigger project it is all about how easy it is to read and write them.

> And null pointer exceptions? They only happen to me very rarely, when I quickly hack something together and then it is a "oh forgot - and fixed" problem.

And you never run into NPEs in production? It's something you always discover during development? How?

> The problems I do struggle with are non reproducable race condition fun etc. and I doubt haskell could help me with them.

In a pure system, thread race conditions are impossible. You can still get race conditions for your external effects, which is unavoidable.

Ouch.