Programming question

[Kuciwalker]

Why do you not understand that the 'final' workaround does not always apply?

Because it does, in fact, always apply. Do you want to be closed over an int? Drop it in a final collection - done!

[Kuciwalker]

If I were writing a Javascipt-y language, my first intuition for how to implement its closures would be to associate a map from strings to objects with every lexical scope, and then give each lexical scope a reference to its parent... which is exactly the pattern I'm describing in Java.

[Asher]

Because it does, in fact, always apply. Do you want to be closed over an int? Drop it in a final collection - done!

Oh for **** sakes, please tell me you are joking...

This whole thread is surreal. My estimation of your programming abilities has fallen.

[Kuciwalker]

I have stated from the start that fully expressive closures are syntactically disgusting but still possible. That is, of course, a perfect description of the mechanism you quoted.

[KrazyHorse]

You guys are ****ing dorks.

[Kuciwalker]

Oh, oops, I thought this was the "this should piss Asher off" thread. My bad.

[Asher]

Look...closures do not do anything that you cannot do without them. What they do provide is a clean, tidy, efficient, sensible way to do some kinds of operations.

The fact that you can approximate such behaviours in some languages with verbose, messy implementations is obviously not the same thing. Another advantage is decreased overhead and memory consumption -- something the Java approximations do not provide since they use heavy-weight classes.

I'll even revert back to C# 2.0 here and not use lambdas. Here's anonymous delegates in C# vs Java's hack:

C#:

int totalWeight = 0;
passengerWeight.EachPerson(delegate(Person person) 
			{  
				totalWeight+= person.Weight;
			}
Console.WriteLine("Passengers weight {0}", totalWeight);

Java:

final int[] totalWeight = { 0 };
passengerWeight.eachPerson(new PassengerWeightAnonymousFunc() 
			{
				public void handle(Person person) 
				{
					totalWeight[0] += person.getWeight();
  				}
			});
System.out.println("Passengers weight " + totalWeight[0]);

Doesn't this just SCREAM hack?

[Asher]

Here's how I can compute factorial in C# 3.0 with lambdas and closures.

I know Java doesn't have lambdas either, but how would you code this in Java, Kuci?

delegate int FactorialFun(int i);

static FactorialFun Factorial = (n) => n <= 1 ? 1 : n * Factorial(n - 1);

In closing, C# continues to spank Java and make it its *****.

[Kuciwalker]

Look...closures do not do anything that you cannot do without them. What they do provide is a clean, tidy, efficient, sensible way to do some kinds of operations.

I'm not taking advantage of Turing completeness here. You literally cannot implement even pseudo-closures in C without writing a compiler or interpreter. Java has all of the elements you need to write a closure, and it's just a matter of awkward syntax if you want the full generality. Adding usable, fully generalizable syntax for closures is a very worthy goal for Java, but many (most?) of the closure/lambda use-cases actually already exist as interfaces and are frequently used as closures and lambdas.

[Asher]

Another cool feature of lambdas? They're what enabled LINQ to work.

In C#, you can do a SQL-like query on any collection. Automagically.

It's very badass.

Eg:

public void Apolyton()
{
    List sextoysKuciHasUsed= GetSexToys();
    List peopleKuciSleptWith = GetPeopleWithLowStandards();

    var toyFirstChars =
        from s in sextoysKuciHasUsed= 
        select s.ToyName[0];
    var peopleFirstChars =
        from p in peopleKuciSleptWith 
        select p.PornName[0];

    var uniqueFirstChars = toyFirstChars.Union(peopleFirstChars);

    Console.WriteLine("Unique first letters from the names of Kuci's sex toys and  the names of people he's slept with:");
    foreach (var letter in uniqueFirstChars)
    {
        Console.WriteLine(letter);
    }
}

Write that in Java.

Bedtime now. Enough coding...

[Kuciwalker]

Here's how I can compute factorial in C# 3.0 with lambdas and closures.

I know Java doesn't have lambdas either, but how would you code this in Java, Kuci?

delegate int FactorialFun(int i);

static FactorialFun Factorial = (n) => n <= 1 ? 1 : n * Factorial(n - 1);

In closing, C# continues to spank Java and make it its *****.

Erm, the only "free variable" in that "closure" is the function name, which isn't actually any more powerful than recursion. Observe...

interface FactorialFun { public int apply(int i); }

FactorialFun foo = new FactorialFun() { public int apply(int i) { return (i <= 1) ? 1 : i*apply(i-1); } }

[Asher]

Look...closures do not do anything that you cannot do without them. What they do provide is a clean, tidy, efficient, sensible way to do some kinds of operations.

I'm not taking advantage of Turing completeness here. You literally cannot implement even pseudo-closures in C without writing a compiler or interpreter. Java has all of the elements you need to write a closure, and it's just a matter of awkward syntax if you want the full generality. Adding usable, fully generalizable syntax for closures is a very worthy goal for Java, but many (most?) of the closure/lambda use-cases actually already exist as interfaces and are frequently used as closures and lambdas.

The fact that you can implement closures in Java by wrapping things up in various levels of pointless abstractions to accomplish the same thing does NOT mean you are implementing the actual concept. You are approximating it.

And in the process, you're using something like 10x the memory to do it.

[Asher]

Erm, the only "free variable" in that "closure" is the function name, which isn't actually any more powerful than recursion. Observe...

interface FactorialFun { public int apply(int i); }

FactorialFun foo = new FactorialFun() { public int apply(int i) { return (i <= 1) ? 1 : i*apply(i-1); } }

I didn't ask you to implement it with recursion. (FWIW, there's a significant performance difference between using recursion and using lambda expressions in C# -- do you know why?).

Implement the same functionality using "closures" in Java.

I chose a simple example because it's simple. The point is implementing closures, not solving a specific problem with the solution you find best.

[Kuciwalker]

Asher, welcome to me at the beginning of this discussion, when I claimed that fully general closures are syntactically terrible but not impossible or even especially difficult. Also welcome to the earlier discussion where I said C# is a better language overall than Java. What exactly are you trying to prove?

[Asher]

Well, C# is a better language and I like to demonstrate why.

Your claim that Java supports closures still remains incorrect, by virtue of having to jump through so many hoops to approximate it that it negates the whole purpose of closures.

You've then spent a ridiculous number of posts claiming the authors of Java are wrong when they say Java does not support closures. You seem to be under the impression that supporting true closures in Java is just a matter of "syntax", when in reality it requires a big change in the whole JVM. Java does not support closures, it supports features that let you emulate closure behaviour with ugly syntax and even worse performance.

To claim it supports closures is:
(a) incorrect
(b) ignorant
(c) disingenuous

That is all.