Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (120)
games submitted by our members
Games in WIP (577)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 2 [3] 4 5
  ignore  |  Print  
  Java Lambdas Finalised!  (Read 13723 times)
0 Members and 1 Guest are viewing this topic.
Online princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #60 - Posted 2011-10-08 20:42:43 »

Then again, we had embedded SQL in Powerscript 20 years ago...

Cas Smiley

Offline longino

Junior Duke


Medals: 1



« Reply #61 - Posted 2011-10-08 21:14:53 »

Then again, we had embedded SQL in Powerscript 20 years ago...

Cas Smiley

And Java doesn't.
Online princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #62 - Posted 2011-10-08 21:44:18 »

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 Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline JL235

JGO Coder


Medals: 10



« Reply #63 - Posted 2011-10-08 22:23:44 »

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 Smiley
or Java could just steal LINQ from C#, along with stealing lambda expressions.

You're missing the point.  All useful programming languages are the "same" in the sense that they are Turing complete (which if memory serves only requires 5 operations).  The syntax of various languages, in effect, only create lots of different specialize versions of these operations. BUT sytnax (and paradigim) matter...a ton.

I think you are the one who doesn't get it.

Different programming languages are conceptually different in the sense that they employ complete different approaches to solving the same problem.

It means that using a different language requires you to think in a completely different way. It is not a simple one to one translation of the code.

An example of a worthy feature was LINQ in C#. LINQ is conceptually different than anything previously present in a mainstream language, and it really enables the developer to do things he couldn't before. LINQ is more than syntactic sugar. It changes how you think about the software you are developing.
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.

Offline sproingie

JGO Kernel


Medals: 202



« Reply #64 - Posted 2011-10-08 23:14:58 »

An example of a worthy feature was LINQ in C#. LINQ is conceptually different than anything previously present in a mainstream language, and it really enables the developer to do things he couldn't before. LINQ is more than syntactic sugar. It changes how you think about the software you are developing.

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.)

Offline longino

Junior Duke


Medals: 1



« Reply #65 - Posted 2011-10-08 23:41:18 »

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.

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.
Offline Roquen
« Reply #66 - Posted 2011-10-09 16:13:18 »

That is precisely my point as well as, I presume, Roquen's.

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).  Brainf**k 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 Brainf**k.  Which, of course, would be silly.

Smalltalk has lambdas.  Smalltalk has closures.  So by defination they are OO features.
Offline sproingie

JGO Kernel


Medals: 202



« Reply #67 - Posted 2011-10-09 22:35:30 »

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.
Offline JL235

JGO Coder


Medals: 10



« Reply #68 - Posted 2011-10-09 23:40:54 »

That is precisely my point as well as, I presume, Roquen's.

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).  Brainf**k 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 Brainf**k.  Which, of course, would be silly.

Smalltalk has lambdas.  Smalltalk has closures.  So by defination they are OO features.
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.

Offline Roquen
« Reply #69 - Posted 2011-10-11 13:32:16 »

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".
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Spasi
« Reply #70 - Posted 2011-12-09 23:10:51 »

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.
Offline sproingie

JGO Kernel


Medals: 202



« Reply #71 - Posted 2011-12-12 17:52:50 »

1  
int sum = list.map(e -> e.size()).reduce(0, Integer::plus);


By golly, that's much more pleasant than I expected.


Offline ra4king

JGO Kernel


Medals: 350
Projects: 3
Exp: 5 years


I'm the King!


« Reply #72 - Posted 2011-12-12 23:29:07 »

1  
Integer::plus


Huh?

Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #73 - Posted 2011-12-13 01:19:08 »

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.)

弾幕 ☆ @mahonnaiseblog
Offline ra4king

JGO Kernel


Medals: 350
Projects: 3
Exp: 5 years


I'm the King!


« Reply #74 - Posted 2011-12-13 01:24:42 »

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

Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #75 - Posted 2011-12-13 03:09:54 »

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.)

弾幕 ☆ @mahonnaiseblog
Offline gouessej
« Reply #76 - Posted 2011-12-13 11:02:48 »

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(); }
}

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...

Offline Roquen
« Reply #77 - Posted 2011-12-13 11:08:17 »

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.
Offline Scarzzurs
« Reply #78 - Posted 2011-12-13 15:10:40 »

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

My games and Projects:
BlastingPixels.com,
Old website
Offline Scarzzurs
« Reply #79 - Posted 2011-12-13 15:29:22 »

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(); }
}

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...
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

My games and Projects:
BlastingPixels.com,
Old website
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #80 - Posted 2011-12-13 15:42:02 »

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.

Well due to the single-inheritance rule putting a default implementation in an abstract base class is a lot less confusing. Could someone tell me what would happen in the case of conflicting default methods?

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
interface InterfaceA
{
  void draw() default { System.out.println("drawA"); }
}

interface InterfaceB
{
  void draw() default { System.out.println("drawB"); }
}

class Confused implements InterfaceA, InterfaceB {}


I'm hoping to be told my understanding is wrong, because this looks flat out broken.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline Roquen
« Reply #81 - Posted 2011-12-13 15:43:03 »

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

I never claimed otherwise.  If you have cross-cuts in types, then using an abstract class is not an option and is the whole point of interfaces in java.  Not having default methods in the first place was a mistake.  But there are a fair number of people that will never need to write a default method and can pretty much ignore this feature (and likewise for lambda expressions)  WRT: Needed to read other people's code, protector method defs aren't brain surgery...there are alot of possible java 1.0 expressions which would be infinitely harder to read...so what?  My guess is there are a fair number of people that don't really understand generics, but are living just fine.
Offline Spasi
« Reply #82 - Posted 2011-12-13 16:02:54 »

