Java 9 with GPU processing, Java 10 will be all-OOP without primitives

I think ultra long term planning is what you call 'premature optimization'

Even on the "evolutionary" web, I don't think anyone in 2007 would have predicted the rise (and now... fall?) of MVC frameworks or the explosion of jQuery, both of which existed and were relatively popular at the time. Likewise the NoSQL rebellion was a surprise. Five years from now, we'll all be using WebGL-based dyanmic UIs. Or will we?

I think the point is more that 5+ year planning in the tech industry is simply pointless, not that all technologies will be replaced. Sure, there are some constants. We can all safely predict that in five years we'll still be writing drivers and middleware in C, still be using zlib and libjpeg, etc...

> stuff like Hadoop for big data or Groovy for DSLs were built upon the existing JVM

Hadoop become popular for handling big data, but I'm not sure if many are using Groovy for DSL's. The 2 big uses for Groovy in industry seem to be (1) scripting on Grails, and (2) quick standalone scripts for testing or booting Java code. For these it rocks but the stuff added after Groovy 1.0, such as DSL's, isn't really being used much.

"Look at mobile, 2007: J2ME, Symbian, Windows Mobile, BlackBerry -> 2012: iOS, Android, Windows Phone."

Blackberry remains much more relevant than windows phone. You also forgot to mention Bada which also has more share than wp and is growing. I'm not trying to beat up on wp but as it stands reality conflicts significantly with marketing.

Edit: why the down mod? if I'm in error, please point out where.

That article is an incredibly useful warning against the temptation for casually taking code rewrites, but it's incomplete.

Sometimes full rewrites are necessary and good. The trick is doing it correctly. Rewrites are riskier, more difficult, and require more development resources than greenfield development. More so when you consider that you can't just abandon the old code until the new code is mature and has proven itself.

Most people do rewrites the wrong way, and they get into trouble, but that doesn't mean there isn't a right way. There are many examples of unsuccessful rewrites in history, but also many examples of highly successful ones.

"You are wasting an outlandish amount of money writing code that already exists."

On the contrary, there has been a number of times that I've completely rewritten some code to use a framework or library that was already battle-tested and more fully-featured than the previous effort. I ended up saving myself from writing code that already exists.

The netscape rewrite became Firefox.

I didn't say they should rewrite everything, but to make a new Java version with backward incompatibilities. Drop a new 1.x version on java for decades can't be the solution.

There's no way I'd put Python 3 and Perl 6 in the same sentence.

Also, IMO there's no chance of Perl 6 being successful in time (which makes me sad, because 10 years ago or so I was really hopeful about it).

I think Python 3.0 is really well executed. With such a big ecosystem this takes a while, but when you wait too long somebody else eats your lunch.

The problem really isn't with a particular component in Java. The problem with Java is, Java came as a quick relief to people who had problems with managing memory themselves. Java solved what seemed to be the most pressing problem at that time. Times have changed, today I have completely forgotten some thing called as 'memory management by programmer', today its a given that a modern language today should do that by default.

The problem with Java today is how big and bloated it has become while it doesn't solve fundamental problems programmers face. Its growingly becoming impossible to program in Java without an IDE. Only Java ninjas can probably program Java with a Text editor. Its XML mess all over the place.

Now it takes several tens of lines of code to do trivial file operations and other trivial tasks. This problem was long solved with languages like Perl and Python around 20 years back. Its almost two decades and Java still hasn't caught up. There are still no practical lambdas and good functional programming capabilities.

The issue is something like this. By asking everything to become an API of some sort and writing so many method calls both my unit tests and exception handling code bloats like crazy. My eyes cringe every time I open a Java class file and nearly 60% of the code in there is either try/catch statements or some form get/set methods.

The code to boilerplate ratio is too high. And it just doesn't feel like a language that belongs to the 2010's. Java and its community also promotes heavy use of XML's often used as bad replacements for RDBMS, this leads to building of small buggy and wrongly built DSL equivalents of small parts of SQL all the time.

The path from now is not the make the language bloat like crazy and then provide IDE's to handle that. It is to make the language syntax intelligent enough to take care of many problems you have to other wise worry about. If you see the whole concept of Lisp and other extensible languages like Perl are all about. To provide forms of extensibility that solve the code scalability problem.

And lastly and unfortunately the Java market is full of substandard programmers whose life begins and ends inside eclipse.

A manager or a pointy haired boss might prefer Java for hiring cheap programmers and the 'Oracle factor'. But Java is dead for Start up's and other sexy glorious projects.

So you're saying that type erasure makes programming easier and less error prone?

Oh if you could find it I would be super grateful. I've done my usual rounds such as searching on Google Books and found nothing. Made me start to wonder if it had been Jung instead.

