Gilad Bracha writes...
Java was actually designed to have tuples from the start, but they never quite got in. At one point, I tried to add a tuple-like construct as part of JSR-65. We wanted to extend array initializers to full blown expressions. Eventually, that effort got quashed; I didn’t really resist, since the extension was painful, as such things always are in Java. We should have just done straight tuples as a separate construct - but at the time, that was frowned upon too.This is because Java's syntax and the better part of its semantics are derived from the C family. Ironically Java is essentially a "symbolic language" underneath (i.e. the implementation is derived from the Lisp/Smalltalk family.)
Arguably both of these choices increased Java's popularity. Unfortunately the choice of syntax and semantics has stunted Java's expressiveness and will never overcome that beyond incremental improvements.
Update
I am asked in a comment what I mean by "symbolic language". I could have written "dynamic language". Essentially I mean the languages that have evolved from or were greatly influenced by the original Lisp implementations from the 1960s. The "symbolic" part goes back to Lisp's fundamental data types: symbols and lists (or symbols). Of course it has numbers and all kinds of data types now, but originally Lisp was intended for manipulation of symbols more than numbers, and so was called a "symbolic language".
End
2 comments:
> Ironically Java is essentially a
> "symbolic language" underneath
> (i.e. the implementation is
> derived from the Lisp/Smalltalk
> family.)
Patrick,
Can you explain more what you mean by symbolic language.. I am interested and don't quite grok what you mean. I understand the smalltalk lineage, but am interested what could be lispish about it?.
- Corey Goldberg
p.s. I enjoy your blog
----
www.goldb.org/goldblog
Patrick wrote:
Unfortunately the choice of syntax and semantics has stunted Java's expressiveness and will never overcome that beyond incremental improvements.
Inner classes provide a lot of flexibility in defining new control flow constructs. I've recently been working on adding E-like eventual control flow constructs to Java and I think I've done alright. For example, see asynchronous AND in Java. It's about 50% longer than in E, but I think it's still pretty clear, and of course doesn't require learning a new language. See also the infinite series for an example of doing eventual invocations in Java.
Post a Comment