Two easy steps to see the practical value in the basics of lambdas and fp:
Whenever you manually iterate through a collection, try to replace it with a functional equivalent. Use functions like “map”, “filter”. You can do that in Java 8, Scala, or JavaScript or Ruby or Python. With Java 8, you need to do “.stream()” on your collection to use the functional functions. You can also do this in Java 6/7 with the Functional Java library. That is somewhat hardcore though. The Java 8 stuff is easier to use.
With Java 8, use Optional to represent nullable types rather than just raw nullable types, especially for return values. It can make your code much more concise and easy to read.
In games, C# is bigger mainly due to Unity and Playstation deals. Outside of games, Java is bigger in various data, science, academic, and server functions.
Scala is extremely elegant and is catching on in a big way! What don’t you like?
Try the assignments in this class by the creator of the language:
You will see the elegance of it if you get into it. Java/C# are ugly hacks in comparison and you see many things that were fixed. I’ve listed the flaws before, but for example why do C# and Java use a completely different syntax for arrays than for generics? Legacy reasons. It’s nice to see Scala fix that so arrays use generics and compile to the same byte code as Java arrays so there is no runtime difference.
Most of the Java world has moved away from those type of IDE “projects” and uses a declarative build tool like Maven. If you define your build in Maven, you can use NetBeans or IntelliJ or Eclipse on top of that. All three of those IDEs will natively read Maven project definitions. I’d also suggest Gradle as basically a much better version of Maven, however NetBeans doesn’t work too well with that. IntelliJ is probably just a better IDE choice, it reads Gradle projects natively, and the free community edition is adequate for almost all projects.
Web browsers aren’t inherently safer, the current trend just moves the problems from the plugins to the browser, it doesn’t mean that there will be fewer malwares, most of them will rather target the major browsers instead of Java. If a plugin becomes really hard to install, it will have absolutely no chance to succeed but at first, players will go on accepting the use of a plugin with the games are worth a try (for example Minecraft). Secondly, if a plugin is as safe as the duplicated features available in the web browser, Mozilla and co. shouldn’t display scary warnings only when using this plugin, it’s not fair but they will artificially favor their technologies. I won’t accept that and I’m not alone to protest. Several Java developers bothered Google for years because of the bad support and the bugs of Chrome affecting Webstart. If the developers increase this gap you talked about, some end users will still see a plus value in installing some plugins. Even on a Samsung S3 the performance of plain 2D HTML5 games is sometimes really bad (for example “Pirates loves daisy”, “Runestone Defense”, …). We can’t drive Java as easy to use as plugin-less technologies (except by using Java to Javascript solutions) but it’s up to us to do our best to improve its performance and to make great Java games but I’m not the best guy for this mission. The latest security changes in Oracle Java itself are discouraging.
This is no comment on other syntax choices (what’s important is self-consistence and not polluting the syntax) but from the perspective of Java: a generic is a type bounds contract. An array is limited pointer arithmetic. These two features are completely unrelated. So for a java like language it would be a bad choice to make them look similar.
invokedynamic is cool, rest is a bunch of fluff. Disclaimer: I haven’t looked at any of it because I don’t really care. Lambdas are neat but don’t make a big difference for me. Iterating using them annoys the shit out of me. Stack map frames are FUBAR and apparently mandatory soon, yay.
Arrays can be thought of as pointer arithmetic and that’s not wrong. In C/C++ the pointer arithmetic is more obvious and exposed. But it is also accurate to view an array as a data structure with a type bounds contract. And why should type bounds have different syntax and different casting rules?
hmmm … a) isn’t invokeDynamic actually from Java 7? b) so I presume you’ve missed the link between lambdas and invokeDynamic and the significant performance gains therefore over earlier options (ie. inner classes)?
Because you need to consider “syntax pollution”. Java the language has a number of desirable features which could added which actually are array related so consuming syntax space on a non-array feature makes no sense what-so-ever. Examples include flattened multi-dimensional arrays, arrays 2.0 like features, flattened arrays of proper structures. Don’t know what happen to the java.util.Map array accessor overloading.
Oh while talking about non-fluff features. Default methods. All the focus has been on published API design & versioning, but it also make design by interface slightly less PITA since you no longer have to boiler-plate identical code in each base concrete (implementing) class. Consider using (say) a circular doubly linked list as: design-by-{interface, composition, interface}. As long as some type ‘T’ need only be a member of one CDLL, design-by-interface now moves to be a pretty reasonable option.
Although I like the new features a lot (e.g. lambdas) I think these things are somewhat of a mixed blessing: one of the relative strengths of Java IMHO is that there generally are few different (although all verbose) ways of writing things down. This makes it a good language to “communicate” in as there are relatively few dialects (e.g. one programmer using feature X to express a solution, other programmer using feature Y). The more different ways are added to do basically the same, the more different “dialects” the language gets in practice, and the harder it gets to communicate in Java between developers. It may not be a huge issue, but something I’m pondering about.
If we kept making new things compatible with dead technology, cars would be pulled by horses. Let it die, stop feeding it. People need to upgrade or gtfo.
There’s still a vast number of 32-bit devices out there though… like, most of them. Think ARM chips. For desktop implementations though… probably not such a bad idea, but give it another few years - still approximately 20% of my target (Steam) are on 32-bit machines, way too large to ignore.
Planned obsolescence? Windows XP has been through enough extensions of planned obsolescence (eeek, people are selling NetBooks with Linux on it ). It officially dies in two weeks - why would any company wish to support it beyond that? It’s not even like Java 8 will be the recommended consumer release in anywhere near that time.