Maybe they're was using Coffeescript with jQuery, and jQuery has some built in looping functions like .each that don't exactly look like a for loop.

A Haskell developer?

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.

Any functional language, pretty much.

They use enumeration (list/array traversal) to process a list/array of inputs.

And it entirely makes impossible the off-by-one error.

I am happy if I never have to see a for-loop again. (Even in JS, I use iteration/enumeration constructs as much as possible.)

I find it hard to believe a beginner with no theoretical CS background would pick up a functional language first. So the question still stands.

How strange. Why would you find it hard to believe?

It is one of several programming paradigms, after all. Am I missing something?

The "advanced intro CS" class at Cornell (CS 212, at least at the time) used Scheme.

Maybe I should become a high school CS teacher, because I would not curse anyone with a procedural language.

The parent said they didn't know what for-in was, which implies they were using a language like C for their side projects which only has for (i=0;i<n;i++) loops.

You can google that in 2 seconds. A CS degree isn't going to help you there if you have not covered a language that uses iterators.

Any self-respecting computer science degree education should cover at least one language that has iterators or enhanced enumeration.

My CS degree (2002-2006) did not explicitly cover "for x in y" iterators. But it did cover an understanding of algorithms and data structures well enough that I could implement one.

Which is better? YMMV.

That was probably before they were really in style e.g. C# didn't add foreach / iterators until ~2005 with v2.0 and your curriculum probably lags a bit behind the industry state-of-the-art unless it was Ivy league

It has not been very long since CS degrees were taught entirely in C89 or C++98, and there are a lot of us who won't touch Python or Java unless forced to.

exactly - I had a similar learning curve (and no CS degree) where I could never remember what certain methods did but I knew exactly what to google for the answer

That or they only used `while` (and friends if available in the language) loops.

Sounds like you didn't read the parent post carefully? He wrote:

> I didn't know how to write a for loop

If