The Struggle To Keep Java Relevant

snydeq writes "Fatal Exception's Neil McAllister questions Oracle's ability to revive interest in Java in the wake of Oracle VP Jeet Kaul's announcement at EclipseCon that he would 'like to see people with piercings doing Java programming.' 'If Kaul is hoping Java will once again attract youthful, cutting-edge developers, as it did when it debuted in 1995, [Kaul] may be in for a long wait,' McAllister writes. 'Java has evolved from a groundbreaking, revolutionary language platform to something closer to a modern-day version of Cobol.' And, as McAllister sees it, 'Nothing screams "get off my lawn" like a language controlled by Oracle, the world's largest enterprise software vendor. The chances that Java can attract the mohawks-and-tattoos set today seem slimmer than ever.'"

Comments

Groovy

[goombah99]

THe thing that makes me think Java has a huge path forward is groovy.

in theory groovy has all the advantage python has and more. Plus unlike python it has a path forward to a statically typed quasi compiled and generally close-to-c speed when you need it without much effort.

Re:Groovy

[Jurily]

Java got drowned in four letter acronyms on top of yet another layer of XML. I say let it die.

Re:Groovy

[ccarson]

Speed is scalable with hardware so I'm not concerned about Java there. My main concern is whether youth can overcome the environmental hurdles that comes with Java. MS got it write with .NET. Setting up MS's framework is effortless which may attract those who don't wish to fight the platform to incorporate lucene or red5 to their project.

The future of Java will depend on standardization of cross project support. It's gotta be easy like connecting legos.

Re:Groovy

[FlyingGuy]

With syntax like this:

amPM = Calendar.getInstance().get(Calendar.AM_PM)

No thanks.

Re:Groovy

[sjames]

One huge advantage of Python is that it's incredibly easy to incorporate C modules into it or to incorporate it into C. Then you get actually-c speed for the performance critical parts.

How is the C integration for Groovy?

Re:Groovy

[simoncpu was here]

I was about to mod you funny when I realized that "groovy" is a programming language, not something that describes Java.

Oh well, I also realized that I'm starting to grow my own lawn...

Re:Groovy

[Bill, Shooter of Bul]

That's not an advantage to python. Java is nearly as fast as c, easier to write, no chance for manual memory screw ups. I prefer python, myself, but not for your reasons.

Re:Groovy

[Z00L00K]

Whoever that did mod parent to -1 seems to have gone off on a wild hike. That's no Goatse.

Anyway - what Java does lack is primarily good tools for GUI design. People in general are put off by the use of Swing and Awt where the layout consists of object that do float around and have a general unexpected/unpredictable behavior when a window is resized.

A fixed/locked GUI design is a lot easier for many to understand when things stay where you placed them. I can understand the Java design too, but it requires too much time from the programmer to cause comfort and speed.

However - for a lot of things Java is really good. It has a good support for interaction and communication with other systems in a humongous amount of protocols. It does miss some things that C# has, but on the other hand some of the things that C# has are kludges and brain farts to say the least - like the built in Select-statements in C# that aren't compatible with SQL, but their own syntax/language that just causes headache.

You may find Java as a Cobol of today, maybe so, but is it from a good or bad perspective? C# is just similar enough to Java to fall into that same category.

Re:Groovy

[BikeHelmet]

Wrapper objects. If you write them like this...

public boolean isAM()
{
return (Calendar.getInstance().get(Calendar.AM_PM) == Calendar.AM);
}

... then the performance impact is negligible. I wonder if newer versions of Hotspot completely filter the wrapper method out. They seem to in -server mode, but I haven't tested regular desktop mode in recent months.

Oh - bonus points if you store the Calendar instance in a static variable, and never require the getInstance() call again.

Re:Groovy

[Z00L00K]

And if you use 24 hour format you can throw away all that AM/PM stuff right away.

Re:Groovy

[sjames]

C integration is just one of many reasons I prefer Python. However, the ease of integration says a LOT about the internal structure of Python.

The reason I don't just write whatever it is in C is because of the many other advantages of Python.

Re:Groovy

[modmans2ndcoming]

uhhh.....

Linq is not meant to be sql compatible, it is meant to be an interface to any data format you have and it uses sql syntax that most developers are familiar with.

Re:Groovy

[sjames]

Because C is the new assembly language! It has a huge existing codebase. I like having the option of implementing the performance critical bits in C if it proves necessary (often, it doesn't). The way C is called from another language also tells me a lot about the underlying structure of that language.

Re:Groovy

[binarylarry]

JNA makes it very easy to use native code with Java: http://en.wikipedia.org/wiki/Java_Native_Access

Re:Groovy

[IntlHarvester]

The history of Java is very instructive for any aspiring professional coder.

Management: Damn these irreplaceable "programmers"! Look at their goddamn salaries. We need to standardize technology, remove the sharp edges, and train people who understand! Sun has got the thing.

Programmers: Heh. We're going to be spinning out gotta-haveit ETLA frameworks faster than your Indian developers can say 'Yes sir! Right away sir!". Good luck with that. Now bend over and take another load of XML. *cracks-knuckles*

Live by the marketing hype, die by the marketing hype, Sun Java.

Re:Groovy

[mabinogi]

I see nothing wrong with that syntax - it's pretty standard C++ style syntax, the same code is identical in pretty much any C based object oriented language.

Unless of course it was the libraries you had the problem with, not the syntax.

Re:Groovy

[jb_nizet]

Oh - bonus points if you store the Calendar instance in a static variable, and never require the getInstance() call again.

This would introduce a bug in your application, since Calendar.getInstance() always returns a new instance, containing the current time at the moment it is created. Storing it in a static variable and reusing it would return the same time forever.

Moreover, Calendar is not thread-safe and is mutable, so storing it in a shared static variable is a really bad idea.

Re:Groovy

[abell]

I have recently started working on my first project in Scala and I think the situation is quite similar to the Python/C one. Scala is a much more pleasant language to write in, having type inference and a much more dynamic feeling, and in cases when there is no specific library for a task at hand you can just tap into the gazillion Java packages.

Re:Groovy

[kobaz]

C integration with Groovy is the same as C integration with Java... since Groovy uses the JVM, which means making some definitions in Java for the external functions handled by C, adding some extra build options and writing the C module itself. It's the same as any other language... it's fairly easy to write C modules for tcl, perl, python. java, etc... you just need to look up the bindings library and off you go.

Re:Groovy

[shutdown -p now]

JVM as a spec is actually pretty limiting (no raw memory operations, no unsigned integer arithmetic, no tail calls, no parametric polymorphism). In fact, many languages cannot be properly implemented in it at all, or cannot be implemented efficiently. HotSpot implementation is nice in a sense that it does some pretty advanced optimizations

Ruby, Scala, Python, Haskell, Lisp and many other languages already exist on the JVM.

There's no implementation of Haskell on JVM that I know of. I don't think it's even possible to have one that would be useful, because JVM doesn't have tail call optimization. For the same reason, you won't see a proper Scheme or ML implementation on Java.

I know that SISC does tailcalls, but IIRC they do it by ignoring Java stack for locals and rolling out their own heap-based one (they need it for call/cc, anyway), with corresponding performance hit.

Re:Groovy

[clockwise_music]

Couldn't agree more. After coding in Java for 2 years I then moved onto an c# ASP.NET project. I was in heaven. Could get things done 5 times faster, no stuffing around. Java is just configuration hell and terrible documentation. Screw Java, go microsoft.

Re:Groovy

[BikeHelmet]

This would introduce a bug in your application, since Calendar.getInstance() always returns a new instance, containing the current time at the moment it is created. Storing it in a static variable and reusing it would return the same time forever.

That's not a bug - that's a feature!

But in all seriousness - I wrote an app for myself to keep track of reminders, which works similar to anacron. It's about 5 years old now, and still working. I used setTimeInMillis periodically rather than constantly creating new Calendar objects every time a method is called. (which could be thousands of times within a second very occasionally, or no times per second)

Moreover, Calendar is not thread-safe and is mutable, so storing it in a shared static variable is a really bad idea.

In the case of my reminder app, it's single-threaded, so who cares?

Read the bloody docs before you use a class. ;) That's advice everyone should follow.

Once you've read Date, Calendar, GregorianCalendar, and TimeZone, you're probably ready to use those classes.

http://java.sun.com/javase/6/docs/api/java/util/Calendar.html

Re:Groovy

[mcvos]

THe thing that makes me think Java has a huge path forward is groovy.

in theory groovy has all the advantage python has and more.

This is entirely correct. Groovy is really great: accepting (almost all) Java syntax, but offering almost the same level of flexibility and expressiveness as Ruby (it falls short in a few places, though). Accepting Java syntax can also be a problem, however: old Java programmers may cling to their old ways instead of solving their issues with closures, metaprogramming and other powerful constructs.

Also, sticking to Java basics also means that Groovy truth lacks Ruby's power. 0 is false in Groovy (because it's false in Java and C), despite it being a valid value. In Ruby, only false and nil are false, which allows you to do amazing things with logic. Even better, || and && return the last evaluated value, whereas in Groovy, they return true or false. Because of those shortcomings, Groovy's expressiveness falls a little bit short of that of Ruby.

But in the end, closures and metaprogramming are a must for any modern, serious programming language. Java lacks them, Groovy adds them. That alone is more than enough to justify Groovy's existence. But to really make Groovy fly, more Javaisms need to be kicked out.

Re:Groovy

[mcvos]

And Scala is every bit as fast as Java straight out of the box. It's a shame many of those gazillion Java packages suck so much.

Why has Sun still not added a sensible way to deal with Dates, for example?

Re:Groovy

[mcvos]

JVM as a spec is actually pretty limiting (no raw memory operations,

I think practically everybody would agree that's a good thing.

There's no implementation of Haskell on JVM that I know of. I don't think it's even possible to have one that would be useful, because JVM doesn't have tail call optimization. For the same reason, you won't see a proper Scheme or ML implementation on Java.

Isn't Clojure basically Scheme or Lisp for the JVM?

Re:Groovy

[mcvos]

With syntax like this:

amPM = Calendar.getInstance().get(Calendar.AM_PM)

That's not Groovy's fault. That's Sun's fault for writing a retarded Date library and refusing to replace it with something sane.

Groovy has TimeCategory, which is what you want to use. With it, you can just do:
2.months.ago
and get what you'd expect to get.

Re:Groovy

[MillionthMonkey]

Why didn't you import static? The AM_PM wouldn't need the Calendar in front.

When I write shit like this I'm thinking about the objects, not what the syntax looks like. I agree that in Java once you look at what you wrote, it looks like a steaming load, but it's easier to read than certain dynamic languages I've seen where the syntax is nice and short but you have to infer half that crap anyway.

Re:Groovy

[DarkOx]

no chance for manual memory screw ups

This is just false oh sure you can't do some pointer arithmetic wrong and segfault or forget to free something but you sure as heck do things that make the garbage collector lose its marbles. You do need to worry about memory management in Java, not some of the low level details but you do need to think about it. At least if you are working on a nontrivial project.

Re:Groovy

[gbjbaanb]

you forgot the 'committee' stage that gave us stuff like Enterprise Java Beans.

and the lack of progress in required features like Generics (though to be fair, a stable language is a good thing as you can learn it and concentrate on building stuff with it, rather than continually re-learning it. But that assumes you have all the good building-block stuff in it from near the start)
you also forgot the performance and resource usage of it, especially in the early days (and see EJB) that really gave it a bad name.

And, of course, you did mention the marketed 'easyness' of coding it, such that everyone thought you could hire cheapass, crap coders who'd write excellent code in it. Which is also why we have enterprise monstrosities written almost solely in Java.

Java turned into corporate enterprise horribleness. I for one will not be upset to see it go. Now.. C#, if it wasn't that we have gobs of Ram and multi-core 3Ghz CPUs, it too would be tarred with the same brush. EJB == Microsoft Pattern and Practices; Same cheapass coders required to use it; XML for everything and more; its only a matter of time before we have the same monstrosities written using it (though they will be prettier)

Re:Groovy

[JamesP]

Thank you, you made my day!

Re:Groovy

[JamesP]

C integration with Groovy is the same as C integration with Java...

You're right

It's the same as any other language... it's fairly easy to write C modules for tcl, perl, python. java, etc... you just need to look up the bindings library and off you go.

In theory yes, in practice no.

One of the main problem is getting the data from the 'mother language' (like, in python it's one thing, in Java C++ bindings are more common, etc, etc). And then you want to call a function on the other side, etc, etc

Maybe the easiest way is serializing and going through sockets.

Re:Groovy

[kobaz]

A while ago I worked on a java/c app, and it really wasn't that bad to integrate with the jvm and pass data around. It's a matter of reading the docs.

Re:Groovy

[bdcrazy]

Years and Decades old Already Built Optimized and tested C-Libraries that you use python to glue together to rapidly solve real world problems. Hybrid programming is like lego, take the nice building blocks and put them together.

Re:Groovy

[jc42]

Because C is the new assembly language!

Uh, no; C was the new assembly language 35 years ago. By 30 years ago, C had pretty much conquered all, and assembly was a relic surviving in only a few highly-specialized niches.

And a major problem with C for the past 20 years has been the attempts to make it into a good high-level language. The result has mostly been to make it materially more difficult to write good assembly-level code in C, while not producing a good higher-level language.

Re:Groovy

[rve]

I know you're trolling, but I'll bite.

I code in Java for a living, and I'm pretty good at it. Java is not nearly as fast as C. There are a lot of things that Java is more suitable for than C, but (raw) speed is not one of them. Also, if you're relying on the GC to prevent memory leaks, you're using it wrong.

Re:Groovy

[chthonicdaemon]

Python's way around that is to make it trivially easy to implement stuff in C or Fortran.

Re:Groovy

[tehBoris]

Isn't Clojure basically Scheme or Lisp for the JVM?

Yeah, but IIRC they had to put special syntax in it to generate trampolines and loops because they couldn't make proper tail call elimination automatically.

Re:Groovy

[Z00L00K]

That's not the point I was trying to make - the point is that there is yet another syntax that has to be coped with for programmers.

Re:Groovy

[emanem]

Hi, I definitely agree with what you say.
Even if in my comp science student life, and/or professional worklife I have found no equivalents of C++.
With shared_ptr, auto_ptr and STL containers memory management is for newbies and you get all benefits of a properly compiled/optimized language.
The only thing that made me consider Java as a language son of a lesser god is the fact you can't actually manage memory as you wish. You can call the garbage collector, do tricks, but is not the same as telling the OS "look mate free/delete that chunk of memory, restrict my data segment (brk/sbrk)". Or is it possible in Java?
I'm saying this because just the other day a 32 bit (Java run-time process) has reached the limit of 4 GiB and...bye bye.
This is the event that makes me think "hey, why is difficult to use C++ with smart pointers?".
Still I consider Java a good language better than many others, for the reasons you stated before.

Ciao!

Re:Groovy

[sjames]

That would be C++. Ignore it and stick with C for low level stuff. Use another language like Python for the rest.

Re:Groovy

[togofspookware]

if you're relying on the GC to prevent memory leaks, you're using it wrong.

How else would one use a garbage collector?

Re:Groovy

[binarylarry]

You're not even a programmer, you've proved this in other discussions.

Why do you even post? Shouldn't you be copy and pasting some PHP scripts or whatever it is you do?

Re:Groovy

[JamesP]

Have you ever written a device driver for Windows? For Linux? For an embedded device?

Have you ever had to replace the default memory allocator on a C++ program??

You see, I don't have to rely on a "virtual machine" to make my programs run. Also, I don't have the luxury to add more memory to some machines where my code runs.

Re:Groovy

[Bill, Shooter of Bul]

Not trolling. Just commenting some obvious facts in a succinct manner while glossing over the intricacies. Yes, me culpa, me culpa, me maxima culpa, Java is not memmory worry free. It is *Less* of a worry.

Re:Groovy

[rve]

A program written in a garbage collected language can still have memory leaks. GC is there for convenience and speed of development. It's there so you can design and implement a program in a different way; often much quicker to implement, but that doesn't mean you can just stop worrying about making mistakes because the GC will take care of it.

Re:Groovy

[maraist]

You're about 3 years out of date here - annotations, aspect-oriented programming, and reflective-programming in general have replaced XML (outside of some copy-pastable bootstrap stage).

spring2, EJB3, hibernate3, servlet2.5, along with the proliferation of REST and JSON have obviated the need for XML almost entirely. I certainly have cheered on this post-XML movement.

As for 4 letter acrynyms, consider ruby-on-rails. There's nothing intrinsic about the language that makes this powerful, you can do it in perl/python and even java (it's already been done). The only difference is that it's the only one for Ruby, whereas people have tried it different ways in other languages, because one size doesn't always fit all.

Re:Groovy

[FlyingGuy]

That comes straight from the Groovy home page. I kinda figured they would know what they were doing.

isAM is not a method it is a property and thus it would more properly me expressed as:

if( calendar.isAM ){
...
}

Confusing methods with properties is a bad thing. Anything that requires a () after it should properly be a method, not a property and a property that requires a () after it is horrible as it implies it will take a parameter. I do like C but I have never particularly liked the fact that even if you declare a function that takes no parameters you must still have the () after it in declaration and in calling.

Re:Groovy

[FlyingGuy]

Gads I am not sure which is worse!

Re:Groovy

[jamie(really)]

Thats funny, coz after programming C# for 6 years I started to use java, and I find that the libraries available are much better. C# is a nicer language, but Java has tons of really good open source "stuff", like spring, hibernate, and mina. The XML stuff bothered me at first, because I'm used to Visual Studio: if I had classes referenced in XML and I refactored I was fucked. With any java editor worth its salt, e.g. IntelliJ, Eclipse, any given XML format is understood and refactored accordingly. Add Maven2 to that and I spend my time solving problems, not reinventing the wheel.

Re:Groovy

[niteice]

The nice thing is that LINQ is just syntactic sugar. So the two cases are equivalent:

List<int> numbers = { 5, 383, 291, 274, 104, 184, 63 };
List<int> results = from n in numbers where n > 150 select n;
List<int> results2 = numbers.Where(n => n > 150);

If you like to write lambdas instead of SQL-like queries it works just as well and either is very expressive.

Re:Groovy

[Z00L00K]

Is doesn't matter Linq still looks and handles like shit when you are used to SQL.

Re:Groovy

[krishy]

MS got it write with .NET.

You sire did not!

Re:Groovy

[modmans2ndcoming]

try type checking that sql string in your code.

Re:Groovy

[pkphilip]

Groovy is really very, very slow. You are probably better off doing the development in scala or jruby.

Just let it die

[Rix]

There are some good ideas in Java, but they're drowned by the inconsistent implementation, and Oracle will most certainly not make that better.

Re:Just let it die

[zappepcs]

I agree with this. Oracle will have to do some serious sucking up to the world to convince anyone they are not out to destroy everything that MS licensing was unable to touch. I'm not saying that Oracle sucks, just that their business model is not really where the world has been migrating to lately. For more or less all the reasons that MS products are not looking so good these days to many people, Oracle products (including the products they buy) will also not look good. There is reason to think this looks like a sinking ship taking on ballast weights.... IMO

Re:Just let it die

[abigor]

Can you be specific about these inconsistencies? I'd like to hear about them.

As for "letting it die", Java is the default language of enterprise everything. Outside of the embedded world, there's probably more lines of Java currently deployed than anything else. And I have to say, Spring 3.x is actually pretty neat.

Re:Just let it die

[XopherMV]

Swing, Java3D, Vector/ArrayList, StringBuilder/StringBuffer, Date handling, etc.

Re:Just let it die

[Vellmont]

As for "letting it die", Java is the default language of enterprise everything.

He's just part of the Java backlash because it's popular. It's like the people 15 years ago saying "Let C die" because there's C++ or Java now. An essentially useless comment and nothing more than a troll.

Re:Just let it die

[visualight]

You're mostly right. Back in the 90's Sun was so successful in hyping Java I remember VC's funding software companies _just_ because they were focusing on Java. Got it into a lot of (maybe all?) schools too. So damn near every young developer knows Java now and as a result that language gets chosen over others.

So yeah, letting it die might not work, we'll have to be more proactive.

Re:Just let it die

[Anonymous Coward]

Swing,

It's a GUI toolkit. Where's the inconsistency? If you don't like Swing, you can also use the older AWT, SWT, or Qt...

Java3D,

It's a 3D API. Where's the inconsistency?

Vector/ArrayList, StringBuilder/StringBuffer,

In both cases, one of these is synchronized and one is not. Their naming scheme could have been more consistent, but otherwise that seems fine to me.

Date handling, etc.

I'll give you that date handling in Java is a pain the ass, but on the other hand, I've yet to find a programming language that didn't do something related to dates that seriously frustrated me. Every once in a while I think, "How hard can it be to get this right?", so I start working on my own Date implementation, and then I run into timezones, sub-nanosecond precision, string formatting, leap years, leap seconds, all while trying to make it reasonably fast...

Re:Just let it die

[Z00L00K]

For Date handling - regardless of platform you run into date handling issues. The way I work around it is to store the timestamp value instead (the milliseconds since 1970-01-01 for Java) and then I have one key value that I know is consistent and that I can do math with. When I come to presentation of the date I use the suitable date functionality that exists to handle it.

As for language opinions: Look here.

Re:Just let it die

[ls671]

> Swing, Java3D, Vector/ArrayList, StringBuilder/StringBuffer, Date handling, etc.

This is because, unlike what php did when going from 4 to 5, older constructs have always been supported in Java. In the worst case scenario, older constructs are only "deprecated", then a warning is given to you recommending to use the newer constructs but the older ones continue to work fine.

This sure would be a nice feature to have when deploying php 4 applications into a php 5 platform and it is also one big shops with thousands of lines of legacy code are looking for. It is sometimes called "backward compatibility" and I have no problem with that. ;-)

Re:Just let it die

[owlstead]

