"I have a mind like a steel... uh... thingy." Patrick Logan's weblog.

Search This Blog

Loading...

Saturday, February 24, 2007

Non-Symbolic Languages

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:

Corey Goldberg said...

> 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

Tyler said...

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.

Blog Archive

About Me

Portland, Oregon, United States
I'm usually writing from my favorite location on the planet, the pacific northwest of the u.s. I write for myself only and unless otherwise specified my posts here should not be taken as representing an official position of my employer. Contact me at my gee mail account, username patrickdlogan.