OCPJP 6
Wikipedia wrote: Lambda calculus (also written as λ-calculus or called "the lambda calculus") is a formal system in mathematical logic for expressing computation by way of variable binding and substitution.
Mohamed Sanaulla | My Blog | Author of Java 9 Cookbook | Java 11 Cookbook
Good luck for yourself.
Stas Sokolov wrote:Is there any Java framework / JVM extension that already in one way or another mimics this syntax ?
Mohamed Sanaulla | My Blog | Author of Java 9 Cookbook | Java 11 Cookbook
Mohamed Sanaulla wrote:
Stas Sokolov wrote:Is there any Java framework / JVM extension that already in one way or another mimics this syntax ?
You can have a look at the JVM based language called Scala.
Good luck for yourself.
OCPJP 6
Stas Sokolov wrote:
Mohamed Sanaulla wrote:
Stas Sokolov wrote:Is there any Java framework / JVM extension that already in one way or another mimics this syntax ?
You can have a look at the JVM based language called Scala.
It looks not so good. Syntax is unreadable. Somebody who decided to use a class body to define lines of constructor between different methods was just insane. This one Kotlin is a little bit easier and structural but I still like to stick with all good Java just using the same nice things that were defined in Project Coin and then Oracle took them off.
Palak Mathur wrote:
Stas Sokolov wrote:
Mohamed Sanaulla wrote:
Stas Sokolov wrote:Is there any Java framework / JVM extension that already in one way or another mimics this syntax ?
You can have a look at the JVM based language called Scala.
It looks not so good. Syntax is unreadable. Somebody who decided to use a class body to define lines of constructor between different methods was just insane. This one Kotlin is a little bit easier and structural but I still like to stick with all good Java just using the same nice things that were defined in Project Coin and then Oracle took them off.
Stas,
You are making up your mind just after a glance. Just give sometime to understand the philosophy behind the language, try to build few things with it and then you would be in a better position to judge a language.
Good luck for yourself.
Rick Goff wrote:I'm not sure it's due diligence for you to glance at a language Martin Odersky and others took years to produce, and declare it unreadable. What else is unreadable to you? Russian? Mandarin?
Sorry if that's snarky. More constructively, I suggest you post a sample of "unreadable" Scala and see if we can work out what it means.
Good luck for yourself.
Stas Sokolov wrote:
Rick Goff wrote:I'm not sure it's due diligence for you to glance at a language Martin Odersky and others took years to produce, and declare it unreadable. What else is unreadable to you? Russian? Mandarin?
Sorry if that's snarky. More constructively, I suggest you post a sample of "unreadable" Scala and see if we can work out what it means.
Any Scala code premier looks like an ugly PERL script. It might be shorter than Java in some way, but I would give +1 for this and -10 for readability.
OCPJP 6
Hendra Kurniawan wrote:AFAIK, lambda expressions exist only in .Net technology. Does this mean Java will also introduce this feature in the next release?
Mohamed Sanaulla | My Blog | Author of Java 9 Cookbook | Java 11 Cookbook
Hendra Kurniawan wrote:AFAIK, lambda expressions exist only in .Net technology.
No more Blub for me, thank you, Vicar.
chris webster wrote:
Hendra Kurniawan wrote:AFAIK, lambda expressions exist only in .Net technology.
Actually, lambda expressions (or anonymous functions) have been around in a lot of other languages for quite a long time. Java is still playing catch-up.
Dennis Deems wrote:Why is this something an object-oriented language should be expected to "catch-up" to?
Closures were left out of Java initially more because of time pressures than anything else. Closures, as a concept, are tried and true - well past the days of being PhD topics. The arguments are in the details, not the broad concepts. In the early days of Java the lack of closures was pretty painful, and so inner classes were born: an uncomfortable compromise that attempted to avoid a number of hard issues. But as is normal in so many design issues, the simplifications didn't really solve any problems, they just moved them. We should have gone all the way back then
SCJP, SCJD, SCEA
OCPJP 6
Stas Sokolov wrote:... in Scala every primitive type is an object.
Consider Paul's rocket mass heater. |