Inconsistent implementation? Of java, javac or the API? Compared to *what* I ask you? I've seen many API's and I think Java is one of the more consistent ones. At least it is possible to use many many libs without too much fuss (mostly for it's unequaled way of handling strings, exceptions and collections).

Unless there is a more maintainable language in which it is even easier to focus on the problem at hand, I vote for letting it live. And yes, I know that maintainability has no coolness factor about it. No matter, I'll try and make my apps cool instead.

Re:Just let it die

[mcvos]

My University only has two programming courses: C++ and Java

That's terrible. No Prolog? No Lisp? No functional programming language at all? No assembly, for that matter? And what about parallel programming languages? I must have learned about a dozen languages at my university (not all of them very thoroughly, mind you).

Re:Just let it die

[TheDarkMaster]

I agree. As a personal example, a few days ago I needed to create a java application that could communicate directly with the parallel port for the printer status. I found that I need the javax.comm, but it does not come as part of the JVM. And after much work to install it I found that Java was still unable to do what I needed (read the status flags of the parallel port), and to make matters worse I found that support for Windows is ... nonexistent (i need the program working both on Linux and Windows).

Then I could solve the issue with a "hack" of others, but any language that is proposed to be a "language of general use" should do that sort of thing without hacks.

Re:Just let it die

[NewbieProgrammerMan]

From what i could tell at the university where I did my undergrad, the only way you touched anything other than their main language (C++) was if you went on to a graduate CS program. It looked to me like the CS degree was heavily slanted towards making entry-level programmers for local industry, not for giving people a thorough tour of computer science. :(

good riddance

[Anonymous Coward]

java can FOAD, as can the lecturers around the world who bought into sun's bullshit.

for academics there's haskell, for professionals there's C++, and everyone else can suck my dong

the best programmers?

[Anonymous Coward]

Maybe he's barking up the wrong tree. The best young programmers I know don't have any piercings or tattoos that I can see.

I have no data to support this, but I have always thought the best of the tech crowd were too busy being into their tech to get into the body modification scene. I don't think this is different now than it was 30 years ago.

On the other hand, there's a lot I can't see (and in many cases, thank goodness!)

Re:the best programmers?

[Unoti]

I'm gonna go out on a limb here and guess that you don't live or work in the San Francisco area.

Re:the best programmers?

[spiffmastercow]

I have tattoos, and I used to have piercings. I'm also a damn good coder. I seriously doubt the two are related.

Re:the best programmers?

[Alex Belits]

I'm gonna go out on a limb here and guess that you don't live or work in the San Francisco area.

I do, and STILL the best programmers I know have neither piercings nor tattoos.
Attention whores with dubious amount of talent, on the other hand...

Re:the best programmers?

[Trepidity]

I do, and don't see much of that from top coders. If you go to cultural events like SuperHappyDevHouse, meetups at the Hacker Dojo, etc., there are a handful of mohawked/pierced types, but not many. Maybe up in SF proper (as opposed to Silicon Valley) there are more, but I haven't seen 'em.

Now if you're talking web designers, yeah, there's lots of those.

Re:the best programmers?

[keeboo]

I have tattoos, and I used to have piercings.

According to people with piercings and tatoos that is "+4 Insightful".

I'm also a damn good coder.

Thanks for your unbiased opinion.

I seriously doubt the two are related.

I seriously doubt a person who uses him/herself as a positive example to prove a point.

Re:the best programmers?

[selven]

but I have always thought the best of the tech crowd were too busy being into their tech to get into the body modification scene.

Programmers care about things being useful, not pretty. It applies to the software they write and it applies to the body modifications they are willing to accept.

Re:the best programmers?

[mcvos]

The best young programmers I know don't have any piercings or tattoos that I can see.

I have a wedding tattoo. But then, I'm old.

Re:the best programmers?

[spiffmastercow]

I'm often amazed at the level of hostility on /. to anyone who claims they are good at what they do. In comparison to the programmers/developers/software engineers/architects/whatever title inflation demands a coder be called, I'm pretty good. And I should be, since I've been coding for 15 years. Judging someone's coding ability based on their appearance is utterly retarded, as is believing in stupid rules like 'only people who suck at something will claim to be good at it'.

Re:the best programmers?

[spiffmastercow]

I disagree. If I write ugly code, it keeps me up at night. If the only way I can do something is with a hack, I get pissed off. My aesthetic concerns may not be predominantly visual, but they're there.

Re:the best programmers?

[selven]

I was referring to what the final product looks like, not the underlying algorithms.

Re:the best programmers?

[icebraining]

You may be a good coder, but you suck at reading. Nowhere did GP said you were a bad coder, he said you're biased.

Re:the best programmers?

[spiffmastercow]

I have tattoos, and I used to have piercings. I'm also a damn good coder.

Anyone who refers to themselves as a "coder" is just a kid with delusions of grandeur.

Or a person who doesn't give a shit about title inflation. I've been a programmer, developer, lead developer, software engineer, data architect, and (most recently) a computer specialist. Under which of those titles do you think I did the most impressive work? Hint: it's not the one you think it is.

Re:the best programmers?

[jamie(really)]

Well there was a study that I read once (but I'm fucked if I can find a link to it) that measured people's IQs, and their perceived IQ. People with lower IQ universally thought they did well on the tests. People with high IQs thought they did worse. Specifically, there was an inverse correlation between how well a person thought they did and their IQ.

This appears to be matched by experience. If someone tells me a task is going to be easy, or that they can do it "no problem", then 99/100 its going to be a train wreck.

Caveat: if there is a manager in the room, its ok to say something is going to be easy because managers get scared easy. I'm talking about if its just a bunch of programmers talking. :-)

Re:the best programmers?

[spiffmastercow]

Citation please? I don't disagree that stupid people often feel they are stupid, and vice versa, but I don't think it's definitive. Furthermore, people with a lot of technical ability are often arrogant (anecdotal observation). Engineers and MDs are the worst about this, IMO. Also, please note that I never claimed to have a high IQ, but rather that I'm a good programmer. It's a skill, not an attribute.

Cutting edge == Johnny Rotten?

[Vellmont]

Someone emulating the punk movement of 40 years ago is "cutting edge"? If that's his idea of "cutting edge, hot talent", he needs to stop thinking he's in the movie "hackers" and he's looking for Angelina Jolie. Associating dress or style with talent is stupid no matter if it's "you wear a suit, you're smart" or "you've got 3 piercings and drive a crotch rocket you're the next big thing"

Demanding innovation never works. Innovation just happens from a need, not a demand from some Oracle guy who desires it and thinks it'll be good for marketing. There are interesting things happening in Java. Scala is certainly interesting. I haven't used it myself, but I'd love to try it if I had a good project to use it in.

Re:Cutting edge == Johnny Rotten?

[mooingyak]

Someone emulating the punk movement of 40 years ago is "cutting edge"? If that's his idea of "cutting edge, hot talent", he needs to stop thinking he's in the movie "hackers" and he's looking for Angelina Jolie. Associating dress or style with talent is stupid no matter if it's "you wear a suit, you're smart" or "you've got 3 piercings and drive a crotch rocket you're the next big thing"

Valid points, but I think you're taking him more literally than he meant it. He wanted to convey the idea of 'cutting edge', and to be honest it seems like both you and I understood what he meant even if his example is a bit cliche.

Re:Cutting edge == Johnny Rotten?

[ponraul]

I doubt that he remembers using Java or things written in it fifteen years ago when kids with mohawks routinely brought computers to a halt with their buggy AWT GUIs and applets.

Personally, I prefer my software to come from disciplined engineers and not some caricature listening to a Prodigy mix-tape, chugging Jolt Cola straight out of a two-liter bottle and admiring the reflection of his cyan colored hair in the flicker of his amber terminal that he salvaged from an unsecured dumpster in an industrial park.

Re:Cutting edge == Johnny Rotten?

[zanewatts]

With the global economy in a downturn comes reduced profits for Oracle being able to see a growth in their core products. If anything there will be a larger than normal downturn in core customers in the near future for their RDBMS and RAC as less expensive solutions become more and more available. Java has a long future though in many fronts. Like anything, there is the good,bad and ugly. The ugly being this cheap marketing ploy. Silly

Re:Cutting edge == Johnny Rotten?

[Vellmont]

He wanted to convey the idea of 'cutting edge', and to be honest it seems like both you and I understood what he meant even if his example is a bit cliche.

I understand what he meant, I just think it's kind of stupid. Call me crazy, but I'd rather focus on keeping a language relevant to the kinds of problems people are trying to solve, not trying to maintain some level of trendiness like the latest cool band.

All languages have a useful lifetime, and Java is no exception. Languages have come a long way since the abomination of something like COBOL, so the comparison is more than a little stupid. As an industry advances the tools become more advanced and long lived. I don't see anyone worrying that circular saws are going to "die" anytime soon in carpentry.

Re:Cutting edge == Johnny Rotten?

[Vellmont]

I doubt that he remembers using Java or things written in it fifteen years ago when kids with mohawks routinely brought computers to a halt with their buggy AWT GUIs and applets.

I've seen buggy code come from well dress nice looking people who just didn't know what the hell they're doing. I've seen great code come from long haired weirdo's who are thoughtful and would be extremely offended if you called them an "engineer".

The point being, trying to find some set of outward properties for good software developers doesn't really work. You have to be smart, but even smart doesn't make a good developer. You have to be smart enough to know you're dumb (an exceedingly important quality).

Re:Cutting edge == Johnny Rotten?

[Tablizer]

It was mostly a figurative statement that you took too literally. The punk-like examples were a stand-in for "edgy youth".
   

Re:Cutting edge == Johnny Rotten?

[arjan_t]

I've seen buggy code come from well dress nice looking people who just didn't know what the hell they're doing. I've seen great code come from long haired weirdo's who are thoughtful and would be extremely offended if you called them an "engineer".

Sure, and I've seen long haired tattooed weirdos not knowing the first thing about correctness, stability or consistency of their code, and where basically every other class of theirs has a different layout and does similar things in a different way. You know, the kind of code where they store an image in the root folder as /tmp.png with the excuse that 'it's very unlikely that 2 people upload an image exactly at the same time'. Yes, I've heard those 'cool kids' uttering stuff like that.

Just because you are a 'cool kid' does not necessarily make you an intelligent, well thinking developer.

The point being, trying to find some set of outward properties for good software developers doesn't really work. You have to be smart, but even smart doesn't make a good developer. You have to be smart enough to know you're dumb (an exceedingly important quality).

Exactly ;)

Re:Cutting edge == Johnny Rotten?

[MagikSlinger]

There are interesting things happening in Java.

Since I was forced into Java EE programming 3 years ago, I have to agree with this. When I got into it, I figured it was another COBOL. But when you got innovations like Maven, the entire Apache Commons library, RichFaces/JSF, etc. I really began to like Java -- seriously! I put away my childish .Net books and moved on. :-)

Although I must admit, for full disclosure, that I never liked PHP even when developing in it. Maybe because almost every PHP book I've ever seen includes code like:

sql = "SELECT * FROM foo WHERE id=" . $foo;

shudder

Re:Cutting edge == Johnny Rotten?

[rjiy]

  Call me crazy, but I'd rather focus on keeping a language relevant to the kinds of problems people are trying to solve, not trying to maintain some level of trendiness like the latest cool band.

On the other hand, trends are relevant too.

What is out there right now?

[ipquickly]

"I would like to see people with piercings doing Java programming,"

So what do people with piercings do now?

Re:What is out there right now?

[Macrat]

So what do people with piercings do now?

Work at Starbucks.

Re:What is out there right now?

[nitehawk214]

So what do people with piercings do now?

Work at Starbucks.

Java engineers.

Re:What is out there right now?

[McNally]

So what do people with piercings do now?

Work at Starbucks.

Which involves java, no? So what's the problem?

Re:What is out there right now?

[mrjb]

"I would like to see people with piercings doing Java programming,"

Never mind the people. I just want to see those piercings doing Java programming.

wow

[phantomfive]

When did "youthful, cutting edge developers" become equated with "the mohawks-and-tattoos set?" All I can think about when I see a mohawk these days is the 80s and Mr T.

Re:wow

[M. Baranczak]

Maybe Oracle should hire Mr. T. I don't think he's doing anything much at the moment.

Re:wow

[mcvos]

Maybe Oracle should hire Mr. T. I don't think he's doing anything much at the moment.

I think he's selling stuff on TV. Youthful, cutting edge stuff like World of Warcraft and new kinds of ovens.

Re:wow

[Blakey Rat]

This is one of the indicators that the person writing the article is full of shit. He doesn't even know what a youthful developer *looks like*, and yet he's trying to tell Oracle/Java how to recruit them.

um

[Anonymous Coward]

um google app engine? spring? android? gwt? groovy?

Please it's evolving and even finding new uses.

All those "java is going to die" people are silly and not grounded in reality. Plenty of talented developers see its power and use it.

Re:um

[Jurily]

All those "COBOL is going to die" people are silly and not grounded in reality. Plenty of talented developers see its power and use it.

Re:um

[Tumbleweed]

um google app engine? spring? android? gwt? groovy?
Please it's evolving and even finding new uses.
All those "java is going to die" people are silly and not grounded in reality. Plenty of talented developers see its power and use it.

Just a note here - I'm interested in Android app development *despite* its use of Java, not _because_ of it. Still, at least it's not perl. *shudder*

Re:um

[mabinogi]

you know, copy and pasting a sentence and replacing a work in it is very easy, but it doesn't actually constitute an argument, despite what a number of slashdotters might think

Re:um

[Hognoxious]

you know, copy and pasting a sentence and replacing a work in it is very easy

Apparently it's too difficult for you.

Re:um

[JamesP]

um google app engine? android? gwt? groovy?

Yeah, too bad that's nothing to do with the java language, rather, with the JVM (and not even that in android)

Spring!?? Most of it comes with other languages and frameworks, without all the hype.

Re:um

[Jurily]

Just because people can't get rid of it doesn't mean it shouldn't die.

In 1997, the Gartner Group reported that 80% of the world's business ran on COBOL with over 200 billion lines of code in existence and with an estimated 5 billion lines of new code annually.

It's evolving, too:

Work is progressing on the next full revision of the COBOL Standard. It is expected to be approved and available in the early 2010s.

And if you still think it's unfair to compare Java to COBOL, I got news for you.

Re:um

[sourcerror]

So, what can you do with C# that I can't with Java+Scala?
What does the language of the future has to know?

Re:um

[ElForesto]

Not to mention Blackberry, a platform with a commanding (for now) 44% of the smartphone market. Combined with Android and various dumbphones, the odds are that if you're doing mobile development, you're using either Java or Objective C. It's also used in a significant number of middleware projects and for server backends. You know, stuff that's really important that you don't see. Anyone dumb enough to discount Java as dead just because its use on the desktop is limited deserves to march themselves right into irrelevancy in the job marketplace.

Re:um

[mabinogi]

yes, so it would seem...

tattooed love boys program?

[skyler_fox]

let me get this straight... Java needs tattooed programmers to be relevant? Snarky comments about Cobol aside, Java is the current programming workhorse. It provides the greatest infrastructure and options for scalability. Since when does fashion dictate what technology is best for the job?

Re:tattooed love boys program?

[mrjb]

It provides the greatest infrastructure and options for scalability.

This also shows, at the same time, what I perceive as being the main problem with Java. Scalability, high availability and generally making things enterprise-y does have a big impact on complexity, and as such on maintainability as well.

When rolling out *any* Java application, the tendency is to make sure it's scalable, and that it works in a HA cluster, because it may be difficult to "staple on" scalability and high availability later on. Fair enough?

But what I see all the time is situations where tuning for high availability results in more downtime than it prevents; situations where the scalability options are not used because they were not needed in the first place.

If there is so much focus on using technology that is not needed, at the cost of having low-maintenance systems, then indeed it was technology for the sake of technology. Or in other words, it was fashion dictating the technology to use for the job, rather than actual requirements.

Re:tattooed love boys program?

[LizardKing]

let me get this straight... Java needs tattooed programmers to be relevant?

I better amend my CV to mention that my entire right arm is tattooed then. Not sure I should mention where I've got a piercing though.

Re:tattooed love boys program?

[skyler_fox]

So which magical, fashionable language optimizes itself? I agree that there are herds of languages and frameworks that will allow someone to create a system that will serve even medium size load. But I have yet to see any language that will self optimize, and I am not sure that I would trust one that did. Scalability/Optimization usually take place outside of Java proper anyway, either at the application server level, the database level or at the caching layer. And from what I have seen most modern frameworks use the same sorts of options. Heaven help the poor Ruby on Rails programmer that thought the data layer was going to scale by itself. I don't really want to be put in the position of defending Java if there is a better option out there, but I don't see it.

good coders will follow the money

[ilmdba]

piercings and mohawks somehow make someone 'cutting edge' or a better coder?  i think not.

good developers will follow the jobs.

i'll save you the trip to monster.com, here are some search results from there:

search  results
------  -------
java    5000+
.net    4581
c++     3706
c#      3369
perl    2569
python  1035
ruby    547
cobol   286

- 5000 is apparently the limit for the number of results a query can provide at monster.com (weak) so there are most likely far more that 5000 java jobs in their database
- couldn't figure out how to search for C reliably, but it's probably up over 5000 as well.

Re:good coders will follow the money

[pushing-robot]

So true. Popularity is one of the worst ways to measure interest.

Re:good coders will follow the money

[abigor]

Popularity isn't a good measure of relevancy?

Re:good coders will follow the money

[michaelmalak]

piercings and mohawks somehow make someone 'cutting edge' or a better coder?

Youth makes one a cheaper coder, which in the eyes of management is better.

Re:good coders will follow the money

[Hurricane78]

Actually, if you look at smaller data sets (regional ones), and data from other job sites that have language categories, you will notice, that Java tops out even C by a good bit.

Re:good coders will follow the money

[istartedi]

couldn't figure out how to search for C

Maybe the Craigslist trick works. Try searching for "letterc".

Re:good coders will follow the money

[moosesocks]

- 5000 is apparently the limit for the number of results a query can provide at monster.com (weak) so there are most likely far more that 5000 java jobs in their database

Yeah. Apparently their java-based search engine runs out of memory at around 5000 results....

Re:good coders will follow the money

[Prof.Phreak]

you do of course realize that number of job postings is inversely proportional to the $$$ a developer makes. ie: I'd imagine those cobol developers making $200k/year vs $50k/year for those gazillion Java job postings.

Re:good coders will follow the money

[Tablizer]

That's because it takes more Java programmers to produce the same product. A jobs program, perhaps, but not a productivity program.

Re:good coders will follow the money

[dr00g911]

Thank the powers that be Ruby's in the basement, but seriously... the search engine utterly explodes.

Not really the most persuasive argument.

--D

Re:good coders will follow the money

[noidentity]

Yeah. Apparently their java-based search engine runs out of memory at around 5000 results....

It's evolved beyond those other languages that don't limit population growth, and later crash due to overconsumption.

Re:good coders will follow the money

[_newwave_]

No, GOOD developers will follow the GOOD jobs. Now try resorting the list by both the average quality of job and the most elegant syntax offered to do just that with the given language.

Re:good coders will follow the money

[_newwave_]

Actually, it's a cached page from google, because this stupid end user (aka, comment author) didn't have the sense that the JVM takes 5 hours to start and set is browser timeout settings appropriately. the last time this article was actually worked it stopped at 5k results when the dinosaur that "engineered" it thought that 10 minutes of up-time with results he liked meant that the http request to MSSQL Reporting worked.

Re:good coders will follow the money

[AtlantaSteve]

Ding ding ding! We have a winner! The problem I have with most Java-bashing is that it seems so utterly disconnected with the real world and the marketplace.

I read comments in this thread, and they sound like, "Last night I was analyzing differences between Erlang and Smalltalk, and while pondering the merits of Lua vs. Forth I realized that Java doesn't support true closures...". Hey, do you even work as a programmer? I mean, programming professionally... do you get PAID to write code? Enough to support a mortgage and retirement savings and all that livelihood stuff? Have you ever kissed a girl?

I enjoy tinkering with scripting languages and "new" (or at least repackaged from Lisp) programming concepts myself. But when I need drivers to connect to a database (other than MySQL!!!), or to an inventory system on an old IBM midrange box, or just about anything else used in the business world, I need Java. When I need mature toolsets and continuous integration systems, such that I can work in a team of two dozen or more programmers and keep everything straight, I need Java. When I need my credibility with management tied to figures who don't go by names like "Why The Lucky Stiff" and who don't make a childish ass of themselves every time they open their mouths, then I need something like Java. When I need to post my resume on the major job hunting sites, have recruiters call ME, and have my next gig nailed down within two weeks... I need Java.

With Java, I'm even able to "sneak in" some things like Jython or JRuby here and there... so that if indeed the "paradigm shift" occurs during my career, I'll be able to hype those experiences in my resume and have a foot in that door. However, I'm not holding my breath. There are so many factors which come into the picture when doing large-scale enterprise development, and such a different skillset and mindset required. Where a project uses one of these scripting languages, it would wind up LOOKING LIKE Java development anyway. It takes years to get used to that mindset, whereas it took me about an hour and a half to get the hang of closures... so I feel pretty comfortable no matter which way the industry goes.

Re:good coders will follow the money

[Chemisor]

> piercings and mohawks somehow make someone 'cutting edge' or a better coder?

The article is talking about attracting a younger audience, which they equate with some of their more appalling (to the older generation) fashion markers like piercings and mohawks. If you can't attract younger developers, you'll eventually die out. Older programmers burn out, get married, and have little interest in working 80 hour weeks. They also cost several times more than a fresh graduate, and while that often correlates with higher skill and better quality output, these things have little effect on a manager's short term bottom line. So the old people get laid off in hopes of attracting a younger and cheaper generation. If a company fails to do the latter, they end up with no developers, no code, and no money. That is the path to bankrupcy.

Re:good coders will follow the money

[JamesP]

So??

That's like saying "there are more jobs flipping burgers than electricians, so you better shoot for flipping burguers'

Also, the pay is less (most likely)

Re:good coders will follow the money

[blaster151]

Also, I'd add up the results of the .NET and C# searches - in this context they might be considered as interchangeable, as C# is the most popular implementation language for .NET development.

Re:good coders will follow the money

[hoggoth]

> Great... except that if you know Cobal you can just demand a truck load of money and get it because there are so much fewer developers than there are jobs.

Hint: If you are putting it on your resume, you'd better spell it right.

Re:good coders will follow the money

[ZipprHead]

Monster.com is a .NET site.

Re:good coders will follow the money

[vaporland]

The chances that Java can attract the mohawks-and-tattoos set today seem slimmer than ever.

Unless, of course, they want a job...

With piercings...?

[Kozz]

I thought that having excessive piercings (plus mohawks, tattoos) was the way to tell the world, "I don't ever want to be someone's boss."

Re:With piercings...?

[penguinboy]

You say that as if it's a bad message to send. Some people like getting things done, not pushing paper in management.

Re:With piercings...?

[grouchomarxist]

Or "I don't want a boss".

Re:With piercings...?

[JamesP]

I'm glad you didn't say anything about having a ponytail...

Re:With piercings...?

[Kozz]

I think ponytails these days are FAR more rare than multiple piercings or tattoos. There's only one guy I can think of in our offices (of several hundred) who has a ponytail. But he's the one known for visiting the salad bar after NOT washing his hands in the restroom. Ick.

But I'm sure you (and your other ponytail-loving friends) are far more sanitary-minded.

Re:With piercings...?

[JamesP]

Have you heard of Jonathan Schwartz???

Re:With piercings...?

[colinrichardday]

Yeah, he's some guy who couldn't prevent Oracle from buying his company.

JVM keeping it alive

[godofredo]

Java will remain relevant because of the large number of languages being built for the JVM: scala, erjang, clojure, groovy etc. Thus writing libraries in java has significant appeal.

JJ

Re:JVM keeping it alive

[polgardy]

Erlang?

Re:JVM keeping it alive

[TheTurtlesMoves]

And the openJDK will mean that Oracle ability to shaft it will be limited. Java will remain relevant just like C will.

Nothing screams get off my lawn like this comment

[jason.sweet]

like to see people with piercings doing Java programming.

The amount of drugs involved in the decision to get said piercings is not conducive to good software engineering.

Here's how to make Java again

[grepya]

The problem with Java today is... it's syntax looks too much like C. And as everybody knows, C is for geezers. Can't we write java code as follows:

<class>
<classname>MyPony</classname>
<method>Run</method>
<code>
<if><condition>IsExcited</conditon>
<if_block>walkFaster </if_block>
</if>
<method>trot</method>
<method>gallop</gallop>

.
.
etc...
  Once the java manufacturing association fixes the syntax to my satisfaction, I'd give up on my 10 GL super auto functional metaprogrammers language (Saufml) and start writing java code. Until then, I'll keep working on my latest NoSql data-store for my soon to be mobile-social-media-empire (leveraging P2P crowd-sourcing) in my beloved Saufml.

Oracle has some work to do

[hedrick]

Java isn't about to become irrelevant. There's no chance it's going to be the latest thing, because that opportunity only comes once. But if you want a language for doing major projects with long lifetimes, there's really Java, .NET and C++. For a lot of things, Java or .NET makes more sense, and realistically .NET limits you to Windows. For that class of things, the limiting factor in Java now is that Sun does't support the same range of APIs that MS does. Particularly desktop APIs needed for things like multimedia and games. If I wanted to make Java as useful as possible I'd put some manpower into that, and find ways to put some of the newer interpreted languages on top of the Java JVM. That would give them access to a good compiler and to the range of packages available in Java. (Despite a more limited set of APIs than .NET, there's still more than a newer language would otherwise have available.)

Re:Oracle has some work to do

[binarylarry]

What? For every .NET API there are 5+ APIs for Java.

I agree though, Java's only really failing so far has been on the desktop. Server wise it dominates. It's on almost every mobile platform and with Android's popularity sky rocketing it's dominance in the mobile space will only solidify.

Re:Oracle has some work to do

[shutdown -p now]

What? For every .NET API there are 5+ APIs for Java.

Depends on the area. For example, Java has many more web frameworks or ORMs. But then some tricks are simply beyond its reach, because it doesn't have the language features that are needed to complete the puzzle, whereas .NET (C#/VB) does - e.g. LINQ (specifically its expression trees, though using it for general-purpose monadic computations is also a neat hack), or first-class functions and concise lambdas.

Re:Oracle has some work to do

[pjt33]

Particularly desktop APIs needed for things like multimedia and games.

The advantage .Net has here is that MS can add stuff to it without caring about non-Windows platforms. There are a couple of widely used third-party Java bindings for OpenGL / OpenAL (and one of them was brought in-house until the Oracle buy-out), and I believe that OpenCL will be supported soon.

The Java game development community is small, but there are some very profitable companies. The big lack is multimedia support.

Also, there are some curious gaps in the .Net libraries which are currently filled by third parties - .zip (de-)compression springs to mind. So it's not entirely one-sided.

If I wanted to make Java as useful as possible I'd put some manpower into that, and find ways to put some of the newer interpreted languages on top of the Java JVM

Like Jython, JRuby, etc?

Re:Oracle has some work to do

[leenks]

I think you are spot on with your post, apart from one thing - do you really think that Java has a limited set of APIs compared with .NET? What is missing in Java that is in .NET (I work with both and I can't say I agree)?

Re:Oracle has some work to do

[hedrick]

I'm assuming (without having used it myself) that .NET does a better job of desktop support than Java. I am particularly concerned with JMF. Sakai (a course management system that we use) had a rather nice video conferencing component. It's been abandoned by its developer, largely because JMF was never finished for the Mac, and generally doesn't support what you'd expect. But JMF just happens to be the one thing I need at the moment. I believe that are a number of other examples.

If .NET doesn't have better support for applications like this, then I retract my statement, but still think Java needs to do more with the desktop.

Re:Oracle has some work to do

[ScrewMaster]

It's just my own observation, but it seems Java enjoys a stronger long term trust.

And I'd agree with you, because there was longer term trust in Sun than there was in Microsoft. The problem is, now Sun has been replaced by Oracle (Oracle. Why did it have to be Oracle? I'd rather IBM had ended up with Java, personally) as the official steward of Java, and nobody trusts Larry Ellison and Co. Any trust that Sun Microsystems earned in the Java space isn't worth jack, anymore, and that's sure to drive some Java types right in to Ballmer's arms.

Re:Oracle has some work to do

[TheTurtlesMoves]

Despite what a lot of people think. The games market on PC/servers etc is pretty small. Sun was wise not to push it really. For games you would need Xbox..etc to support a jvm for it to really make sense. And that will not happen for a number of reasons.

However there is lwjgl (opengl/openal binding for java), and most common higher level languages can run on top of a JVM these days. (Jython, JScheme, Kawa, lua, ....)

Re:Oracle has some work to do

[Blakey Rat]

They gotta get the *basics* of desktop software working before trying for games and multimedia. I've still yet to see a Java GUI program with a UI worth using, although I have to admit Eclipse is getting close.

Tempest, meet teacup...

[neiras]

I make a lot of money working with Java. I have piercings. I've been known to have hair in a primary color.

Seriously though. Android applications. Eclipse. Adsense, GMail, Wave - in fact, just about every big Google web application (yes, even the client side stuff is written in Java and translated to Javascript). Openfire XMPP. Tomcat. Geronimo. ActiveMQ. Azureus.

You can badmouth Java all you want, but performance and tooling are excellent and there seems to be an infinite supply of libraries and sample code. It runs in lots of different places. There are 100% open source implementations. You can compile it to native code. You can run it in the CLR.

I know it's trendy to play with Ruby and Python, and that's fine. I'm a big fan of Scala, which runs on the JVM. I believe Twitter's backend is at least partially built on Scala. El Reg, I know, I know.

Anyone who thinks Java is fossilizing needs to give their head a shake. It's everywhere, and it's being used in very diverse ways.

If that doesn't excite this mythical "pierced programmer", then said idiot is too busy practicing the Hipster Doctrine - studied disinterest.

Re:Tempest, meet teacup...

[Sarten-X]

I just recently got a job at an all-Java shop. I might, if I feel the need, write a shell script or two. From what I can tell, Java's still accepted in the "real world", but it doesn't have the hype it used to.

Java's Big Thing was its ability to be written once, and run on VMs on any platform. That advantage was promptly killed by the rise of AJAX and all its cross-platform happiness. The same buzz Java once enjoyed is now held by cloud computing, for much the same reason: it allows programmers to write something once, and not worry about the future as much. As languages have progressed, we've consistently moved away from hardware-specific details. Today, I see Java as a sort of middle ground between using the "edgy but immature" languages like Python, and the "old but crusty" languages like C and C++. It has enough libraries and tie-in packages that any modern technology can be easily implemented.

Programmers today don't want to (and shouldn't need to) deal with memory allocation, pointers math, or any such arcane matters. They also don't want to have to refactor as their chosen language tries to stabilize itself. This is why C rose to such prominence. It allowed programmers to stay away from the processor. Java currently allows programmers to stay away from the operating system. Eventually, I expect we'll move toward even more abstract languages, where we just need to specify what we want, and the compiler (or something) will figure out the steps needed to reach that goal. It'll be an automatic software engineer, just as compilers are automatic replacements for the grad students who used to translate programs into machine code.

Here's to the future, where I, too, will be obsolete.

Re:Tempest, meet teacup...

[noSignal]

You're exactly right. Anyone who feels that java needs help staying relevant doesn't write software for a living.

Re:Tempest, meet teacup...

[Logic and Reason]

Seriously though. Android applications. Eclipse. Adsense, GMail, Wave - in fact, just about every big Google web application (yes, even the client side stuff is written in Java and translated to Javascript). Openfire XMPP. Tomcat. Geronimo. ActiveMQ. Azureus.

You're missing the point. Nobody denies that Java is used everywhere; the point is that it is no longer (if it ever was) a cutting-edge language, the kind that "pierced programmers" get excited about.

I know it's trendy to play with Ruby and Python, and that's fine.

Using the word "play" shows that you have no idea just how much real work is being done in these languages. And they're growing in popularity precisely because they are exciting to use. After all, if the kinds of "practical" concerns you mentioned (ubiquity, performance, libraries) were the only things that mattered then we'd all still be using FORTRAN, COBOL, or C.

Re:Tempest, meet teacup...

[shaitand]

"but performance and tooling are excellent"

Did you really just claim that java performance is excellent?

Re:Tempest, meet teacup...

[Alex Belits]

Java programmer never seen a program that fits into L2 cache of a modern CPU, so Java performance seems "excellent" to him.

Re:Tempest, meet teacup...

[serutan]

Yeah, I was going to say I thought people with piercings already did Java programming. But then you can't expect a corporate VP to know that. He probably still thinks leet-speak is kewl.

Re:Tempest, meet teacup...

[binarylarry]

Yeah he did because Java performance IS excellent these days. Not that it couldn't be better (everything can always be better for everything).

But Sun's JVM is very competitive with native code in terms of performance and it's massively better in most other areas (security, debugging/tools, profiling, code reuse and design, etc)

Re:Tempest, meet teacup...

[BikeHelmet]

Eventually, I expect we'll move toward even more abstract languages, where we just need to specify what we want, and the compiler (or something) will figure out the steps needed to reach that goal. It'll be an automatic software engineer, just as compilers are automatic replacements for the grad students who used to translate programs into machine code.

Here's to the future, where I, too, will be obsolete.

And if Adobe's new image and video manipulation in CS5 are any indication, it'll do it 1500x faster than a human can.

Good thing most programmers like being employed, and aren't working on projects like that. :P

Re:Tempest, meet teacup...

[fm6]

"Tempest in a teacup" means a small problem that's being overblown. This isn't even a small problem. This is one poorly-informed pundit struggling to get out his daily quota of BS. It always bugs me that idiots like that actually make a living with their idiocy.

Re:Tempest, meet teacup...

[neiras]

Nobody denies that Java is used everywhere; the point is that it is no longer (if it ever was) a cutting-edge language, the kind that "pierced programmers" get excited about.

*My* point was that "pierced programmers" who can't get excited about new and diverse ways of doing things (in ANY language, regardless of age) are missing out on the best part of their job.

Using the word "play" shows that you have no idea just how much real work is being done in these languages.

No it doesn't. I'm a software guy, through and through. Languages are play to me. As I alluded in my original post, I don't live in the ironic, sarcastic Hipsterverse. You have no idea what tools I've used in the course of my Real Work.

It seems I hit a nerve! Piercings are painful at first, aren't they.

After all, if the kinds of "practical" concerns you mentioned (ubiquity, performance, libraries) were the only things that mattered then we'd all still be using FORTRAN, COBOL, or C.

I don't believe I said that. Here, have a read.

Re:Tempest, meet teacup...

[Tablizer]

Anyone who thinks Java is fossilizing needs to give their head a shake. It's everywhere, and it's being used in very diverse ways.

So is COBOL, and COBOL is fossilized.

Re:Tempest, meet teacup...

[Tablizer]

This is why C rose to such prominence. It allowed programmers to stay away from the processor. Java currently allows programmers to stay away from the operating system.

By becoming one. We once had a kit that used Java underneath, and when the daylight-savings times changed per Congressional law, the Java engine didn't know about it even though Windows Server got the upgrade. It had its own time computation engine when it *could* have used the OS's. It took us a while to get a working fix from Sun.

Re:Tempest, meet teacup...

[Logic and Reason]

*My* point was that "pierced programmers" who can't get excited about new and diverse ways of doing things (in ANY language, regardless of age) are missing out on the best part of their job.

So tell me: what is "new and diverse" about Java?

No it doesn't. I'm a software guy, through and through. Languages are play to me. As I alluded in my original post, I don't live in the ironic, sarcastic Hipsterverse. You have no idea what tools I've used in the course of my Real Work.

Are you asserting that "I know it's trendy to play with Ruby and Python" doesn't strongly imply these are toy languages?

It seems I hit a nerve! Piercings are painful at first, aren't they.

I don't even use Python or Ruby. Nice try, though.

I don't believe I said that. Here, have a read.

You certainly implied it, by pointing out those qualities of Java as if they were an answer to the criticism that Java isn't fun or exciting to use.

Re:Tempest, meet teacup...

[owlstead]

Mod parent up, I was about to quote that overpaid idiot from Cap Gemini 15 years back that said the same thing (in a university class), but this is much better.

Wake me up when computers understand context (say, 30 years on if not way more).

Re:Tempest, meet teacup...

[Terrasque]

Anyone who thinks Java is fossilizing needs to give their head a shake. It's everywhere, and it's being used in very diverse ways.

Well, to be exact, so does oil... ;)

Re:Tempest, meet teacup...

[ErikZ]

Yeah. Do you think Oracle has any interest in developing those VMs? Or if a new OS comes out, will they write a new VM for it?

Budget time is coming! You know, removing OS/X and Linux VM development would save Oracle some cash.

Re:Tempest, meet teacup...

[LizardKing]

Did you really just claim that java performance is excellent?

Java performance for real world implementations is excellent. And I say that as someone who only stopped coding the most performance critical parts of a project in C a couple of years ago, when carefully crafted C code for one project was outperformed by a colleagues Java version. As long as you understand a little of what the JVM does under the hood, you can code Java that is highly performant, in a fraction of the time it would take to debug and plug the memory leaks in C/C++ code.

Re:Tempest, meet teacup...

[shaitand]

"And I say that as someone who only stopped coding the most performance critical parts of a project in C a couple of years ago, when carefully crafted C code for one project was outperformed by a colleagues Java version."

I don't think I would be saying that out loud. That speaks of your lack of skill at tuning C code not Java performance. There are a few textbook scenarios where this can happen with properly written code but it is rare enough that the first thing a Java fan does is publish a paper on the subject.

Re:Tempest, meet teacup...

[ScrewMaster]

just as compilers are automatic replacements for the grad students who used to translate programs into machine code.

Just as render farms replaced the "tweeners" who created all the in-between frames from the key frames drawn by a master animator. Automation, in a word. Whether that will be good for software engineering as a career is yet to be determined.

Re:Tempest, meet teacup...

[JamesP]

Seriously though. Adsense, GMail, Wave

[Citation needed]

Except for GWT of course.

And then you have BigTable (C++) and Google File System (C/C++)

<quote>
</p><p>You can badmouth Java all you want, but...runs in lots of different places.</quote>

Funny how one of the last things to run on Linux 64 bit was the JVM. Oh yeah, and even Flash became more popular as a 'run everywhere' platform on the web.

Re:Tempest, meet teacup...

[LizardKing]

Note that I pointed out the time factor in developing a C solution (and a C++ one to a pretty similar extent) as compared to developing one in Java. I can program C/C++ just fine, but even with tools like Valgrind and Purify, I spend far more time fixing up issues related to memory management than I can really justify to a project mamager. Then there's the poorer tool support for C and C++, and the frustrating gotchas of the latter language.

Re:Tempest, meet teacup...

[r7]

