Lambda the Ultimate

1. eachof

The author proposes things like

for (Object o = eachof c) .... while ((Object o = eachof c) != null) ....

Makes you think that "eachof" is an operator of its own, hm? Ok, now what if I write :

return (eachof c);

Either this is refused (=> not orthogonal) or "eachof c" has a type like "Iterator<Object>". Now the assignment implied by the proposed syntax looks broken.

2. Generics

"* It leverages and generalizes existing constructs. The programmer's existing understanding of type casts aids the understanding of this syntax."

"(Number) Collection" should mean to cast Collection into Number then? Damn! I always tought that "Collection" was more like a function type applied "Number".

"*It is more readable than angle-bracket type parameters. This is a matter of taste, of course, and your taste may differ from mine."

Well, I don't like it. Let's call it even?

"*It doesn't result in type parameters and variable parameters becoming "stacked up.""

Don't they? A polymorphic method declaration (with type parameters to the method) would sure look great.

"*It reflects what actually happens in a generic system based on type erasure, such as Generic Java."

So does the proposed syntax.

"*It starts to unify generic collection syntax with existing array syntax."

Ok. Granted.

"*It maps simply to the standard Generic Java syntax, making it easy to modify existing tools."

So does the proposed syntax. Even more simply! :))

To sum up, not really better.

3. Variance

The syntax "Object..Number" makes you believe that you can write "A..B" for any classes. Which you can't, even when B inherits A. (The current system does allow not arbitary bounds) Furthermore, how to you write invariant types? Maybe "Number..Number"? Argh! The pain!

What's the point of an alternative that is arguably only slightly better than the intial proposal? As a conclusion, let's repepat that syntax is way too much discussed. (as this post demonstrates :). I'm sorry, I could not resist this.

My thoughts exactly.

As a conclusion, let's repepat that syntax is way too much discussed. (as this post demonstrates :)

I agree with your points, especially this ultimate one.

I would also mention that adding complexity to a syntax-constrained notation does not typically result in beauty.

What are some ways to avoid a syntax-constrained notation in the first place? There are sexprs, widely discussed already. There's Haskell's for example ability to define new types by composition (type classes, etc.). Haskell again, as well as several other languages, support defining new infix operators.

Has retrofitting a notation ever resulted in beauty?

http://www.onjava.com/

gets a response of

Bad Request Your browser sent a request that this server could not understand.

Apache/1.3.27 Server at www.onjava.com Port 80

Does anyone know an alternate source/cache/mirror?

1. eachof
Maybe Java could have embraced something straightforward

   for (Object o in myCollection)

I think they wanted to avoid taking a new alpha keyword, and so they went with the colon.

The "eachof" is the invention of the author of the OnJava article.

int i = list.get(0); 

ArrayList<Integer> list = new ArrayList<Integer>(); 

Nice (and someday C#) will at least maintain the illusion:

ArrayList<int> list = new ArrayList(); 

Maybe the VMs will eventually encode small integers within a 32-bit pointer so all this (un)boxing becomes more efficient, and dynamic languages run better.

Yeah.

I've extended JavaScript Array to implement java.util.Enumeration, java.util.Iterator, java.util.ListIterator, java.util.Collection and java.util.List. Actually this is done via wrapper objects provided by Rhino. For example:

js> a = [1,2,3];
1,2,3
js> java.util.Collections.shuffle(a.list());
js> a
2,3,1

Also, I've provided wrappers that transform Java iterator, lists, etc to BeyondJS lazy lists. This means you can apply list comprehensions to them, e.g.

js> var a = new java.util.ArrayList();
js> a.add(1);
true
js> a.add(2);
true
js> a.add(3);
true
js> Beyond.list(a).foreach(alert);
1
2
3

Combining the two:

js> var a = [1,2,3];
js> var b = new java.util.ArrayList(a.collection());
js> Beyond.list(b).foreach(alert);
1
2
3

foreach on top of JVM 1.4.1 (with a little help ;-)

BTW, most of the work went into making sure that JavaScript values are transformed to the appropriate Java types and vise versa.

Would that mean - Smalltalk made something mainstream?

I guess not - even though it has been used far more widely than might be supposed - so that honor will go to C# 3 or Java 3 or VB 19.

objects => c++
gc => java
patterns => c++
crc => not mainstream
xp => java
scrum => not mainstream
...
MVC => java (jsp!)
VM - guess not, that would be UCSD Pascal ;-)

OK, the "VM => UCSD Pascal" item too!

Of course this is all arbitrary and inprecise, which leads to heated debate. Such fun.

Former Smalltalkers making their techniques popular through the medium of Java cannot add to the Smalltalk account - they must add to the Java account. We have to take care that the c++ guys don't claim credit for refactoring on account of Bill Opdyke's work ;-)

I think you will find fairly direct influence from Smalltalk people behind each of the others.

Now that's a nice question from an historical pov. Care to be more specific, about some example that may be of interest?

Extreme Programming - Ward Cunningham and Kent Beck, Smalltalk.

SCRUM - Jeff Sutherland, Smalltalk.

Patterns - Cunningham and Beck, Ralph Johnson, Smalltalk.

Java (and so, GC, etc.) - Sun approached ParcPlace Systems about licensing Smalltalk before designing Oak/Java. No deal, PPS said!

CRC cards - Cunningham and Beck, Smalltalk.