Yes, the example was to illustrate that the unconscious doesn't process negation the way the conscious mind does. The fact that you said the king is not an ass proves that you had the idea that he is. So I think your alternate interpretation of the principle is not so different from the first. The claim is that negation is a logical/abstract construct that exists at a higher cognitive level not recognized by the (allegedly) more primitive unconscious, which deals in concrete language and images.

Another way to put it is that psychologically, a statement and its negation are not opposites but rather go together. The same idea comes up in hypnosis, where it is said that the unconscious mind drops the "not" and simply receives the images that are given. For the same reason, it's better to say "Remember" than "Don't forget", which is a kind of subliminal invitation to forget. And so on.

Choosing Java for everyday projects is a long term disaster?

What about Android apps?

What about solid back-end?

What about Google AppEngine-Java?

People are still using Java for everyday projects and I don't see a disaster coming anytime soon.

I don't get the impression that Oracle really cares about startups. It costs a shitload to license Oracle, and the companies that fork out that kind of money do so because they're running SAP or Siebel, PeopleSoft, data warehousing, legacy LOB apps, etc.

There's lots of old, conservative, slowly changing companies out there that have craploads of money and need (for certain meanings of the term) Oracle. Having control over Java gives them a lot more leverage in those markets, too.

It's never occurred to me to think of Oracle as being a company concerned with any of those things. It seems totally outside their character, everything they do screams "huge, established customers only".

Java objects have functionality beyond dispatch tables. Synchronization is one. You can also have x != y where x and y are different objects with the same value.

Well, actually, in C# struct instances ARE objects allocated on the stack, instead of the heap.

A parallel can be drawn with C++ in which the user of a class decides on declaration/initialization where to store the object (either on the stack, or on the heap). The difference with C++ is that in C# the author of the class decides where instances of it should be stored, so this decision happens when the class is declared, not when it's used.

Otherwise there are few differences between structs and classes and all differences stem from the differences in storage. For example struct instances must be passed by value and not reference, because by definition stack-allocated values are short-lived and playing with references to stack-allocated values is dangerous. Structs must also have an implicit constructor because stack-allocated values cannot be NULL (logically, you need a reference to represent NULL).

In my experience, all discussions about what is or isn't an object are counter-productive.

What really bugs me about Java is that you cannot build your own types that behave just like the built-in types. For instance you cannot override operators like "+" (which works for primitives or Strings), you cannot override [] (which works for arrays), you cannot declare other stack-allocated structures, arrays are reified and yet you cannot declare your own reified data-structures and so on. The presence of primitives doesn't bother me as much as lacking the means to build my own primitives.

>In C# primitives are not objects

http://msdn.microsoft.com/en-us/library/system.valuetype(v=V...

>Data types are separated into value types and reference types. Value types are either stack-allocated or allocated inline in a structure. Reference types are heap-allocated. Both reference and value types are derived from the ultimate base class Object.

An inner class is the ugly half-brother of a closure. 99% of the time they're used they define just one method.

When they are used for more than 1 method implementations, well ... they shouldn't be inner classes.

They just exist to fill the gap of having no closures. I say this as a long time and affectionate java user but project lambda in JDK8 is long overdue.

No, a class's methods are not instances of java.lang.reflect.Method. The latter is simply a 'reflection', per the package name, of first class JVM construct e.g. a reflection on a method.

I think the experience of Haskell is relevant here. Once Haskell introduced first class functions, everyone stopped using typeclasses.

[edit: apparently my sarcasm was too subtle. HOF and typeclasses are both vitally important pieces of Haskell, which are orthogonal to each other. I'm pretty sure both were in Haskell from day 1. Some code for which both are essential:

    class Monad m where
      (>>=) :: m a -> (a -> m b) -> m b
      (>>) :: m a -> m b -> m b
      return :: a -> m a
      fail :: String -> m a

]

Not sure I agree with the GP's point, but I believe he's arguing that when fulfilling the contract of a fictional MouseClickListener:

  interface MouseClickListener {
    void mouseClicked(MouseEvent e);
  }

one often uses an anonymous class to do so:

  void init() {
    mouse.setClickListener(new MouseClickListener() {
      void mouseClicked(MouseEvent e) {
        println(e);
      }
    });
  }

the exact effect could be achieved with a reference to a named function (if Java supported them, which presumably it will once "everything is an object"):

  void init() {
    void mouseClick(MouseEvent e) { println(e); }
    mouse.setClickListener(mouseClick);
  }

given that interfaces are simply syntax for function routing, when you have the ability to reference functions by first-class types (i.e. you have the ability to determine function routing yourself), the set of things that you can only sensibly do with interfaces is a lot smaller.

This is how C# delegates work, right? Any Java -> C# programmer want to comment on whether they rely less on interfaces now and what they use them for?

Clojure, Golang, Scala and Rust all implement similar interface.