Java's Big Thing was its ability to be written once, and run on VMs on any platform. That advantage was promptly killed by the rise of AJAX and all its cross-platform happiness

AJAX is wholly orthogonal to Java uptake.

Re:Tempest, meet teacup...

[daniel.b.douglas]

I don't necessarily endorse the following statement, but Alan J. Perlis has an epigram for you: 93. When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop.

Re:Tempest, meet teacup...

[Sarten-X]

And yet, from what I hear (not knowing it myself) the latest version breaks most attempts at backwards-compatibility. That's a good mark of an immature platform.

Re:Tempest, meet teacup...

[shaitand]

All fair points. But we were discussing performance not devel time or ease of use. You may include those when you refer to performance but I use performance to mean raw execution time and in some cases memory usage.

Now if you are saying Java increases YOUR performance, that is certainly possible.

I don't know about your personal performance or coding skills. I do know that well written java can perform well enough to suffice for most tasks. I also know that the majority of Java I have seen used, including use in major widely used projects is both slow and memory hungry.

Re:Tempest, meet teacup...

[cheekyboy]

java still has limitations based on the OS.

try to allocation an array of 1 trillion items, or realistically use 500,000 sockets to do IO, yeah is your server fast enough to handle 500,000 clients, not likely.

WTF?!

[oldhack]

What planet do these people live on? Worse yet, Timothy, my man, for fuck's sake, are there any "editors" with some programming experience? About the only one seems to be ScuttleMoney, you know, the one we piled tons of flak back in the days.

I guess nothing good last forever.

I've.never.used.groovy.so.I.have.a.question.

[Daniel Dvorkin]

Does.it.allow.you.to.do.useful.things.without.typing.a.classpath.fifteen.layers.deep?

If.so.it.might.be.exactly.what.is.needed.to.make.Java.an.appealing.language.for.programmers.with.fresh.ideas. Else.it.won't.do.the.trick.

Re:I've.never.used.groovy.so.I.have.a.question.

[MichaelSmith]

Would you prefer not to have name spaces? C is pretty crap you know. "import" is pretty easy in Java too.

Re:I've.never.used.groovy.so.I.have.a.question.

[youngdev]

oh yeah. this problem is solved real elegantly by providing a namespace feature of classes. you simply import the class with its full package and classname and then you can use it everywhere in that class by only referencing the simple classname. come to think of it, this feature is part of java too. if you ware worried about having to type all those import statements don't sweat it. All modern IDEs have a key combo that automatically imports missing fully qualified classnames. In Eclipse, for example, the combo is ctrl + o.

if.you.stop.using.notepad.as.your.ide.your.problem.GoesAway

Re:I've.never.used.groovy.so.I.have.a.question.

[Daniel Dvorkin]

Namespaces are useful, and custom namespaces cut down on a lot of the clutter in Java, but they shouldn't be necessary for basic functionality. The way I see it (YMMV, of course) K&R C provides pretty much the functionality that any language should have as part of the core language spec; if I can do something in n characters in C but it takes me 10n characters to do it in some newer and supposedly better language, I'm hard-pressed to consider that an improvement.

Re:I've.never.used.groovy.so.I.have.a.question.

[Daniel Dvorkin]

See my reply to the previous answer to my comment; the workarounds you describe are effective, but they shouldn't be necessary. One of the main things that distinguishes a good language from a bad one, IMNSGDHO, is that the former doesn't make you feel like you're fighting the language to get things done.

Ah, pay me no attention, youngdev -- I'm just a grumpy old man, one of the get-off-my-lawn crowd that is supposedly the only group of people using Java these days. ;)

And no, I don't use Notepad for development. Or for anything. Dear God. I may be old (by /. standards, anyhow) but I'm not senile.

Re:I've.never.used.groovy.so.I.have.a.question.

[Abcd1234]

Uhuh... so you determine language quality by the terseness of it's text.

Interesting.

Well, you have fun writing your terse programs with inexplicably named, but I'm sure very compact, variable and function names, while the rest of us move on to writing code other people can actually, you know, read and understand while putting up with the horrible hardship of having to type a little bit more.

Oh, and BTW, any language that has namespaces has an import keyword. Maybe you should try it out sometime.

Re:I've.never.used.groovy.so.I.have.a.question.

[smartr]

It's not necessary in Java really... It's just the preferred way of doing things. The basic functionality is there, and you could even get hell bent on using the default package. I mean, if you really wanted to, you could make some default package class called "stdio", put any additional non-default library functionality into it you wanted, then just extend it everywhere in place of Object.

Re:I've.never.used.groovy.so.I.have.a.question.

[Z00L00K]

And if you run Eclipse just press SHIFT+CTRL+O to resolve any imports.

If there is more than one variation of the implementation you will have to select. Like for "java.util.Date" and "java.sql.Date". Just make sure you select the right one.

Re:I've.never.used.groovy.so.I.have.a.question.

[forkazoo]

Uhuh... so you determine language quality by the terseness of it's text.

Interesting.

It's certainly not a complete measure of a language, but they are certainly worse ways to look at it. Java has some inconveniences, like famously deep class hierarchies which lead to very long lines of code. OTOH, Java has support for generics, and some inherent safety mechanisms which would need to be handled manually in C. In C, it's normal to have a set of similarly named functions that operate on floats, doubles, int, shorts, etc., which are all basically copy-pasta, which is a bad thing about C. Like most bad things in a language, it really does directly correlate with the fact that you have to write more C.

Nobody ever sold a language feature on the fact that it was hard to use. Every language prides itself on the fact that you don't have to write more of it.

Re:I've.never.used.groovy.so.I.have.a.question.

[Etriaph]

class Example
{
    public static void main(String[] args)
    {
        consolen("If you design your classes correctly, you won't have to type so much.");
    }

    public static void consolen(String out)
    {
        System.out.println( out );
    }
}

Re:I've.never.used.groovy.so.I.have.a.question.

[Anonymous Coward]

Odd criticism. I've written tens of thousands of lines of Java over the past decade +, and I can't remember the last time I manually typed in a fully-qualified class name, or even an import statement. Eclipse (and presumably the other Java IDEs) take care of this for you. The only time you'll see a fully-qualified class name in the body of reasonably-written Java code is when you've got two classes of the same name. And even then, you don't have to type it in - autocomplete will still take care of it.

Re:I've.never.used.groovy.so.I.have.a.question.

[BikeHelmet]

if I can do something in n characters in C but it takes me 10n characters to do it in some newer and supposedly better language, I'm hard-pressed to consider that an improvement.

Careful mate - there's languages that'll do stuff in 1/50th the lines it takes to do it in C. Lines is a very bad measure of whether a language is superior.

My opinion is that better languages are more concise, have code flow that can almost be read, and cut down on unnecessary symbols when the compiler could figure out what you wanted it to do. (if it were coded to do so)

My opinion is it's better to code in languages with "smarter" compilers, which do more of the low-level thinking for you, allowing you to focus on the code flow and avoiding logic errors.

I think Java would be pretty good if it adopted public: and private: from C - also var from javascript, for declarations where you don't want to type out ArrayList<SomeObject> myList = new ArrayList<SomeObject>();. Just a few tweaks here and there would make Java so much more legible, and cut down on the typing a lot.

The core of Java is mature - so now we an opportunity to simplify the syntax without losing any capabilities.

Re:I've.never.used.groovy.so.I.have.a.question.

[HappyEngineer]

ctrl-shift-o is your friend. Deeply nested namespaces are rarely a problem for me. I just type the name of the class and hit ctrl-shift-o in eclipse.

Re:I've.never.used.groovy.so.I.have.a.question.

[thsths]

> OTOH, Java has support for generics

How are generics a good thing? They are a band aid for the fact that not everything in Java is an object. I would say that is the most serious defect of Java, apart from the lack of closures (yes, I know they are coming, but when?).

Plus any JVM I have seen is a piece of shit. Sorry, but if the official JVM takes several seconds just to start, that disqualifies it from a lot of perfectly good uses.

Re:I've.never.used.groovy.so.I.have.a.question.

[peppepz]

Namespaces are useful, and custom namespaces cut down on a lot of the clutter in Java, but they shouldn't be necessary for basic functionality.

In fact they aren't. Java automatically imports the java.lang package, so for "basic functionality" all you might have to import are the java.net or java.io packages. Which is quite reasonable since Java is designed to work (and does work) on systems which might not have access to either the network or the file system. And a string like "java.net" is pretty far from the "fifteen layers deep classpath" you were grieving about.

The way I see it (YMMV, of course) K&R C provides pretty much the functionality that any language should have as part of the core language spec; if I can do something in n characters in C but it takes me 10n characters to do it in some newer and supposedly better language, I'm hard-pressed to consider that an improvement.

Leaving aside any considerations about the quality of C's standard library, which is apparent to anyone wo has used it, let's do a comparison.

In C, in order for your program to do any kind of interaction with the external world, you have to #include <stdio.h>. In Java, you don't import anything.

In C, in order to allocate some memory, you have to #include <stdlib.h> (otherwise, you won't even get NULL!), and <string.h> if you want to do anything useful with that memory. In Java, you don't import anything.

In C, if you want to use a socket, you #include <sys/types.h> and <sys/socket.h>. And <unistd.h> if you want to be able to read() from it. In Java, you import java.net, which is not only much shorter than that, but will also provide much nicer names for the imported symbols: and while you might like the terseness of names such as "fcntl", you'll agree that at least for higher level functionality, more informative names are needed, which is why all C-based high level libaries tend to have extremely long, reverse-polish names such as gtk_file_chooser_get_preview_filename_utf8. And unlike Java, where you can get away with importing the "namespace" just once, in C you'll have to repeat that stuff for every single use of your imported symbol.

Moreover, in Java, if you use a plain IDE, which is provided for free by the same people who develop the language, you can just right click the source code and select "fix imports" to have it automatically add import clauses for every external class you've been using.

Re:I've.never.used.groovy.so.I.have.a.question.

[smartr]

Find me a useful javascript IDE that knows wtf to do with all those var's that can also run quickly, and I'll tell you Eclipse and NetBeans are much better because the strictly typed languages inherently works better with IDE's. I'm not saying Javascript is bad because of it, but simply that Java is superior in a giant set of applications because of this "apparent" kludgyness... Java is incredibly "simplified". There's a can of worms, and this article doesn't seem to get that Java gets its strength by fulfilling a solid "niche" that so happens to be needed by a large portion or programmers. It might be more popular than it deserves, but it does fulfill certain roles impressively. Also, most people declare their array lists as lists....

Re:I've.never.used.groovy.so.I.have.a.question.

[horatiocain]

That's just it - your code describes the minimum needed for a "Hello World" level application in Java. Some us us really hate

Re:I've.never.used.groovy.so.I.have.a.question.

[peppepz]

import static java.lang.System.out;

class Test {
public static void main(String[] args) {
out.println("Hey");
}
}

Re:I've.never.used.groovy.so.I.have.a.question.

[ls671]

> ArrayList myList = new ArrayList();.

Then just use the construct from the "founding fathers" if it bothers you that much, it still works you know :-)

ArrayList myList = new ArrayList();

More seriously, how much time does a developer spend typing compared to what he should be spending thinking ?

The fact that java forces you to type more also forces you to type basic documentation as you code and in my opinion, this is a good thing. In the end, you get easier to maintain code at almost no extra cost ;-)

I have never understood developers saying that a language was superior because you can write code using less key strokes using it.

Re:I've.never.used.groovy.so.I.have.a.question.

[shutdown -p now]

How are generics a good thing? They are a band aid for the fact that not everything in Java is an object.

Please be more specific.

Oh, and generics aren't a band aid for anything. They are a necessary feature to produce reusable typesafe code in a statically typed language.

Re:I've.never.used.groovy.so.I.have.a.question.

[arjan_t]

> OTOH, Java has support for generics

How are generics a good thing?

Because:

• They prevent you from inserting a type in a collection that shouldn't be there? Good luck trying to put a battleship in a collection of pencils. It won't fit with generics and it shouldn't fit.
• They take away the need for guessing and down casting anytime you retrieve something from a collection.

There are some other reasons though, not all generic usage is for collections, but these are two major use cases.

They are a band aid for the fact that not everything in Java is an object.

No they're not. Maybe unfortunately, but they don't even work with primitives in Java.

Plus any JVM I have seen is a piece of shit. Sorry, but if the official JVM takes several seconds just to start, that disqualifies it from a lot of perfectly good uses.

Java is currently primary used server side. I'm not sure what kind of code you write, but if we need to restart the JVM once a month it's already a lot. A few seconds doesn't really matter when the uptime of your server is at least weeks, but more likely months or for 'finished & stable' software maybe even years.

Re:I've.never.used.groovy.so.I.have.a.question.

[arjan_t]

also var from javascript, for declarations where you don't want to type out ArrayList<SomeObject> myList = new ArrayList<SomeObject>();. Just a few tweaks here and there would make Java so much more legible

It does indeed gets a tweak a little like this. You still have to write out the declaration in full, but there's a shorthand for the generic part of the right hand side: ArrayList<SomeObject> myList = new ArrayList<>();. It doesn't look like a major improvement in this example, but when there is a lot of generic type information, it can surely help.

Re:I've.never.used.groovy.so.I.have.a.question.

[atomic777]

fresh.ide[CTRL+Space][Down]

That was 11 keystrokes. You may want to upgrade from notepad.

Re:I've.never.used.groovy.so.I.have.a.question.

[Compaqt]

While it's true that Java's library is highly hierarchical, you don't type out whole namespace paths all the time. You just import namespaces.

Java 5 also features static imports:
import static java.lang.Math.PI;
import static java.lang.Math.*;

double r = cos(PI * theta);

Free Java IDEs like Eclipse and Netbeans manage imports automatically. You don't have to type them out.

Re:I've.never.used.groovy.so.I.have.a.question.

[Compaqt]

>>I think Java would be pretty good if it adopted public: and private: from C - also var from javascript, for declarations where you don't want to type out ArrayList myList = new ArrayList();. Just a few tweaks here and there would make Java so much more legible, and cut down on the typing a lot.

Check out Scala, a JVM language. Scala not only reduces declaration cruft, but it introduces a variables vs values (final variables) distinction that decreases the possibility of modifying what should be a one-time calculated value.

val age:Int=22
var numPrimesFound:Int=0

Re:I've.never.used.groovy.so.I.have.a.question.

[ardor]

Then again, Java generics are an ugly hack that applies unnecessary type erasure, because internally, generics boil down to implicit down/upcasts (either from/to Object or a specified type in case of bound generics). C# generics and C++ templates are much more powerful and do NOT apply this type erasure. For example, try to do something like template < typename T > void foo(T t) { t.some_call(); } in Java, for _any_ type that fulfills one requirement: instance.some_call() should be a valid expression.

Re:I've.never.used.groovy.so.I.have.a.question.

[u17]

For all practical purposes, Java doesn't have namespaces. If it did, you would not see class-name prefixes floating around all the time in java code. Say, javax.swing.[J]Button, org.odftoolkit.odfdom.dom.element.table.[Table]TableRow, etc. If the only way to resolve name clashes is to type out the full package-name of the class whenever you refer to it in a source file, then this is not using a namespace, and the presence of class-name prefixes only confirms that this is how developers view it. Compare to C++, where you can do "namespace thr = boost::thread;". With aliases like these, you don't have to worry about class name clashes at all, since you could easily translate something like "org::odftoolkit::odfdom::dom::element::table::" into "tbl::", making the use of namespaces convenient and practical. While I would love Java to be more popular, it's full of half-assed features like this, and it's no surprise to me at all that it's being pushed back into being a niche language for "enterprise" developers.

Re:I've.never.used.groovy.so.I.have.a.question.

[ardor]

No. K&R C lacks the following things:
* first class functions, lambda, closures
* comprehensions
* coroutines
* proper generics/templates (no, macros are _not_ a replacement)
* painless string handling
* module system
* namespaces
* reflection
* support for common oop patterns and tools, like class definitions, dynamic dispatch etc. it has to be manually constructed, which is quite time consuming

Now, of course it is a valid point that these things do not necessarily belong in C. It is a system programming language, after all. But these features are very important for other domains, such as application development. Right tool for the right job, please. C is _not_ the shiny hammer, and not everything is a nail.

Re:I've.never.used.groovy.so.I.have.a.question.

[Anonymous Coward]

Except that 'out' isn't a really good name to be polluting your unit namespace with.

Re:I've.never.used.groovy.so.I.have.a.question.

[owlstead]

Use an IDE that fixes this for you. Really, I don't see a problem with import statements at all. They can be easily inferred during code creation and when looking at code outside the IDE it makes it abundantly clear which class/enum you are referring to. I've never had a junior complain about package names (for long). Classpath issues are e.g. much more troublesome.

Re:I've.never.used.groovy.so.I.have.a.question.

[owlstead]

How are generics a good thing? They are a band aid for the fact that not everything in Java is an object.

Bollocks, auto-boxing is a band aid for that. Generics *require* the use of objects instead of basic types.

I would say that is the most serious defect of Java, apart from the lack of closures (yes, I know they are coming, but when?).

Generics are hard to add, since they require specific support on the language level, it's not just adding syntax and be done with it.

Plus any JVM I have seen is a piece of shit. Sorry, but if the official JVM takes several seconds just to start, that disqualifies it from a lot of perfectly good uses.

And there am I, replying to a fucking troll. Applets still have pretty bad startup times, but the JVM? Seriously?

Initial startup time:

real 0m0.928s
user 0m0.080s
sys 0m0.030s

second startup time (things are in cache now)

real 0m0.109s
user 0m0.070s
sys 0m0.000s

Re:I've.never.used.groovy.so.I.have.a.question.

[mcvos]

Java is readable, it's just not very expressive, which means you need a lot of code to get anything done. Often you need a couple of classes to get the structure of your code right. Perl is indeed the polar opposite: expressive but unreadable.

Good languages have both. Ruby, Python and Groovy are readable, but also very expressive. You can do stuff in a single very readable line that would take a page of Java, or a very arcane line of Perl.

Re:I've.never.used.groovy.so.I.have.a.question.

[Anonymous Coward]

Are you a Perl fan, or an old-school APL guy?

Re:I've.never.used.groovy.so.I.have.a.question.

[mcvos]

Try Groovy. You can simply do def myList = new ArrayList>SomeObject<();.

It also does closures and internal iteration, it automatically generates your getters and setters, you don't have to handle exceptions if you don't want to, and it does nullpointer-safe bean paths: foo?.bar?.baz() simply returns null if foo is null, rather than throwing an exception.

Re:I've.never.used.groovy.so.I.have.a.question.

[ardor]

And guess what, in C#, C++, Python, Ruby, Javascript, Haskell, Ocaml etc. you do _not_ need an interface here. Using an interface in this case is just wrong, necessary in Java, but essentially wrong.

Generic programming requires structural, not nominative typing. The former does not care about the type's name, only about what it can do (for example, whether or not it provides a some_call member, or whether or not foo(x) would be valid if x is of that type). Nominative typing only cares about the name, it identifies the types by name. This is what you use with your interface.

In other words, the only requirement for the type should be that instance.some_call() should be a valid expression, and not that it inherits from an interface with name X.

Re:I've.never.used.groovy.so.I.have.a.question.

[Tridus]

[quote]ArrayList myList = new ArrayList()[/quote]

Hell, even VB.net has a shorthand for that: dim myList as new ArrayList(of SomeObject)

Re:I've.never.used.groovy.so.I.have.a.question.

[arjan_t]

Then again, Java generics are an ugly hack that applies unnecessary type erasure

Sadly this is true, and an unfortunate consequence from the fact that Java added generic support relatively late in its life cycle. This opens the door to some very awkward corner cases.

That said, the benefits of such a sub-optimal generics implementation for me still far outweigh the disadvantage of not having any generics at all.

Also, don't forget that C++ templates not only are a whole different beast, but they actually have issues too. Not in the least that they function more or less as type factories, that produce different types for a different T, that are in no way related to each other. Maybe the situation has improved lately, but I remember that the compiler would generate a complete new list definition for each T I used it for. Ouch!

Re:I've.never.used.groovy.so.I.have.a.question.

[arjan_t]

And guess what, in C#, C++, Python, Ruby, Javascript, Haskell, Ocaml etc. you do _not_ need an interface here. Using an interface in this case is just wrong, necessary in Java, but essentially wrong.

It's true that Java doesn't has a direct syntax to do that, which indeed may be a shame. But it's also not absolutely necessary. In the UI layer for example and increasingly in other parts of the code, Java uses an expression language (typically abbreviated as EL).

With EL in Java, I basically do precisely that. E.g.

T getFoo() { return foo; }

And then in the view definition e.g.

<h:outputText value="#{myBean.foo.some_call()}" />

Because of the usefulness of this, there are various efforts going on to support EL in more parts of Java than just the UI.

Re:I've.never.used.groovy.so.I.have.a.question.

[owlstead]

Well said.

One little remark though:

That would be List myList = new ArrayList() by now. The hole idea that you create an ArrayList but only use the List interface is one thing that is missing when languages use type inference. Personally I only use the class interface when the additional methods are required for that part of the application.

Re:I've.never.used.groovy.so.I.have.a.question.

[owlstead]

But you would still have to type "out.", what are you thinking?

Re:I've.never.used.groovy.so.I.have.a.question.

[JamesP]

Would you prefer not to have name spaces? C is pretty crap you know. "import" is pretty easy in Java too.

Except you need 5 imports and deal with 5 namespaces to do what you do in C in 10 lines and 2 C include

Re:I've.never.used.groovy.so.I.have.a.question.

[JamesP]

I have never understood developers saying that a language was superior because you can write code using less key strokes using it.

It really doesn't matter, except when it's really over the top, like Java

And no, not even C# is that bad

Re:I've.never.used.groovy.so.I.have.a.question.

[isorox]

Initial startup time:

real 0m0.928s
user 0m0.080s
sys 0m0.030s

Yes, similar numbers on my 4 year old laptop running linux, although "ffmpeg -version" is 25 times faster.

I'm not sure about windows in general, but the corporate windows we have at work, on similar hardware, takes 10 seconds to run java -version the first time.

Re:I've.never.used.groovy.so.I.have.a.question.

[LizardKing]

I think Java would be pretty good if it adopted public: and private: from C - also var from javascript, for declarations where you don't want to type out ArrayList myList = new ArrayList();. Just a few tweaks here and there would make Java so much more legible, and cut down on the typing a lot.

Why would Java need public: and private: from C++ (not C)? C and C++ encourage a separation of declaration and implementation, but that's because of the way linkage works. Java doesn't distinguish things in this way as the implementation is also the declaration, however you can use interfaces to much more cleanly separate interface from implementation.

As for var declarations, this would remove the preferred idiom in Java of declaring types to be of an interface type - a List of SomeObject in your example.

As for typing, most of us use IDE's with auto completion these days, so that's not an issue.

Re:I've.never.used.groovy.so.I.have.a.question.

[LizardKing]

Look up static imports in Java. Hell, look up packages and importing them in Java in general, because you clearly don't know Java well.

Re:I've.never.used.groovy.so.I.have.a.question.

[Alomex]

They are a band aid for the fact that not everything in Java is an object.

I'd say they are a band aid for the fact that in Java everything has to be an object to be treated as a first class citizen. What primitive types abundantly show is that object scaffolding can be excessive for simple data types and data structures.

Re:I've.never.used.groovy.so.I.have.a.question.

[SpinyNorman]

Sure it lacks those, but:

* first class functions, lambda, closures

First class functions are primarily the realm of functional programming languages, not procedural ones.
Lambda's, combined with ways to refer to them (C++ std::function, templates, auto) are a type of first class function.
Closures provide an interesting alternative way to code some things, but seriously who really misses them in C/C++?

* comprehensions

Use a libary.

* coroutines

Use a library.

* proper generics/templates (no, macros are _not_ a replacement)

Agreed. Templates are very useful.

* painless string handling

Use a library.

* module system

To do what? You've listed namespaces and classes separately, so what's left that you can't do in C?

Most C programmerss use paired .h/.c module definition/implementation pairs, and #ifndef/#define to allow module definitions to be blindly included.

* namespaces

Agreed. Namespaces are useful, although not a show stopper.

* reflection

C's a low level language. There is nothing to inspect. Feel free to build layers on top of it.

* support for common oop patterns and tools, like class definitions, dynamic dispatch etc.

Agreed. Classes are enormously useful.

Of course C has evolved into C++ which has the useful items on your list, and is aquiring others (lambdas in c++0x).

Re:I've.never.used.groovy.so.I.have.a.question.

[polgardy]

Maybe you should read some dynamic language code before making a comment like this. It's not variable and function names that are terse and compact: it's the amount (or lack thereof) of boiler plate code that accomplishes the same job. Compact syntax makes code more readable, not less, because you don't have to figure out which parts of the complexity are accidental, and which parts are essential. And of course you know that you can write inexplicably named, compact variable and function names in any language.

Sorry, that shouldn't have been anonymous.

Re:I've.never.used.groovy.so.I.have.a.question.

[mortonda]

How is that better than this in ruby: (and similar in perl and python I think)

myList = []

Being too verbose interrupts the flow of thinking about the overall structure. That statement needs no documentation, it is obviously creating an array. Your Java example still doesn't document anything other than it's creating a list.

Using the least keystrokes may not make for the best language, but neither does requiring the most. Java requires way too much time thinking about the language syntax which detracts from the logic of the program.

Re:I've.never.used.groovy.so.I.have.a.question.

[leenks]

import some.very.long.famously.deep.package.hierarchy.Comment;

public class OhDear {
        public static void main(
                new Comment().post("Never heard of import?);
        }
}

Re:I've.never.used.groovy.so.I.have.a.question.

[Javagator]

I have never understood developers saying that a language was superior because you can write code using less key strokes using it.

I think there are two types of programmers posting on Slashdot. One type writes a lot of one person utility programs running into the thousands of lines of code. Sometimes these programs are run once or just a few times. Programmers writing code like this find verbose languages annoying. Another type of programmer works on a team writing programs that run into the hundreds of thousands of lines of code. Programs that will be maintained for years. Programmers working on these projects like namespaces, strict typing, and all the things that help them manage the complexity of a large system.

Re:I've.never.used.groovy.so.I.have.a.question.

[u17]

So you disagree with my comment. Would you care to contribute anything to the discussion and explain why?

Re:I've.never.used.groovy.so.I.have.a.question.

[binarylarry]

C# is a clone of Java you clueless fucktard.

Re:I've.never.used.groovy.so.I.have.a.question.

[JamesP]

NO

Well, it may have began like that, but MS knew how to fix java.

So there you go.

Re:I've.never.used.groovy.so.I.have.a.question.

[Anonymous Brave Guy]

You forgot the part where every type that you want to use with your generic code must then implement an arbitrary number of interfaces like the one you mentioned, and be changed to add an extra interface every time a new generalisation in other code requires it. This is poor even compared to C++ templates, never mind the much more powerful type systems that various recent languages and languages with a lot of research interest are using now.

It's like the much older Java problem with implementing observers for things like GUI events: taken to its logical conclusion, relying on interfaces to do everything and providing only single inheritance of implementation means either you need an interface for every public method (or set of completely inter-dependent methods), or you need to implement a whole bunch of unnecessary no-op methods for parts of an interface you don't care about just to get the other parts. Either way introduces an almost comical amount of bloat, not to mention the accompanying maintenance hazards, and Java is rightly criticised for this.

Re:I've.never.used.groovy.so.I.have.a.question.

[owlstead]

I meant to say that closures are hard to add. Generics too of course, but closures take complexity a step further. It's the most debated change of the language spec so far. It's not just *if* they are added, it is how they affect the whole language structure.

Re:I've.never.used.groovy.so.I.have.a.question.

[Anonymous Brave Guy]

Sorry, I somehow replied to the GP post when I meant to the reply that started "Jesus that should be easy in Java."

Re:I've.never.used.groovy.so.I.have.a.question.

[Anonymous Brave Guy]

Uhuh... so you determine language quality by the terseness of it's text.

Not necessarily. But being able to express powerful concepts concisely without losing readability is a benefit, and not having to write lots of boilerplate to express even simple concepts is another benefit. Java fails on both counts, lacking the expressive power of many other modern languages, and requiring obscene amounts of boilerplate code for many common tasks.

Re:I've.never.used.groovy.so.I.have.a.question.

[owlstead]

Oh, you can mess up about anything, including the VM startup times, although 10s is completely insane.

First of all, if you don't make exceptions to an idiot virus scanner such as McAfee, it will scan each and every .jar file you start up. Since every class in Java is likely to be in a .jar, that is already a huge amount of trap.

Then you can create a huge minimum heap size. It's easy to see the trashing that will occur when -Xms is set to the same amount of memory as the entire server is using.

Of course, you can save some space by removing the pre-compiled class files from your install, making it necessary to repeat that process for each and every class in each and every standard Java package, each time the VM is started up.

There is tons of idiotic things you can do with the Java install as well. I'm not sure what happens if you overload the "ext" folder of the VM with .jar files, but it certainly won't help. The only thing you should be doing to your basic java install is installing the unlimited crypto files (not required any more for 1.7 - phew).

Probably the biggest abuse you can do to it is to install it on a network drive. No file caching will be performed, your virusscanner will go ape and all the initial network overload will be present. Installing it on anything other than a drive intended as a system drive can be called abuse. Installing it on an SSD is the reverse of abuse of course - zip files are just meant to be indexed using flash.

Oh, and starting it up as "-server" (probably automatic on his hardware) might introduce some lag too, but nowhere near 10s. Try starting it up as -client on 32 bit hardware for short lived applications.

OT: Network drives are also "fun" when developing. We've compile times of tens of seconds for a single component of an application because each and every .jar will be pulled over the network IF each and every time. Brilliant. Apache Maven seems to solve that problem by the way.

Re:I've.never.used.groovy.so.I.have.a.question.

[Anonymous Brave Guy]

Programs that will be maintained for years. Programmers working on these projects like namespaces, strict typing, and all the things that help them manage the complexity of a large system.

None of which precludes a concise, expressive syntax. For example, Haskell is far beyond Java in its type system, yet its syntax is in many ways far simpler.

By the way, I think you are too quick to put people posting here in boxes. I'm not even close to either of your categories, neither in the kind of projects I've worked on, nor on the kind of views I have formed as a result.

Re:I've.never.used.groovy.so.I.have.a.question.

[sourcerror]

"How are generics a good thing?"
It helps the JIT compiler make code run faster.

Re:I've.never.used.groovy.so.I.have.a.question.

[LizardKing]

I pointed out your clear lack of knowledge about imports in Java. That invalidated your comment. Game over. Now fuck off.

Re:I've.never.used.groovy.so.I.have.a.question.

[Javagator]

I think you are too quick to put people posting here in boxes

You're probably right. Maybe I should have added a Cowboy Neal box.

Re:I've.never.used.groovy.so.I.have.a.question.

[maraist]

Ok, good, so you've confirmed that Perl is 10x better than C.. Just checking.

Re:I've.never.used.groovy.so.I.have.a.question.

[maraist]

The single best case for using Java over most every other language is it's tendency to reduce syntactical and logic errors.. Yes, you still make them, but there are entire classes of common errors that go away with java.

Generics solve one problem very well in my opinion.. Nested collections. It is incredibly verbose, to say the least, but if you've ever had a map of a map (repeat ad infinitum), you know what I'm talking about.. You can very easily get your type-casting wrong, and if there is a rare use-case, you won't detect the type-cast exception until it's too late.

By adding strict binding to these generalized utilities, you dramatically increase the readibility and reliability of the code. It becomes a syntax error to insert or extract data of the wrong type. Now if everything is a string for you, this isn't going to help, but I typically deal with complex data-types, and it's a life-saver.

You are right that they are otherwise verbose and actually do decrease performance somewhat (because it forces an extra otherwise useless typecast java-op).

As for startup times.. what exactly are you dealing with where startup times are a problem? eclipse?? Try loading up MS word sometime without the boot-shifted offloading. That was C++ last I checked.. Complex code is slow to load in any language. Something like apache hides the complexity through lazy-loading, but this isn't always possible.

For most things you'd use Java for, there is a long lifetime of the process, so it's worth having a relatively slower startup period to identify JITable code - though it would be nice to cache the JIT metadata/code for future restarts. In fact, SUN Java6 DOES this for it's core libraries, not sure why it can't for dynamically loaded code (via SHA1 hashes or whatever). And of course, most java classes are deflated, thus you have the obligatory decompress stage to any startup process.. Again, SHA1 based metadata could avoid this entirely in theory.

Re:I've.never.used.groovy.so.I.have.a.question.

[maraist]

"No they're not. Maybe unfortunately, but they don't even work with primitives in Java."

Think about what you're asking. From almost every other dynamic languages, you don't get true primitives - you have an object handle that contains the primitive bytes or an object like Integer (or worse, a polymorphic object which is very heavy weight and slow for things like ++).

So you get java collections gives you what you want from a logical perspective. The only thing you're missing is the memory efficiency and muteability (you can't just hit ++ on the stored hash value, well actually, yes you can, but via implicit new object instantiation).

