Then again, we had embedded SQL in Powerscript 20 years ago…
Cas 
And Java doesn’t.
I know, most annoying if you’re a database programmer. Sometimes I wonder if Java would be best split into several DSLs all using the same bytecode but with appropriate dialects for different sorts of programmers.
Cas
or Java could just steal LINQ from C#, along with stealing lambda expressions.
I half agree with you. You do end up thinking about problems differently, in various languages, but you also tend to compare new ways of doing things to what you already know. For example I often see Anonymous Classes and lambdas/closures as being quite comparable, because they are often used to solve different problems, even though they are different features.
That is precisely my point as well as, I presume, Roquen’s. Everything LINQ does, you can boil down to primitive instructions, making it “mere syntax sugar”. But you’d never manage to express anything so high-level that way, meaning the particular syntax it uses is important as an expression of the higher level idea behind it; that is to say, it matters. Java without lambdas is effectively java without functions as values, at least not without having to jump through enough hoops that most of the time one doesn’t bother.
(I’m not under any illusions that Java will even remotely become a functional language, mind you.)
You can boil down everything to atoms, so you, the computer you use and the chair are all the same thing…
Ah no, not really.
Syntax is just cosmetics. If people cared about it then Ruby would never become popular because it looks like shit. People use Ruby, or Python, because it enables them to something they need done.
People tolerate the syntax, as long as it is worth it.
Exactly. To spell it out in painfully many word. The argument that language “A” shouldn’t have some feature “B” to address some concern “C”, if you already can address it in some manner is a flawed argument. It’s only slightly worse than the “If we include that feature, someone will write bad programs” one.
Taking the feature arguement to a logical extreme (which I assume was sproingie’s point). Brainfuck is Turning complete. Therefore it can perform any computation. So if you’re programming a computation, you don’t need to use anything other than Brainfuck. Which, of course, would be silly.
Smalltalk has lambdas. Smalltalk has closures. So by defination they are OO features.
I actually do have a problem with feature creep in a language if the feature in question is marginal and doesn’t lend itself to any generality. Thus why I can’t get myself excited about switch statements now supporting strings. It’s not a bad thing to support it, but it sure isn’t anything like pattern matching or even a decent interned symbol class. Lambdas on the other hand have very general utility that I should hope goes well beyond simple shortcuts for inner classes – how useful depends on how strongly typed they make anonymous methods.
I mostly agree with you, except for your Smalltalk example. You can also do variable assignments in Smalltalk, which is not an OO feature.
Personally I see ‘OO features’ as being anything that helps building object-oriented designs easier. This is because you can write object-oriented programs in non-OO languages, such as C.
I find the string switch statement annoying in the sense that it’s actually more complex sugar than operator overloading which so many Java folks hate. (By complex here I mean the generated black box) Since it doesn’t pollute the sytax I can’t really care too much…same for the underscores (or whatever) in numeric constants.
WRT: My smalltalk comment. That was tongue-in-cheek. The argument that feature X isn’t OO. Push that to a logical extereme and Java isn’t OO. It seems like this arguement is ususally code for “I don’t understand X” or “I don’t need X so why should anyone else”.
State of the Lambda has been updated. A JDK8 dev preview build is also available. Took them a while, but it actually turned out quite nice.
int sum = list.map(e -> e.size()).reduce(0, Integer::plus);
By golly, that’s much more pleasant than I expected.
Integer::plus
Huh?
Check Spasi’s link. It’s a method (or constructor) reference. It’s kinda odd, but I guess this will work, too. (It’s basically a workaround for Java’s lack of first-class functions.)
Hmm I must have missed that part. Reading and re-reading it still makes no sense. There is no “plus” method? Does it mean to add? I’m confused T___T
It references the method “plus” from a class called “Integer”. Well, it’s just an example. The class isn’t necessarily java.lang.Integer. (They might add this kind of methods though.)
This example is fine for showing the useless confusion and complication added into Java:
[quote]interface Robot implements Artist, Gun {
void draw() default { Artist.super.draw(); }
}
[/quote]
The “default” keyword is used above instead of creating an abstract class, interfaces should not contain methods with code. In my humble opinion, Java is taking the wrong path…
The thing is, you don’t have to use any of these new features if you don’t find them interesting. But protector methods will aid many people.
I disagree: You WILL eventually have to read/edit other people code, which means you WILL have to understand it.
If that’s not enough, it’s a pretty common statement that the best understanding comes from use.
- Scarzzurs
The “default” keyword is used above instead of creating an abstract class, interfaces should not contain methods with code. In my humble opinion, Java is taking the wrong path…
[/quote]
Can’t quite make up my mind on this one…
At one hand “default methods” makes me shiver for their invasion on the purity of interfaces.
On the other hand, how are abstract classes any better? To me it appears that they do indeed already emulate the “default methods” behaviour.
I’m kinda thinking, either you discourage people from using abstract classes in the first place, or you support them by language features…
- Scarzzurs