Tcl/Tk 8.6.6 Released (tcl.tk)

Nothing, really. COBOL is the way it is by design. It is not something that its creators should be expected to regret to have done this way and not the other. The language was designed to serve a specific purpose, and it has served well. Look at SQL (which originally stood for "Structured-English Query language"). It shares some important features with COBOL (being "structured English", having easy-to-understand semantics), and, of course, just like COBOL, it often meets some harsh criticisms. I think that bringing both languages together (and I am not talking about Embedded SQL here) could result in a kind of "happy marriage" - in that one would get a pretty powerful tool for doing stuff on a computer without having to learn complex control and data structures - let alone things like macros, generics, iterators and such. I have met people who struggled with Visual Basic and who would certainly struggle with such languages as Python, but who have enough intuition and logical abilities to make it possible for their untrained intelligence to successfully create useful programs in COLBOL and SQL - not unlike non-programmers showing the ability to use, say, Microsoft Excel, very skillfully and efficiently (which, I must say, not every programmer can do; incidentally, I have also met professional programmers who struggled with programming subjects I'd thought were easy to understand!).

Primarily, the irritating verbosity, which still exists in modern cobol. In addition, it has many frustrating features and misfeatures, which may have made sense at the time, but definitely don't now. Modern COBOL has much of the same, but at least there are alternatives to many of the more awkward bits.

>Mmm... I wouldn't really say that JS is a good example of idiomatic HOF - just look at the standard library. I would say that JS has specific idiomatic patterns (such as callbacks) that are a subset of HOF, but most JS code you see around is not like ML or Haskell with regard to HOF in general.

Lodash/Underscore is tremendously popular. Yes, most JS libs HOF merely for callbacks, but the IDEA of, "foo takes a function and returns a function," is a fairly widespread idea in the JS community: The same is true of ruby, and a few other mainstream languages.

>And scoping. And magic semicolons.

Scoping is semantics, not syntax. And yeah, scoping semantics suck. But hey, IIRC at least they were never as bad as python's used to be :-).

However, this is no excuse for how awful the semantics are. Variable Hoisting is the devil. However, ES6 seems to improve this somewhat.

As for the 'magic semicolons,' JS doesn't do ASI when the syntax is ambiguous. So I fail to see what's so magical about them.

Unless you mean the semicolon/lack of semicolon on the end of a function definition. And that's for the same reason as C struct semicolons, and about as easy to remember.

>Can you clarify? So far as I can see, all you need for lambdas are first-class functions (function-typed values), function literals, and closure semantics for the latter. Most mainstream languages offer that these days. C# would be a good example - what do you find limiting about its lambdas that JS does better?

<rant>

First of all, people talk closures like they're some magical entity: They're not. They are a natural consequence of lexical scoping and every lexically scoped language you have ever used has them. Yes, even whatever one you're thinking of right now. They may not support inner functions, but all a closure is is a lexically closed environment, so semantically, EVERY function is a closure.

</rant>

My pedantic nature over that aside, yes, I will gladly clarify. I am not familiar with C# or Perl, and am not super familiar with the Java lambda semantics, so let's talk scripting languages: Ruby, Python, JS. And since this IS JS's domain, and Perl is Perl, the comparison should be useful.

Let's start with Python:

  def apply(f, arglis):
      f(*arglis)

It seems simple enough, but as you no doubt know, Python's lambdas can only have one statement: So while this works:

  >>>apply((lambda x, y: x+y), 1, 2)
  =>3

This doesn't:

  >>>apply((lambda x: \
  ...    if x:
  ...        print("oh noes")), 2)
  =>syntax error

Next, ruby. Off the bat, Ruby looks better: blocks, procs, and lambdas are everywhere!

And thus begins our first problem: Blocks, Procs, and Lambdas are all SUBTLEY DIFFERENT. Bad, okay, but not awful.

However, Ruby is, unlike Python, fully Object Oriented. Thus, procs and lambdas are instances of their respective classes. What ruby should have done is introduce python style call methods, allowing any object to act like a function. Instead, much like Smalltalk before it, it added a call method to each object, which you call to invoke the code. This means that you can't just pass in a kernel method (What most of us call functions) instead of a block or proc when a function is expecting one: you have to wrap it. Thus, functions defined with def aren't the same as the anonymous procs you create: they're different entities. The Schemer in me is shouting that making functions and lambdas different entities should be a compiler optimization, not something transparent to the programmer.

Finally, Java: I said I wouldn't cover this, I lied. Java actually handles lambdas surprisingly well. The only problem is that a lambda can only touch 'final' variables. So a lambda can read the args of the function that created it, but it can't change them, and thus you cannot g...