At the end of the day, the generics don't change how you code, they just replace your references to Object with a token. Thus if your algorithm requires storage as per-object, you get NOTHING by storing the primitive. The only other possibility is to have the generic-library somehow produce different code for different types of primitives. That would be pretty sweet, BUT, bug-prone if not hard-to-read IMO.

If you want the memory compactness, there are primitive collection data-types out there - no per-item objects used. (try trove).

Re:I've.never.used.groovy.so.I.have.a.question.

[maraist]

Ok, no problem:

public <T extends SomeCallable> void foo(T t) {t.someCall(); }

We do it all the damn time, and it's a more reliable way to handle the code. I can trace every implementation of SomeCallable so I know if it's being used correctly.

What you're describing is a pseudo-reflective model, which is fine.. You can do that too in Java - though not as concisely, I agree. But reflection makes for coding errors due to the obligatory 'there be dragons here'.

Re:I've.never.used.groovy.so.I.have.a.question.

[maraist]

Yeah, but they did this better in Object-C; called it message-passing. Pass a message to an object and see if it can handle it, if not, have some default symbolic handler. The big bonus is that you do your normal static stuff in C, then identify this quasi language stuff and put it in objects. Thus best of both worlds.

Perl, Python, Ruby all deal with function calls as hash-map lookups. Perl only has parent-namespace lookup tables. Not sure about Python/Ruby.

Guess what, you can do this in Java/C# as well with.. drum-roll-please... A HashMap!!! Sure it's not pretty looking, but it's a hell of a lot prettier than the equivalent parameterized passing in perl:

sub foo {
  my %args = @_;
  my $x = $args{x};
}

As for the 'message-passing' in java, You can do this with reflection (generic object proxies). That's how we do unit-testing actually.

Concieness aside, the question is whether this is really a good practice or not. You lose staticness with this model, and Java is all about provable code.

Re:I've.never.used.groovy.so.I.have.a.question.

[multi io]

I think he was talking about namespace aliasing, so you could e.g. use both org.foo.Table and org.bar.Table in the same source file without having to write out the fully-qualified name of either of them.

Re:I've.never.used.groovy.so.I.have.a.question.

[BikeHelmet]

Why would Java need public: and private: from C++ (not C)?

Sorry - usually I write "C/C++". I was being sloppy. :P

It'd just be cleaner. If you want to declare a dozen or so members in a class or interface or whatever, a single public: or private: at the top looks so much cleaner than retyping it on every line. (or every few lines)

Re:I've.never.used.groovy.so.I.have.a.question.

[SnapShot]

I love the artistic -- almost poetry -- of well-written Ruby. But the verboseness of Java can be helpful for long term code maintenance (this is assuming the programmer writing the code is aware of what the various constructs mean.)

Java:
// Hey code maintainers, I'll probably be doing inserts and deletions with this list
List list1 = new LinkedList();

// Hey code maintainers, I may be doing a lot of random access with this list
List list2 = new ArrayList();

// Hey code maintainers, either: // a. I haven't learned any new Java since 1.1 or // b. I really need a synchronized, random access list
List list3 = new Vector();

// Hey code maintainers, I need a synchronized, random access list
List list4 = Collections.synchronizedList(new ArrayList());

This is versus your Ruby example; concise, but not very implicit information.

Ruby:

# I'm informing my readers that I need a list
myList = []

Re:I've.never.used.groovy.so.I.have.a.question.

[arjan_t]

Think about what you're asking. From almost every other dynamic languages, you don't get true primitives - you have an object handle that contains the primitive bytes or an object like Integer .

Well, I wasn't really asking anything to be honest. It's true that the default collections in Java can not store primitives directly, and thus by extension their generic versions can't either.

Java and primitives have a rather debatable relationship with each other. Some say Java would be cleaner if there weren't any primitives and only their Object versions. Like bit-shifting operators and native arrays, they were included in the Java language for the class of algorithms where simple and direct memory manipulation offers huge performance gains. But Java is not really used a lot for these kinds of niches (C and C++ shine here) so most of the time they feel a little out of place and they often bleed into business code where they have no place really.

(or worse, a polymorphic object which is very heavy weight and slow for things like ++)

Well, in Java the primitive wrapper types are final (can't be sub classed) and immutable, so that takes care of a whole slew of problems. However, incrementing a primitive wrapper type may seem heavy weight, since it would always require unboxing of the wrapper, evaluating the increment expression and then creating a new instance (and discarding the previous instance). In the end though, all that matters is what instructions are eventually generated for the CPU. Because of the strong run-time optimizations being done by the VM, the actual code that gets generated may in fact not at all do this and may actually be optimized into a simple register allocated value that gets incremented, instead of the entire Object manipulation with all the complicated stuff around that.

At the end of the day, the generics don't change how you code, they just replace your references to Object with a token. Thus if your algorithm requires storage as per-object, you get NOTHING by storing the primitive.

I agree that the current state of generics in Java won't give you any advantage even if it was possible to declare say a List<int> But just to be sure, let's not confuse that with generics in general (for Object types), which actually do make your code more type safe.

Re:I've.never.used.groovy.so.I.have.a.question.

[ardor]

As other posters and myself below already replied, using interfaces is just wrong. It adds unnecessary bloat, and uses the wrong type system. You want a _structured_ typing here, not a nominative one (which is what you get with interfaces). This is not about pseudo-reflection. Read below.

Re:I've.never.used.groovy.so.I.have.a.question.

[ardor]

* first class functions, lambda, closures
First class functions are primarily the realm of functional programming languages, not procedural ones.
Lambda's, combined with ways to refer to them (C++ std::function, templates, auto) are a type of first class function.
Closures provide an interesting alternative way to code some things, but seriously who really misses them in C/C++?

Have you been living under a rock? Just about every major language out there is implementing these features. Python, C#, C++, Ruby, Javascript among others. (Java doesn't, and it is sorely missed.)
And, I do miss closures in C++. Right now I can think of several factory pattern implementations that would be greatly simplified if I could return closures instead of objects. Closures are objects are closures, sure
but they do differ in practice.

* comprehensions
Use a libary.

Good luck writing and/or finding one in C that doesn't end up requiring hundreds of lines for what can be done in at most 5 in other languages, like in Haskell.

* coroutines
Use a library.

Forget it. Coroutines work completely against the abstract machine that C models. It is a different control flow, and screws with the stack. You *may* be able to do this with Assembler code inside, but this would necessarily apply to every coroutine you write. Not good.

* painless string handling
Use a library.

No amount of C string libraries will be as convenient and easy to use as strings in other languages. C++ std::string is a good example. It is by far not the best out there, and still looks like heaven compared to the things that are usual in C. Guess why so many people use fixed char buffers for strings (and therefore cause potential buffer overflows): because proper string handling is a real PITA in C.

* module system
To do what? You've listed namespaces and classes separately, so what's left that you can't do in C? Most C programmerss use paired .h/.c module definition/implementation pairs, and #ifndef/#define to allow module definitions to be blindly included.

The .h/.c stuff is exactly what has to go. Headers are used as interfaces 99,999% of the time, and are an ugly hack. I want _proper_ modules/packages, like the ones in Python, Ruby, C#, Java, ObjC. ONE file (.cpp). Intelligent dependency tracking. The pimpl idiom, the need for include guards, and having to manually find circular #includes are some examples why this obsolete cruft has to go, and is gone in every single major programming language except for C and C++.

* reflection
C's a low level language. There is nothing to inspect. Feel free to build layers on top of it.

Oh come on. This is _exactly_ what I've said already: "Now, of course it is a valid point that these things do not necessarily belong in C. It is a system programming language, after all. But these features are very important for other domains, such as application development. Right tool for the right job, please. C is _not_ the shiny hammer, and not everything is a nail."

Of course C has evolved into C++ which has the useful items on your list, and is aquiring others (lambdas in c++0x).

I thought we were talking about K&R C....

Re:I've.never.used.groovy.so.I.have.a.question.

[dave87656]

For example:

import javax.swing.*;
import static javax.swing.JOptionPane.*;

Re:I've.never.used.groovy.so.I.have.a.question.

[forkazoo]

Maybe you should read some dynamic language code before making a comment like this. It's not variable and function names that are terse and compact: it's the amount (or lack thereof) of boiler plate code that accomplishes the same job. Compact syntax makes code more readable, not less, because you don't have to figure out which parts of the complexity are accidental, and which parts are essential. And of course you know that you can write inexplicably named, compact variable and function names in any language.

Sorry, that shouldn't have been anonymous.

Exactly! The reason I love Python so much is because I don't have to write very much of it for the sorts of things that I use it for. In some cases, a 100 line python script does as much work as a codebase in c++ of a few headers, a few implementation files, and a make file which add up to like 10x the writing I have to do. (Sure, a Makefile isn't actually written in c++. But, controlling the build process is one extra thing I have to worry about in c++ vs. python, and more stuff that I need to write.)

OTOH, with some types of code, the amount of headaches that I'd have to deal with in python just aren't worth it. As much as I love python, if I have to write a lot of it, I go looking for a better solution.

Re:I've.never.used.groovy.so.I.have.a.question.

[ThePhilips]

Generics solve one problem very well in my opinion.. Nested collections. It is incredibly verbose, to say the least, but if you've ever had a map of a map (repeat ad infinitum), you know what I'm talking about.. You can very easily get your type-casting wrong, and if there is a rare use-case, you won't detect the type-cast exception until it's too late.

Java created the problem to begin with. Because the standard containers required one to always convert everything to the Object back and forth.

I *LOVE* coding nested maps in the C++. Compiler detects *all* typing problems already during compile time.

[ Somehow Java managed to mess up the whole nicety of the Smalltalk or Objective-C's MVC concept and turned weak typing into a problem. Me praising C++'s strict typing?? Unbelievable. ]

As for startup times.. what exactly are you dealing with where startup times are a problem.

Desktop/interactive applications. Small (e.g. command line) tools. What describes number-wise about 90% of software today.

Re:I've.never.used.groovy.so.I.have.a.question.

[ThePhilips]

Import isn't panacea. Ever heard of name collisions?

Re:I've.never.used.groovy.so.I.have.a.question.

[ThePhilips]

Java is readable, it's just not very expressive, which means you need a lot of code to get anything done. Often you need a couple of classes to get the structure of your code right. Perl is indeed the polar opposite: expressive but unreadable.

I'd rather not bring Perl into the discussion.

In Java, one has to write readable un-expressive code to get the work done.

In Perl, there are about a gazillion of ways to code and about 1/4th of them are both readable and expressive.

In Java you have to live with it, in Perl it's your choice.

Ruby, Python and Groovy are readable, but also very expressive.

Ruby is a descendant of Perl and supports all the unreadable/inexpressive stuff of the latter. Just check the "Ruby for a Perl programmer" tutorials. One can write the arcane one-liners in Ruby too.

Re:I've.never.used.groovy.so.I.have.a.question.

[ThePhilips]

AWK is underrated...

Re:I've.never.used.groovy.so.I.have.a.question.

[mcvos]

Ruby, Python and Groovy are readable, but also very expressive.

Ruby is a descendant of Perl and supports all the unreadable/inexpressive stuff of the latter. Just check the "Ruby for a Perl programmer" tutorials. One can write the arcane one-liners in Ruby too.

It's true that Ruby contains some ugly Perlisms, but the plans for Ruby 2 are to kick them out and make the language prettier. The beautiful parts of Ruby are really very beautiful, but it still has some ugly legacy stuff.

Re:I've.never.used.groovy.so.I.have.a.question.

[youngdev]

btw I was typing this on my phone and after re-reading I noticed that I mistyped the key combo for organizing imports in eclipse. The key combo is actually ctrl + shift + o.

Re:I've.never.used.groovy.so.I.have.a.question.

[mortonda]

I find it funny that you need to imply one of 1) insertions or deletions 2) random access 3) old or obscure use or 4) yet another special type to deal with syncronization (ok, you'd probably have to do something else in ruby too, so that example is moot)

I know what can be done with a list, and in ruby duck typing, all that matters is that it responds to list like messages like [], push, pop, each, etc

Re:I've.never.used.groovy.so.I.have.a.question.

[Paul Jakma]

You have no type-safety there: some_call() may be the method that fulfills the intent of the template then again, maybe it's something completely different that just happens to have the same name.

What you're describing is basically a pre-processor/macro system. And it's a triviality to use one with Java or any other language - just add cpp, m4, whatever floats your boat, to your build process. Guess what, this is basically what C++ templates are.

Generics that act on well-defined types are a different and far more powerful thing, and C++ doesn't have it.

Also, though I havn't used C#, I think you may be wrong to claim C# generics are template based like C++. AFAICT, they're proper type-based generics. All in all, I'm left wondering if you understand generics/templates and am suspicious of your claims about which languages do what..

Re:I've.never.used.groovy.so.I.have.a.question.

[ardor]

You are wrong on several occasions. Templates are no preprocessor/macro system. Templates are turing complete, a proper duck-typed metalanguage. Duck typing does not equal "no type-safety". The problem you mention _is_ valid, but a fundamental issue in structural typing techniques. (Duck typing is a form of structural typing where the requirement-checking happens while it is being used, so to speak.) In terms of power, C++ templates _are_ comparable to Haskell typeclasses, for example - if used properly. (There are even papers comparing them.) Look up: generic programming, concepts, template metaprogramming. See the STL concept documentations for an example.

But you are right that the typing isn't enforced in the metalanguage properly. Concepts were supposed to do that, but were left out of the next revision of the language. This means that you indeed have a sort-of untyped situation, where the concept is mere documentation. You can manually replicate a concept check (which would equal the structual type checking), but this ain't trivial. However, compilation failures will happen if the concept isn't modeled properly. This is similar to the behavior in dynamic languages like Python, which use duck typing at runtime. If, say, you require something to have a foo() call, and it isn't present, the code will break when the foo() call is supposed to be made.

Also, I did not say that C# generics are template based. They aren't. They work differently, but do allow for expressions like the one I wrote, that is, without the unnecessary baggage that is an extra interface.

Re:I've.never.used.groovy.so.I.have.a.question.

[ardor]

After submitting, I see that I have contradicted myself in one sentence. Replace
"This means that you indeed have a sort-of untyped situation, where the concept is mere documentation"
with
"This means that you indeed have a not properly typed situation, where the concept is mere documentation". Because, as said, duck typing and typelessness are two different things.

Re:I've.never.used.groovy.so.I.have.a.question.

[Paul Jakma]

Thanks for your reply. I have to admit I can't tell if I'm talking to someone whose understanding is way below my own or way above :). Still, I suspect you're missing something. Apologies in advance if I'm the one being an idiot. ;)

I think I understand how the typing in C++ templates work. And yes, templates are not macros - they're a closed subset that can't be abused as macros can, and they're type-checked (I thought). And yes, if you write your programme according to a convention that says "method names must be globally unique, according to their function" it will work so long as you don't make a mistake. If that convention doesn't hold, e.g. because you're trying to use code from multiple independent sources (like using a library, whatever), or because you simply made a mistake, then it no longer works. It's a very very weak typing system, as the compiler can't help you with it much, beyond checking for the existence of a method.

The Java generics stuff is heavily influenced by CS type theory. It's not perfect per se, but it can provide quite strong guarantees. Further, I believe the C++ templates are NOT as you describe - they also require well-formed and compatible types. I did not think it was sufficient with C++ to pass any class that had whatever method names were used.

Can you give an example of the C# thing you're talking about? Cause, from what I can tell C# generics also do type-checking, as Java does.

Re:I've.never.used.groovy.so.I.have.a.question.

[Paul Jakma]

That post is bit confusing. The 2nd paragraph largely is talking about how typing would work if it depended only the existence of a member element - which is the level of safety you get with macros, and which you seem to be talking about. However, I believe C++ templates are type checked.

I see what you mean now about C#, it has "dynamic" typing. My comments from the 2nd paragraph on type safety would apply to it.

FWIW, you could sort of achieve the same with Java introspection, but you'd need a lot more scaffolding.

Re:I've.never.used.groovy.so.I.have.a.question.

[xiong.chiamiov]

ArrayList myList = new ArrayList();

More seriously, how much time does a developer spend typing compared to what he should be spending thinking ?

