Java 9 with GPU processing, Java 10 will be all-OOP without primitives • Hacker News Board

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

#101

Post by ssmoot » Sat, Mar 31, 2012, 1:59 AM UTC

JunkDNA wrote: post #3

Wow, how can you seriously plan releases of a programming language out to 2021? That is an eternity in this industry. Even 2015 for JDK 9 seems mighty far off, especially accounting for the usual slippage of release dates with big software projects.

That's 9 years.

I've used Ruby for almost as long, and on MRI at least, I can't think of anything as significant. (JRuby FTW)

Think of c#'s evolution. Ruby's. JavaScript's. SQL's. 9 years isn't exactly blazingly aggressive, but in the context of a programming language it's not eyebrow raising either.

I think generally that's a good thing.

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

#102

Post by jrockway » Sat, Mar 31, 2012, 2:00 AM UTC

spacemanaki wrote: post #93

jrockway wrote: post #75

Earlier quoted context omitted.

Java is already 30 years behind the state of the art, so planning 10 years ahead is very easy. Just do what other languages were doing 20 years ago. (Fuck boxed primitive types. How about generics that weren't designed by drunk retarded monkeys?)

Yep, Gilad Bracha, Philip Wadler, Martin Odersky... all drunken, retarded monkeys.

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

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

#103

Post by kamaal » Sat, Mar 31, 2012, 2:04 AM UTC

spacemanaki wrote: post #93

jrockway wrote: post #75

Earlier quoted context omitted.

Java is already 30 years behind the state of the art, so planning 10 years ahead is very easy. Just do what other languages were doing 20 years ago. (Fuck boxed primitive types. How about generics that weren't designed by drunk retarded monkeys?)

Yep, Gilad Bracha, Philip Wadler, Martin Odersky... all drunken, retarded monkeys.

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.

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

#104

Post by kamaal » Sat, Mar 31, 2012, 2:12 AM UTC

samspot wrote: post #85

mindcrime wrote: post #74

Earlier quoted context omitted.

> Wow, how can you seriously plan releases of a programming language out to 2021? "A plan is useless, but planning is essential" [1] More true than ever, if you ask me. Sure, you make plans, why wouldn't you? But you also retain the flexibility to adapt the plan as the environment changes. You don't chisel the damn plan into a stack of stone tablets and render it immutable for all time. I don't see any conflict whats…

Exactly, there is nothing wrong with long range planning. Planning this far out allows you LOTS of time to iterate on your plans, making them better.

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

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

#105

Post by tsotha » Sat, Mar 31, 2012, 2:18 AM UTC

teraflop wrote: post #98

tsotha wrote: post #92

Earlier quoted context omitted.

>You can also have x != y where x and y are different objects with the same value. May be true, but it's not guaranteed one way or the other. In the Oracle JVM the smaller integers are cached such that new Integer(10) == new Integer(10) but new Integer(1000) != new Integer(1000)

Actually, "new Integer()" is guaranteed to always return a new, distinct object. The caching only comes into play during autoboxing conversions, or when you call Integer.valueOf().

Ah, you're right. I was thinking of autoboxing, i.e.

  Integer a;
  Integer b;

  a = 10;
  b = 10;
  a == b; // true

  a = 1000;
  b = 1000;
  a == b; // false

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

#106

Post by kamaal » Sat, Mar 31, 2012, 2:23 AM UTC

protomyth wrote: post #62

kbd wrote: post #58

Earlier quoted context omitted.

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

If you are some manager in a big company and looking at the press, there is little distinction. In fact, more stories have been posted about Python 2.x to 3.x conversions (mostly because Perl 6 is not a story). Heck, I would imagine a couple of people on HN have run into the "can't use Python 3 because it isn't compatible with anything"-meme. Carefully considered logical analysis with realistic risk mitigation gets t…

You are not getting it, Perl 6 is not designed as a successor to Perl 5 but as a Age proof Perl.

Think of it like pg called a hundred year lisp language. Perl 6 might be the age proof Perl language. When you have such and ambitious goal the time taken is worth to fulfill it. Larry wall figured out quite a while back evolving Perl 5 may fix some warts but it won't solve the larger problem.

The larger problem today is doing language extensibility sane-fully. There are no C based languages that are as much extensible as a Lisp based languages. Perl 6's larger aim is to solve that. While retaining the 'Perl factor'.

Re write is inevitable if you have to solve this problem, no matter what joel says you have to rewrite a few things to fix them. The incremental path is too slow and you will loose out on time while somebody eats your lunch.

Perl 5, Python x.0 and Ruby x.0 series are all great languages but eventually on the very long run they will be plagued with the same technical problem every language runs in to. Providing sane ways of extensibility without bloating too much.

IMO Perl 6 will do well, for the same reasons Lisp has done well.

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

#107

Post by shareme » Sat, Mar 31, 2012, 2:24 AM UTC

I think I will switch to Google Go

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

#108

Post by kamaal » Sat, Mar 31, 2012, 2:28 AM UTC

mgkimsal wrote: post #77

nknight wrote: post #51

Earlier quoted context omitted.

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

The current crop of smaller companies and bootstrappers will evolve in to the next generation's "established" companies. No one is starting a company today with COBOL. How many are starting today with Java? Not rhetorical - I know some are - just wondering how this will play out over time...

There are only three factors Java is getting used today.

    1. 'Hiring the cheap programmer' factor.
    2. 'The Oracle' factor.
    3. 'The pointy haired boss' factor.

And those are not awesome reasons to stay alive.

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

#109

Post by ootachi » Sat, Mar 31, 2012, 2:34 AM UTC

jrockway wrote: post #102

spacemanaki wrote: post #93

Earlier quoted context omitted.

Yep, Gilad Bracha, Philip Wadler, Martin Odersky... all drunken, retarded monkeys.

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

What choice did they have? Either break compatibility, or use type erasure.

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

#110

Post by kamaal » Sat, Mar 31, 2012, 2:35 AM UTC

edwinnathaniel wrote: post #61

kamaal wrote: post #45

Earlier quoted context omitted.

I don't think so, Although I agree with you that COBOL is still alive and kicking. That is totally different that being used for awesome projects and by start ups. If Oracle's plan is to keep Java alive as a glue for their DB that strategy would work fine. But it would be a long term disaster in terms of overall innovation, and long term viability for choosing everyday projects.

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.

According to me the disaster has already occurred. The only section of programmers using Java day in and out for their projects are low price substandard developers who can't write a line of code without the IDE doing autocomplete at every key stroke.

Coming to Android and other Google initiative they tend to happen only because the tooling, documentation support and a large pool of programmers that exist.

Java today is not used because its awesome, its used because for a certain section of industry needs massive supply of low price programmers. And with Java the people, the tooling support and rest is already there.

Hence no doubt Java is the next COBOL.