All I'm asking the compiler to do is insert an implicit cast to the destination type to save me having to pollute the meaning of my code with (String) etc all the time. That's trivial for the compiler to do. It doesn't have to do any compile time analysis beyond that, so yes, I'm not asking for "full type inference" but just "implicit casting".

All I'm asking the compiler to do is insert an implicit cast to the destination type to save me having to pollute the meaning of my code with (String) etc all the time. That's trivial for the compiler to do. It doesn't have to do any compile time analysis beyond that, so yes, I'm not asking for "full type inference" but just "implicit casting".

Cas

wondering how your code looks like, so that you need casts "all the time".

only thing what could be done in this direction could be something like this:

1 2 3 4 5

Objecta;if(ainstanceofString){Stringb = a;//without compile error}

also the try cast from C# can be helpfull, which casts or returns null if the type dosn't match.

I think one don't need any casts anyway, perhaps only for some strange magic deep inside some implementation.

wondering how your code looks like, so that you need casts "all the time".I think one don't need any casts anyway, perhaps only for some strange magic deep inside some implementation.

I think casts are fine. I use it to grab my game instance, from almost anywhere. Slick has this "GameState", but ofcourse I've extended it to fit my needs, like grabbing the current map being drawn. The API doesn't care for that though, so this is what I do to get access:

1

game = (IngameState) sbg.getState(GAME_STATE.GAME.getID());

Different states, different needs. Since this is part of Slick, I see no slick () way of doing that, without casting. Another example is datagram packets. I use KryoNet, so serialized objects are the packets. To keep it OOP, I have to do a cast though, to know what fields I should be looking for. Else, it'll just be a byte-array which takes away the entire point of serializing objects to send over the network.

only thing what could be done in this direction could be something like this:

1 2 3 4 5

Objecta;if(ainstanceofString){Stringb = a;//without compile error}

Indeed, for example this is what Kotlin lets you do. The benefit is that you never encounter unpleasant surprises at runtime. The IDE also highlights variables within inner scopes that have been auto-casted to another type.

My main issue with this is that I have to guess what the type of 'e' is.I really hate it when a language hides important stuff from me.

That's called type inference, and it already does this with generics. The language guesses, and it's always correct (it it can't guess perfectly, it won't compile). Welcome to the state of the art in compiler technology, circa 1973. I imagine some people still have a problem with this the same way that others did with automatic memory management, sure.

Yes, I'm snarky about it, but we're arguing about things that have been solved problems for 40 years, and the consequences to real-word productivity over this kind of sloth are quite real.

Yes of course using mouse hover IDE smartness to know what the type is helps deciphering this sort of thing. But it's still a bit of an obfuscated syntax if you ask me.I mean I like to be able to easily read code 'as-is', without having to depend on IDE voodoo. For example reading code from the internet or books.

It's probably not a big deal in practice and perhaps I'll learn to like it, but to be honest I usually prefer a bit of verbosity but completeness and consistency over brevity by leaving out information and implying stuff. For example one of the reasons I don't like Groovy is because it seems it goes for brevity for the sake of it, which has the effect of making Groovy seemingly very inconsistent and not that readable at all.

How does this work btw if in this example 'addActionListener' accepts different types as arguments? Do you then just need to explicitly note the type as per Spasi's example?

How does this work btw if in this example 'addActionListener' accepts different types as arguments? Do you then just need to explicitly note the type as per Spasi's example?

If it can be inferred based on what you do inside the listener body, it will do so. Otherwise, it will make you give the type explicitly, yes. Java however doesn't go to heroic lengths to infer it like Haskell (nor does Scala), and tends to make you use explicit typing at the slightest hint of ambiguity.

Lots of smart things have been thought up by really smart people. Together with millions of other developers, I'm probably not that smart. There's a reason that many really old and genius language concepts haven't really caught on while simple stupid languages like C and Java did become popular.

If it can be inferred based on what you do inside the listener body, it will do so. Otherwise, it will make you give the type explicitly, yes. Java however doesn't go to heroic lengths to infer it like Haskell (nor does Scala), and tends to make you use explicit typing at the slightest hint of ambiguity.

Lots of smart things have been thought up by really smart people. Together with millions of other developers, I'm probably not that smart. There's a reason that many really old and genius language concepts haven't really caught on while simple stupid languages like C and Java did become popular.

I don't understand the calculus behind type inference myself either, but I don't have to in order to use it. That of course is the whole point of compilers: they do the work so you don't have to. They're already running some pretty sophisticated algorithms just to allocate registers, to pick one example out of many. Full global type inference is a knotty problem (in fact it's equivalent to the halting problem) but local inference has, I think passed from voodoo to common sense, and I don't think any new language coming out now will gain acceptance if it doesn't support at least some local type inference.

Well I guess I'll just have to learn the benefits of these lambdas besides giving you more code brevity. I just tend to cringe with too much implicitness, but that might be just me not seeing the big picture yet and not having done any real work using these lambda expressions yet

I am not a fan of function pointers, first class functions, or anything similar. For object methods, the exclusive use of interfaces is superior to what other languages do. It would be nice if the language supported interfaces with static functions defined in a different class. "Class" for lack of a better term. The benefit would be for stateless functions where there is no need to create new objects. Comparator objects for example usually doesn't benefit from having a state.

There are benefits, but I don't like exotic solutions. (Based on unrelated languages.) Time invested in making Java more like super theoretical hypothetical academic languages or a scripting language instead of trying to compete with C, C++, and C# bothers me. (When will structs be added?)

Lambda expressions are only "exotic" hoity-toity ivory tower things because you don't have any experience with them. I recommend stepping out of your comfort zone and seeing what various languages have done since the 1960's.

Incidentally, even C++ has lambda now (and unspeakably weird syntax but C++ users are used to that I suppose)

This is not normal Java. I remember reading that the exclusion of a Pair<A, B> class as in STL was deliberate. There is a Point class because it it is preferable to Pair<int, int> because the latter obfuscates meaning. The same was said to apply to methods. Even though you could make a generic Pair, Triple, Etc. or an interface with a generic public void method(A a, B, b) header, people advised others not to. I suspect duck typing will be the next addition because it's been hyped on C# blogs. Obfuscation is the main problem. The other is that a syntax sugar arms race that makes the language bloated. (Not that there isn't a need for certain new features.) Syntax should be simple and semantics should be obvious and accurate.

I worry we will see indefinite hacks and new Java 1.X versions. Java suffers from backwards compatibility like most languages. (C++ being most extreme.) It would be interesting if Java 2.X chose to re-implement features with a smaller but more powerful feature set overall. (And new API to take advantage of extra power.)

Q: Why is Java such a manly language?A: Because it forces everyone to grow a Pair.

Tuple types are useful, but I'm not sure how useful without literal syntax.

As for Java 2.x, I really just don't see that happening. The only thing likely to break backward compatibility is going to be a whole new language, and I'm afraid that's likely to be some form of Javascript

Java might not be perfect, but it is a good language that is verbose enough and (up until now) did not have to have all the bells and whistles. Sadly that has changed. Guess we have to follow every dumb trend just because someone came from a different language and is now complaining that their bells and whistles are missing.

Strange that Java became so widely used even without all this feature bling.

If you want to do functional programming, go grab a functional language. If people do not want to write code, maybe coding is not their thing. Also the compiler should not do your thinking for you. And you should be able to see what the code does WITHOUT the IDE helping.

I guess if my crappy hammer cannot slice and dice and use it as a shovel, it must be a crappy hammer and I am to dumb to see the benefits of said features.

Revisionist history here folks. Most of the big features that have been added to java over the years are all things that would have been there in the first place in an ideal world of infinite engineering time and budget.

I guess if my crappy hammer cannot slice and dice and use it as a shovel, it must be a crappy hammer and I am to dumb to see the benefits of said features.

One(?) word for you - "multicore". Java has always been pretty good at supporting concurrency, and this feels a natural evolutionary step in that. Have a look at the slides here - http://www.slideshare.net/buzdin/lambda - good overview of some of the thinking behind this (even if the implementation details are a bit old).

I'm sure we'll all get used to it over a few years and then we'll wonder how we managed without.

(see: annotations, generics, etc)

Having said that I'm convinced that the current "state of the art" when it comes to multicore computing design is basically just a massive bodge job. If I ruled the world we'd have software configurable core pipelines and immutable message passing and languages would be kinda designed around a more transputery sort of way of doing things.

One(?) word for you - "multicore". Java has always been pretty good at supporting concurrency, and this feels a natural evolutionary step in that. Have a look at the slides here - http://www.slideshare.net/buzdin/lambda - good overview of some of the thinking behind this (even if the implementation details are a bit old).

I keep on hearing that again and again, but it seems to only boil down to 'annon inner classes suck, but my cryptic hackery is totally cool'.Trying to sell a feature that supposedly fixes something that is not broken?

Revisionist history here folks. Most of the big features that have been added to java over the years are all things that would have been there in the first place in an ideal world of infinite engineering time and budget.

You might say so, but there's a paper long predating the lambda proposal out there from one of the big names in Java (might have been Gosling himself) going on about how Java doesn't need any kind of lambda syntax because it has anonymous inner classes.

Thankfully less conservative voices like Bloch ultimately prevailed, and others like Gilad Bracha, and the aforementioned Gosling signed on to it. So folks, are they just kiddies with their bling trying to bodge silly hacks, who don't know what they're doing?

Leaving snark aside (don't worry snark, I'll come back, daddy loves you) one of the main reasons for ultimately adopting lambdas after all, and as has been discussed here previously, is that they're not simply syntax sugar, but can be optimized specially by the compiler in ways that the JLS would otherwise specifically forbid for anonymous inner classes.

One(?) word for you - "multicore". Java has always been pretty good at supporting concurrency, and this feels a natural evolutionary step in that. Have a look at the slides here - http://www.slideshare.net/buzdin/lambda - good overview of some of the thinking behind this (even if the implementation details are a bit old).

I keep on hearing that again and again, but it seems to only boil down to 'annon inner classes suck, but my cryptic hackery is totally cool'.Trying to sell a feature that supposedly fixes something that is not broken?

So, you didn't read through all the slides or the point above about bytecode implementation then?

Lambdas aren't inner classes, and because they're not specified or implemented that way, there is potential for significant performance improvement.

You might say so, but there's a paper long predating the lambda proposal out there from one of the big names in Java (might have been Gosling himself) going on about how Java doesn't need any kind of lambda syntax because it has anonymous inner classes.

Thankfully less conservative voices like Bloch ultimately prevailed, and others like Gilad Bracha, and the aforementioned Gosling signed on to it. So folks, are they just kiddies with their bling trying to bodge silly hacks, who don't know what they're doing?

You might call them 'less conservative', others might call them opportunistic. You just like them now because you agree with them on this one part.Though I doubt if Bloch et al would look at your code, you would really want to hear what they have to say.

or as someone once mentioned: Lambdas in several languages seem to be defensive moves more than anything else ("Stick around! We've got those too!!)When I look around, most of the people calling for these are people coming from other languages asking why their cool feature is missing.

Quote

Leaving snark aside (don't worry snark, I'll come back, daddy loves you) one of the main reasons for ultimately adopting lambdas after all, and as has been discussed here previously, is that they're not simply syntax sugar, but can be optimized specially by the compiler.

Got anything to back up that statement? Not just rumours or whatnot, I want to see facts.Because I honestly only hear about what all these cool features will do, but nothing that would convince me. Show me just how great it really is and how much better everything will be if I do pick it up and you just might sell me on it.

Until then, it is simply today's shiny new toy.

Not that really anything we say or do will change anything. I simply see Java going the way of so many other languages and joining the feature death-march that will only lead to it's demise. Today it might be the one you like, tomorrow it might be something you do not want. Once the 'omg, we need this also' dam is broken, you will be hard set to stop it again.That was once what made Java so great.

You might say so, but there's a paper long predating the lambda proposal out there from one of the big names in Java (might have been Gosling himself) going on about how Java doesn't need any kind of lambda syntax because it has anonymous inner classes.

Thankfully less conservative voices like Bloch ultimately prevailed, and others like Gilad Bracha, and the aforementioned Gosling signed on to it. So folks, are they just kiddies with their bling trying to bodge silly hacks, who don't know what they're doing?

I'm pretty sure that I remember what you're talking about and want to think it was Gosling. But you gotta take into account the "public face" factor. Look at the spin on "type erasure" as an alternate example. (Which of course they're working on a non-type erasure version). Looking at the pre-and-post Java works of various early Java folks:

So you have a bunch of people (ignoring all the other smalltalk/strongtalk/self people) with experience designing/implementing languages with lambda expressions before working on Java...AND working on/designing/implementing during or post their work on Java...all of which include lambda expressions. It's simply not plausible that lambdas were not considered early on...and rejected since it was an issue that could be (painfully) worked-around (and thus moving the task from the VM/compiler & design side...which had to have been critical path to library side with grunt programmers).

BUT: Be that as it may...my point is that it's rather silly to think that java is just adding lambda's to follow some fad. And likewise java didn't add generic's simply to follow C#'s lead.

Transputers are awesome. The problem is someone needs to design a language to program them in.

They did, it was called Occam. I suspect just about anything message-based would do fine though.

Yes Occam...that's sort-of proves my point doesn't it? Seriously, the problem with transputers is that it too much of a paradigm shift. Programmers want coherent memory architectures and to be able to think in a logically sequential programming style. And code/data memory should be logically infinite and not manually managed. Sure you "could" use any off the shelf functional and/or message passing system, but it doesn't really map well. Look at all the love programming the PS3 got, which is (basically) a transputer rip-off design. I'd love to be proved wrong...and I've always wanted to take a look at Cray's chapel to see if it is promising or not....but I'm too lazy!

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