Does anyone else think that none of this is really that important? Really, not having to name a function and using it inline is an important feature, compared to defining it just before? And map is a lot more powerful than a for loop? I get the argument that its a nice to have, but does it justify a post called "can your language do this"? Really?

This article proved to be right - now all mainstream languages have some kind of lambda functionality.

What’s next? My predictions are:

- expression orientated

- algebraic effects

Further along: affine types, refinement types, formally verified preconditions/postconditions, maybe even dependent types.

Automatic theorem provers are stuck in AI winter. Pre/post-conditions and dependent types currently need too much handholding. Once the AI firms deign to release heuristic language models for proof discovery, we can have nice things like that.

> In fact, if you have two CPUs handy, maybe you could write some code to have each CPU do half of the elements, and suddenly map is twice as fast.

I remember this came up a lot in late-aughts functional programming discussions. But is there any language where this actually works? Where map is just parallel because of course it is?

F# defines a parallel map with the same type signature as sequential map, but you have to ask for Array.Parallel.map rather than Array.map or whatever, because of the possibility of side effects. Only in a pure language like Haskell could you safely parallelize automatically. I'm not sure why Haskell doesn't - maybe overhead?

I think it's pretty much impossible to tell statically whether you're going to be drowning in overhead spinning up a thread for every pixel on the screen, or leaving tons of parallelism on the table. Maybe with PGO it can be made to work. Even if it could be automatic, parallelism can be so important, and usually requires explicit design to enable, you probably don't want to delegate it.

Elixir does this with Task.async_stream.

https://hexdocs.pm/elixir/Task.html#async_stream/3

https://news.ycombinator.com/item?id=14882880 - July 29, 2017 - 2 comments

https://news.ycombinator.com/item?id=2476440 - April 23, 2011 - 110 comments

https://news.ycombinator.com/item?id=2209970 - February 12, 2011 - 1 comment

Couldn't find more, but I thought it had come up more times.

Programming sure has come a long way. This is all common now, he was completely right, and it's exactly as awesome as it sounded when it was new.

> Many older languages simply had no way to do this kind of stuff.

Mainly due to not cribbing from other older languages like Lisp and Algol 68.

As people already commented in 2011, that's pretty common.

Closures and stuff are great, but for the sake of being ornery:

  function Cook( i1, i2, f ) 
  { 
     alert("get the " + i1); 
     f(i1); 
     f(i2); 
  } 

  Cook( "lobster", "water", PutInPot ); 
  Cook( "chicken", "coconut", BoomBoom );

(or worse)

  Cook("lobster",
       "water",
       function(x) { alert("pot " + x); }  
      ); 

  Cook("chicken",
       "coconut",  
       function(x) { alert("boom " + x); } 
      );

This to me looks like a great example of The Wrong Abstraction. You're removing a tiny bit of code duplication at the cost of creating a weird, hard-to-read, inflexible, limited-use helper; he's taken something straightforward and turned it into, honestly, a bit of a hash.