Not a lot, admittedly, but the fact of the matter is that I generally just decide that I want a list of things to do [whatever I'm actually thinking about], and I don't want to have to wonder if I actually want an ArrayList, or a LinkedList.

The fact that java forces you to type more also forces you to type basic documentation as you code

I don't understand your logic here at all. If anything, I'm more likely to write more documentation when I'm writing less code (to do the same thing), since I'm not all tired out from typing. It's not like once I get my fingers flowing they just keep typing on their own.

I have never understood developers saying that a language was superior because you can write code using less key strokes using it.

Having to write less is only a minor argument, and is related to being able to spew out your thoughts quickly - it's annoying when your train of thought gets interrupted because you're too busy typing lots of boilerplate crap.

More importantly, though, is that there is much less to read. When I look at most Java code, it's difficult to quickly parse what's going on, whereas a smaller language like Python or Ruby tends to be much more easily grokkable. Note that terseness is not everything, as Perl has proven.

Re:I've.never.used.groovy.so.I.have.a.question.

[ls671]

> Not a lot, admittedly, but the fact of the matter is that I
> generally just decide that I want a list of things to do
> [whatever I'm actually thinking about],

Yep, you want to have everything quickly without planning and thinking long term. Chances are your code will be less easily maintainable. I simply use bash scripts for throw away code to do a job quickly. You seem to have a throw away code coder attitude.

> I don't understand your logic here at all. If anything, I'm
> more likely to write more documentation when I'm writing
> less code (to do the same thing), since I'm not all tired out
> from typing. It's not like once I get my fingers flowing they
> just keep typing on their own.

Indeed, you do not understand ! Nicely written Java code with meaningful variable names needs almost no documentation. The code self-document itself, this is the idea.

> Having to write less is only a minor argument, and is related
> to being able to spew out your thoughts quickly - it's
> annoying when your train of thought gets interrupted
> because you're too busy typing lots of boilerplate crap.

You mean your thoughts are so clear that you need to write them right away in fear of forgetting them ? This seems illogical to me. It sounds like a music jam session, of course you ain't going to stop for thinking when you are jamming. Are you jamming when you write code ?

You could use bash scripts for everything then, do you begin to get the idea ?

Also, if you were fluent at Java, you would realize that with auto-complete and modern development tools, you can write Java code just as fast. (auto-imports etc..). As a bonus, modern tools will hint you when you do something that might be stupid so, at least you get a warning.

> More importantly, though, is that there is much less to read.
> When I look at most Java code, it's difficult to quickly parse
> what's going on, whereas a smaller language like Python or
> Ruby tends to be much more easily grokkable. Note that
> terseness is not everything, as Perl has proven.

Much less to read should obviously go with less self documented code.

Anyway, if you do not get it, chances are you never will, giving my past experiences with people bringing exactly the same arguments as you did. So let's keep our own opinions and respect each other anyways ;-))

Re:I've.never.used.groovy.so.I.have.a.question.

[xiong.chiamiov]

Not a lot, admittedly, but the fact of the matter is that I generally just decide that I want a list of things to do [whatever I'm actually thinking about],

Yep, you want to have everything quickly without planning and thinking long term. Chances are your code will be less easily maintainable. I simply use bash scripts for throw away code to do a job quickly. You seem to have a throw away code coder attitude.

Admittedly, I do, since quite a few of the things I write *are* throwaway. I tend to use perl/python/ruby rather than bash, though.

I don't understand your logic here at all. If anything, I'm more likely to write more documentation when I'm writing less code (to do the same thing), since I'm not all tired out from typing. It's not like once I get my fingers flowing they just keep typing on their own.

Indeed, you do not understand ! Nicely written Java code with meaningful variable names needs almost no documentation. The code self-document itself, this is the idea.

Nicely written Python code with meaningful variable names also needs almost no documentation.

Having to write less is only a minor argument, and is related to being able to spew out your thoughts quickly - it's annoying when your train of thought gets interrupted because you're too busy typing lots of boilerplate crap.

You mean your thoughts are so clear that you need to write them right away in fear of forgetting them ? This seems illogical to me. It sounds like a music jam session, of course you ain't going to stop for thinking when you are jamming. Are you jamming when you write code ?

I most certainly am.

You could use bash scripts for everything then, do you begin to get the idea ?

I would if bash didn't suck so much. The languages I use are much faster to write than bash scripts.

Also, if you were fluent at Java, you would realize that with auto-complete and modern development tools, you can write Java code just as fast. (auto-imports etc..). As a bonus, modern tools will hint you when you do something that might be stupid so, at least you get a warning.

Eclipse/NetBeans/IntelliJ won't turn my

for city in ('austin', 'atlanta', 'albuquerque'):

into

String[] cities = {"austin", "atlanta", "albuquerque"};
for (String city : cities) {

Admittedly, that's just a poor implementation of for loops, rather than boilerplating, but it still stands that I am forced to think about things that I don't wish to (or at least, in a different order than is natural for me).

I use an almost-IDE (Komodo Edit) for all of my code, so I am quite aware of (and appreciate!) the niceties of a modern editor. That's no excuse for being overly verbose (see: json vs. xml).

Re:I've.never.used.groovy.so.I.have.a.question.

[ls671]

Nice reply ;-)

Re:I've.never.used.groovy.so.I.have.a.question.

[SnapShot]

(Sorry for the delay)

I should have been more clear. A linked list (implemented as a dequeue, I think) provides for O(1) efficiency for insertions and deletions while an array list is O(N). However, an array list allows for O(1) for random access while a linked list is O(N). You use different list types for different tasks.

The vector is an old version of an array list this is synchronized. The current, correct way of indicating a synchronized data structure is to wrap it on one of the "Collections" wrappers.

But, don't get me wrong. I'm loving working in Ruby but it doesn't make Java inherently wrong, just different.

Well this is awkward

[RevWaldo]

I'm currently in a CS class that uses Java to teach software design; although the emphasis is made that the principles involved are applicable to most other software languages.

So what are considered the "write your own ticket in this job market" languages if you know them backwards, forwards, and sideways?

Re:Well this is awkward

[Shados]

.NET, Java, PHP and C++, each with their own specialty fields, so which one you end up using depend greatly on what you end up doing.

Re:Well this is awkward

[AuMatar]

None. Learn algorithms, data structures, and theory. You can and will change languages a half dozen or more times in your career. Theory works for everything. And the good employers know that.

Re:Well this is awkward

[shutdown -p now]

Learning languages doesn't hurt, either, since there usually aren't great leaps there - new languages evolve from old ones, and a lot of concepts remain the same. Syntax changes occasionally (though it looks like we're stuck with curly braces family for a long time to come), but semantics, not so much.

Of course, learning several is still much more helpful than learning one, even if you aren't going to use most of them. Quite often, learning another language leads to an insight of why the one you were using before is designed the way it does (and maybe even what is wrong about that design, and how people learned from that mistake).

Re:Well this is awkward

[incripshin]

(First of all, the article title brought the biggest smile to my face.)

At least you can use it. I had Scheme for my intro class, and that doesn't exactly come in handy unless you're in PL. Anyway, I'm self-taught in almost every language I know. Most classes I've had either tell you 'we're using X, so keep up' or 'just write it, we don't care how'. Maybe take each summer as an opportunity to learn a new language.

I definitely get pissed off when I hear whiny untalented graduates say their CS program didn't give them what they needed in the real world (so don't be one of them). Good CS programs don't waste time teaching languages. It's all about the algorithms, data structures, and theory.

That said, you'll need to know some languages backwards and forwards. At least a general-purpose language (C, C++, Java, Go, etc) and a scripting language (Python, Perl, etc). Definitely learn how to do parallel programming in some of them. Also regular expressions: built-in to many languages and accessible from the rest.

Re:Well this is awkward

[ScrewMaster]

None. Learn algorithms, data structures, and theory. You can and will change languages a half dozen or more times in your career. Theory works for everything. And the good employers know that.

Good engineering managers may, but HR departments don't.

Re:Well this is awkward

[Dragoniz3r]

Do be careful to be aware of the distinctions between "theory" and "academic buzzword of the year" though. I think this year it's Patterns or some such?

Re:Well this is awkward

[cheekyboy]

yeah well in my CS class in the 80s, we were taught PASCAL, and yeah... that really went somewhere didnt it.

Re:Well this is awkward

[Beezlebub33]

Most of your advice is good. However,....

It's all about the algorithms, data structures, and theory.

I'm annoyed when I see CS graduates who have never heard of source control, bug tracking systems, continuous integration, unit testing, haven't learned how to debug their programs, don't have any idea how to write comments, how to draw a UML diagram (of any kind), or work as part of a team. But, damn, they know their doubly-linked lists! I think that there should be a class that teaches people some of the basics about how to be a programmer in real life.

No, this should not be on-the-job training. It's part and parcel of being a developer in the real world. You don't need to know the intricacies of git, or how to deploy Hudson. But, you have to have some of the basic concepts taught to you in a 'here's why these things matter' fashion. Otherwise, the young developer is going to be breaking things for a long time.

That said, you'll need to know some languages backwards and forwards. At least a general-purpose language (C, C++, Java, Go, etc) and a scripting language (Python, Perl, etc). Definitely learn how to do parallel programming in some of them. Also regular expressions: built-in to many languages and accessible from the rest.

Yes, I would hope that these should be part of a normal modern CS curriculum.

Re:Well this is awkward

[incripshin]

Yeah, I have a bit of disdain for software engineering, so I would never think to mention it. I agree with most of that, except for the UML.

I meant that you learn languages on your own to get along, but it shouldn't be a part of the curriculum. Once you have learned a couple languages, you realize that they're all the same. The only way language-learning belongs in the curriculum is (1) for an intro class, (2) the class spends only a couple weeks on the language, or (3) a low or zero credit course teaches a language.

The VM is decent. The language sucks.

[SanityInAnarchy]

I remember taking a long, hard look at the state of various VMs awhile back, and here's what I came up with: .NET isn't a bad design, but it's entirely controlled by Microsoft.
Rotor doesn't change that at all.
Mono changes it a little, but Mono (at least back then) wasn't really a great platform in its own right -- not enough tools, not enough reason to use it, always playing catch-up. Plus, there's the whole patent issue.
On top of all of that, it was never really designed to be cross-platform, and instead seems to be primarily aimed at creating native apps.

The various "scripting" languages have been moving towards VM architectures, and some are quite good, but none that I know of actually feature any kind of ahead-of-time compilation, even to bytecode. That includes Perl, Python, Ruby, JavaScript, and plenty of others.

Lisps are better, but they generally don't compile to an intermediate form -- if they compile at all, it's to something platform-specific, likely machine code.

Smalltalk is interesting, but is even more closed off than Java, and basically requires an entirely different set of tools for working with. It's not really designed to work as a text-based language.

The closest would seem to be Erlang, but it's radically different. While I know of at least one other language trying to target the Erlang VM, it's something that's really designed to work with Erlang. I'm also not entirely sure if the performance is there.

LLVM looks very, very good, but very few languages actually target it, beyond, say, C. It seems to be targeting runtime optimizations, not portability.

I probably looked at a few others I'm forgetting now...

Basically, the top two are still Java and .NET. Both present a VM that supports multiple real languages. In Java, this is by accident, it's hackish, but there are plenty of robust, mature languages other than Java which target it -- Scala, Groovy, Clojure, JRuby... In .NET, this is by design, but the more interesting other languages targeting it seem to be in an alpha state.

So Java is pretty much it. And it means we can take our fun, dynamic languages, and (eventually) compile them to Java bytecode, and create entirely cross-platform apps with no local dependencies other than Java. It means we get much of the work that's been put into optimizing Java for free -- for example, the Java garbage collector. It also means that even when designing a native app, well, Ruby just got threads in 1.9, and there's still a GIL, so no support for multicore. Python has and probably will always have a GIL. JRuby has had real, native Java threads almost as long as it's existed. Ruby has plenty of options for concurrency, but if you want to take advantage of multicore, your options are either JRuby or a unix fork(), and Ruby's GC is not COW-friendly, so fork() is potentially much more expensive than in other languages.

I don't know if Java is the way forward. I hope someone builds something cool on top of LLVM. I certainly hope Java the language dies. But the JVM is about the best we have in terms of open-source, cross-platform, compile-once-run-anywhere VMs.

Re:The VM is decent. The language sucks.

[devent]

I don't get it, why you want the java language to die? I programming Java now for 4 years and the only thing I'm missing are closures.

The core of Java is very robust, you have class, enums and interfaces. Generics are do what they are suppose to do (and they are backwards compatible). Threading is integrated in the Java with synchronized and the threading API. In addition, Java have neat features like annotations and anonymous classes.

Reflection is very easy to use, but the exception model is perhaps debatable.

The tools and the libraries are top class. Maven is my favorite killer-tool for Java.

If Java get closures, what are you missing in Java? It's maybe not the future but Java is a very robust and consistent language.

Re:The VM is decent. The language sucks.

[fatwilbur]

Good analysis, I agree with most of your points. I've also lead a few different development teams at large organizations. I'd like to point out that the cross-platform capability of Java is usually a very insignificant aspect; for business software, 99% of it has migrated to the web so it doesn't really matter what we run in the back end, we control it. Developing business software is a bit more fully functional (windows desktop integration) and easier (cheaper).

Re:The VM is decent. The language sucks.

[Just Brew It!]

Google has been working on a version of Python that targets LLVM instead of the Python bytecode interpreter. They're also planning to attempt to tackle the GIL issue, but that may be wishful thinking...

Re:The VM is decent. The language sucks.

[0xdeadbeef]

The .NET VM is no less "hackish" than other languages targeted to Java. They both essentially follow the same model for their bytecode. If anything, the blatant Windows-isms make the CLR far more clunky.

Re:The VM is decent. The language sucks.

[Logic and Reason]

Functional programming and dynamic typing. There's also the general ugliness and verbosity of Java's syntax, and the over-engineering that so many of its libraries suffer from.

Re:The VM is decent. The language sucks.

[devent]

Well, Java isn't a functional programming language and is strong typed. The same is valid then for C, C++ and C#. As I said, with closures it will be much better. Hopefully they will be implemented.

As for the libraries, maybe you using the wrong ones? Compare for example Ammentos ORM library (Java) with OPF3 (C#). Annotations are a very good feature, I wouldn't use a library now that don't utilizing them.

Re:The VM is decent. The language sucks.

[deblau]

Perl has bytecode. Yes, it's experimental, but I've played with it and it works.

Re:The VM is decent. The language sucks.

[binarylarry]

Yeah but .NET has a great marketing program that's been very successful in seducing the lower rung programmers into thinking that the CLR is not a JVM clone, C# isn't a Java clone, etc, etc.

Re:The VM is decent. The language sucks.

[binarylarry]

99% of it has moved to "the web" and the majority of the the servers running "the web" are Java.

I doubt you've done any serious enterprise development. Being able to run software on both Windows or a Unix with no changes can be a god send at times.

Re:The VM is decent. The language sucks.

[WeirdJohn]

Smalltalk is interesting, but is even more closed off than Java, and basically requires an entirely different set of tools for working with. It's not really designed to work as a text-based language.

I don't think you've really looked at all the issues with Smalltalk. If you look at squeak, for example, most of the VM is smalltalk, that gets translated to a subset of C, and you only have to implement primitive data types to build a new VM on a new platform.

Gnu Smalltalk is text-file based (and is unusual amongst smalltalks for it).

As for tools, smalltalk provides the tools, they are just different than what is used for other languages. The tools for smalltalk (the browser, monticello, the file list etc) work really well for smalltalk. It's not that you have to learn a new set of tools to use smalltalk, rather that there is no need for any others - nearly 40 years of development has produced a very efficient and intuitive environment.

In my opinion the only place Java beats Smalltalk is in that its threading model is a bit more efficient. In return you are forced to abandon most of the benefits of a dynamic language, and use multiple layers of nearly-C++ to get the job done. Or maybe I just don't understand Java. I don't get why an object has to care about what class a reference dereferences to, and why methods have to have all that type declaration fluff around them. Maybe I'm just old though.

Re:The VM is decent. The language sucks.

[peppepz]

I find no appeal in dynamic typing. It just makes programs harder to read and debug. Have you tried Scala? With type inference, it manages to get the type-safety of static typing along with the reduced verbosity traditionally associated to dynamically typed languages.

Re:The VM is decent. The language sucks.

[chromatic]

... none that I know of actually feature any kind of ahead-of-time compilation, even to bytecode.

Parrot does, and thus so does Rakudo Perl 6.

Re:The VM is decent. The language sucks.

[shutdown -p now]

The .NET VM is no less "hackish" than other languages targeted to Java. They both essentially follow the same model for their bytecode.

.NET gives you more primitives, though - byref, unmanaged pointers, structs, unions etc - enough so to write, say, a fully conformant ANSI C implementation targeting it, with practically no dirty hacks (I think you'll need to use exceptions to simulate setjmp/longjmp, but that's pretty much it). Try that for JVM.

Or, say, tailcalls. It's why ML/F# is doable on CLR, but not on JVM.

If anything, the blatant Windows-isms make the CLR far more clunky.

The multitude of references to Win32 concepts in the base CLR spec is definitely annoying, but a portable IL generator can pretty much ignore them.

Re:The VM is decent. The language sucks.

[omuls are tasty]

They gave up on removing the GIL, and their work is accepted for merge into Python 3.3.

Re:The VM is decent. The language sucks.

[TeknoHog]

The various "scripting" languages have been moving towards VM architectures, and some are quite good, but none that I know of actually feature any kind of ahead-of-time compilation, even to bytecode. That includes Perl, Python, Ruby, JavaScript, and plenty of others.

Python is, by default, compiled to bytecode before execution. There are also third party compilers to native code.

Re:The VM is decent. The language sucks.

[owlstead]

Both are a problem for code maintainability. Java will never have dynamic typing. It's not that it is hard to implement (e.g. look at bsh an interpreter that is still, basically Java), it's that it has way to many drawbacks. If you want to have that, use a scripting language (and don't use it for large programs).

Re:The VM is decent. The language sucks.

[owlstead]

Even with type inference, I feel that the idea of interfaces and implementations (e.g. a Set can be any class derived from the Set interface underneath) is weakened. I haven't tried any type inferring language long enough to see if it matters enough. It's certainly one of the more verbose things about Java.

Re:The VM is decent. The language sucks.

[u17]

A couple of reasons why Java sucks:

1. No proper support for namespaces (see my other comment)
2. No support for storing members in-place. If you want a Vector3d class, (i.e. an array of 3 doubles with an associated set of functions), and you want it to be fast, without referring to the members by pointers, you have to enumerate the members: {double x; double y; double z;}. If you wanted to have an array of doubles, you could only store a pointer to the array, and with an extra allocation: {double[] data = new double[3];}. For a Vector3d this is not so bad. But imagine the code for Matrix4x4d. This is a real shortcoming, if you look at Java3D, it actually uses a matrix with members defined like this: {double m00; double m01; double m02;... etc, 16 times}, instead of a double[][] array. If you do it this way then in functions you have to manually unroll loops, you can't just iterate over the values.
3. No support for proper templates. The "generics" are only syntactic sugar. You can't have something like template <int N, int M> Matrix<N, M> for faster code. ArrayList<int> doesn't work. When you write "arraylist of integers", you expect an object with a tightly packed array if ints. But the only way to do this in Jave is to box them, and if you do, think of the waste: the array actually holds pointers and each Integer is separately, individually allocated. Additionally, each Integer not only holds an int, but also a mutex, which leads to the next problem.
4. Every object has a mutex. WTF? Why endure such a huge waste, why increase the size of every object, when only very few of their mutexes are actually used?
5. No operator overloading. OK, this can be abused like everthing else, but when you're working with a custom number class or with BigInteger, you don't want to clutter your code with method names that represent operators.
6. No unsigned types. Of course there are conversion issues when mixing signed/unsigned in expressions. Normally you're fine with just signed, but what about, say, file formats that have uint64_t in them? Should you store them in BigIntegers?
7. The standard library is a mess. They keep putting more and more stuff into it, never deprecating anything, and the result is pretty bad in many places. The library is over-engineered and in many places the implementation shines through the interface. They keep shooting themselves in the foot by having to maintain crap code like Swing for eternity. Coding in Swing is horrible when compared to, say, Gtk.
8. Missing lambda functions/closures, 'nuff said
9. No function pointers. This leads to one-function interfaces which only clutter your code whenever you use them.
10. No typedefs. Especially when using generics, you don't want to type Map<String, List<Integer>> all the time, you want to type MyFancyMap instead.

There are more things, these are just those that irk me most. I love the idea of applets, webstart, and portable bytecode, and I'd love to see Java succeed, but the language is so badly done I can't see this happening.

Re:The VM is decent. The language sucks.

[MemoryDragon]

I think java is the way forward, Java the language itself is aging, basically also because of the stallment on the language side of things, but the exciting part is the framework ecosystem there has been so much bleeding edge research going on on the frameworks side and you also have one of the biggest library ecosystem in the world which is cross platform that it would be unwise not to leverage the VM as base.
The funny thing is that Java7 might give scripting languages a severe speed boost, it will ad an invokedynamic operation on bytecode level for untyped method and function invocation.
The only thing missing is class hotplugging, you still have to go through some hoops to enable that instead of having a real hotplugging on VM level. Not sure if this applies to the bytecode level.

Re:The VM is decent. The language sucks.

[Just Brew It!]

Cool. I'd only been following the project sporadically since its announcement, and didn't realize that they'd been accepted for merge into the upstream code. Too bad about the GIL (but not surprising).

Re:The VM is decent. The language sucks.

[SanityInAnarchy]

If Java get closures, what are you missing in Java?

Others have listed other reasons, but let's see...

It's statically typed. Understand, I don't mind strict typing (Ruby is strictly typed), I just get annoyed at having to declare variable types all the time.

The generics is a mess -- as u17 says, it's a hack, and it's also incredibly difficult to understand, and requires a lot of heavy thinking and planning about types and interfaces. Compare to what you get for free from a language like Ruby.

And most of that mess is in the name of backwards compatibility. Excuse me, but do we care that much about backwards compatibility? I suppose it made sense at the time, and I suppose I can't blame them, but it cripples the language today.

Java's threading API sucks. Aside from the overhead u17 pointed out, it's still the same old threading API. Compare to something like Erlang.

Reflection? Easy to use? You've obviously never used a language where it's actually easy to use, like, say, Ruby.

Aside from closures, it's missing Lisp's macros, which take that idea to a whole other level.

And the syntax is brittle -- no operator overloading, for one -- it'd be very difficult to correct any of what I've just said with a library. For example: In most sane languages, a == b has well-defined semantics of comparing the values of a and b. In Java, it compares the values for numerical primitives, and the references for everything else. Because of this, you end up with Object.equals(), which is much more verbose and cumbersome to use, and incurs boxing/unboxing overhead when used with primitives.

Yet despite all that, Java does do some overloading of its own with Strings -- it overloads +, but not ==.

So you can imagine, just about anything interesting I'd want to add to the language, which would be an internal DSL in smarter languages like Ruby and Lisp, would be a mess of verbose library calls in Java.

Similar problems: You can use enumerations and integers for a switch statement, but you can't use strings. Because Java lacks any meaningful way to modify the primitive types, and isn't flexible enough to override case itself, you can't fix this to do what you'd expect, which is for it to use Object.equals(), or even a more verbose version that allows you to pass a Comparator.

What else...

No keyword arguments, and no sane way to add syntax for them. No built-in hash type, and thus no hash literals. Ruby doesn't have keyword arguments either, but its syntax is loose enough that you can use the builtin hashes to replace them.

No symbols/atoms, either.

No good interactive shells. Then again, do you really want an interactive shell in a language that's that friggin verbose?

Hell, verbosity deserves a category of its own. Just look at Hello World in Java. Compare to Hello World in pretty much any other language.

The built-in array type, aside from having an unnecessarily verbose literal, is also a fixed size. I suppose it's useful to have a fixed-size array, but 99% of the time, that's not what you want. Make ArrayList the default array type, have things accept Lists (or better yet, Collections) rather than arrays, and provide syntactic sugar for creating ArrayLists instead of Arrays, then tuck the actual Array type deep in some system library so programmers don't have to bother with it again... but like so many of these problems, you can't actually solve it that way without breaking the language.

Then again, u17 points out a potential problem with that -- ArrayLists, like all Collections, must store objects (and thus references) rather than the actual values. That means ArrayList<Integer> is necessarily slower and bloatier than int[] (by much more than it should be), and there's again nothing you can do about it. Contrast to Ruby -- you'd expect a construct like [1, 2, "three", 4] to be even worse, but it's actually better than an ArrayList of [1,2,3,4] in Java -- I believe it uses a

Re:The VM is decent. The language sucks.

[SanityInAnarchy]

Granted, but I was wanting to do game development -- you're going to need a desktop client of some sort. The idea was to have a very small set of native bindings, and have the entire game be portable.

Taken a step further, which I didn't mention (but did consider while evaluating these VMs), I wanted to be able to sandbox a program without losing too much performance. The idea here was to be able to download a game targeting my meta-platform on any platform (Windows, Linux, OS X, consoles) without worrying about security, and to be able to develop such a game without worrying about portability.

If I was going to try that again, I'd probably use WebGL -- but notice, the problem hasn't disappeared, and some new problems have cropped up, like the reluctance of proprietary software developers to allow their source code to be distributed -- they'd be much more comfortable with some sort of bytecode representation.

Re:The VM is decent. The language sucks.

[SanityInAnarchy]

Python normally caches the compiled bytecode of imported modules in .pyc files and only recompiles them as necessary. It also provides modules for doing this beforehand, which can also be used like programs with python -m, which most distros will do when packages with Python code are installed, because you won't have write access to /usr/lib (or wherever) as a normal user. It is also capable of directly running bytecode even without a corresponding source file.

Sorry, I forgot about that. I suspect it was the GIL that was the deal-breaker here, not to mention the fact that it was tied to a single platform.

I don't know about Perl and Ruby, not being particularly familiar with them, but I wouldn't be surprised if they could do something similar.

They can't. Perl6 will be able to, if it's ever released.

JavaScript can't really be compared to any of the others, as the language doesn't have any standard implementation, de facto or otherwise, and thus one cannot sensibly speak of the features of "its implementation".

Well, we can talk about the fact that Google's v8 (part of Chrome) JIT-compiles to native code, and Firefox and Safari both contain relatively fast Javascript engines which have got to be doing something similar.

You are going to have to provide different packages for all the different platforms you wish to support,

Not necessarily. I suppose it's the case right now that you can't expect users to know what to do if you just give them a jar, but as a contrived example, suppose I distributed a single .deb and a single .rpm. If that contained either source or bytecode, it would work on pretty much all Linux platforms. If it contained machine code, it would be bound to a specific architecture.

using the same binary for all of them really only saves you compilation time,

That can be significant, but the primary motivation here was a new platform which would allow distribution of cross-platform proprietary apps.

The idea was that there are still some apps which don't make sense as web apps (yet) -- my motivation at the time was games -- and if people are going to be building these at all, I'd much rather they be inherently, automatically cross-platform than Windows-only.

Re:The VM is decent. The language sucks.

[SanityInAnarchy]

When I Google that, I find an OS. Fine, but what languages target it?

Re:The VM is decent. The language sucks.

[SanityInAnarchy]

As for tools, smalltalk provides the tools, they are just different than what is used for other languages. The tools for smalltalk (the browser, monticello, the file list etc) work really well for smalltalk.

That's great, but they are also different than the tools for any other language. I want to be able to use my favorite text editor, my favorite version control system, etc.

there is no need for any others - nearly 40 years of development has produced a very efficient and intuitive environment.

And nearly 40 years of development has produced a multitude of general-purpose tools that make me more productive with any language.

In my opinion the only place Java beats Smalltalk

As a language? No contest, you're right.

But with Java, I compile source to bytecode representations, zip those up, and distribute them. With Smalltalk, unless I'm misunderstanding something, I run that program, edit the running program if I want to make a change, and save a bytecode snapshot of a running program, then distribute that -- which seems somewhat cumbersome if someone else wants to import my program into their Smalltalk environment.

I don't get why an object has to care about what class a reference dereferences to, and why methods have to have all that type declaration fluff around them.

I agree completely, which is why I use Ruby when I can.

Re:The VM is decent. The language sucks.

[SanityInAnarchy]

I'm not targeting a big system anyway.

Re:The VM is decent. The language sucks.

[SanityInAnarchy]

So when will these actually be ready for general use?

Re:The VM is decent. The language sucks.

[WeirdJohn]

But with Java, I compile source to bytecode representations, zip those up, and distribute them. With Smalltalk, unless I'm misunderstanding something, I run that program, edit the running program if I want to make a change, and save a bytecode snapshot of a running program, then distribute that -- which seems somewhat cumbersome if someone else wants to import my program into their Smalltalk environment.

If I'm distributing a commercial product, then I do as you've described. Or I can file-out a class or category (or a change set) and distribute the source for file-in into someone else's image. Not so different from how C works. A very common misconception by the way. Exactly when something is run is also an interesting question, as all objects are live, including those objects called classes.

Re:The VM is decent. The language sucks.

[binarylarry]

I wouldn't call it more elegant it just has more features.

It's like saying the Homermobile was more elegant than a Mercedes.

Re:The VM is decent. The language sucks.

[Logic and Reason]

Both are a problem for code maintainability.

I've heard this claim about dynamic typing before, but never with any evidence. Can you offer any? And why would functional programming be bad for maintainability?

Java will never have dynamic typing.

Did I say I wanted those features added to Java? I was simply expressing what I don't like about the language. Java can stay exactly as it is until the end of time, for all I care.

It's not that it is hard to implement (e.g. look at bsh an interpreter that is still, basically Java), it's that it has way to many drawbacks.

You know you can have both static and dynamic typing in the same language, right? See Objective-C, for example.

If you want to have that, use a scripting language (and don't use it for large programs).

So you think all dynamic languages are "scripting languages"? Enjoy being left behind over the next few years.

Re:The VM is decent. The language sucks.

[r7]

Java had a great start but really dropped the ball after the first couple of releases, as did its parent company after SunOS 4. I mean come on, Java had no regular expression support until Java 1.4!

The future of Java is in its scripting languages, Jython in particular. As per Sun's "GM Management Style" their languages guru emphasized Groovy and Jruby and didn't support Jython to class compilation development. Not surprisingly Java's slide has continued throughout this manager's tenture. He resigned a few weeks ago, indicating there is more of clue among top management.

If the dysfunctional JVM scripting language de-emphasis goes away we'll be see more applications with a Java core and scripting at the edges. I'm sure hoping it does, and soon.

Re:The VM is decent. The language sucks.

[owlstead]

Both are a problem for code maintainability.

I've heard this claim about dynamic typing before, but never with any evidence. Can you offer any? And why would functional programming be bad for maintainability?

The more options are left open for runtime bugs, the more bugs will be in the final product. The more options there are for converting one value to another, the more bugs there will be in the final product. There is a lot of things that can go wrong during conversion.

Java will never have dynamic typing.

Did I say I wanted those features added to Java? I was simply expressing what I don't like about the language. Java can stay exactly as it is until the end of time, for all I care.

Well, that's what the main article is about.

It's not that it is hard to implement (e.g. look at bsh an interpreter that is still, basically Java), it's that it has way to many drawbacks.

You know you can have both static and dynamic typing in the same language, right? See Objective-C, for example.

Yes, e.g. bsh supports that as well. I know that is a possibility, and I know sometimes including both options can be a viable alternative that should certainly be considered. In this case though it would certainly lead to sloppier code. Sloppier code is not something most Java programmers (should) want. And including each and every option in a language is also a big no-no (e.g. D, the language that ticks everything off).

If you want to have that, use a scripting language (and don't use it for large programs).

So you think all dynamic languages are "scripting languages"? Enjoy being left behind over the next few years.

Meh, no. Not really. I have programmed C, C++, JavaScript and Java professionally. I've tried out at least JavaFX, PHP, C, C++, Lua, SmallTalk, Python and PERL. Oh, and lately Google GO (highly unfinished unfortunately). Then there are the domain specific ones (.bat, bash, awk, sed, SQL etc).

Strangely enough, when it comes to creating secure, maintainable programs as well as API & tools support Java still seems to be top of the hill. I'd jump to a language that would improve on the secure/resilient programming ideas expressed in Java. E.g. no basic types, additional constructs for (runtime) immutability, everything final and non-null by default, default private fields etc..

Instead there are all those programming languages that focus on expressing things in as few characters as possible or doing things a full ms faster. Oh well, at least closures (and other functional language features) will make some problems clearer to express, that certainly is a boon.

Re:The VM is decent. The language sucks.

[u17]

I did not explain this sufficiently because to me it seemed obvious. "No lambdas" is closely related to "No function pointers", and the argument is similar. The advantage of lambdas as I see them is that you can specify the body of a callback function "in-line". You can already do something similar with anonymous inner classes, but only if you accept the boilerplate code you need to provide whenever you use them. The boilerplate code is especially annoying when you only want to define a single callback method.

I agree with you that the ability to slap a method on an object does not lead to good code, but I view this as a different feature from lambdas.

In comparison with the other bad points of Java, this point is perhaps not the most important, but having closures would certainly contribut towards eliminating some of the "ugliness" of the language.

Re:The VM is decent. The language sucks.

[Logic and Reason]

The more options are left open for runtime bugs, the more bugs will be in the final product.

Maybe if all else were equal, but it's not. I could argue that the time you save with a dynamic language leaves more time for debugging, and that the kinds of errors a type system helps with are generally the kind that show up early and are easy to fix.

Anyway, there's a reason I asked for evidence and not arguments. I've heard plenty of the latter already.

The more options there are for converting one value to another, the more bugs there will be in the final product. There is a lot of things that can go wrong during conversion.

I'm not sure how this is relevant to dynamic typing. Are you referring to weak typing?

Re:The VM is decent. The language sucks.

[ralphbecket]

Well, it's more efficient for a start since generics are part of the IL. Java generics, as I understand it, allow extra checks by the compiler, but still result in dynamic type cast instructions in the generated bytecode.

Re:The VM is decent. The language sucks.

[owlstead]

Personally I don't think dynamic language leaves more time for debugging; you need to do a lot more debugging, and debugging takes time (unless you are that one off programmer that never makes obvious mistakes). I can type a 300 line Java application including multi-threading that runs the first time.

As for the evidence, I can supply as much evidence as you can for the "over-engineering" of the libraries. This is a discussion forum, winning arguments by skipping logic and asking for hard facts is not something you can do.

Hmm, yes, weak typing has problems with conversion. Dynamic typing also suffers from problems but not conversion specifically. Most of the time dynamic typing occurs when weak typing is used, but it was not correct to equal them.

Re:The VM is decent. The language sucks.

[chromatic]

They're both available from the FreeBSD, Fedora, Debian, and Ubuntu repositories, among others. Do you have more specific requirements in mind?

Re:The VM is decent. The language sucks.

[Logic and Reason]

I simply disagree that dynamic languages require "lot more debugging". We're not likely to come to an agreement on this based on logic alone, which is why I specifically asked for evidence-- I was trying to avoid pointlessly retreading well-known arguments, not to "win" the discussion.

By the way, I haven't heard your reason for claiming that functional programming is also bad for maintainability. And in this case I am interested in arguments, since this is the first time I've heard such a claim.

Re:The VM is decent. The language sucks.

[SanityInAnarchy]

Stability? Maturity?

Basically, this page has a large and scary list of stuff that's not done yet, but is in the basic language spec. It's also pretty clear they're nowhere near 1.0.

I admit, that's much farther along than any Perl6 was last I checked, but contrast to, say, JRuby, which is in version 1.4, has access to tons of Java libraries (Does Rakudo connect me to Perl5 libraries from CPAN?), and is, in general, actually production-ready.

Re:The VM is decent. The language sucks.

[chromatic]

Basically, this page has a large and scary list of stuff that's not done yet, but is in the basic language spec.

That list is a year out of date.

It's also pretty clear they're nowhere near 1.0.

"Stability" and "maturity" mean different things to different people. Good luck encoding all of that into a single floating point number.

JRuby, which is in version 1.4, has access to tons of Java libraries....

JRuby has advantages and disadvantages. One huge advantage is that it has had years of funded developer time. Another is that Ruby 1.9 is a much, much simpler language than Perl 6 (there's almost no type system in Ruby, for example). Yet another is that the implementors have, at times, considered themselves free not to support core Ruby features.

Does Rakudo connect me to [Perl 5] libraries from CPAN?

Indeed it does, and to libraries written in other languages running on Parrot.

... is, in general, actually production-ready.

You write that as if you believe that "production-ready" is a boolean quality. That doesn't match my experience. The only reason I don't use Rakudo as the basis of my own business is that it hasn't been worth my effort to port existing software to Perl 6. If I were to write that software anew today, I'd use Perl 6.

Re:The VM is decent. The language sucks.

[mahadiga]

Wondering why JVM is not bundled in IC?

Re:The VM is decent. The language sucks.

[owlstead]

The problem with functional constructs is simply their complexity. They. Require a whole new way if understanding a problem. Because of their power they are often expressed in a sperse, abstract way. Just look at the examples given by the proponents.

I'm already preparing to think on how I can explain them to my colleagues. And I will have to because they are going to wind up in libraries. They also tend to broaden scope. A larger scope means more testing and less programmatic security.

From my android, I apologize for wrong words un advance (no keyboard).

Re:The VM is decent. The language sucks.

[Niten]

The various "scripting" languages have been moving towards VM architectures, and some are quite good, but none that I know of actually feature any kind of ahead-of-time compilation, even to bytecode. That includes Perl, Python, Ruby, JavaScript, and plenty of others.

Just a minor correction, Python can be pre-compiled to bytecode:

http://effbot.org/zone/python-compile.htm

But I definitely agree with you on the whole.

Re:The VM is decent. The language sucks.

[SanityInAnarchy]

That list is a year out of date.

Out-of-date documentation is scary.

"Stability" and "maturity" mean different things to different people... You write that as if you believe that "production-ready" is a boolean quality.

It is boolean depending on the individual, yet we still generally seem to have a consensus about what the term means. For example, I doubt you would try to convince me that Rubinius is production-ready. The version number is another dead giveaway -- while sub-1.0 software can certainly be high quality, especially in the open source world, I feel much better with a stable, finished version that calls itself stable and finished when it's something as fundamental to what I'm doing as a language.

Another is that Ruby 1.9 is a much, much simpler language than Perl 6

In what way? I mean, I would consider that to be a good thing, but it certainly seems to be somewhat complex, at least syntactically.

Yet another is that the implementors have, at times, considered themselves free not to support core Ruby features.

Well, yes and no. For a very long time, "core Ruby features" meant "exactly what MRI does". It's only fairly recently that there's actually a standard to compare against. We still find some implementations deliberately not supporting features from that standard, or being able to optionally turn some off -- for example, I believe JRuby can turn off the ability to redefine arithmetic operators on numeric primitives (so you can't define 2+2 to be 5), which allows for significant optimizations.

However, the fact that Rails runs on JRuby is a good sign. Not because Rails is necessarily the best choice, but it is a fairly large, complex, and reflective bit of code, so it's a good stress test. I know of no such test I could perform on Rakudo to compare it to any other Perl6 implementations.

there's almost no type system in Ruby, for example

...what?

Yes there is. Ruby is, in fact, strongly typed. It's just also dynamically typed, which means you don't usually see it, but it does leak out occasionally.

Re:The VM is decent. The language sucks.

[chromatic]

Out-of-date documentation is scary.

I don't consider that page documentation. Yes, it needs an update. No, it hasn't had one in a while. Many things should happen. Volunteers do what volunteers do.

The version number is another dead giveaway....

For every project you mention where the version number means something, I can find another where the version number means nothing. Wine, as just one example, had commercial support long before the release of Wine 1.0.

I know of no such test I could perform on Rakudo to compare it to any other [Perl 6] implementations.

The voluminous specification tests exist for exactly that purpose. There's also the standard grammar; a fully bootstrapped Perl 6 implementation supports a fair amount of Perl 6.

Ruby is, in fact, strongly typed.

I'd believe that if there were any sort of consensus about what the word "strong" means in the context of typing.

Re:The VM is decent. The language sucks.

[devent]

You don't want Java, you want a completely different language. So, why are you using Java in the first place?

You want a magical language, which combines the advantages of at least Erlang, Ruby and C++.

Btw, verbosity is sometimes a good thing, also backwards compatibility is in a industrial/enterprise used language like Java a must. See C or C++ for example, what it takes to add a new feature.

If you want/need dynamic typing (for example for rapid development) just use Ruby, Python, JavaScript, etc. With JRuby/Jython you can it with Java easily.

Java is in it's constrains a good, solid language. More, with the JVM you can implement all your favorite languages and create easy to use binding between them and the Java API.

Re:The VM is decent. The language sucks.

[SanityInAnarchy]

Yes, it needs an update. No, it hasn't had one in a while. Many things should happen. Volunteers do what volunteers do.

Which is exactly why I'd prefer something which is either run by professionals, or by volunteers who at least keep documentation -- or pages which appear to be documentation -- up to date.

Wine, as just one example, had commercial support long before the release of Wine 1.0.

And even at 1.0, I wouldn't ever assume Wine worked -- I would test it thoroughly for each app. I would tend to recommend against Wine and towards Windows in a virtual machine, for stability reasons.

I'd believe that if there were any sort of consensus about what the word "strong" means in the context of typing.

Strict might be a better word. In this case, it refers to the fact that an object absolutely is a given type, and cannot be coerced into another type by the interpreter. For example, in Ruby, the only false values are nil and false, everything else is true -- you don't have Perl's weirdness where an empty string or a 0 integer value might also be false.

On the other hand, operators are implemented as methods, and it's entirely up to the method implementation how it reacts to a given object. Thus, in practice, you can pretend types don't exist when you know what you're doing, but it usually won't let you do things like add a number to a string.

Re:The VM is decent. The language sucks.

[SanityInAnarchy]

You don't want Java, you want a completely different language. So, why are you using Java in the first place?

Because of the advantages of the JVM (as I mentioned), and because the courses I'm taking require Java.

You want a magical language, which combines the advantages of at least Erlang, Ruby and C++.

Actually, just Erlang and Ruby would be nice. And there are attempts.

Btw, verbosity is sometimes a good thing,

I'll be the first to agree with that. The problem is needless verbosity. For example:

Foo> x = new Foo>();

Even if you agree that templates are a good thing, why must I explicitly specify the type of x there?

also backwards compatibility is in a industrial/enterprise used language like Java a must.

Certainly, but at a certain point, I don't think it's worth it. There should've been an option to compile backwards-compatible bytecode (erasures), or non-backwards-compatible bytecode (proper generics).

If you want/need dynamic typing (for example for rapid development) just use Ruby, Python, JavaScript, etc. With JRuby/Jython you can it with Java easily.

That's more or less what I do, on my own time.

Java is in it's constrains a good, solid language.

The problem is what those constraints are actually good for -- why you would want to use Java instead of the alternatives. I could even make a case for using C++ over Java -- just as typesafe, you can add enough to be garbage-collected, but it at least has operator overloading.

More, with the JVM you can implement all your favorite languages and create easy to use binding between them and the Java API.

Which was my point overall -- I like the JVM, but there's a lot of room for improvement, and a lot of the oddities of the current JVM are related to Java, the language, which I hate with a burning passion.

Re:The VM is decent. The language sucks.

[pkphilip]

Other problems:

1. No support for returning more than one value from a function.
Example:
var1, var2 = doSomething()

2. No support for default values for function parameters:

Example:

public int doSomething(int var1, int var2, boolean var2=false, int var3=0) { ..
}

3. When running an app from a jar file, the classpath cannot be specified in the commandline.

Example: This won't work:
java -jar something.jar -classpath .....

Re:The VM is decent. The language sucks.

[xiong.chiamiov]

I find no appeal in dynamic typing. It just makes programs harder to read and debug. Have you tried Scala? With type inference, it manages to get the type-safety of static typing along with the reduced verbosity traditionally associated to dynamically typed languages.

If you merely use it as a way to avoid typing types, then yes, dynamic typing is fairly worthless.

IMO, dynamic typing is only useful in duck-typed languages, because then you have the flexibility to do all sorts of crazy shit that you can't otherwise, or even to just DRY things up a bit.

Android and Blackberry anyone?

[Envy Life]

Considering mobile applications are the hottest thing going and that Both Android and Blackberry use Java APIs, the author brushes over this fact by stating they are non-standard custom API's and JVMs... but what open source language/standards-based API has strict across-the-board standards? Apple? proprietary. Ruby? laughable. Python? no. .Net? proprietary...though good point about Mono being more popular than Java on Linux, a topic for another discussion.

That being said, I was disappointed Android has only a Java API... It would have been interesting if Google could have made Python the de facto API for Android, based on their support of the language, but probably felt Java was...well...better for the task at hand.

Re:Android and Blackberry anyone?

[backspaces]

Kinda interesting that Google limits themselves to 4 languages:
C/C++
Java
JavaScript
Python
http://steve-yegge.blogspot.com/2007/06/rhino-on-rails.html
"One of the (hundreds of) cool things about working for Google is that they let teams experiment, as long as it's done within certain broad and well-defined boundaries. One of the fences in this big playground is your choice of programming language. You have to play inside the fence defined by C++, Java, Python, and JavaScript."

And for GAE, JavaScript and Java/Rhino look great.

I think JavaScript is due for a huge burst of popularity as soon as folks "get it". JS on the server and on the client, and JSON for data/ajax. Brilliant. But it takes a lot to understand JS .. the Good Parts.

Re:Android and Blackberry anyone?

[moosesocks]

Don't forget go.

Although I imagine that we'll eventually see C/C++ disappear for user-facing applications, I'd place money on Go become the "de-facto" systems language at some point in the future, simply by virtue of the fact that nobody has pushed the envelope in this area in many years, and Google have some of the best minds in CS working on Go.

The "java everywhere" mentality also hasn't worked out all that well for some companies -- ask any poor soul who's been forced to develop for the Blackberry.

Re:Android and Blackberry anyone?

[shutdown -p now]

That being said, I was disappointed Android has only a Java API... It would have been interesting if Google could have made Python the de facto API for Android, based on their support of the language, but probably felt Java was...well...better for the task at hand.

It's not surprising at all. Android is meant for (relatively) resource-constrained devices, where performance is an important factor alongside portability. Python is still slower today than Java, even if the latter is interpreted (as it is in Dalvik) - it is a fundamental problem of any dynamically typed language. It can be partially solved by clever interpreters doing type inference and whatnot, but this kind of analysis is itself quite expensive.

Then, there's one other big thing that Android gets for free by using Java - tooling. Not just a basic code editor, but a proper IDE with working code completion and advanced code refactoring.

TFA misses the point about Java

[Anonymous Coward]

Java is described in TFA as a cutting edge language from the 90's having somewhat lost its edge since them. Java was never cutting edge. It's always been technology from the 70's - mostly a Smalltalk derivative. Java always has been about been about compromise between being more advanced than its mainstream predecessors (C, Delphi/Pascal...) and keeping accessible to the average programmer.

If anything, in the last 10 years Java has succeeded, turning from a questionable language for client-side applets to a stable and widely used environment for serious server-side apps. Unless Oracle are totally braindead they will keep it moving in the same direction, slowly moving forward and not confusing the average programmer with too much Haskell/Lisp/Perl-like complicated stuff.

If you have to struggle to keep it relevant...

[xdancergirlx]

maybe it's not worth the fight. Why not just use a language that IS relevant rather than "struggling" to make relevant people use one that isn't?

SmallTalk

[Anonymous Coward]

Java was brain-dead at birth. SmallTalk is the cleanest of object-oriented programming languages with a simple, clean syntax. A good programmer can develop an interpreter for a language using SmallTalk in a weekend. Try that in Java and your head will explode due to the inherent complexities of the language. Java, at best, is C with bytecode execution rather than native machine code.

Re:SmallTalk

[binarylarry]

Wow, you don't know anything about anything do you?

Java has been executing native machine code for well over a decade!

Are you some kind of unfrozen coder who was accidentally frozen in the mid 90's and was recently unthawed?

Re:Java the Pig

[M. Baranczak]

I'm gonna go out on a limb here, and say that he must be talking about JavaScript. Or just fucking with us.

Oh, now what the hell is this?

[Marrow]

Ok, so they want to get the love back and show that java is still relevant. Maybe they want some people to expand their skillsets and add java to their toolbox. Well I thought, lets see how heavy this thing has become. I found the necessary magic words to install it on ubuntu from apt. And then: SPLAT! Upon trying to install it, I get this very unfriendly looking licensing message during the install!

Sun is willing to let you install this under the condition that you accept the terms of this 15 PAGE! licensing agreement! In order to install, you must accept the terms, do you accept the DLJ license terms? YES or NO?

If you say NO, then the installation -crashes- and you get prompted again, in a loop asking you to accept the terms again! Ok, after 3 declines, it bails out completely.

You know what? I dont remember that kind of love when I installed PYTHON. Maybe this is what they mean by tough love.

Re:Oh, now what the hell is this?

[Vellmont]

Well I thought, lets see how heavy this thing has become. I found the necessary magic words to install it on ubuntu from apt. And then: SPLAT! Upon trying to install it, I get this very unfriendly looking licensing message during the install!

You've identified a problem that was largely solved when Sun opened up the Java licensing scheme about 3 1/2 years ago. If you want to avoid all the silly licensing that Sun makes you go through, just use the openJDK http://openjdk.java.net/. You likely tried to install the Sun JVM.

I haven't used it myself, so I can't say how mature it is.

Re:Oh, now what the hell is this?

[binarylarry]

Sun's JRE/JDK for 7+ is based on OpenJDK.

This is different from before where OpenJDK was based on Java 6.

Re:Oh, now what the hell is this?

[atomic777]

apt-get install openjdk-6-jdk

not

apt-get install sun-java6-jdk

Re:Drown already.

[cduffy]

Dunno -- the cutting-edge people I know are digging on Clojure pretty hard.

Yes, Java-the-language sucks hard. Yes, it took them waaay too long to get better bytecode-level support for languages that don't conform to their typing model (see JSR 292). Even with these things being true, there are some cutting-edge languages that target the Java platform, so I'm not about to call it dead to me yet.

(Other cutting-edge people I interact with are targeting things like OCaml -- but I'm maybe a little too pragmatic to go there just yet myself).

I know how *not* to make it more relevant

[hedrick]

What they had better NOT do: treat it like Solaris. You're only allowed to use it in production if you have support, and the only support they sell is a site license which costs $25 * the number of people in your company + the number of users for your application.

I'm not being entirely silly. I have an application for which I would have been willing to pay for Java support. But the only support Sun would sell us (late 2009, when they had already started Oraclizing) was an unreasonably expensive site-wide support contract.

Re:I know how *not* to make it more relevant

[cmdr_tofu]

What does "java support" for your application involves? You wrote the application in-house no? How can any third party support it? Do you turn the code and documentation to their services division and pay software developers to test and manage it for you?

Re:I know how *not* to make it more relevant

[hedrick]

Now and then we've had problems where good support could help. When we moved to Java 1.6 the JVM started crashing. It turned out to be a problem with a Solaris-specific library. At the time, Solaris support included Java, so they gave us a workaround. We also thought we had GC-related issues, where we could have used help. We'd be interested in trying G1, but there are still enough bugs that Sun advised not doing it without support. Hopefully the support people would know more about the status, and could advise whether it is safe.

However we're talking about maybe one service request per year. So the very high priced contract they quoted us didn't make any sense.

Google is mostly a C++ shop

[melted]

Contrary to popular belief, Google is mostly a C++ shop.

Re:Google is mostly a C++ shop

[binarylarry]

Actually, I hear the entire google search engine is written in TurboBASIC.

Re:Google is mostly a C++ shop

[cheekyboy]

Java uses 10x more ram, and probably in a true sense, 5x more cpu.

Now do you want your datacentre to be 500,000 square feet, or 100,000.

If the difference in cost is $20m in land, and $5/m anual power costs, then java can go out the window.

the cutting edge itself has moved on

[anomalous cohort]

It's no longer language constructs, data structures, or algorithms that are cutting edge. Innovation has moved on to more fertile pastures. Yes, those who build software tools, libraries, IDEs, and compilers will continue to innovate. They have and will continue to come up with some brilliant stuff. But cutting edge developers don't pick a shop because they write in groovy or whatever the language-de-jeur is. Cutting edge developers go where they believe the next killer app is going to be born.

The best developers are multi-lingual. They don't identify with a single programming language. They're not VB developers or Java developers or even Rails developers. They can pick up any language/library/environment quickly. They don't really get off on curly braces versus colons. What feeds the best developers is the challenge of world domination through innovation.

Change the world, right?

Re:the cutting edge itself has moved on

[Vellmont]

It's no longer language constructs, data structures, or algorithms that are cutting edge. Innovation has moved on to more fertile pastures. Yes, those who build software tools, libraries, IDEs, and compilers will continue to innovate.

Hmm.. language conststructs, data structures, or even algorithms are simply much harder to innovate in since they're so basic to software.. but I just don't agree there's no innovation happening in these areas. It just happens with less frequency because it's harder. The payoffs are likely of much higher impact though than anything of what you listed.

The rest of your post I think I agree with. The idea of the article seems to be something to to with trendiness or "cool". That's great and all, but I rather agree with your approach that it's about the interesting problems, not the technology.

Re:the cutting edge itself has moved on

[Tablizer]

Cutting edge developers go where they believe the next killer app is going to be born.

I can tell you what that is: a "GUI Browser" that can deliver desktop-like GUI behavior without the problems of buggy bloated version-sensitive AJAX and JavaScript libraries. HTML browsers were designed for eBrochures, not real GUI's, and have resisted successful retrofitting for real GUI's.

Base it on an XML GUI markup language. It will be the next Mosaic: build it open-source and they will come. Everybody wants it because they are tired of rocket science to get basic GUI elements to work together.
         

Re:the cutting edge itself has moved on

[bjourne]

Yes and no. It is the results that matters and producing cool, world-changing applications is much more important than what language you are using. But you can dig a ditch using a shovel or a digging machine. The ditch will be built regardless of what tool you use even if it takes you years to complete using the shovel method. Java is the shovel and "cutting-edge" languages such as Python, Ruby and even PHP are the digging machines.

I can produce results ten times as fast by using Django/Python/nginx than with J2EE/Java/Glassfish so it makes no sense for me to waste time on Java if I want to change the world. Non-programmers doesn't understand that, they think development work means staring at a screen and typing at a keyboard. Java programmers who are to stupid to experience more advanced technologies doesn't understand it either.

Re:the cutting edge itself has moved on

[jez9999]

whatever the language-de-jeur is

I believe you mean language-du-jour.

Re:the cutting edge itself has moved on

[arjan_t]

Java is the shovel and "cutting-edge" languages such as Python, Ruby and even PHP are the digging machines.

[...]

Java programmers who are to stupid to experience more advanced technologies doesn't understand it either.

Hold on there for a sec. PHP is an advanced technology? Really??? Crap like this http://lwn.net/Articles/379909/ is what 'advanced' technology is about?

PHP is basically JSP with plain Java SE on it, and a rather poor version of that approach that this. It's perfectly suited for Joe's Burgers 4 page website, but when something more 'advanced' is needed, PHP just doesn't cut it.

For instance, the platform offers zero provisions for any form of concurrency. There is not even something like the basic threading support that Java has had since 1.0, let alone that there is any support for simple asynchronous execution (e.g. the @Asynchronous annotation) or highly efficient parallel computing paradigms like a fork/join framework. And what about an O/R mapper that comes with Java by default? How about dependency injection? What about declarative transactions? What about transactions that automatically span multiple method calls and multiple transactional resources?

Does PHP offers anything like that? Does the standard PHP library already comes with an MVC framework? Is unicode already natively supported? Is there any name spacing support? Is there ...

I can produce results ten times as fast by using Django/Python/nginx than with J2EE/Java/Glassfish

And I can produce results a hundred times as fast by using Java EE/Java/JBoss AS than with Django/Python and surely PHP. I'm not sure what this proves though... Also, don't forget that hacking together stuff and throwing it out is nice when you're 16 and in high school, but in the real world maintainability, correctness, stability, scalability, etc etc all count and in the end are way more important than just the ability to get some prototype like code out of the door, that 'usually-works-but-breaks-down-every-tuesday-when-it-rains'.

Re:the cutting edge itself has moved on

[gbjbaanb]

It's perfectly suited for Joe's Burgers 4 page website, but when something more 'advanced' is needed, PHP just doesn't cut it.

At risk of defending PHP, it does cut it. That's the thing - look on sourceforge and you'll see hundreds of good PHP webapps. Now, sure, you'd never use it for anything else, but if you're writing a web application, then PHP is an excellent choice - very easy to install, easy to admin.

Its perhaps the midset that says you need something more complex and featured to do the tasks that are required that is Java's problem. Think about all the web apps you've ever seen. They're not that complex (except the crap one that are), all they need to do is manipulate data via a GUI (ie html page) and shove it into a DB. And vice-versa. Occasionally making some interpretation of that data. You do not need Java for that, especially when its so difficult to install glassfish/Tomcat/JREs/etc.

Don't knock those PHP apps, they're doing stuff right - despite being written in PHP! Look to them to see where your Java apps are going wrong.

Re:the cutting edge itself has moved on

[LizardKing]

I believe you mean language-du-jour.

No I think he was grasping for language-de-jerk - something like Ruby coupled with Ruby on Rails.

Re:the cutting edge itself has moved on

[six11]

I don't think anomolous was saying that innovation has stopped in the realm of language syntax and structure. There's a cyclic relationship between language and application design. New application areas or computational paradigms will feed back to basic language design.

For example, the mature languages of today were developed in an era based on single-core processors. We currently have multi-core processors that are a total bitch to optimize code for because our tools are based on an opposing paradigm. A post nearby by Tabilizer gives another example: GUI programming for web interaction is currently a pain in the ass, but a new language might just be the thing that serves as a killer app.

So, we might be in the part of the cycle where innovation is easier in the high-level application areas, but I promise there's still loads of compelling work to be done at lower levels as well.

Re:the cutting edge itself has moved on

[dodobh]

OTOH, the Polyglot developer with 2 years of LISP, two years of Java and two years of Ruby will do the same thing with far lesser code. Especially if Java is not the right language for the task.

Most Java developers tend not to know Design Patterns outside the Java context. Functional programming has it's own patterns, and those are very useful in the right context.

Re:the cutting edge itself has moved on

[arjan_t]

Its perhaps the midset that says you need something more complex and featured to do the tasks that are required that is Java's problem.

I'm sorry, but I think you're making the exact same mistake, but the other way around; thinking that because Joe's Burgers 4 web page website doesn't need transactions and asynchronicity, no application needs it. That's equally false. Quite a lot of (web) applications actually DO need that, and especially parallel and asynchronous execution is going to be a lot more important now that e.g. the top tier of commodity hardware can give you no less than 32 cores, while cheap entry level servers already feature 8 cores. In general you're not going to keep those cores busy just by means of letting each request go to a core. At some point you have to start dividing the work that needs to be done for each request. Java is ready for this, PHP hasn't even started with the absolute basics.

Think about all the web apps you've ever seen. They're not that complex (except the crap one that are), all they need to do is manipulate data via a GUI (ie html page) and shove it into a DB.

For starters, there is a LOT more server side software running in this world than just all those crappy CRUD-style websites. More importantly perhaps, you somehow equate 'advanced' stuff like transactions with complexity. But nothing could be further from the truth. Do you know what it takes in Java to make the methods of a class transactional? 1 annotation. You annotate the class with @Stateless, and its methods are transactional. Now you tell me, where is the complexity there?

Furthermore, even simple web apps that manipulate data via a GUI could easily benefit from transactions. If I operate a simple web app that lets my customer say order stuff, I won't really be happy if I have an order in my DB, but nobody to bill. Simple does not necessarily needs to be the same as simplistic. I can build a very simple CRUD style app, but still take advantage of parallel execution and transactions in my persistence methods. If a simple page needs to execute 3 distinct queries in order to get the data it needs to display, why not execute those queries in parallel? It's not the complexity you have to be afraid of, just apply the @Asynchronous annotation to a method and it will execute asynchronously, giving you a very simple yet super powerful way to exploit those cores in your machine.

especially when its so difficult to install glassfish/Tomcat/JREs/etc.

Excuse me??? Difficult to install Tomcat??? It's a freaking unzip of the archive you downloaded and it's fully operational. Same goes for Glassfish and JBoss AS. You download something, unzip it, and it's there. Or you use your package manager and execute a simple sudo apt-get install tomcat. If that's already difficult for you, you probably shouldn't be in programming really.

Don't knock those PHP apps, they're doing stuff right - despite being written in PHP! Look to them to see where your Java apps are going wrong.

My Java apps are not going wrong at all. They're humming along nicely thank you. Now have you ever tried to maintain a PHP app of any non trivial size? I mean, have you really had to? If you had, you'd known about the typical unreadable spaghetti mess that most PHP code so quickly deteriorates to. People may occasionally curse at Java's request life-cycle, backing beans and enterprise beans, but at least my view code, validators, converters, view logic and business logic are neatly in a default location. With PHP, the sky is the limit. It's basically an assembly kind of web language. There is no pre-defined structure, no guide lines, no nothing. Want to dump that critical business logic between the tr and td tag in your view code? PHP happily lets you and worse of all, your peers and the whole community even seem to push you in doing that, or at the very least turn a blind eye or just simply don't care.

If that's the kind of community you want to live in, have fun! But it's not my kind of fun.

Re:the cutting edge itself has moved on

[Scaba]

I'm not a particular fan or foe of PHP (it's a tool that can get a certain class of jobs done), but I should point a few things out...

PHP is basically JSP with plain Java SE on it, and a rather poor version of that approach that this. It's perfectly suited for Joe's Burgers 4 page website, but when something more 'advanced' is needed, PHP just doesn't cut it.

Agreed. If you have the second most popular website in the world serving over 400 billion dynamically generated page views per month from a backend of over 30,000 servers, you absolutely do not want to rely on PHP to serve those pages for you.

Does PHP offers anything like that? Does the standard PHP library already comes with an MVC framework? Is unicode already natively supported? Is there any name spacing support? Is there ..

Those aren't real problems unless they are actively preventing you from developing your website, which is probably only the case about 2% of the time. The other 98% of the time you never need consider them.

And I can produce results a hundred times as fast by using Java EE/Java/JBoss AS than with Django/Python and surely PHP. I'm not sure what this proves though... Also, don't forget that hacking together stuff and throwing it out is nice when you're 16 and in high school, but in the real world maintainability, correctness, stability, scalability, etc etc all count and in the end are way more important than just the ability to get some prototype like code out of the door, that 'usually-works-but-breaks-down-every-tuesday-when-it-rains'.

You sound like you did very well in school, and maybe even graduated at the top of you CS class. You also sound like you may have little real world experience. If you're in the bowels of some large corporate IT department where even your boss forgot you existed, you may have the time to plan everything, consider all of the potential problems, and do everything perfectly right the first time through, but it's more likely that either your boss or someone above him will see the cost of you spending six months planning something that will be perfect as way more expensive than just spending three weeks delivering something that is good enough. And this isn't even considering that you may have competition in the marketplace, competition that will put you under if you spend all your time planning while they are delivering actual products.

Re:the cutting edge itself has moved on

[arjan_t]

Agreed. If you have the second most popular website in the world serving over 400 billion dynamically generated page views per month from a backend of over 30,000 servers, you absolutely do not want to rely on PHP to serve those pages for you.

This is the same old argument over and over again. Facebook and a couple of other large sites building on PHP don't work the way they do because of PHP, but despite being build on PHP. There's a lot of engineering effort put into those sites, with a not unimportant share of that devoted to things having nothing to do with what PHP handles. With such engineering effort being poured in, Facebook could have been developed in assembly or COBOL, neither of which would have been prove that they are inherently suited for such environments.

Also, don't forget that Facebook is migrating to their C++ based hiphop toolchain and have build their own internal framework, a framework that resembles the Java EE stack in a couple of ways and is NOT available to the general public. The kind of PHP that Facebook does is NOT your typical 'phpfreakz' kind of PHP that is most commonly practiced.

I've also personally talked to the lead developer of Hyves -- the Dutch version of Facebook with some 12 million users -- and he said 'PHP is a little shit language' (PHP is een kut taaltje). I understand that out of context this may not mean much, but he did said that. Additionally, Hyves, Tweakers (a Dutch news site) and a couple of other companies I know that use PHP professionally, some of which I know people working there, almost all seem to agree on that it's very difficult to find really skilled PHP programmers. There is an abundance of programmers that are of the Joe's Burgers variety and have hacked on some PHP script, but that's a completely different category really and not at all what a professional organization is looking for.

So, even though a select few companies are using PHP very professionally, the norm in the PHP market is that it's used by people who barely know the difference between a while loop and an if statement, let alone that they know anything at all about data structures, algorithms, or efficiently structuring their code.

Does PHP offers anything like that? Does the standard PHP library already comes with an MVC framework? Is unicode already natively supported? Is there any name spacing support? Is there ..

Those aren't real problems unless they are actively preventing you from developing your website, which is probably only the case about 2% of the time. The other 98% of the time you never need consider them.

And that's precisely where it all goes wrong. We don't need no education anymore, we don't need no knowledge about CS theory, we don't need no transactions, we don't need no unicode, we don't need no MVC... PHP is so easy... a baby can now program any web site. .... Until it all comes falling down.

It's the typical Visual Basic kind of mindset. A mindset about which you can read everyday on thedailywtf. Sure, idiots can produce crap in any language, but for some reason both PHP and VB seem to produce a disproportionate amount of that.

You sound like you did very well in school, and maybe even graduated at the top of you CS class. You also sound like you may have little real world experience.

I did okay in school and CS went well too, thank you. I'm currently the lead developer of a 12 person strong development team I've worked with for about 7 years. We're building an enterprise application consisting of several 100k LOC and every day have to deal with an infuriating amo

Re:the cutting edge itself has moved on

[bjourne]

Java programmers who are to stupid to experience more advanced technologies doesn't understand it either. Hold on there for a sec. PHP is an advanced technology? Really??? Crap like this http://lwn.net/Articles/379909/ [lwn.net] is what 'advanced' technology is about? PHP is basically JSP with plain Java SE on it, and a rather poor version of that approach that this. It's perfectly suited for Joe's Burgers 4 page website, but when something more 'advanced' is needed, PHP just doesn't cut it.

Right, the "Java is needed for advanced stuff" argument. Fact: If your web application is "too advanced for PHP" you are doing it wrong and should simplify your design.

For instance, the platform offers zero provisions for any form of concurrency. There is not even something like the basic threading support that Java has had since 1.0, let alone that there is any support for simple asynchronous execution (e.g. the @Asynchronous annotation) or highly efficient parallel computing paradigms like a fork/join framework. And what about an O/R mapper that comes with Java by default? How about dependency injection? What about declarative transactions? What about transactions that automatically span multiple method calls and multiple transactional resources?

Who the fuck gives a shit? Any web app will be IO bound anyway. Dependency injection is a kludge you only need because Java is static and not dynamic. Transactions should be handled by the framework. In those JEE apps I've worked on, the transaction decorators always been misused by overzealous developers creating huge transactions slowing the application down to a crawl.

And I can produce results a hundred times as fast by using Java EE/Java/JBoss AS than with Django/Python and surely PHP. I'm not sure what this proves though...

It proves that you are one of those Java only developers too stupid to learn new languages. Sorry but it is true. Do yourself a favor and take a week to learn a dynamic language. You will thank me for the advice. You will also realize all talk about Java being "enterprise grade," more robust, scalable, yadda yadda is just bullshit.

Re:the cutting edge itself has moved on

[arjan_t]

Right, the "Java is needed for advanced stuff" argument. Fact: If your web application is "too advanced for PHP" you are doing it wrong and should simplify your design.

For the love of god, wake up man. Not every web application is Joe's Burgers. Not every web application is essentially a web site with some dynamics. Some web applications are simply enterprise applications where the front-end happens to be rendered via HTML accessible via a web browser. They do heavy computations, processing, reporting, run simulations and yes, they DO NEED concurrency, and yes they DO NEED transactions.

If a web application is "too advanced for PHP" then mark my words "it's too advanced for PHP". The model of fetching parameters from the request at the top of the page, feed them into an SQL query, and iterate over the result set while spitting out some HTML is fine for those 4 page web sites, and maybe even the 20 page ones, but it does not fit every possible application out there.

Are you the same kind of person who walks up to a civil engineer designing that bridge over a large river telling him al his or her schooling and techniques are wrong, and the design needs to be simplified, and that it all can be done in an afternoon instead of 3 years, since that 16 year old kid just threw an old shelf over a ditch and he had a bridge?

And I'm not sure how many times I have to explain this, but there is nothing complicated about USING some of this 'advanced' stuff. Yes, it's quite complicated to implement this under the hood, but guess what, the guys who bring us Java EE implementations have already figured out the hard stuff. I can simply use it, and with 'simply' I really mean 'simply.

But okay, Mr Einstein, let me play along a little. Tell me how 'simplifying' my design magically gives me transactional semantics for non trivial operations.

Any web app will be IO bound anyway.

Good one. Take an app, ANY app. Slap a web interface on top of it, and any part of the app that was CPU bound suddenly becomes IO bound. Really?

Dependency injection is a kludge you only need because Java is static and not dynamic.

Dependency injection is about separation of concerns mister, and has very little to nothing to do with typing.

Transactions should be handled by the framework

Which is precisely how it is done in Java, via the very stable and mature Java Transaction API, that one can either use programmatically or declaratively via enterprise bean. Your point again?

the transaction decorators always been misused by overzealous developers creating huge transactions slowing the application down to a crawl.

Maybe you're referring to some home grown 'transaction decorator' as may typically attempted to be made in PHP by programmers who have a basic understanding of stuff, yet overestimate their abilities and think they can just build transparent transactions themselves. I mean, what could possible go wrong, right? If you're referring to the default declarative transaction support in Java EE, then really this is rarely a problem. If you don't know your stuff and simply do too much work in a transactional method, then you're simply doing too much work. That would have been a problem regardless of using a transactional method or not. Like so many other things, it's a professional tool that's utterly simple to use, but you do have to know what you're doing. Just as you should not blindly make each and every method asynchronous or each and every method synchronized etc.

It proves that you are one of those Java only developers too stupid to learn new languages.

I think it actually proves you are someone who jumps a little too fast to a conclusion. For the record, I started programming when I was 6 in C64 BASIC, quickly moved on to assembly, then C on an Amiga and later Apple, C++ on an SGI

Re:the cutting edge itself has moved on

[cervo]

The best developers have their preferences... While they can pick up any programming language tool, some are definitely more fun than others. If given a choice, you're not going to want to do COBOL unless there is a HUGE pay increase for it... VB 6 as well is a pain in the butt to work with....

In my career I cannot escape from VB 6 completely because of VBA (and Excel Macros....). But I would never accept a position as a full time VB 6 programmer because it is such a pain in the butt to work with. Even if the next cutting edge application was going to be VB 6, I'd pass....

There are some features that everyone likes (namespaces, first class functions, garbage collection, etc..) and whether you pick C#, VB.NET, or Java (to a point) there isn't that much difference in capabilities. But if you pick C, then you're going to be working 3 or 4 times as hard to do the same stuff. If given a choice of building a business app in Java or C, 10 out of 10 times I would pick Java. I love C as a language, but for doing a business app with a fixed deadline, it is better to use Java and get it done sooner and to have more time for testing/debugging.

Still if there was a startup building the next cutting edge app in C, I'd question that. I would think at a start up building the next big thing, the most important thing is to get the app to market ASAP....and for that you want a language with as many built in libraries as possible. There are a lot of libraries for C, but not built into the language so you have to evaluate them and make sure they play nice together and that takes time. Meanwhile Java has a huge standard library. Need to zip a file, no problem. Need a GUI, no problem.... And for windows, I might question Java over .NET for a consumer application since .NET seems to run much faster for windows and be able to more easily interface with COM objects.

Anyway my point is that sure you can pick up any imperative language once you know how to program one. Functional languages may require more study. And most developers can build the next big thing in any Turing complete language. But all languages are not equal.... Some are easier to use than others. And some developers if given multiple positions will look at language choice. And some will also turn down the next big thing due to the language. No one wants to use an antiquated language that no one has heard of. I once interviewed at a brokerage using their own custom programming language fresh out of school. I didn't get the job, but later when another one opened up and they considered me, I told them I wasn't interested. Basically if your only job is working on some custom language, it's going to make it hard to find another job because HR likes to hire you for a job doing the same thing you did in your last job, or at least some of the same things... And in companies where you are paid on how to get the software out, if someone insists you write windows entirely in assembly in a year, run hard... In fact if they insist on anything written in assembly that is not relatively simple run...... There is some common sense here. While sure Java/C#/VB.NET are not that different and maybe there it doesn't matter so much. The difference between C and these other languages, assembly, etc. does matter. C++ is somewhere in between. With the Boost and the STL it can be very similar to Java. Or if you write it c-like it can be similar to C. And of course LISP/Scheme/Haskell/ML/F# are all another can of worms. The lower level languages are harder to write/debug and will require more time. The higher level languages are easier to write/debug and will require less time, but for a performance sensitive app, may result in a failure. You usually won't want to work on the next big thing in fail because then you will be back to looking for a job. It is better to work on the next big thing and succeed and cash out big....

Re:the cutting edge itself has moved on

[Tablizer]

XUL didn't seem to work out how client and server communicate. It was an awkward standard in many ways.

Completely new features out of the blue take a lot of effort to get into browsers.

Well, it might take starting over to finally get it right. That's why I'm proposing a new GUI-centric browser. Tacking stuff onto the eBrochure model of current browsers has been unspectacular.
 

Re:the cutting edge itself has moved on

[orngjce223]

Firefox. XUL. Remind me why this doesn't work, again?

Re:Here's how to make Java again

[travisb828]

To get buy in from the geezers, you should get in the habit of formatting your code. It makes things easier to read, and it just looks more professional. CamelCase also is helpful in improving readability, and to enforce proper code formatting you should make formatting part of the syntax.

Doesn't this look so much nicer? I almost forgot. You will need a declaration.

<?saufml version="1.0" encoding="UTF-8" ?>
<Class>
        <ClassName>MyPony</ClassName>
        <Method name="Run">
                <Code>
                        <If>
                                <Condition>IsExcited</Condition>
                                <If_Block>walkFaster </If_Block>
                        </If>
                </Code>
        </Method>
        <Method name="trot" />
        <Method name="gallop" />
</Class>

Who cares?

[Foredecker]

This question is ask as if Java is somehow imporant in and of itself. It isnt. Neither is perl, or PHP, Phython or gasp - C++ or even C. Throw C#, F# and VB into that group as well.

These are tools. We (as in devleopers) should simply use the right tool for the job. If thats Java - then okey-dokey. If its C#, then groovy, if its C++ then thats ok to. Hey, I still use assembly language for a few things.

Do real engineering work folks! Pick the right tools for the job based on the business and technical requirements.

-Foredecker

Re:Who cares?

[shaka]

If thats Java - then okey-dokey.
If its C#, then groovy, if its C++ then thats ok to.

This doesn't make sense. If Java is the right tool, then I should use "okey-dokey", if C# is the right tool, I should use Groovy, and if C++ is the right tool (is it ever, though?) then it would be ok to use Thats?

Oracle is cool.

[tjstork]

People that dismiss Oracle's database software are foolish. The transaction management, up time, and all the other robustness features of an Oracle database server gave me plenty of time to go look for hot girls when I was single. Meanwhile, those SQL Server guys hung in the lab.

Re:Here's how to make Java again

[shaitand]

I was with you up to the camel casing. Camel case is a fad I could have done without, not only is walkFaster less clear than walk_faster, it is also more error prone to type.

What the... FUDFUDFUD

[Hurricane78]

As far as I know, pretty much every “enterprise” server software still in written in Java, and hence the developer base is gigantic. I mean just look at the job offers. 9 out of 10 say Java, the last time I looked.

What is he talking about?? Does he even know anything about what he is supposed to manage?

Re:Drown already.

[Internalist]

(Other cutting-edge people I interact with are targeting things like OCaml -- but I'm maybe a little too pragmatic to go there just yet myself).

Some people with very practical interests do rather well with OCaml.

Punks don't care about type inference

[powerpopolon]

I for one would like geeks to be like the lab girl in NCIS but in fact they are not. Most "punks" in IT are just doing their programmer job to get some money at the end of the month. They do not care about advanced computer language theory.

Anyway if you're one of the few geeks with piercings and really want your language to be "cutting edge" as TFA puts it, Scala, Clojure, Groovy, SISC, you name it, are available in the Java ecosystem. I'm sure you can even find some Forth dialect if you look hard.

As for most people with piercings they'll be glad to use a language that is neither too cumbersome like C or Cobol or Pascal or VB, neither too hard to understand or organize like ML or Perl or Scheme. Java is nice for them and will stay so even now Oracle has bought Sun.

Re:Java the Pig

[binarylarry]

Applets used to be bad but last year it was rewritten and it's pretty fantastic now.

https://jdk6.dev.java.net/plugin2/

Lemmings

[Animats]

I was just by the Apple Store in Palo Alto, CA. There are people lined up for the iPad launch, some sleeping in tents. Three TV stations are covering the waiting line. Reminds me of Apple's "Lemmings' video.

Actually, the state of the art in programming languages still sucks. The mindset that "it has to be unsafe to go fast" is so deeply entrenched in the C/C++ community that fixable problems aren't fixed, and as a result, millions of programs still crash every day. The "virtual machine" thing has resulted in ".NET", a virtual machine for x86 only. The "scripting language" approach is useful, but fanatical late-binding coupled with naive interpreters makes for very slow execution, as with Python. Few mainstream languages do concurrency well; the notion that concurrency is the operating system's problem results in pain for all concerned.

Looked at that way, Java isn't bad. Memory safety is good. There are efficient compilers. There's some language support for concurrency. It's not too weird, and not too theoretical. Java is mediocre, but better than most of the alternatives when you need to get large amounts of work done.

Re:Lemmings

[shutdown -p now]

The "virtual machine" thing has resulted in ".NET", a virtual machine for x86 only.

.NET exists in many varieties. Desktop one runs on x86, x64 and IA64 (Itanium). Then there's .NET CE which runs on x86 and ARM. Then there's whatever thingy is used to run XNA games in XBox 360 - that has to deal with PPC. Most of those are, to some extent, built from the same codebase. Then there's Mono , which supports all of the above platforms, and then some.

And the CLR spec itself is not tied to any particular architecture - not anymore so than JVM - which is makes it all possible.

Re:Lemmings

[croftj]

I can crash my Java programs just as quick as my C++ programs! Just one exception in the right place makes the program quit running without apparent reason. Safe my ASS! Hidden garbage collection does not make a program safe! That is all Java offers for safety. I can still get Null Pointer Exceptions (pretty slick for a language with NO POINTERS). I can still run out of memory in any number of ways, especially when dealing with activemq and hibernate and not cleaning up.

So in the end, Java or C++ you have to actually think BEFORE and WHILE you code or you end up with a big stinking pile of crap you call a program. What C++ has over Java is only about a 5th of the typing to see if two objects are equal. Java has things over C++ but those can be worked around (just like so many thinks have been worked around Java to overcome it's short comings).

You put is best when you said Java is mediocre. Which confirms my 3rd rule of life: Mass mediocracy breeds mass popularity, or vice versa.

Re:Lemmings

[dkf]

Few mainstream languages do concurrency well; the notion that concurrency is the operating system's problem results in pain for all concerned.

There are two fundamental problems there:

1. There are (at least) two fundamentally different models of concurrent programming: shared memory, and message passing. You can't really mix and match between the two in the same program because they manage memory accesses in totally different ways.
2. Most programmers don't grok concurrent programming at all, even at the level of several processes talking to each other. There's a need for much better training here; at the very least, concurrency principles and techniques ought to be a mandatory part of every CS programme in the world.

The operating system can share out execution time easily enough, but doing the right thing with it requires thought and planning; throwing code at the wall to see what sticks doesn't really cut it.

Re:Lemmings

[Blakey Rat]

The "virtual machine" thing has resulted in ".NET", a virtual machine for x86 only.

Nah, it can run on mobile processors as well, my Zune has no issue running .net apps. And apparently it has no trouble with PPC, as evidenced by the Xbox 360. Hell, it even runs on fucking IA64, for what that's worth.

I think your imagination is a little limited here. The world is much bigger than desktop PCs.

Re:Lemmings

[cmburns69]

When the GP talks about safety, he doesn't mean a bug-free program (which is what a NPE in java is). What he means is that you cannot accidentally corrupt your memory (or hack the system) by accessing arbitrary memory.

It's also true that you can run out of memory with java. Simply create a collection, and add objects to it until the system is out of memory. There is not a language on earth that can deal with that-- How could it possibly know which ones you wanted to keep and which ones you wanted to throw away? Yes, you have to think about memory management, but you don't have to worry about it to the extent required in the C languages.

Personally, I really like Null Pointer Exceptions. They tell me exactly what and where my bug was-- unlike the behavior that can happen with one of the C languages. Because the java GC won't free an object unless nothing points to it, you cannot access a deleted object and consequently don't have to worry about the security implications of dangling pointers. In some ways, they traded one class of problems (pointer insecurity) for another (memory usage).

There are other good languages available, and java is not the best at everything. But because of its strong security features, strict typing, huge library of existing code, and simple yet cohesive syntax (there's generally only 1 way to do a specific task which makes it really easy to read somebody else's code) I believe it's one of the best general languages for business applications.

Re:Lemmings

[croftj]

and simple yet cohesive syntax (there's generally only 1 way to do a specific task which makes it really easy to read somebody else's code)

Bwaaaa haaaa haaaaa!!! That's a new one I haven't heard yet. I've seen code books and example code on line which is totally indecipherable! Literally as bad as the purposely obfuscated C programs you can find on line.

I can add this to the rules I have learned about Java.

1) Everything is an object except those things that aren't such as ints and chars and floats.

2) Java has no pointers, everything is a pointer, except those things that aren't (see 1).

Null pointer exceptions are great. They prove rule #2 that Java has does in fact have pointers (yes, I'm old enough that this was one of the biggest pluses to sell Java, it doesn't have pointers like that nastier C language. They would be much better (as would most run time exceptions) if they didn't just kill the thread they occurred in, but the whole damned program like they do in C/C++.

Java would is an okay language. It makes you type type type. It would be nice if just had a few tweaks. Sadly, the tweaks are tweaks that will never occur because the 'keepers' think they are evil, or they would break compatibility.

-joe

Re:Lemmings

[cmburns69]

there's generally only 1 way to do a specific task which makes it really easy to read somebody else's code

You can certainly write obfuscated code in any language. Simply name your variables poorly and you're done!

But what I mean is that you can generally tell what the JVM will do with any piece of code, even if you don't know what the programmer is attempting. This is definitely not true of C++. Because of operator overloading, even the simplest looking code could compile in unexpected ways. For example, "a == b" looks like a simple comparison. But it might invoke the overloaded comparison operator if it has been defined. Or worse, the compiler might decide that the only way to make the comparison work is to do all sorts of type-conversion on the sides until it can find one that works. It certainly allows it to compile, but it probably won't do the operation the way you expected.

If you see "a->b" do you know that the dereference operator won't initiate some long running algorithm (maybe a computationally heavy database lookup of "a" in some remote location)? I think we both agree that doing anything like that would be bad form. But you cannot know that's not happening simply by looking at the source.

To address your bullet points, java has a few simple rules:

1) If the type name starts with a capital (Object, Integer, etc), it's an object. You can only get a pointer to it. It is always passed by reference.

2) If the type name starts with a lower-case (int, float, char) it's a primitive. You cannot get a pointer to it. It is always passed by value.

Regarding null pointer exceptions, as with dereferencing NULL memory in C family languages, they usually indicate a bug or design flaw: either an uninitialized value or the unchecked result of a map lookup. However, if you cannot fix the design, you can catch them like any other exception and let your thread continue where it left off. This is different from C family languages where those sorts of bugs give you either a crash, or unknowing access to rotten memory. At least with the NPE you get a stack trace and can find it!

Java is very verbose. However, the pain from that can be mitigated significantly by using an IDE that types most of it for you like eclipse

Re:Lemmings

[cmburns69]

Bad form to reply to my own post and all that, but I re-read the GP and noticed that I failed at reading comprehension regarding null pointer exceptions.

I noticed the GP said he would prefer if the whole program would crash on an NPE like C/++ - I think it would be useful to be able to tell the JVM to completely die on certain (arbitrary/user-selectable) classes of exceptions. So I guess we both agree about that. However, I still prefer the java model of throwing an exception rather than allowing access to arbitrary memory.

Re:Drown already.

[Abcd1234]

Dunno -- the cutting-edge people I know are digging on Clojure pretty hard.

Any particular reason why? What does it offer over the gajillion other Lisps out there, aside from running on the JVM?

As an aside, if I'm gonna work with a functional language, I prefer it be Haskell. 'course, it doesn't currently target the JVM or CLR, though maybe some day...

Young developers

[sjames]

Java attracted the young developers because more experienced ones had already watched the "new next thing" come and go too many times to be blinded by the hype. Many of them realized that the whole bytecode, write once run anywhere was done in 1969 (p-code) and that if those hyping Java didn't know that, they didn't have enough experience to know if it was good or not. If they did know that then they were liars. Of course, the p-code interpreter fit on a single sided floppy with room to spare and ran acceptably on a 6502....

It is amazing to me the way the hype machine strapped JATOs on that pig and sorta made it fly, but that can only last so long.

Now with Java in the clutches of the enterprise people who are the leading source of anti-cool, it doesn't stand a chance.

Re:Young developers

[owlstead]

OK, that's it, I'm dropping Slashdot. If this is the level of +5 articles then I'm fuckin' off.

Re:Young developers

[dkf]

Now with Java in the clutches of the enterprise people who are the leading source of anti-cool, it doesn't stand a chance.

At least it's gradually edging out all that fossilized COBOL.

Re:Young developers

[MemoryDragon]

Java got off because of several reasons, system became so complex and distributed that C++ simply was a sure tool to make such a project fail, and java was very simple back then but could pull off things which C++ was not able to in a decent matter of time only with a few locs.

The other issue was Smalltalk, ParcPlace single handedly killed with a stupid business move the entire Smalltalk market, they bought the most popular Smalltalk vendor on the PC side, Digitalk promised to unify their apis and the Digitalk ones and what happened was that they killed digitalk never fullfilled their promise, it did not help either that Digitalk was the cheap kid on the block why ParcPlaces Smalltalk did cost a fortune. Add to that some infighting at ParcPlace which drove important people away and a load of Smalltalk programming companies gotten burned and you had the perfect fiasco, which even IBM with their Smalltalk could not fix anymore.

Java was just heavens sent for those companies, while not as powerful as Smalltalk and in its infancy, it was the perfect next choice.
Funny thing is, that Smalltalk already had most things in place which languages like Ruby etc... try now to achieve, but in my opinion in a leaner and more thought out manner.

Re:Here's how to make Java again

[Nerdfest]

Others are starting to do this as well. It probably won't go any where until we move the standard place where the underscore is on the keyboard.

Help keep C relevant in the modern era!

[symbolset]

Why is noone asking to examine the C programming language, to adapt it to modern programming processes and methods? Why is noone speaking out to defend C as a useful language, to update the aged methods of Kernighan and Ritchie?

Oh, wait. Never mind. That was a stupid question.

Re:Help keep C relevant in the modern era!

[istartedi]

Why is noone speaking out to defend C

A rhetorical question, but I'll bite: Because the implementations for all the other "cool" new languages already speak on C's behalf. Although, there are things like PyPy now; but it's not exactly mainstream, is it?

Re:Help keep C relevant in the modern era!

[Thundersnatch]

Why is noone asking to examine the C programming language, to adapt it to modern programming processes and methods?

They have, and it's called the D Programming Language. And it sucks.

Re:Groovy + other languages

[crowne]

I would say that the future popularity of the JVM is pretty secure with groovy, jruby, scala and the myriad of other languages that are now available on the JVM, see wikipedia List_of_JVM_languages.

There is a huge advantage to java programmers by staying within the familiar JVM world when changing a language rather than jumping to a completely new and foreign environment - familiar stacktraces, reusable libraries etc.

The "primary" language on the JVM - java will inevitably evolve slower (JCP = design by committee) and will therefore struggle to remain at the cutting edge.

Java isn't pure OO

[elgee]

I went from Smalltalk to Java in 1996 and didn't like its implementation. In Smalltalk, EVERYTHING inherited from TOFU (Top OF Universe). Not so in Java. Haven't done it for some years, but I thought it wasn't very elegant.

Re:Java isn't pure OO

[WeirdJohn]

The thing I hated most about Java is that I can't just create a new class and implement a few messages and use it in existing code, unless I somehow shoehorn it into an existing class hierarchy, or implement an interface. If the existing code was done without interfaces in mind, I have to edit a few hundred methods in dozens (if lucky) of files, and not break anything.

To avoid this I have to over-engineer prototype code, and increase production cost estimates by at least a factor of 4, or else use a generating framework that leaves me with no idea what any of the generated code does, which makes fixing subtle bugs so much fun.

At least smalltalk works. And the smalltalk debugger is possibly the most elegant and efficient ever.

Re:Java isn't pure OO

[mwvdlee]

Personal pet peeves for Java:

1. int/float are not treated as classes. Okay, only a minor peeve.

2. Classes wrapping the basic datatypes and string are finalized. This one is a major peeve.

3. Operator overloading is not allowed and the designers of Java clearly stated it never will because operator overloading is just pure evil and no sane programmer should ever, ever want to do operator overloading, for no reason whatsoever. The standard String class uses operator overloading.

4. The library is an inconsistant mess. Not quite upto PHP levels of messiness, but a mess nonetheless.

Any others?

Re:Java isn't pure OO

[MemoryDragon]

Sure you can, thats what AOP is for (see what AspectJ, Spring and JEE5+6 provide in this manner)

It is especially easy in JEE5 with the @Interceptor annotation!
Spring and AspectJ are more complicated in this matter, but mostly because they expose the core of things instead of going for the easy usecase!

The same is true of Cobol

[Rix]

The enterprise sector is spectacular at painting itself into corners. Java isn't the first instance of that, and it certainly won't be the last. So yeah, Java isn't going anywhere as far as enterprise is concerned. But neither is Cobol or Fortran or many other moribund technologies.

The rest of us can sensibly let all of that die.

As for inconsistencies, how many mutually incompatible versions of Java are there? How many revamps compared to languages stewarded by standardization bodies or other neutral actors? (C has, what, 3 over it's 40 years of history?)

I'd say that the best thing Oracle could do for Java would be to give it to ISO, but I think it's 10 years too late. I'd love to be surprised, though.

Re:The same is true of Cobol

[Prof.Phreak]

The enterprise sector is spectacular at painting itself into corners.

What are some of the alternatives? Is .Net not worse of a corner? And at ``enterprise'' level, pretty much everything turns to crap anyway, and as far as crap is concerned, Java is usually easier to deal with than say... poorly written Perl (I'm a big Perl fan, but I've seen the code written at a fortune500 corp, and... well... it's unmaintainable crap written by a cobol programmer).

Would C/C++ be a better alternative for internal apps? Unlikely!

Would Python? Perl? PHP? I doubt it. Primarily 'cause nobody who writes such enterprise apps would really know what they're doing (consider folks who've worked at a corp for last 15 years).

Yeah, everything most enterprises need should be web-based anyways---but the guts behind that would still be... what? VB.NET? Heh!

Obviously there are different definitions of ``enterprise.'' But if YOU had to pick a language for some internal app with a dozen or so existing developers (all of whom know Java, some of whom know other languages), which language would you pick? [throw in assumption that you need to run it on a unix-like platform]

Re:The same is true of Cobol

[peppepz]

As for inconsistencies, how many mutually incompatible versions of Java are there?

Isn't extreme backward compatibility the reason Java gets most often bashed for? For what I know, any 1.1 source code should compile fine under java 1.7 (unless you used something like "assert" as a symbol name, but even then you should get away by using the -source switch for the compiler).

How many revamps compared to languages stewarded by standardization bodies or other neutral actors? (C has, what, 3 over it's 40 years of history?)

I'd say that the best thing Oracle could do for Java would be to give it to ISO, but I think it's 10 years too late. I'd love to be surprised, though.

To be honest, every single C compiler out there defines its own incompatible implementation of C. That's because the standards move so slowly that every manufacturer tends to put its own custom features in his compiler. I don't recall this happening with Java, only MS tried to do that with J++ IIRC, but Apache Harmony, the Eclipse compiler, OpenJDK, GNU Classpath and Sun's JDK all implement the very same language if I'm not wrong.

That said, I'm favorable to an independent standardization of Java, but I don't think it will solve any problem of Java.

Re:The same is true of Cobol

[gbjbaanb]

Yeah, everything most enterprises need should be web-based anyways---but the guts behind that would still be... what? VB.NET? Heh!

today... hmm... oh, yes I know!!!

Cloud-based web-services of course. I read about it on a management consultant report, so it must be true.

C/C++ most likely would be a better choice - less fluffing about with language toys means more real work getting done, especially when that means you can ignore the current latest buzzword b*ll*cks the other languages are pandering to with bloated, poorly-implemented and designed frameworks that are there so your job can be outsourced to India. ...

To be honest, if you want a better language choice for internal apps, I would recommend PHP over Java. Yep, you hear that right. See - I've used these Enterprise apps written in Java and they are by and large complete pants. I also use some OSS PHP apps to solve my specific needs, and by and large, they're wonderful. So, either the language is at fault or the development process.

For example, I use Siebel at work (Oracle Java Enterprise $1000 per-seat cr*p) and I also use Mantis (OSS PHP $0 per seat). Mantis kicks the arse of Siebel, some teams refused to use Siebel once they got Mantis (cue management battle).

So, really, you can use these huge, bloated, expensive piles of nonsense. Or you can use a smaller more targetted application. Even written in PHP its simple to maintain and manage, and simple to write in the first place. I'd say you can write these little apps in Java, but I don't think its quite designed for that - better to go with a simpler language from the start (and no, it doesn't *have* to be PHP).

Re:The same is true of Cobol

[Alomex]

As for inconsistencies, how many mutually incompatible versions of Java are there? How many revamps compared to languages stewarded by standardization bodies or other neutral actors? (C has, what, 3 over it's 40 years of history?)

This is one of the biggest drawbacks of old languages. Because they are updated so rarely, even the biggest, dumbest mistakes that every one acknowledges are there live for 10-15 years before they get fixed. My pet peeve in C is that sqrt(2) would silently return garbage in pre-ANSI versions of C.

Re:The same is true of Cobol

[SpinyNorman]

To be honest, every single C compiler out there defines its own incompatible implementation of C.

No they don't. They may implement extensions which you are free to use or ignore, but that's a different matter.

If you read the C language specification there are some things that are defined as being implementation defined (e.g. order of function argument evaluation), but if your program relies on such things it's your own fault.

Re:The same is true of Cobol

[icebraining]

Have you looked at PHPBB's source code? Yeah, I use it for a personal forum with 20 people, but I wouldn't touch it with a ten-foot pole for any kind of real website. It's messy, to say the least.

Besides, saying C/C++ is better because it has less toys and then talking about PHP, well, that doesn't seem very coherent. PHP web frameworks are where all the flair is at nowadays in the community.

Re:The same is true of Cobol

[TheTurtlesMoves]

C has, what, 3 over it's 40 years of history?

And yet there is still a sizable code base in this "standard" C that won't compile for a 64bit CPU. And not just any 64bit CPU, but one thats so bloody close to the 32bit version that it supports both modes/instruction/register whatever.

Re:The same is true of Cobol

[Cruxus]

I agree. Where I work, we're a JDK 1.4.2_08 shop, and it just feels like a modern-day COBOL. There's been anticipation off and on about moving towards version 1.5.x of the JDK, but it keeps getting pushed back.

Re:The same is true of Cobol

[gbjbaanb]

no, never looked at PHPBB, or PHPNuke, but that doesn't mean Bugzilla, Mantis, dotProject, MediaWiki, etc are not nearly as bad.

Have you looked at some dreadful Java code? I can't claim PHP makes for worse code than Java, I prefer to go by coder ability rather than any inherent language flaws.

Can we mark the post as troll?

[drolli]

It seems to be a modern version of COBOL? What is that supposed to mean? I believe this is right and the main conclusion is that will be around for the next 50-70 Years. Cobol is approaching its 50th Birthday and i don't think all the systems which caused the spike in demand of cobol programmers in the year 2000 will be turned off immediately (as a matter of fact i believe many of them will run happily for 20 more years). The fact that the biggest database company now owns one java implementation and that IBM another makes me feel this comparison may be indeed more true. However it means that there will be a lot of stable work going on, also because the java-compatible mobile devices, which outnumber the iphone seriously. Right now i dont see any competitor (including .net) having gained such momentum for a long-term development. I dont care if the application maintaining my data at the insurance comanies is written by a programmer with a piercing in his nose or not.

Re:Can we mark the post as troll?

[Midnight Thunder]

I should add that there are other implementations of Java available:
    - JRockit
    - Apache's, though I forget the name

what would be handy is if the JVM's bytecode was standarised, by submitting it to ISO. I would be interested to see who is making the best JVM out there.

For anyone mentioning Smalltalk, I believe the biggest nail in that coffin was incompatible VMs and the lack of types.

The Future of Programming must have Tatoos

[CranberryKing]

WTF is this supposed to mean? The new COBOL? We need a hip new language that appeals to the bohemian hacker (flash/designer). Please.

Which way is the wind blowing today?

[Informis]

On January 28, 2010, Neil Mcallister published this article: http://infoworld.com/d/developer-world/oracles-big-bear-hug-java-bodes-really-well-021 He concludes the article by saying: "But at the very least, [Java developers] can rest a whole lot easier." Someone can't make up his mind about Java. The rest of us have, and know that -- while not perfect -- Java is an extremely powerful tool that ain't going anywhere.

improve the JVM bytecode

[basiles]

I believe what would be significant is to improve the JVM bytecode, to add some additional instructions. Tail-recursive calls is an example. There are some others. If the JVM specification was improved (and implemented by Oracle & other major JVM sources), several new languages (or language feature) could flourish. And the important part is not the Java language; it is the JVM. Better languages (Clojure, Scala) can be implemented for the JVM, and if the JVM was improved, even better languages could be experimented, all able to use the legacy of Java. Regards.

Re:improve the JVM bytecode

[binarylarry]

oooh and while we're at it, lets add addressing modes! yeah!

Re:improve the JVM bytecode

[basiles]

I was serious. Tail recursive call is one of the major feature lacking in the JVM. See http://blogs.sun.com/jrose/entry/tail_calls_in_the_vm http://openjdk.java.net/projects/mlvm/ And there is no way to implemnent tail-recursive call in its full generality (including tail-call optimisation to statically unknown code, e.g. thru virtual methods...) without a proper support from the JVM. This has nothing to do with addressing modes (which you don't need in a VM offering garbage collected values). And the Ocaml virtual machine bytecode does indeed show that other kind of bytecodes can be useful. JVM is not the perfect VM; it could and should be improved.

Re:improve the JVM bytecode

[binarylarry]

I was joking but you're right, the JVM can be improved in many ways. :)

Re:improve the JVM bytecode

[MemoryDragon]

Actually I personally think the bytecode level is in need for a serious overhaul, while it is not bad, it has served us well with gradual improvements it has some weak points.
One is being addressed with J7, invokedynamic.
But its weakest point still is a missing real class hotplugging system, they wanted to tackle it for J7 but could not because of hotspot.
In the meanwhile we have to live with workarounds, like dynamic class recompilation in the runtime which introduces unwanted proxies, workarounds on classloader level by introducing throw away classloaders, various framework hooks etc...
Just to get something out of the box which is needed by every developer!

What do you mean "Keep"?

[WheelDweller]

Java was always a bloated, misconfigured mess from the start. The idea to unify on a single machine language is old and proven: you do this kinda think in _hardware_ not software. Don't think so? Take a Linux box with Sun's own Java on a stroll of Bongo, Facebook, and other all-game sites and see what kind of "compatability" you have.

Oh, sure, when people like COMPAQ think they're gonna revitalize their market holdings by merely putting TORX heads on the exact same case screws, it's hard to debate with them. Often times CEOs are dorks; people relent because they have money, and things stop from getting done. But if we want computers that interface, we NEED THIS AT THE CHIP LEVEL.

There seem to be several camps creating several environments in which Java(TM) code can be run. But which version? Can we manage to keep the RAM bill under 1G this time? NO? Ok.

I've been arguing the usefulness of a 'common language' of microprocessors since about 1978. For a while they DID manage a completely solid translation of CP/M (8080/8085/Z-80) on early 8088's. Completely different architecture, worked perfectly. No multiple versions, no need to 'convince people' that it was still relevant. No apologies: that's the way it is when you emulate a given processor in hardware.

If anyone *ever* wants this to work in a rational, grow-old-with-it technology that doesn't fail, there needs to be a small number of CPU instructions which are agreed-upon by chip makers. In a worlds of perhaps hundreds-of-thousands of instructions, what's a couple hundred more if it means complete software freedom?

Yeah, I know- I'm old; I used to be a sysadmin prodigy, but I got sidetracked with caregiving. But I'm tellin' ya: this is the way to unify, if only someone has the balls to ACTUALLY MAKE IT HAPPEN.

We've done hundreds of things harder- why can't we just agree on something?

There's plenty of room making these instructions faster than the other guy. There's plenty of room making multiple co-processors for this work. Why can't we just get it done already?

Re:What do you mean "Keep"?

[sgt101]

It's all about Balls - risk taking, competition, innovation.

The computer is a new and novel device. It is probably more important than the wheel, perhaps less important than fire (with all the chat about cooking being a primary driver for evolutionary change in humans). Your view of the correct set up and instruction set for computing may be correct, but surely you would be the first to admit that if it is then you have been strikingly prescient. In my view the use cases for computers are far from decided, and while it is true that complete equivalence of all Turing complete instruction sets would enable any language to be used to do what any other language does I think that we want tools that are convenient and efficient for a particular task.

So, 70, 80, 100 years of diversity and then convergence; at least! The more that the energy of change is put into the system the more diversity in the ecosystem. Eventually it will settle down and a standard set of tools will emerge, but not yet.

Re:What do you mean "Keep"?

[pydev]

The problem with Java wasn't that the concept was wrong, it was that Sun screwed up the language design, the implementation, and the stewardship. LLVM and CLR work considerably better than Java/JVM.

A common instruction set for a Java/C#-like language is hard to do because there are too many different tradeoffs involved in functionality like dynamic typing and garbage collection; people tried for years, and they never came up with a good design.

no objective C, bazinga

[cheekyboy]

haha, apple is doing well with Oc.

Why cant they let it die,and use C++ / anything else with bindings.

Re:no objective C, bazinga

[am 2k]

Well, they do ship with python and ruby bindings. C++ simply can't handle the API due to being a static language.

Eheh

[SmallFurryCreature]

And you are aware most job offerings tend to take the kitchensink approach? "Lets include every word we ever read and then demand 4 years experience with it. iPAd, senior engineer!".

Also (java) matches javascript.

I know you are blowing smoke because PHP is not listed. Oversight or some other reason?

Oh and wouldn't your query also match "Need highly skilled X developer who knows enough Java to migrate us away from the steaming pile of crap?".

Or indicate that there are no good Java developers to be found?

What about companies that offer you a nice cup of java every morning?

I know that a job count for PHP has to discount those companies with .php in their url.

In fact, does posting a few queries to Monsterboard not tell you anything more then that you have to much time on your hand?

Re:Maybe it's because

[peppepz]

If people were interested in high throughput math, we'd be all using FORTRAN now.

Re:Here's how to make Java again

[Tablizer]

Congratulations, you reinvented ColdFusion.

For the Twitter+Scala story,

[toby]

There other other sources than The Register, including posts by Twitter devs linked from the Scala language site.

Java architect Gilad Bracha has created:

[toby]

Newspeak is a new programming language in the tradition of Self and Smalltalk. Newspeak is highly dynamic and reflective - but designed to support modularity and security. It supports both object-oriented and functional programming.

Re:Java architect Gilad Bracha has created:

[SanityInAnarchy]

A quick glance makes me suspect I'd rather go with IO or self.

But I wasn't looking for a new language, I was looking for a new multi-language VM.

Did p-systems do JIT?

[toby]

n/t

Re:Did p-systems do JIT?

[sjames]

No. p-code was interpreted. However, the interpreter was much lighter weight, so in practice didn't need to be JIT to keep up with Java in the early days.

That's not to say that JIT wasn't an innovation, it's just that the Java hype machine wanted to claim that every last thing about Java was brand new in concept as well as in implementation.

Date Handling

[warrax_666]

The Jodatime library is fantastic for date handling. I think it's the only sane date/time API I've [b]ever[/b] seen. Admittedly, it's a little complex, but that just the nature of the date/time problem domain.

Re:Date Handling

[arjan_t]

On top of that, Jodatime (or rather a slightly modified version of it) is slated to be included in the standard library of Java 7.

Re:Date Handling

[Eric Smith]

And Java 7 is actually going to be released some day?

Re:Date Handling

[mcvos]

Jodatime is a lot better than Java's standard date handling, but for many applications, it still falls short of Ruby's date handling or Groovy's TimeCategory.

In my opinion, nothing beats being able to write (2.months + 5.days).ago. Jodatime does support durations that keep track of months and days rather than milliseconds (which are often useless), but it doesn't patch that support into existing Java dates and integers, and that's what you really need to make date handling trivial.

Re:Date Handling

[kcitren]

With Groovy, if the date in January 31st 2010, and I add 1 month to it, what date do I get? I'm genuinely curious. I hate date handling.

Re:Date Handling

[arjan_t]

Believe it or not, but the latest is that they're actually going to release it this year. Not that there's a JSR yet, but don't let that destroy our hopes ;)

but but but

[toby]

Guido says you don't need it! (/me ducks)

Erlang programmers might disagree ;-)

I don't care what you say

[toby]

The One True Instruction Set was the PDP-11's.

la-la-la-la-la-la-la...

WTF

[Quiet_Desperation]

'Nothing screams "get off my lawn" like a language controlled by Oracle, the world's largest enterprise software vendor. The chances that Java can attract the mohawks-and-tattoos set today seem slimmer than ever.'"

No, nothing screams "get off my lawn" than seeing young people as the "mohawks-and-tattoos" set. Did this guy just walk out of a time portal from the 1960s?

on a more serious note

[toby]

(Java architect) Gilad Bracha writes,

Support for tail recursion should be required by the language specification

Re:Here's how to make Java again

[tyrione]

I was with you up to the camel casing. Camel case is a fad I could have done without, not only is walkFaster less clear than walk_faster, it is also more error prone to type.

Cocoa programming is not a fad.

Small steps

[Arancaytar]

Try reviving interest in mohawks and tattoos first.

Nothing screams "get off my lawn" more than the rebellious fashion of thirty years ago.

Modern-day COBOL

[mwvdlee]

'Java has evolved from a groundbreaking, revolutionary language platform to something closer to a modern-day version of Cobol'

So Java has gone from immature, constantly changing and buggy to stable, reliable and fast? I can see how that would be a problem for somebody that wants to attract unexperienced scriptkiddies to a programming language.

Re:Java the Pig

[binkzz]

That's java applets. Their integration with browsers is as poor as it was ten years ago. But java applets are a tiny speckle of all things java, and not really representative of java as a whole.

All Those Guys You Just Acquired Have Piercings

[Greyfox]

You're just not checking the right bits. Look harder!

That oughta keep him busy for a while...

Re:All Those Guys You Just Acquired Have Piercings

[TeknoHog]

Look harder!

That's exactly why I got the piercings in the first place.

Re:Here's how to make Java again

[mikael_j]

I think what you want is Ant.

Really, I've been involved in a project where we had external consultants who were pushing for all shell scripts to be stored as and deployed from Ant xml files (so it would essentially have been shell scripts packaged as huge XML files), their main argument for this was that if we did this we could "use version control on all the scripts", we decided to ignore them and simply use Subversion for the scripts without XML-ifying them.

The whole point

[shutdown -p now]

Java has evolved from a groundbreaking, revolutionary language platform to something closer to a modern-day version of Cobol.

The whole reason why Java enjoys the widespread popularity that it has is precisely because of that. Most projects aren't made by "trendy" guys in a basement somewhere - they're made by corporations, most of them not exactly small, who value predictability and the peace of mind that comes with it over new & trendy.

The advantage of Java there is that it is a well-known quantity, and it has been in that state for a while, with few changes. There are many development tools, all top-notch, with code editing features unmatched by IDEs for any other language. There is a huge amount of useful code in third-party libraries, most of them under liberal (free, non-copyleft) licenses. There is a large workpool, and it's going to remain that way for some time to go.

There's nothing wrong with that. It's a niche that has to be filled, and Java is doing remarkably well in doing so. Don't fix what's not broken.

And in the meantime, the trendy guys always have Groovy, Scala etc to play with.

Java aint going anywhere

[jonwil]

Java (specifically J2EE with an Oracle or similar database back-end) seems to be second only to .NET/ASP.NET/C#/VB.NET with SQL Server in terms of jobs I see when I look on the job sites here in Australia.

Plus Java is still the #1 mobile language. Not just on Android but on the 1000s of feature phones out there running various incompatible versions of J2ME for applications (I have owned 3 feature phones, all of which have supported Java apps in some form)

Java on the desktop is dead (if it was ever anything but stillborn in the first place). Java for client side web development died and got replaced with ActiveX, Flash and other technologies.

But Java in the enterprise and mobile spaces is far from dead.

If anything, Oracle should be pushing J2EE even harder (Oracle is the dominant choice of database to use alongside J2EE)

Re:Java aint going anywhere

[MemoryDragon]

No worries, now that JEE finally has become a really nice stack, it will be pushed even harder.
Spring would not exist in its current form if JEE before 5 would not have sucked such a big time, but they got the turnaround with JEE5 and given from what I have seen with JEE6 it has become now outright excellent!
My only gripe now is it slowly becomes too easy to pick up :-)

Re:Java aint going anywhere

[TheTurtlesMoves]

Java on the desktop is dead.

I think you missed a memo.

Re:The Calendar class is going the way of the dodo

[owlstead]

I was writing this when I noticed the AC above with 0 mod points.

To be honest, that is more a problem with the API than with either Java or Groovy. It's currently being worked on in JSR-310.

The time API is well known for it's ugly design and is commonly brought up as a way not to design API's. Because of that I think it's far fetched to use it as an example of how ugly a language can be.

JSR-310 is much more sensible and uses Joshua Blochs Java design principles (for immutability and thread safety). It's based on Joda time (actually the lead dev is the same), which sensible people are using right now.

FTFY

[AlXtreme]

Primarily 'cause nobody who writes enterprise apps really know what they're doing

Re:FTFY

[gbjbaanb]

not quite true... some of them do know what they're doing.. unfortunately, they're swamped by so much project process, project managers, 'architects', designers, consultants, mandatory frameworks, and suchlike that their contributions are insignificant in the end result.

Re:Here's how to make Java again

[owlstead]

I've been thinking about doing largely away with most part of the ASCII representation of a language (as a followup to Java). So that certainly could become a representation of the source, or more precisely of the abstract syntax tree (AST). Of course, it would be for the machine, not for the programmer.

Re:Here's how to make Java again

[pjt33]

People don't type method names any more. I suspect that auto-complete is part of the reason for misspelt method names persisting in just about every code base I've seen.

Re:Here's how to make Java again

[rvw]

The problem with Java today is... it's syntax looks too much like C. And as everybody knows, C is for geezers. Can't we write java code as follows:

<class>
<classname>MyPony</classname>
<method>Run</method>
<code>
<if><condition>IsExcited</conditon>
<if_block>walkFaster </if_block>
</if>
<method>trot</method>
<method>gallop</gallop>

.

I see that you don't have a girlfriend because you don't know squid about ponies. Couldn't you have used a car-example? That would have made much more sense.

It explains a lot about Java...

[croftj]

when you think of it as an abstraction layer on top of Cobol

-joe

Re:"the world's largest enterprise software vendor

[bbqsrc]

You've got it all wrong! It's the vendor of the world's largest enterprise software, dah!

Re:groundbreaking? revolutionary?

[owlstead]

"It was never groundbreaking and revolutionary."

Of course not, it was not because it was explicitly designed not to be all that. It was supposed to be a small well defined language that brought good OO practices and GC to the mass market of C/C++ programmers - hence it syntax. For this to happen, it needed also to be relatively fast during execution.

As for all the politics, I am highly surprised by the way you think the market moves. The development market moves because it sees something useful. After that it looks at the license yes, and Java never had much to scare away developers except hard core purists (read: the linux crowd - and they certainly had good reasons for shunning it).

"But betting on Sun was the wrong move: Sun screwed up the language, screwed up the toolkits, screwed up the implementations, and made Java one of the most proprietary languages in existence.
In the end, all Sun managed to produce was the only thing they have ever been able to produce: bloated server side software.
Good riddance, Sun, you won't be missed."

Now that's just trolling. I'm very surprised that you get modded up when that kind of junk is in your post.

What all is wrong with languages these days

[Skapare]

Languages pretty much get created either by corporations or academics. There are occasionally some exceptions. Those created by corporations have the stigma that the corporation controls it and can manipulate it for their own profit purposes. And those created by academics usually involve new concepts that are usually ten or so years before their time. Basically, it comes down to the fact that decisions are being made about languages, either at creation or during the progress of the language, by people who do not really do programming for a living.

So, in the end, unless we programmers get together and create our own suite of languages (we already know it is impossible for any one language to suit all needs at all levels well), then we are just going to have to settle for what few uncontrolled languages we now have, and/or the ones controlled by non-programmers.

Re:What all is wrong with languages these days

[TheTurtlesMoves]

So, in the end, unless we programmers get together and create our own suite of languages..

It would be the worst language of all time. Some ugly cross between python, java, and perl. if else would use 3 different spellings, typing would be optional and the C programmers will insist on direct access to pointers (and hence require an explicit known memory layout for most types) and require (void*) casts everywhere. Because of its total nastiness the compilers would be unable to do any escape analysis and other optimizations would be difficult too. Then the "C" coders will insist that to write fast code you need asm blocks and its all down the toilet. I haven't even got to namespaces, module systems, macros and linking conventions yet.

Re:Here's how to make Java again

[Dodgy G33za]

Hey, you are not a geezer, don't presume to speak for us....

Objective C says hi

[theolein]

The length and verbosity of a language have nothing to do with its use and popularity. The culture surrounding does. Apple is the only company that uses Objective C on its platform in any major way and since the explosion of the iPhone and the hundreds of thousands of iApps onto the scene, ObjC has gone from being a language less popular than, say Prolog to number 12 on the list of popularly used languages. ObjC in Apple's implementation (all the NeXT Step classes and methods) is probably the most verbose language I've ever seen. It's very popular because of the iPhone and the new iPad though.

Java had the same opportunity with Android, but the interest amongst the less geeky programming public is far lower. This is almost purely because Google couldn't market the thing at all well. Google seriously messed up the market for Android apps by not hosting their own searchable and sortable store in a website, and by having zero quality control.

The problem is NOT the language, although if any company could possibly kill a language's popularity it will be Oracle.

London, The City

[jotaeleemeese]

Not a piercing to be seen.

The best programmer money can buy worldwide.

Java was a great language in its day...

[flajann]

I began with Java when it was married to the Netscape browser (remember Netscape?) I knew it would be a big deal once that happened.

But then Flash came in and knocked Java out of the Browser market. Then Sun tried to turn it into an Enterprise language and grew the complexity of the development environment by leaps and bounds. I got sick of it and pulled out of Java development.

I have another peeve. Why is Oracle only interested in attracting the young developers? What's wrong with those of us over 40? I will always be able to write better, cleaner, more bug-free code than some young upstart. Did I miss something here? I'll run rings around any 20-somethings anytime of night or day.

I guess it would scare some young managers that I've been doing software longer than they've been alive. I've gotten really good at it. I know more languages than I care to count, and done just about everything imaginable in the world of Software. The questions that they typically ask at interviews is indicative of the fact that the younger in the crowd just don't get it. If I don't know a particular system, just give me a day or two and I'll be completely proficient in it. Language, API, framework -- it doesn't bloody matter.

You'd think they would want a "quick-study" autodidact like me, but a lot of them don't. I just don't get it. No bother. Don't need them anymore. And thank goodness for that!

Bullshit.

[jotaeleemeese]

Developers have to pay their bills, the best developers I have met were working in banks or hedge funds, not in universities.

Re:Bullshit.

[Nexx]

I've also seen the most elegant solutions to complicated problems in banks and hedge funds. Trying to predict which way a given security will move given past patterns is a very hard problem, yet I've seen systems that do just that and do it correctly 75% of the time.

COBOL is the industry's biggest success to date

[Archtech]

"Java has evolved from a groundbreaking, revolutionary language platform to something closer to a modern-day version of Cobol."

Since the great majority of actual working, robust, reliable, efficient applications that keep our civilisation running are written in COBOL, that is the greatest possible compliment to Java.

It would be a very good thing if we could learn to distinguish between the academic, the artistic, and the business/engineering aspects of software. I don't know about you, but I really don't want to fly across an ocean in airliner designed by this year's latest and greatest methods, using revolutionary new materials that show great promise in some ways. Give me 747 or at least a 777 - as long as it has been properly maintained.

Re:COBOL is the industry's biggest success to date

[Shados]

Completly agree. People here are confusing "Robust industry standard used everywhere that matters" with "New buzz word thats all over 20 year old college grad blogs"

You want the language you use to do real work to be in the former category. The later is useful, either for hobby projects or for niche uses, and maybe even for real work sometimes, but its a risk.

There's a reason a ton of apps are still in, as you said, COBOL, or even C++, Java, and now .NET (which, let face it, while being buzz-compliant compared to Java, is still not "hip" when compared to Ruby on Rail or whatever)

Re:COBOL is the industry's biggest success to date

[jc42]

It would be a very good thing if we could learn to distinguish between the academic, the artistic, and the business/engineering aspects of software. I don't know about you, but I really don't want to fly across an ocean in airliner designed by this year's latest and greatest methods, using revolutionary new materials that show great promise in some ways. Give me 747 or at least a 777...

Funny you should describe it that way, which is directly relevant to the topic at hand. I've worked on a couple of java projects were, out of curiosity, I wrote a little "Hello, world." program, and packaged it according to the project's official packaging rules. In each case, the result was a file over 50 MB in size. Sorta like using a 747 to deliver a postcard to a neighbor down the street.

Now, I'm quite aware that such monstrosities aren't the fault of java. Just like the existence of 747s doesn't negate the existence of ultra-light aircraft. But a corporation adapted to building a 747 or airbus probably wouldn't be the one you'd want to build your small aircraft. And a corporate software culture adapted to building the bureaucratic monstrosities that you see with java (or Cobol) probably isn't the software culture you want to build those apps for your slick new smart phone. (Or maybe I should say tablet, since today is the first sale of the iPad. ;-)

Unfortunately, programming languages tend to come with cultures, and depending on who you are, such a culture can be very appealing or very off-putting.

Re:The Calendar class is going the way of the dodo

[jc42]

http://today.java.net/pub/a/today/2008/09/18/jsr-310-new-java-date-time-api.html
http://jcp.org/en/jsr/detail?id=310

Interesting. I noticed especially the comment:

JSR 310 classes store date/time representations only as a nanosecond offset from the same standard epoch used by Date and Calendar; calendar fields such as day of month are only computed when needed and are not used for internal representation of dates.

Back in the late 1990s, I worked as a developer for a project that was mostly done in java. One of the things we had to deal with twice each year was that, when we switched to/from Daylight Saving Time, the java time-handling code went insane. Every time. We'd dig around to try to find the problem this time, and each time we'd find a good number of discussions of the problem.

I kept pointing them to java "standards" which stated that java's internal clock was kept in local time. I'd simply comment that this totally explains the problems. No time package whose basic clock is any representation of local time can ever be made to work quite right. The main reaction of the managers was to treat me as a trouble maker, and periodically accuse (;-) me of trying to secretly introduce Universal Time into their software, when I knew they wanted only local time.

After a few years, I moved on, as developers usually do. I've talked to the people still associated with the project off and on, and usually asked them about their DST problem. It still bites them every year. I shrug, and move on to another topic. Since then, I've worked in a few projects that used java and were contemplating changing more of the code to java. I've suggested that they should look up the twice-yearly online discussions of DST-related time bugs. This has often been enough to put a damper on further java plans.

It's good to know that the java people have a time package based on a single universal epoch counter, and which even counts nanoseconds. Maybe this will end the time problems. Or maybe managers will nix its use on the grounds that they don't want any of that UTC stuff in their code. Time will tell, I suppose.

And I suppose it's all part of the general problem of bureaucratization of the java user culture. It was pretty bad even 15 years ago, and doesn't seem to have improved with age. So I now mostly prototype in perl or python, and when I have a quick-and-dirty version running, I start talking about recoding it in java (or C++ or C or whatever). It's interesting how often I'm told to not bother, and work on a prototype for something else that's needed.

It does go along with the observation that a major reason for much our ongoing software problems is that most of our code is prototyping. Developers are rarely allowed the time to do it over the right way. I've seen cases in which N departments in a company have "standardized" on N different versions of the prototype code, all of which are slightly incompatible with the others, and none of the managers will permit redoing it all as a single package that works the same everywhere. And you have to carefully hide from them the fact that your date/time calculations use a basic UTC "epoch" counter, because they want it all to be local time.

Who cares?

[kaffiene]

Who cares if Java is cool or not? It's getting a lot of actual work done. In fact, there's a crap load more stuff getting done in Java than Ruby or 'The Cloud' or whatever is supposed to be cool these days. In the end, 'coolness' has absolutely no engineering benefits whatsoever.

The fact that Java has lasted as long as it has and is as prevalent as it is now is testament to its ability to GetShitDone(tm). ...along with a lot of other useful languages which are useful regardless of whether some hack or slashdot group-think thinks it's trendy or not.

good for java development

[hendrasense]

development for the java programmers can hopefully add more extensive knowledge

Re:groundbreaking? revolutionary?

[MemoryDragon]

Actually Java made some inroads in the embedded and set top market, also the jvm was scaled down even into sim cards and cell phones (check out Android for instance or the midp javacard is used almost on every sim card there is)
The problem is, you almost never see this code, because it is in the devices you work with, it is the same situation with ARM, probably every person in the western world uses at least 4-5 devices daily which run on ARM processors, but until recently you never even were aware of those because it was not heavily advertised.

Thing is, that the only thing were java really failed was Applets and the desktop, and Sun hat something to do with it big time. It speaks legends that Java 6u12 was the first incarnation of java were Applets really became useful in Windows, that is 10 years after their initial introduction.
What happened, some simple things, they put some manpower into them for javafx, they pushed them into their own process space outside of the browser, modularized the rt so that the initial download is 5 MB and made finally the online update process work even on module level.
This is all stuff which should have been done before 2002, it was a nice effort, but it did not really revive applets, although they are still way better than anything else we have in this space!

Same goes for Swing, unusable befor JDK4 nor a perfect option for cross platform UIs but given its reputation not really used anymore (well the we have to push everything into the Web craze helped also)
Swing took at least 3 revisions too long to become usable!

Never Revolutionary, but Still Relevant

[RAMMS EIN]

Java is not and never has been groundbreaking and revolutionary. All the features people used to tout about Java back in the day were things that existed before it. A lot of smart people have poured a lot of effort in research related to Java, and the platform has grown stronger as a result, but even most of that seems to be just re-implementing existing ideas for Java.

However, that by no means implies that Java isn't relevant. It has certainly taken the software world by storm, and, as far as I can see, Java is still going strong. People are taking Java courses left and right, either to learn it for the first time or to deepen their understanding. There are so many Java projects that it's hard to find something for those in our company who would prefer to use something else. Even with .NET being backed by a company whose products usually get adopted as a matter of course, I don't see nearly as much demand for .NET knowledge as for Java. Java irrelevant? It sure doesn't seem that way to me.

Who needs the main() method?

[tonywestonuk]

public class Hello {
        static {System.out.println("Hello World");}
}

sure its early

[Maglos]

google app engine may have java support, it's an obvious choice considering the number of developers. However python is right there beside it now, a choice that a few years ago would not have been considered for such an application. Python may still be behind, but its moving quickly. 4 years ago my Alma mater required all BSc to take a python course. That said Java is still the dominant language in the computer science department, but heck it is also the Alma mater of James Gosling(founder of Java).

Google -- Java

[jmrives]

Wow, someone needs to clue in Google about this.

Re:Here's how to make Java again

[swinginSwingler]

I believe that's call Ant. Or close to that ugliness anyway...

Re:Here's how to make Java again

[TheTurtlesMoves]

I believe there is already an eclipse plugin for that ;)

Re:There was this guy in $US_BIG_BANK, London

[phantomfive]

lolol who cares? Having a mohawk doesn't mean 'poor' it means 'no fashion sense.' That has absolutely nothing to do with how much money you make. Furthermore having 'no fashion sense' has absolutely nothing to do with whether you are a good person or not, it just means you care about fashion enough to develop that skill.

It's not as bad as he thinks

[Exawatt]

I'm 20, have pink hair, and my lip pierced, and I program in Java.

as opposed to what?

[maraist]

.NET? How is being subservient to a historically abusive MicroSoft better than Oracle, who to my knowledge doesn't have a path that can force java development to be tied to Oracle licenses. Though architecturally equivalent in my opinion. There are as many java sub-languages as .NET languages.

PHP? Perl? Python? Certainly attractive to piercings, but I don't see this running on cell-phones. And my experience is that it isn't as attractive for larger (million-line) projects. Yes I'm aware of very large PHP projects, but I've not found them to be as easily packaged / extensible.

Ruby? I separate from the above 'scripted' languages, only because of the RAD popularity. People move away from this when they hit a performance ceiling. It just doesn't have anything fundamentally appealing to it, save maybe some syntax concieness.

erlang? Wonderfully efficient / highly available language.. Makes my eyes bleed when reading through.

lisp, scala? Less piercing, more snootiness. But plausible.

C, C++? Surprised these haven't adapted to the current web-services climate.. These are excellent languages - though they're just not fun for me anymore.

Objective-C? Need a registered fan-boy card to use, last I heard.

I'm sure I've missed some modern popular languages.

Sorry but

[JustNiz]

I think C and C++ are way cooler than Java and .Net.
I think coolness is inversely proportional to bloat, and also inversely proportional to someone else deciding that you're too stupid to do the right thing, which is why I also think all Microsoft products especially Windows suck ass (becuase Microsoft presume all users dont know what they are doing).
Java and .Net are like those plastic scissors with the ends rounded off.
C and C++ are like a surgeon's scalpel in comparison. Yes its much more efficient and yes you can hurt yourself if you don't know what you're doing.

Re:Here's how to make Java again

[Ken_g6]

Been there, done that, sort of. I actually had to maintain a program written with something called Jelly. Overall, I'd rather stick with Java/JSP.

It's the degree of difficulty, stupid!

[Baloo Uriza]

Now if they'd only worry about the JVM being dog slow and blecherously painful to debug on any platform...we'd be getting somewhere.

The folks behind lively kernel ...

[quax]

... rather convincingly managed to reproduce a full GUI in modern browsers . Ironically it also started out at Sun Labs.

Re:The folks behind lively kernel ...

[Tablizer]

Seems optimized for mechanical and "chart" diagrams, not "office GUI's", where editable data grids, tabs, MDI, outline trees, etc. need to be robust.

Re:The folks behind lively kernel ...

[quax]

Guess I should have added why I consider it ironic that it started out at Sun Labs: It doesn't use Java.

Re:The folks behind lively kernel ...

[quax]

True. Excellent proof of concept though. It may seem to be kind of a backwards way to go about it but in a sense coupled with the cloud this has the potential to bring back the "dumb" terminal days of yore. Not sure though if this is anything to be happy about.

There's a lack of stewardship

[Rix]

The enterprise sector is very reluctant to take responsibility for anything. They don't build intra-organizational structures to build and maintain the infrastructure they need, they turn to other enterprises like Sun, Oracle or Microsoft. This means that choices are made based on the best interests of Sun, Oracle, or Microsoft, not those who'll actually use the stuff.

So yeah, there aren't any good choices in enterprise, and there won't be until they learn to work together.

I'll not hold my breath.

What struggle?

[jamie(really)]

Are you some M$ schlep paid to get a post on here so you can say "Look, even the slashdot kids think java sucks!"

Android: java.
GWT: java.
Groovy: JVM.

Shouldn't the article be "The struggle to keep windows relevant?" or "the desktop"?

I'm writing java right now (ok, no, not *right now*) because it has the tools I need to get shit done. I use C#, C++, PPC, ARM, etc when I need to.

Am I missing something? Is java going tits up?

Jamie

Re:Drown already.

[cduffy]

programming freshmen college students

Haven't known any of those for a decade at least.

No -- of the people I referred to as "cutting-edge" here, every last one is at least mid-career.

Re:Drown already.

[cduffy]

What does it offer over the gajillion other Lisps out there, aside from running on the JVM?

Transactional memory; lockless concurrency.

"Coolness" does not a good langauge make ...

[CexpTretical]

Mr. McAllister seems to think that software developers pick programming languages like they pick video games. I and all of the developers I know, when we have the authority to choose which language to use on a project do so based on the merits of the technology, not based on how cool we think it is. Maybe if you are a tech writer in SF and know what little you know based on conversations with programmers in the local Star Bucks, then coolness matters. Just look at the facts, number of jobs available for Java developers, versus C# (.NET), versus Ruby, etc. And if you want to judge where software is going based on Linux development trends I think you will miss the mark more often than not. As for Mono and Linux trends McAllister quotes Mr. Worthington, yet another tech writer whose bio states that he got his "BBA from the Fox School of Business at Temple University, majoring in marketing. Aside from studying business, he took a concentration in computer science, studying C, COBOL and SQL." What the .. why is Slashdot even covering the dribble from these guys?

Re:Nothing screams get off my lawn like this comme

[Rusty KB]

I resent that comment. Piercings are a gateway drug!

Re:To be fair

[TheDarkMaster]

Well, My clients still uses special hardware and printers with parallel and serial interfaces (and works well, why change?). And many other devices still have good use for then.

You can suggest USB, rigth? I thought about it, but the USB support of Java is also missing (And the third-party implementations are defective). Which way to go? I'll still end up using C for this type of work.

Re:No there isn't

[TheTurtlesMoves]

Only if *all* the library it links too are *also* 32 bit and only on the x86 version of 64bit where there is a hardware compatibility mode.

The point remains that even Ansi C can and often is written in a way that means it will only compile on one quite specific "system" for whatever definition of system you want.

It sounds like it doesn't work well...

[Rix]

You'll have to weigh the cost of replacing the old equipment against the cost of using an interface no one cares about anymore. If the latter is still preferable, fine, but don't expect anyone else to help.

It seems to me that Java's philosophy would encourage you to use a printing library rather than fiddle with the base hardware yourself, but I've not looked into it.

Re:It sounds like it doesn't work well...

[TheDarkMaster]

The printing library exists, but is incomplete (lacks port status) and buggy. Is why I needed to find something else.
And again, What I will use? USB? Java do not support then too.

Re:When all you have is a hammer...

[TheDarkMaster]

My work at the company is "making the impossible possible" (how I ended up doing in this case). What bothers me in this particular case is that a language that claims to be "the solution to all problems" and that "works even on toasters" had to be able to do things like this without hacks.

Economics Fail

[Slashdot Parent]

Higher demand (5K+ job postings) would typically suggest a higher price (compensation), not a lower price. However, we cannot know price without knowing both supply and demand.

Around here, demand outstrips supply. If you know of a source of experienced Java developers who will work for $50k/yr, please let me know.

Re:When all you have is a hammer...

[Rix]

Who ever said it was the solution to all problems? The JVM itself can't be written in Java...

Re:When all you have is a hammer...

[TheDarkMaster]

The creators of Java, of course :) I still remember the beginning, when they said it would work on anything (even coffe makers) and that would solve all problems. Hehe.

I remember the former...

[Rix]

But not the latter.

Of course you can solve any problem with any language, it's just not always a good idea.

Re:I remember the former...

[TheDarkMaster]

I know, of course. But try to say this to your client (and it is the government) :)