Could someone tell me what would happen in the case of conflicting default methods?

From the link above:

Quote
In the event that two independently-defined defaults conflict, or a default method conflicts with a default none method, the programmer must explicitly override the supertype methods. Often, this amounts to picking the preferred default. An enhanced syntax for super supports the invocation of a particular superinterface's default implementation:

So, like this:

1  
2  
3  
class Confused implements InterfaceA, InterfaceB {
    void draw() default { InterfaceA.super.draw(); }
}

Not overriding draw() should result in a compilation error.
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #83 - Posted 2011-12-13 16:28:31 »

Ah I see, ta. Unambiguous, but still horrifically ugly IMHO.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline sproingie

JGO Kernel


Medals: 202



« Reply #84 - Posted 2011-12-13 17:23:14 »

Interfaces with implementations ... i think it's safe to say java now has multiple inheritance.  Looks to me like there is no linearization order at all though, as opposed to scala traits where it's rightmost depth-first.  Frankly it looks a lot like Python 1.x's mistake that required hardwiring superclass names in, which was rectified with super() in 2.2, and made syntactically nicer in 3.0. 

So I can't say I'm entirely pleased with Java's approach there, but I'm pretty happy with the lambda syntax at least.
Offline gouessej
« Reply #85 - Posted 2011-12-13 18:00:06 »

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.
It won't help anybody because it is useless, it only adds confusions into the language. I read a lot of source code and I don't want to see this. In some case, it might cause compilation errors. I'm against multiple inheritance and I fear this feature can be used to do it in Java. If someone wants to put several "default" implementations of methods into an interface, he should create an abstract class, he should not use this keyword to put some code into this interface in my humble opinion. I can vaguely tolerate other new features but I find this one particularily confusing and crappy.

Offline Spasi
« Reply #86 - Posted 2011-12-13 18:27:28 »

I prefer to focus on the positives. The current state of lambdas has an elegance that's compatible with how we're used to write code in Java. Unlike generics, the most recent major language change, which still feel like an awkward mess. A bunch of tough decisions have been made in order to add lambdas to Java and I find the justifications behind those decisions satisfying. On default methods for example:

Quote
[...]interfaces are essentially set in stone once they are published. The purpose of default methods (sometimes referred to as virtual extension methods or defender methods) is to enable interfaces to be evolved in a compatible manner after their initial publication.

They're not about multiple inheritance and I don't expert we'll be seeing a lot of default methods outside of library code. Every other feature is equally well justified and the corresponding code looks as straightforward and simple as it could be.
Offline Roquen
« Reply #87 - Posted 2011-12-13 19:11:47 »

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.
It won't help anybody because it is useless, it only adds confusions into the language.
Actually it's advocated by people that have a firm understanding of language design, and (as I stated) should have existed earlier.  It addresses existing real world design problems.

Quote
I read a lot of source code and I don't want to see this.
You're very unlikely to see it outside of library code.

Quote
In some case, it might cause compilation errors.
Not in any existing code, so who cares.  For new code...that's the point.

Quote
If someone wants to put several "default" implementations of methods into an interface, he should create an abstract class, he should not use this keyword to put some code into this interface in my humble opinion. I can vaguely tolerate other new features but I find this one particularily confusing and crappy.
As I stated before, creating an abstract class is impossible in the case where an interface is being properly used.  Interfaces are, by design, for dealing with cross-cuts of the inheritance hierarchy.  So what you are suggesting is doesn't work. 
Offline gouessej
« Reply #88 - Posted 2011-12-13 21:11:16 »

As I stated before, creating an abstract class is impossible in the case where an interface is being properly used.  Interfaces are, by design, for dealing with cross-cuts of the inheritance hierarchy.  So what you are suggesting is doesn't work. 
It is possible to create an abstract class implementing some methods of an interface, what is wrong with that? If you really need multiple inheritance, maybe it means that something is wrong in the design of your whole source code, Java doesn't need this feature as it should not handle any crappy choice with crappy solutions. An interface should not contain any implementation of method.

Offline nsigma
« Reply #89 - Posted 2011-12-13 22:21:46 »

As I stated before, creating an abstract class is impossible in the case where an interface is being properly used.  Interfaces are, by design, for dealing with cross-cuts of the inheritance hierarchy.  So what you are suggesting is doesn't work. 
It is possible to create an abstract class implementing some methods of an interface, what is wrong with that? If you really need multiple inheritance, maybe it means that something is wrong in the design of your whole source code, Java doesn't need this feature as it should not handle any crappy choice with crappy solutions. An interface should not contain any implementation of method.

Ah, the joy of arguing with Julien. His opinions are set in stone, just like all the APIs he uses. I admire his ability to write the perfect API at first attempt. For us mere mortals, I find this a positive and sensible move!

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Pages: 1 2 [3] 4 5
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Longarmx (52 views)
2014-10-17 03:59:02

Norakomi (43 views)
2014-10-16 15:22:06

Norakomi (33 views)
2014-10-16 15:20:20

lcass (37 views)
2014-10-15 16:18:58

TehJavaDev (68 views)
2014-10-14 00:39:48

TehJavaDev (66 views)
2014-10-14 00:35:47

TehJavaDev (59 views)
2014-10-14 00:32:37

BurntPizza (73 views)
2014-10-11 23:24:42

BurntPizza (45 views)
2014-10-11 23:10:45

BurntPizza (85 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!