If Java Wasn't Cool 10 Years Ago, What About Now?

10 years ago today on this site, readers answered the question "Why is Java considered un-cool?" 10 years later, Java might not be hip, but it's certainly stuck around. (For slightly more than 10 years, it's been the basis of the Advanced Placement test for computer science, too, which means that lots of American students are exposed to Java as their first formally taught language.) And for most of that time, it's been (almost entirely) Free, open source software, despite some grumbling from Oracle. How do you see Java in 2014? Are the pessimists right?

Comments

I hope not

[onproton]

Java is the (only) required programming course for the IT major at my University. /sigh

Re:I hope not

[Pino Grigio]

It was just coming into favour when I left. When I was around it was Modula-2 and Eiffel (for OOP) at University. I have always found Java to be absolutely horrific in practice, being pretty much the worst of all worlds. Today C# is far superior, whatever you think about Microsoft, and it's a real shame that .NET was mishandled at birth in the way that it was.

Re: I hope not

[bugnuts]

You only need to learn one oo procedure based language. All others are just a book exercise.

One assembly language and how compilers translate stuff.

And then you should also learn scheme.

That will handle basically everything, reducing it to a book learning experiment.

Re:I hope not

[Z00L00K]

I wouldn't state that C# is superior to Java from a language perspective, both are essentially derived from Ada and C with influences from C++.

If Ada had been more open and better promoted then it would have been a far better choice.

Re:I hope not

[Anonymous Coward]

I wrote compilers for Modula-2 in University, and was minimally exposed to Java (thank God). I have seen fans of it, but my own experience is that Java is a narcoticized slug. Its bloated (worse than COBOL), and has a learning curve steeper than a cow's face. Worse, unlike C, which is a compact language (you can learn all of the data structures can be easily described in 2-3 pages of any textbook or manual), Java goes on and on and on (the smallest book I've seen is 850 pages). There are 10,000,000,000,000 libraries, with that number being modified every year, and offers by exponents of the language to offer another 3-5 libraries for every one available already. In order to be productive in any way (eg: Hello World), you need to call in at least half of all available libraries (each, seperately, and in the correct sequence), and then hope that all of your current libraries are up to date and work with each other. Then you run the program, and wait, and finally it gives you your output: "Hello World".

Re:I hope not

[Anonymous Coward]

I wouldn't state that C# is superior to Java from a language perspective, both are essentially derived from Ada and C with influences from C++.

Haven't used C# that much myself (and am totally out of touch with Java these days) but when I first used it just over ten years ago C# *did* strike me as very obviously a Java workalike, albeit one with a few nice improvements. Of course, it had quite obviously enjoyed the benefit of hindsight over Java, picking and choosing the aspects which worked and being able to ignore the dead-ends and mistakes, as well as the legacy library cruft which- even by the early-2000s- Java already had quite a lot of (mainly stuff from the early versions which was later deprecated).

Re:I hope not

[buddyglass]

I have only a dim recollection of Ada from a programming languages "survey" course in college, but I remember being bothered by the fact that everything was a word. Some of them could have been symbols. It seemed really...verbose.

Re:I hope not

[Aighearach]

Jeebus people, just open the story from 10 years and press "reload." There you go, you asked again and got the answers again.

It might be that there are real pros and cons for languages. It might be that the reasons languages are "un-cool" are because they address the needs of the pointy-haired, and don't support pocket protectors.

And it does make perfect sense for Java to be the 1 required language in a CS course; it might be the only way to get kids to learn it, since it is so un-cool, lame, and inefficient for the small projects that students are working on. In a well designed CS course, very few problems have a required language past the basic algorithms classes. (Where standardization allows for a higher quality class when the teachers are grad students)

Anyways, it makes sense to teach Java, because the best use case for Java is to be able to use massive teams of low quality developers, potentially with high turnover, and still make working software. These are the people most in need of the job training type of education. People who are going to work in almost any other area are going to have to be able to learn new tools quickly based on the manuals, and it won't matter what they studied.

Re: I hope not

[Aighearach]

You don't need an "OO... language" because OO is a methodology. You can learn pure, real OOP using almost any language. Plain C works fine.

You can also write bad procedural code in an "OO language" because that is also a methodology. I see that crap all the time; giant 50+ line methods that do a bunch of things and all the utility functions are procedural-style class methods. Lots of Rubyists don't have any idea even what the difference between OOP and Procedural is, they just assume they must be doing OOP since they're using an "OO language."

Same thing with learning scheme; when you associate functional programming with a language instead of a methodology, the first thing new people do is try to find a way to fake some state and they end up with spaghetti procedural instead of functional.

Re: I hope not

[WarJolt]

You only need to learn one oo procedure based language. All others are just a book exercise.

The problem with that is most people think because they can program in that language they understand the paradigm.

There are tons of c++ and c# programmers out there who think object orientation is only about turning UI controls into objects. All other code is more of a mix of bad OO and imperative programming.

I would revise your original statement to you only need to learn one oo language well. Same for functional languages. You are have to know a language well to understand the paradigm.

Re: I hope not

[gtall]

Not Scheme, but rather Haskell. Haskell is a modern functional language with very strong typing. Scheme is a holdover from Lisp with static typing but no strong typing. Plus, Scheme adherents are insufferable. That alone should spike the language.

Re:I hope not

[plopez]

Have been on hiring committees, any person applying who only knows one programming language is not going to get far with me. Or languages from a specific vendor *cough* Microsoft *cough*. If you are at the Uni. I advise you to seek out courses using other programming languages, and at least one of those should be functional.

Re: I hope not

[countach]

Errm, Scheme has strong typing with NO static typing.

Re: I hope not

[countach]

Why not just learn scheme, and everything else is a book exercise? Use it with a CLOS clone for OO. Most scheme courses probably dive into writing a VM also, so that takes care of the assembly side.

Re:I hope not

[RabidReindeer]

Java owes little to Ada. Ada has one of the most rigorous data typing systems of any programming language, but its roots are in Pascal, and thence descend to Algol.

Java's syntactic roots come from C through C++, which added OOP capabilities.

C# is somewhat of a zig-zag. In part, it's Microsoft's alternative after they were prevented from hijacking Java. In part, it's reaching back to C++. Along the way, they attempted to cure some of Java's warts.

One bit of irony. Both Java and C# are programming languages designed and "owned" by private organizations, each of which also owns at least one major OS. Java users always had a high degree of confidence that Sun would never abuse that position and attempt to use Java to lock them into Solaris. C# never enjoyed that confidence, which is why there's precious little C# work done on the non-Windows OS's.

Re:I hope not

[phantomfive]

because the best use case for Java is to be able to use massive teams of low quality developers, potentially with high turnover, and still make working software.

This is exactly what I came here to say. And it does it well.

Re:I hope not

[Anonymous Coward]

What about Computer Science majors? IT is basically a simplified Computer Science.

Re:I hope not

[aaaaaaargh!]

Ada favors readability over brevity, so it takes a longer to type programs but makes them much easier to understand. I find it so easy to read that I can dive into the code bases of packages and even GNAT itself and understand them without resorting to commentaries or additional documentation. It has its quirks, though, and a relatively steep learning curve.

Re:I hope not

[Darinbob]

Nothing wrong with that though. There are people who really really hate C for being an obtuse language with too many symbols (they probably pass out when looking at Perl). If you discount languages derived from C, Ada is not relatively verbose compared to its peers.

Re:I hope not

[Anonymous Coward]

Or languages from a specific vendor *cough* Microsoft *cough*.

Yet another idiot who lets their personal bias get in the way of objective decisions. Regardless of what you think of Microsoft, C# is a very good language as is Typescript (which also has the benefit of being FOSS, licensed under ASL 2.0) and saying that the fact that a candidate knowing languages from Microsoft would cause them to not "get far" with you just demonstrates how out of touch you are and how unsuitable for that position you are. Although it strikes me that perhaps you mean they wouldn't get far with you on a personal level?

Re:I hope not

[Pino Grigio]

This is absurd. Generic programming, for example, is far better in C# than Java. Most of the stuff included with Java 5.0 was already present in C# 1.0.

Re:I hope not

[MightyMartian]

If the only language you have proficiency in is C#, then you have a problem that may very well interfere with your employability.

Re:I hope not

[Wootery]

C# never enjoyed that confidence, which is why there's precious little C# work done on the non-Windows OS's.

Well, let's be clear: it's not just because Sun had more goodwill than Microsoft.

For a start, Sun made JVMs for all major platforms. Microsoft made .Net for Windows only. They made Silverlight for Windows and Mac, granted, but never even a nod to Linux. Mono had to make its own way.

Re:I hope not

[Wootery]

Oh, and that in Java, the 'culture' is to deliberately avoid anything non-standard or specific to any JVM. In the C# world, though, there are things like WinForms: vital parts of the 'ecosystem' which are platform-specific and non-standard.

Re:I hope not

[plopez]

What I am saying is that is if you only know MS products you have a very narrow experience range to your detriment. If all you knew was Objective C and Apple development environments it would also count against it. C#, Transact SQL, Powershell, C, Perl, Bash, and a functional language would be a nice experience range.

Re: I hope not

[Wootery]

You only need to learn one oo procedure based language. All others are just a book exercise.

I guess C++ doesn't count as an 'OO language', then, because you sure as hell can't take a Java programmer and turn them into a competent C++ programmer overnight.

This whole idea of programming languages share the same basic concepts, so once you can program in one language, it's easy to learn new languages needs to die. You cannot take a Java or PHP programmer and have them learn to make proper use of C++, or Lisp, or Haskell, or assembler, or even C, without considerable effort. Even just the compile/link model of C takes some real work to get used to.

Re: I hope not

[deKernel]

I thought I was the only one that laughed at that one.

Re:I hope not

[S.O.B.]

I assume you mean generic programming on Windows is easier in C#. Although debatable on Windows, it's less so on some platforms and impossible on others.

All the languages that have truly had longevity have also been generally available on numerous platforms (i.e. not just Windows and Mac).

Re: I hope not

[Pseudonym]

The only reason that you would teach Scheme is if you were teaching SICP. Teaching Scheme without teaching SICP is a waste of Scheme.

Re: I hope not

[cheekyboy]

Compile and link is a simple concept.

10000 functions, create 10000 objects, 9990 are unused. 10 get copied to one bigger object. Duh!

Re:I hope not

[cheekyboy]

why? If you do 50hrs a week on pure C#, and are considered a genius on it, then you can implement and code anything in it that you can in any other language. If a company only makes C# apps or only has C# web services, why would you need java or C++ expertise. Though if youre an expert in C#, you would find other langs easy to learn.

Java wont magically make a giant problem 10x easier.

So unless you require 100000 linux machines in a cluster, that is cheaper than 100000 windows machines, C# is good.

Infact, I would prefer C# compiled to binary over C++ any day. And which C++ ? there are many variants and addon frameworks that restrict your environments.

Re:I hope not

[Pseudonym]

Anyways, it makes sense to teach Java, because the best use case for Java is to be able to use massive teams of low quality developers, potentially with high turnover, and still make working software.

To be fair, there's a large amount of uninteresting enterprise glue code that the world needs, and somebody has to write that.

Re:I hope not

[Bill Dog]

Not around here. But I had to abandon 10 years of C++ for that very reason. Unfortunately. (Luckily MS has grown C# with a lot of what are to me C++ influences, unlike Java which was among other things meant to be an anti-C++.)

Re:I hope not

[arglebargle_xiv]

It was just coming into favour when I left. When I was around it was Modula-2 and Eiffel (for OOP) at University.

Given that Eiffel was created by Satan himself to torture lost souls, I can't see how Java could be worse. The language itself was quite nice and had some good ideas, but the programming/development environment was appalling, I'd rather spend eternity in the company of Beelzebub and all his hellish instruments of death than have to develop code using those tools again.

Re:I hope not

[mcvos]

I wouldn't state that C# is superior to Java from a language perspective, both are essentially derived from Ada and C with influences from C++.

But C# is far quicker to incorporate modern language features (like closures and other dynamic programming features), while Java is constantly dragging its feet.

I'd never lock myself into a Microsoft ecosystem by specializing in C#, but as a language, it's more up to date than Java. There's a good reason for the proliferation of other JVM languages like Groovy, Scala and Clojure.

Re:I hope not

[angryfeet]

Generic programming isn't the same thing as cross platform programming. C# started off as Java with hindsight, and it's also been evolving much faster than Java has, so its considerably better now. Mono has also made it cross platform. For example, the Xamarin guys ported Android to run on Mono (ie Java to C#). The benchmarks ran a number of times faster.

Re: I hope not

[Anonymous Coward]

Learning the syntax is never the challenge. The tough part is memorizing the bazillion APIs you are tested on the job interview.

Re: I hope not

[Urkki]

Compile and link is a simple concept.

10000 functions, create 10000 objects, 9990 are unused. 10 get copied to one bigger object. Duh!

Mmm, not sure what point or joke you are trying to make, but it is ruined by numerical inaccuracy: generally one object (whether you mean C++ class or a compiler output object file) contains many exported functions.

Re:I hope not

[Z00L00K]

One word: COBOL

Re:I hope not

[Z00L00K]

But then C# also suffers from bad decisions that are making the code hard to maintain. Especially the 'var' type which can mean whatever the coder want it to mean, combine that with some remote objects provided by another server on the network and you have built yourself a nice little time bomb.

Re:I hope not

[turgid]

why?

Learning a language that comes from a completely different school of thought (i.e. "paradigm") will give you a far larger perspective than only having learned one language or family of languages. For example, if all you ever saw was C++, Java and C# your world view would be extremely limited. Someone who has learned a little FORTH, LISP and Smalltalk, not to mention various assembly languages, would be an order of magnitude more productive than you, produce fewer bugs and be able to think of more good solutions to difficult problems.

If all you ever do is write GUIs for the corporate Oracle or MS database, then stay in your C# paradise.

Re: I hope not

[Daniel Hoffmann]

Have you ever used function pointers in C? Proper syntax and semantics built into the language goes a long way to enable the OO paradigm.

Re:I hope not

[Frederic54]

About the same, I got my masters in 1996 and it was Eiffel at the time for OOP, quite heavy language but true OOP.
Java was seen as a little guy bouncing left and right on a web page...

Re:I hope not

[Tamerlin]

Mono had to make its own way.

That's only partially true. Mono had development support from Microsoft, and unlike Java .NET and C# have been officially open standards for a long time, because Microsoft submitted the specs to ECMA.

Re:I hope not

[godefroi]

You are so completely, terribly, obviously wrong. There are definitely 'better' languages.

Re:I hope not

[godefroi]

Um, 'var' always means exactly what the compiler decides it means. The coder gets no say in the matter. It's not a variant type, it simply means, 'compiler, decide what this type is for me'. It's called 'type inference', and it's quite common in non-ancient programming languages. C++ even has type inference, now. ML, Haskell, Scala, and Apple's new Swift language all have it as well.

Re:I hope not

[rhyous]

I heard MS was contributing $$ to Novell to further the mono project from a member of the Novell team. Which essentially helped spawn Xamarine. Can any provide a source that confirms or refutes this.

Re: I hope not

[dilvish_the_damned]

Seconded on the grounds that there are 'worse' languages. Though usually I see Java as the example.

Re:I hope not

[Jefftoe]

Yeah, Ada has always seemed "strongly typed" to me, but customizable. AND I loved := it. lol

Re:I hope not

[Jefftoe]

However, and it's been a long time, but one frustrating thing about Ada was the compiled library or procedures and such. It never seemed portable

Re:I hope not

[Z00L00K]

And that's exactly why the code is hard to maintain - the compiler decides stuff that makes it hard or impossible to know what the "var" type means from a coding perspective. I have lost countless hours on that because I couldn't figure out the type to adapt the code in a suitable way.

It's a typical example of ugly coding that someone inheriting the code will start a hate session for.

Re: I hope not

[PsiCTO]

Two points: 1) (always made) steep is good if the x-axis is time 2) Cow regurgitate and chew cud... or is that cruft? There must be more analogies between cows and programmers, but I'll leave that to Gary Larson...

Re: I hope not

[Max Littlemore]

You can also write bad procedural code in an "OO language" because that is also a methodology. I see that crap all the time; giant 50+ line methods that do a bunch of things and all the utility functions are procedural-style class methods. Lots of Rubyists don't have any idea even what the difference between OOP and Procedural is, they just assume they must be doing OOP since they're using an "OO language."

... and in some cases breaking with OO methodology is the correct approach at least for Java. I'm thinking of squeezing performance out of an Android app on low end devices where it's a good idea to use the "static" keyword all over the place and in doing so treat member variables as globals and functions as effectively global subroutines. I think of it as risotto code - a big bowl of starchy mess that's a bit less stringy in appearance than spaghetti and potentially harder to get your head around.

Which sort of brings me to my view on whether or not Java is cool. Java itself is kind of like a swiss army knife that can be used to do just about anything you could want to do. It comes with a huge amount of bloat to that allows it to handle just about anything and while it's almost never as good as a specialist tool but you can always make it work. Swiss army knives are cool to boys between about 8 - 16 years old give or take. An adult with a swiss army knife in a leather pouch on their belt on the other hand is never cool.

Useful maybe, but never cool.

Re: I hope not

[Wootery]

Do shut up and take your obtuse time-wasting elsewhere. Sigh I'll bite anyway.

Which language did you learn first? Which language did you learn second? I suspect the second took you less time to learn than the first, but I suspect also that it was still a non-trivial learning experience.

Being a "programmer" absolutely does not mean you are able to pick up a new language and get your head round it in a few short hours. That is my point.

I can use any one of those languages, and have in the past

So you can use C, C++, and COBOL. So, three procedural/OOP languages, then. If you were tasked with bug-fixing a Haskell code-base, you'd be facing totally alien programming concepts. Your idea of I am not defined by a language goes out the window, as you realise you aren't a competent functional programmer.

Re: I hope not

[Wootery]

Yeah... not really, no. Suppose there's a name-collision between C functions in two different libraries you're using. Better get the link-order right. You need to know the way that linking concepts interact with with inline functions, static functions, and templates. C++ member-functions always have external linkage. Forward declarations of template classes to reduce compile-times. The magic that goes on enforcing the One Definition Rule in the face of templates. None of these concerns arise in Java. In Java, .class files act as both the header and the dynamic library, and it 'just works'.

Atop all that, you may need to chose a cross-platform build-system like CMake, and maintain its makefiles. In Java you normally have either a NetBeans project or an Eclipse project, and I believe the two are trivially converted. In C++, getting a completely portable codebase but with an autotools build system, to build in Visual Studio through CMake, might take some real doing.

Also, Urkki is right - not sure where you're getting this idea than each function gets its own object file.

Re:I hope not

[Wootery]

Mono had development support from Microsoft

Yes, indeed, but in a conflict-of-interest halfway-house sort of way: the .Net codebase remains entirely separate from Mono, presumably because MS wants Windows to be the best place to run C# code, but they also want to be able to say C# is genuinely cross-platform. HotSpot, however, runs on just about everything.

Re:I hope not

[godefroi]

If you lost hours to 'var', then you lack sufficient skills to perform your job. Congratulations, you've reached your Peter level.

Re:I hope not

[Z00L00K]

You haven't seen the code I have had to dive through.

Re:I hope not

[godefroi]

And I don't need to.

Re: I hope not

[Aighearach]

OO can't be to promote re-use, because it is just a type of structured programming, and all structured programming is promoting re-use very very heavily. That was never an advantage of OOP.

But what he's talking about is the other direction; the library should protect itself from bad clients, but the client shouldn't have to protect itself from bad libraries. The library should be able to encapsulate its own testing. That is true in any structured programming paradigm.

And specifically as to C++, that is perhaps why OOP using plain C is so much cleaner (in the best case where strict conventions and best practices are followed, such as glib/gdk/gtk)

Re: I hope not

[peccary]

People may challenge you on this - refer them to CLU.

Nope

[Anonymous Coward]

Java is not only about FOSS. It also has a strong hold on enterprise software. Which is why is still relevant.

RE: Nope

[Anonymous Coward]

I goes without saying, but I forgot to mention on the previous post. Enterprise software aren't usually cool...

Re: Nope

[bugnuts]

COBOL was never cool, either, but is still in use in enterprises.

For learning the craft, they should use what's best to teach it, not necessarily what's relevant at the time (unless it's a job school).

Re:Nope

[Pino Grigio]

That's the wrong side of the equation. What you should say is that it won out because a bunch of suits who make purchasing decisions got behind it. Don't blame the salesman.

Re: Nope

[meerling]

So most schools should only teach things that are not relevant to employment?

Re: Nope

[bugnuts]

What's relevant for learning to program might not correspond to what's currently being used.

Teach a man code a a language, and he's relevant to a small market. Teach a man to program, and he owns them all.

Re:Nope

[msobkow]

Those "suits" you refer to included every major hardware vendor on the planet. Java was only sold as a silver bullet for portability, not speed, not efficiency, not scalability, but solely for it's ability to be shifted from one vendor's platform to another's.

When it comes to straight forward business service and batch job processing, it succeeds admirably at that goal, which is rather rare for what you claim was a "silver bullet."

The "problem" is that all kinds of people have visions of Java doing this, that, and the other thing, ranging from the addition of database bindings that don't allow for stored procedures to 3D graphics. Java's "problem" is that it's gradually becoming too much of a "kitchen sink" instead of staying focused on what it was designed for: portable business programming.

Re:Nope

[sjames]

It sorta got there. It's an unmitigated disaster on the browser, for example. It is also awfully touchy about what version of java you're running. The desktops with native java CPUs never happened.

Java definitely isn't Hip and never will be. It is, however, the new COBOL which means it'll be around for a long time.

The one exception is it's use in Android. I wouldn't say the language is hip there but it is tolerated because mobile is hip.

Re:Nope

[Anonymous Coward]

> portable business programming.

Only if you mean "portable if the only thing I have is a binary". Considering the crazy amount of compatibility issues between different Java versions, vendors etc, the average C++ program is on a similar level of "portable".

Re:Nope

[Aighearach]

Mostly true, but Java was indeed always sold as being scalable. Portable scaling.

Speed and efficiency were supposed to come from the Java-native CPUs, which of course only made it into thin clients. Well, medium thin clients that had application-specific thick client capabilities that could be remote-loaded. I don't think they ever really even worked out how to describe it in a clear way; it flopped before making it out of the buzzword soup. But apparently it ran Sun's web browser really well.

Re: Nope

[Aighearach]

COBOL was never cool, either, but is still in use in enterprises.

For learning the craft, they should use what's best to teach it, not necessarily what's relevant at the time (unless it's a job school).

Lawyers aren't cool, and they make almost as much money as COBOL programmers. They even have their own schools.

Everybody should learn COBOL though. "Okay class, now we're going to learn what it is like when you only have pass-by-value, and no references. At the end of the unit we will understand why all modern languages use pass-by-reference, except for optimizing literals, and why modern COBOL programmers write all their new code in C libraries."

Re:Nope

[NotInHere]

All browser plugins are unmitigated disasters.

Re: Nope

[RightwingNutjob]

Java is the new COBOL as far as I'm concerned. I work in a large research lab that got bitten by the java bug in the early-mid 2000s. And now we have a large codebase that's locked in to a particular vendor, that only works with other java code, and a whole bunch of "programmers" whose only skill is java. Which means if we need something in C or C++ for low-level hardware interfacing or for running faster than dead slow, we need to reimplement it from scratch, except we need to hire programmers to do it if it's big because all of our "programmers" only know java, except we can't hire anyone new, because we've already got all these "programmers" on staff.

Re: Nope

[AJWM]

Back in my (pre PC) college days, COBOL was big in business but wasn't taught or used by anyone in the Computer Science department. If you wanted to learn COBOL, those courses were offered through the school of Business.

And APL was taught by the department of Mathematics, to the extent that APL packages were used in the statistics classes.

Computer science classes weren't about teaching programming languages (we probably went through a dozen or more, from Algol and assembler to Lisp and Simula and Snobol -- we were expected to learn them ourselves depending on the assignment), but about how to think about programming (and operating systems and so on).

Re:Nope

[phantomfive]

The desktops with native java CPUs never happened.

ARM now makes chips with instructions designed specifically for running a VM (like the JVM, it even calls them the Java extensions). I don't know if Intel has any plan for that kind of thing.

Re:Nope

[BitZtream]

No, they don't. They stopped a while back because no one cared. They tried making some instructions for generic JVM like environments after that, but those too have been deprecated.

ARMv6 added support, but ARMv8 removes support for any JIT VM instructions with the removal of ThumbEE.

That was 3 years ago.

Re:Nope

[BitZtream]

ActiveX has no sandbox and no security issues. No more than a DLL does.

ActiveX is nothing more than a method for a DLL to self describe its functionality to an application that loads it.

Your statement shows you have no idea what ActiveX is or what problems existed RELATED TO (not caused by) ActiveX.

The 'security' issues you are referring to are the result of programmers blindly downloading and loading any ActiveX on the Internet. This is no different than blindly downloading and executing EXEs and its not a flaw with EXEs or ActiveX, its a flaw with the application that is downloading and loading/executing them.

At no point was there a 'sandbox' for ActiveX. Its not part of the design and never was. It was expected that they would be used intelligently, but no one on the IE team was intelligent.

Internet Explorer was broken, not ActiveX.

Please learn WTF you are talking about before continuing to spew this ignorance. Its been 18 years since this ignorance started, you'd think by now you guys would have a clue.

Re:Nope

[Rinikusu]

I thought Java was designed for ease of programming set top boxes and consumer electronics?

Re:Nope

[CauseBy]

Only if you mean "portable if the only thing I have is a binary".

No, also for the development. My company is writing a major piece of new software in Java. All the programmers have Macs although the deployment environments will be mostly Linux and Windows.

But even if not, "portable if I only have a binary" is incredibly valuable because that describes a lot of situations.

Re:Nope

[Pseudonym]

Almost. It was designed for running untrusted code delivered via the network to set top boxes and consumer electronics. There are many things that can be said about this, and how well it translated into the world of the web, but consider what Java gave us.

The JVM is a clean bytecode virtual machine, which can be implemented in hardware and reasonably compiled to native machine code. An implementation can statically verify that the code will not misbehave in certain ways. It scales on platforms varying in size from a 1990s-era smart card to a modern cluster.

It gave us the first garbage collected language that the commercial world could handle. It gave us the first programming language which the open source world took seriously and wasn't C. It sparked a new world of research into previously neglected areas, such as JIT compilation, concurrent garbage collection, and so on. It gave us the notion of an "app" and an idea of apps could achieve in the Internet era.

Java may never have been cool, but it deserves an honoured place in the history of computer science and software engineering.

Re:Nope

[sjames]

In the beginning, Netscape wanted both Java and Javascript in the browser. Javascript was to be the VB of the browser programming world with Java for professional programmers to do the heavy lifting.

The Java side rapidly got the reputation for being slow, crashy, resource hogging, and way too sensitive to sub-minor version differences so it was largely ignored.

Javascript, OTOH was eagerly embraced, first by web designers wanting cutsie special effects and minor amusements and then for more serious pursuits. Then came AJAX..

J2ME could have worked but in the fast moving web world, it was a day late to the party. By the time it came out and demonstrated that it wasn't a lumbering resource hog, the ship had sailed. Javascript was everywhere.

Re:Nope

[TheRaven64]

Wow, that's a pretty old article. ARM9 was introduced in 1997 and pretty much dead for a good 5 or so years. The Jazelle extensions (no, they're not called 'Java extensions', they're called Jazelle DBX) added a decoder alongside the ARM decoder that would execute simple Java instructions natively and trap to the JVM for more complex ones. They were pretty nice for their target (i.e. machines with 2MB or so of RAM) but were surpassed quite a while ago by JIT compilers, for several reasons:

• The JVM is stack-based, so it's hard to get any ILP out of a superscalar core and it's even hard to identify hazard-free pairs for a simple in-order pipelined core, so you don't end up packing the pipeline very well.
• The javac output is not very well optimised, because it's intended to be consumed by something else that will optimise and doing the optimisation in the front end can hide opportunities later.
• Run-time optimisations (trace-based adaptive recompilation) techniques improved a lot

Once ARM devices wanting to run Java had 32-64MB of RAM, you could get better performance with an optimising JIT compiler than with Jazelle and it died. More recent chips have Jazelle RCT (also known as Thumb-2EE) which has some extra instructions for fast bounds checking and so on, but even that isn't used much.

Re:Nope

[TheRaven64]

The JVM is a clean bytecode virtual machine, which can be implemented in hardware and reasonably compiled to native machine code.

Only one of those is really true. You can implement a stack-based ISA in hardware, but there's a reason that most of the companies that tried it went out of business in the '80s: stack-based ISAs are really hard to get any ILP from and so once pipelining became common they started to be noticeably slower and were completely killed by superscalar register-based architectures.

Re:Nope

[phantomfive]

Wow, that's a pretty old article.

Yeah, sorry, I didn't realize it when I posted it. I call it Java extensions because when you look at /proc/cpuinfo, they are named JAVA. Mainly intended to be used with Dalvik (or ART, I guess) so javac isn't relevant there.

Re: Nope

[Toshito]

I don't know where you learned COBOL, but passing parameters by reference is not only possible but also very easy... you just add "BY REFERENCE" after the parameter...

You can pass by value, by reference, by content, and also you can pass the address of the parameter.

Re:Nope

[flargleblarg]

[...] Java was only sold as a silver bullet for portability, not speed, not efficiency, not scalability, but solely for it's ability to be shifted from one vendor's platform to another's.

Your memory is partially correct. What it was actually touted as was:

“Java: A simple, object-oriented, network-savvy, interpreted, robust, secure, architecture neutral, portable, high-performance, multithreaded, dynamic language.”

Re:Nope

[flargleblarg]

[...] It gave us the notion of an "app" and an idea of apps could achieve in the Internet era.

Applet actually.
The notion of an "app" didn't come until 2008 with the iPhone.

Re:Nope

[TheRaven64]

The only thing ARM ships that might speed up Dalvik is Thumb-2EE (a.k.a. Jazelle RCT), which neither Dalvik nor ART actually use. No idea what your /proc/cpuinfo is talking about.

Re:Nope

[phantomfive]

'adb shell cat /proc/cpuinfo' will give you lots of info about the cpu, one of the features being listed there as JAVA

Re:Nope

[TheRaven64]

It's probably the ultra-restricted version of Jazelle that is part of ARMv7 - it supports the branch to Jazelle mode instruction, but throws a trap when it is encountered so that it can be emulated by a JIT compiler.

Re:Nope

[Pseudonym]

You can implement a stack-based ISA in hardware, but there's a reason that most of the companies that tried it went out of business [...]

You mean like Intersil, Sun, and Atmel?

[...] stack-based ISAs are really hard to get any ILP from and so once pipelining became common they started to be noticeably slower and were completely killed by superscalar register-based architectures.

There still exist applications where CPI is a far less important metric than power usage. If you have a car with a remote keyless entry system, for example, chances are good that the remote control's CPU is a stack machine.

Nope

[Mashiki]

Still not cool, it's about as "cool" as activex with all of the broken sandbox and security issues though.

What's the point?

[jeff4747]

The problem is what's the point of Java?

If speed is absolutely critical, you're going to go with C/C++/ASM/whatever native-compiled-language works well for your problem.

If speed is not absolutely critical, there's plenty of "scripting" languages that get the job done more easily with less code. And if you're talking about something cloud-based, you can probably handle the lower speed of these options by adding another server node.

Java seems to be in the middle ground where it's more cumbersome than the "scripting" options, yet slower than the "native" options. Leaving not much of a reason to choose it in the vast majority of cases.

Java just doesn't seem to have much a a role today beyond "Google decided to use it for Android apps".

Re:What's the point?

[makq]

The cool kids may not like it, but they can thank Java or more specifically the JVM for Scala.

Re:What's the point?

[Lennie]

Well, there is a whole lot of Java in the enterprise and other organisations like banks.

Obviously they are always last to move, because they have a lot of legacy applications anyway.

Re:What's the point?

[jeff4747]

And we can thank C for the kernel. Doesn't mean we have to choose C for new development.

Re: What's the point?

[bugnuts]

The point was to provide a sandbox, among other things. That freed up a lot of issues with security (although we know how that story ended) and issues with operating systems.

Re:What's the point?

[MythMoth]

It's a compromise language. Compromises are, in fact, a good thing but purists hate them. Of course. That's what purism *is*. But really, who cares if it's cool? We're geeks, I thought we were supposed to be opposed to "cool" anyway?

It's a known quantity and before you dismiss it you should consider the truly vast amount of software that's been successfully implemented in Java.

Personally I like it. It has it's niggles (if I were king I'd change oh so many things) but it keeps on succeeding like most good compromises.

Re:What's the point?

[lucm]

Who says you are a cool kid?

Re:What's the point?

[Giant Electronic Bra]

The alternative view is that it is fast enough to do the things that need to be fast and cleaner than all those scripting languages.

Here's the thing. Java applications are VERY EFFICIENT. It may be difficult (not impossible but a pain in the ass) to write Java code which performs a specific task in a deterministic period of time. In other words it is not really a real-time sort of thing. OTOH if you want a perform a large number of operations with maximum overall throughput and a fairly stable task completion time then you cannot beat Java. You could do it in C/C++, but you'll spend a lot more time and effort to get the same results. 10 years I coded large high capacity high speed feed handlers in Java and people said I was crazy, but that application continues to exist and outperform anything that tries to rival it while being highly portable, scalable, and superbly reliable.

The thing with scripting languages is they are for small projects. Sure, its MUCH easier to whip out a perl script or something to do a small job. Its faster at run-time as well, but as soon as that task grows to somewhere in the 5-20k lines of code range you simply cannot do it using a scripting language anymore and stay sane. Inconsistencies creep in, problems pile up, the code starts to have to be used and understood by many people, and its just not possible to maintain the level of determinism required of a large code base. At this point you NEED something like Java.

And yes, C# is a perfectly nice language, but it is only really usable on Windows in any consistent fashion. I see no reason to be limited to that platform. Most of my customers are perfectly comfortable with *nix systems and for high reliability high capacity line-of-business applications no version of windows holds a candle to RHEL and isn't even on the same planet with Solaris.

Re:What's the point?

[wispoftow]

Because *some **people ***are &sick and *(&tired) **of *all &of ***the ****bullshit &that **goes &with writing C and C++ in order to get an order of magnitude performance increase over those dynamic languages that you allude to.

Re:What's the point?

[mlw4428]

"The problem is what's the point of Java?"

The problem being solved isn't speed. Most of the scripting languages of yesteryear were very limited or restricted to specific platforms. The problem being solved is cross-platform development.

Re:What's the point?

[bill_mcgonigle]

If speed is absolutely critical, you're going to go with C/C++/ASM/whatever native-compiled-language works well for your problem.

If speed is not absolutely critical, there's plenty of "scripting" languages that get the job done more easily with less code.

Yeah, this is how most 2+-sigma programmers on the right side of the standard distribution of programmers approach problems.

All the rest (the vast majority) need languages with good error messages, good error landing, decent garbage collection, a lack of value/reference handling, etc., and frankly being more procedural than functional is an asset to a below-average programmer.

Code density is not the criterion most mid-level enterprise IT managers need to deal with. Even with a complex project and a team, you can take one guy and have him write the JNI bits in C++ for performance (BTDTGTTS) while the rest of the team handles other parts and they don't have to know as much. It's actually really bad economics to have all top-notch programmers on your team if your project does not require that.

And before all you kids who got trophies for losing a soccer game get into a snit - by mathematical definition, half of all programmers are below-average.

And Java works pretty well for them, and there are stable and scalable deployment platforms for their code. Expect the "cool kids" to be wondering about Java in 2024 - even if there were a better replacement available today (there isn't), the extant code bases would not get replaced in one decade.

Re:What's the point?

[Kagato]

I think that's a pretty dated view of Java. If I'm writing a web service endpoint most of the heavy lifting happens with some very simple method/class @Annotations. My controller classes tend to be in the tens of lines, not hundreds of lines.

The days of writing a some inordinately overthought out factory pattern are long gone for a lot of stuff and the JVM does all sorts of optimizations to make the performance gap between VM and Native pretty small.

Re:What's the point?

[fnj]

Why won't anyone just SAY it? Python. It's clear he meant python. Sure as hell not perl or awk.

Re:What's the point?

[msobkow]

The "point" of Java is portability amongst vendors. It was never designed to be the fastest, most scalable, or most elegant language on the planet. It was designed to be portable.

And it succeeds at that goal, for the most part, so it is and continues to be used widely.

Don't confuse the extensions of the JEE environment or the various JCP packages with the core of Java's mission: running business code across diverse platforms.

Or have you forgotten Java's original tag line? "The Network IS The Computer." And the network includes all kinds of platforms.

Re:What's the point?

[fnj]

Java cleaner than python? Tell me you're kidding.

Re:What's the point?

[DoofusOfDeath]

If speed is not absolutely critical, there's plenty of "scripting" languages that get the job done more easily with less code.

A big problem with duck-typed scripting languages, such as Python, is that the absence of explicitly stated type requirements in the source code. Using types in function signatures and variable declarations is an extremely useful tool for developers to indicate not only how a system is decomposed, but also what potential future usages they intend to support vs. not support.

I've worked on reasonably large Python, C++, and Java projects. The Python code was by far the hardest to make sense of due to the duck typing and other Python idioms (metaclass, i.e. self-modifying code).

Re:What's the point?

[Anonymous Coward]

Advantages of Java:
- It comes with a lot of classes that can be used. E.g. string manipulation is much more pleasant than what it is with C++ (sorry, I don't know about the new C++ versions, perhaps situation has improved). Creating threads is also on a different level. And exceptions are very useful. When I started learning Java, I didn't understand unchecked vs. checked exceptions so I hated the exceptions at first.
- JUnit. I have never met a language where unit testing is as simple as it is with Java + Eclipse.
- Maven. Yeah, I know all the trouble it gives, but still, would you rather compile your own dependencies like you do in C++ Windows, or just execute the maven and get everything downloaded for you?
- Static analysis. There are many tools for C++ and other languages, but for some reason I think that e.g. Findbugs is ahead of them.
- Refactoring tools in Eclipse. I have never seen anything coming even close. I can cut and paste to create new classes, I can highlight code to create a method, I can rename anything. I can find a class with its name. I can automatically fix imports (hello C++). etc.
- It is fast enough for almost anything that runs on PC.
- It is cross platform.

Disadvantages:
- It is slow to start (if it wouldn't be, I would replace even Python with it)
- Oracle
- Memory allocation is too difficult. It would be nice if you could just write to the start of the application "allocate 2 GB of memory for the JVM", but this is not possible for the obvious reasons (I know there are work-a-rounds, but that doesn't make it easy)
- There is a lot of deprecated luggage in Java, e.g. classes and methods that should not be used, but are still there for backward compatibility.

I have used quite many different languages since the age of C64, but Java is the language I enjoy using the most. Especially with Eclipse. Not because Eclipse starts so fast or because it is so bug free, but because Refactoring tools, debugging tools, everything that makes my work more easy.

Re:What's the point?

[jader3rd]

Java seems to be in the middle ground where it's more cumbersome than the "scripting" options, yet slower than the "native" options. Leaving not much of a reason to choose it in the vast majority of cases.

Compile time type checking is a major reason to pick Java over a scripted language. It's not like performance requirements are binary either. There's a lot of distance between optimized assembly and runtime type checking scripts.

Re:What's the point?

[TFlan91]

I disagree, Nodejs has done a tremendously good job on being easy to use for all ranges of expertise.

Re:What's the point?

[fnj]

by mathematical definition, half of all programmers are below-average

Come on, elementary math. That's not true. Half of all programmers are below MEDIAN. If you don't care enough to get THAT right, I'm not going to bother with the rest of your assertions.

Re:What's the point?

[drolli]

The point of java is that you can program more devices on this planet in this language than with anything else.

Java has penetrated all areas of computing, from embedded (down to chipcards) to mobile, from science to database and web servers.

Java has inherent cross-platform mechanisms for elementary things for which c does not have these (treads), and there are (most of the time free) libraries inferfacing in all directions.

Dynamic, standardized binding to databases and XML makes it extremely easy to persist you data in a well-documented and well-tested structured way.

Java has nearly all language features you could desire.

And last but not least: eclipse is a great free IDE. AMong the free IDEs there is IMHO no combination of language+language tools which boots your productivity for specific tasks as eclipse does.

Re:What's the point?

[toejam13]

Both Java and C# are nice in that they give you more power than many scripting languages, while obscuring some of the headaches (read: pointers) that come with lower-level languages like C. Both are [IMHO] also cleaner implementations of an object-oriented language than C++.

Another benefit of Java and C# are in their standard libraries. They're a bit more refined and a lot more consistent than the standard libC library. There has been a huge amount of drift in the libC world since wchars, long longs and safer array handling functions have been adopted. When writing portable C code for both Visual C and Klang, I'm constantly having to write wrapper code that deals with missing, renamed or depreciated functions on either the Windows or BSD side.

Lastly, if your Java or C# apps are speed sensitive, you just do the same thing that people have been doing with C and C++ for years: run your code through a profiler and then write your time critical code in a lower-level language that you call as an external procedure. I haven't written a large app entirely in ASM since my Amiga days (even then, it wasn't the norm).

When learning a new language, students shouldn't have to worry about if Getopt() is a valid function or not. Save that for a more advanced class. With Java, you can assign homework and know that students with Windows, Linux, BSD or MacOS will have the same environment. And in the real world, Java and C# eliminate some of the hassles of the C and ASM worlds, while still allowing you to reach back using external calls when needed. I really do find myself programming in C and C++ less and less every year.

Re:What's the point?

[narcc]

Yeah, I'll agree with that. I think you're simply too dazzled by the "coolness" of python to see it's many, many, terrible warts.

Re:What's the point?

[jonathan_ingram]

As you have only been introduced to elementary math(s), you may not be aware that median is also an average. Half of programmers *are* below average using one of the three usual rivals for 'average'. It would be hard to use mean, as it's not clear that you could find a rating system for which using mean would make sense.

Of course, it's not clear that there is any sensible numeric rating scale for programmers, and it would be interesting to argue about what the modal average would be, but it's just a throwaway comment which doesn't need to be analysed in such depth. The meaning and sense of the comment is clear.

If you are going to play the role of overly pedantic nerd, at least do it correctly so you don't get laughed at.

Re:What's the point?

[Euler]

Or visual basic

Re:What's the point?

[buddyglass]

He may have assumed the normal distribution.

Re:What's the point?

[bill_mcgonigle]

He may have assumed the normal distribution.

It's OK - the poor guy has obviously never been exposed to elementary statistics or he would have recognized what a sigma refers to. I do think it's fair to assume a certain base level of education on Slashdot - it is a nerd site after all. But what a great example of the Dunning-Kruger effect in action!

Re: What's the point?

[bugnuts]

A counterexample would be skill levels (3,1,3,3,7) with a median of 3 and mean above 3. In neither of those definitions are half below average, being 1 or 2, and 4.

Simple math would say at least half would be less than or equal to the median.

Of course, simple math rarely works here to quantify except at the extremes. People have different abilities in different areas, and gray matter is plastic. It changes, and even that rate of change matters.

Re:What's the point?

[Anonymous Coward]

What do you mean by "cross-platform"? Java isn't available on iOS, it isn't really available on Android, OSX comes (used to come?) with outdated versions where a lot of Java programs don't run properly, Linux comes with OpenJDK which doesn't run quite a lot of Java programs either (try using the typical Java-based VPN solutions for example).
It's "cross platform" only if your definition is "it's a huge pain and doesn't work properly on any platform without extensive workarounds", which is a step below e.g. C++ with Qt source code (empasis on source code though).

Re:What's the point?

[buddyglass]

You could meaningfully refer to "2+ sigma" developers without assuming a normal distribution, though. So his criticism is "sort of" valid given you never explicitly stated you were talking about a normal distribution. Maybe the distribution of of ability among developers is skewed right, in which case more than half of them are "below average".

Re:What's the point?

[sjames]

Perl is best kept to small projects. Not too surprising, it was meant to be a report generator.

However, there's no good reason not to use Python for a large project. It is not at all hard to write clean and well documented Python. It is, of course possible to write a complete mess as well but that's true of any language.

Re:What's the point?

[Aighearach]

They used COBOL until they were talked into porting to Java, it is a hard sell to convince them they need to change languages again. Every language they ever used sucked, and they used what the Experts told them to use.

Re:What's the point?

[Euler]

Mean == average (sum of samples / number of samples)
Median == 50th percentile within the set of samples.
Mean != median (unless by chance the distribution is symmetrical.)

When an even number of samples exists, the common practice is to find the median between the two central samples by averaging the two. But that does not imply an average of the whole data set.

Re:What's the point?

[Aighearach]

Well, Ruby is a "scripting language" but then it turns out that you can implement everything in plain C libraries, and just put the business rules in the "scripting" language. And in fact that is how problems are approached. There is no need to switch languages for the project, you can switch languages on a modular basis, as long as the core application language is dynamic and can interface easily with the parts.

"Scripting" can mean "scripting" or it can mean "glue," or just "dynamic."

IMO there are real advantages to having the more static parts in C, and the more dynamic parts in Ruby/Python/Perl/whatever. Though some languages you need an extra glue language to glue the C in, that is why I don't use Perl.

Re:What's the point?

[Aighearach]

Java cleaner than python? Tell me you're kidding.

It is meaningless to argue that one unless you attempt to define "clean," and then both sides will turn out to be using different meanings. Using his meaning of clean you'd probably be forced to agree with him; and using yours, he would likely agree with you.

Is boilerplate dirty, is it cruft, or is it O(1) stuff that isn't even counted and is effectively free? That is the real underlying issue. If boilerplate is cruft, then Java isn't clean. If boilerplate is free and to be ignored, then Java is still verbose, but clean.

Most people who ignore boilerplate probably are using tools that write most of it for them anyways, which brings in its own issues and differences of opinion.

Of course he totally ignores the possibility of using efficient methodologies to write large codebases using "scripting" languages. It certainly can and is done. But you can't hire Dilberts to do it, the way you can with Java. If you're planning to be undisciplined except for the what the language forces you into, then he's right.

Re:What's the point?

[Aighearach]

You cite the advantage of duck-typing as its problem, that tells me you just don't understand the use cases.

Duck typing, done correctly, does not simply give up having defined interfaces, that would be silly. So silly that it would make your criticisms true!

In duck typing, you check if an object has the parts of an interface that you're going to use, instead of checking if it is some named type that presumably has the interface you want to use. The different parts of an interface that go together are also grouped together in code. Just as using static types is a useful tool that tells you how a system is decomposed and what behaviors are likely to be supported, the lines that include the packages of duck-typed behaviors also tell you the exact same thing.

Just because you're not forced to only have pre-defined interfaces does not mean you are prevented from actually defining your interfaces in advance, and using that information in your tools. In fact, fans of duck typing often feel that it enhances this ability, by being able to combine defined interfaces more freely.

Re:What's the point?

[theshowmecanuck]

Netbeans is better. It does all that out of the box, without needing so many plugins. [ducks and waits for the fallout]

Re:What's the point?

[photonic]

There is currently an enormous discussion going on at python-ideas (see various large threads towards the bottom). Guido himself seems to be in favor of including something like MyPy into Python's standard library, which is allows for optional specification of arguments and return types using function annotation. The main use would be for static/offline code analysis/linting.

Re:What's the point?

[Giant Electronic Bra]

Yeah, sorry, I maintain LARGE complex code bases. There's zero chance that's going to be easier using a loosely typed language with porous ideas of module boundaries, etc. I've been there, and a well-architected system built with a classic OO language like Java is just a lot more manageable. Also a lot of the advantages in brevity of things like Python or Perl evaporate when you try to apply some sanity to their use, but the disadvantages are still there to bite you. A 500 line Perl script is undoubtedly a LOT more compact and succinct than some java app built to do the same thing, which will be 2-3 thousand lines long probably. But when you start building well-designed class hierarchies in Perl? You're code will rapidly become just as large and verbose as its Java counterpart. Python and Ruby aren't better, in fact no scripting language will improve on this because all that stuff is NEEDED at scale. I'm an exceedingly accomplished Perl programmer and I can certainly code in other 'P languages' perfectly well, but they aren't the same thing. Each tool to its place.

Re:What's the point?

[bruce_the_loon]

You've got a dangling pointer in there. Just one. I'll leave you to find it before it dumps the stack via the VGA IO space.

Re:What's the point?

[Giant Electronic Bra]

I've written a lot of code in the 'P languages' and I don't really believe that anymore. A 15k python app might be perfectly fine, but loose typing and the lack of a standard error handling strategy bite you in the end. I don't actually think that Perl is any weaker here than Python. You may be more familiar with one and comfortable with it, but I've written some pretty large programs in Perl. It HAS the tools, and I'm not the only one. Ruby is probably the cleanest of this sort of languages, but its still things like loose typing and the attendant inability to enforce calling semantics that hurts in all cases the most. When I write Java I know that if I call a method I have the right type of arguments at least, and that if somehow I manage to partially subvert that with reflection or whatnot that my error will be quickly outed by the run time. In dynamic languages you really don't know what the data is supposed to be until something goes wrong. Mostly though you lack the ability to have your IDE vet everything, you can't do static validation, etc. On big projects things like code validation, test coverage, etc are big deals, as is code GENERATION for that matter. All of these things are vastly better supported and easier to do in a statically typed language like Java.

Re:What's the point?

[sjames]

Duck typing is a mixed bag. You can make the requirements clearer in comments and the doc string. It also has great advantages in being more concerned with attributes than declared type or lineage. It allows modules to deal with classes that weren't even imagined when they were written.

Re:What's the point?

[DoofusOfDeath]

Duck typing is a mixed bag. You can make the requirements clearer in comments and the doc string. It also has great advantages in being more concerned with attributes than declared type or lineage. It allows modules to deal with classes that weren't even imagined when they were written.

The problem is that by an large, code can't be automatically checked against doc strings. (If it could be, then you'd just have a classic type system again.)

As far as supporting unplanned extensibility, it seems to me that interfaces (or pure virtual base classes in the case of C++) provide that functionality in more statically typed languages, so I don't see that as an advantage peculiar to duck-typing.

Re:What's the point?

[tomhath]

There's zero chance that's going to be easier using a loosely typed language with porous ideas of module boundaries

Nonsense. The typical Java project is a big steaming mess of factory classes, wired beans, annotations, aspects, xml, and all the other workarounds that are needed to give the same functionality that's built into dynamically typed languages. And you still get logs overflowing with run time exceptions.

Re:What's the point?

[JoeMerchant]

Gotta throw my perennial plug in for Qt/C++ for portability. As long as your target is desktop only, Qt is super portable, mature, and relatively complete.

Yes, they are just starting to get into serious mobile support, and I notice a lot of the "completeness" suffering as this transition takes place (old libs like QFtp are now "an exercise for the programmer" to port and include in Qt5 based projects.)

We had a Qt vs Python vs VB/Excel contest once - effort was roughly similar between the three to really do the job at hand, VB only won because the start and end point for the data was in Excel. The thing I find about most language comparisons comes down to "where is it socially acceptable to cut corners?" The scripting languages are very oriented toward the quick and dirty, zero error checking, zero declaration, zero structure programming - and if that's what you want, great. C++ enforces declarations and type checking on you - which, if you're doing anything of size, you actually do want. By the time you beef up a Python script to handle the edge and error cases and do all the stuff that the C++ program is probably doing at default level, then the Python isn't so quick or slick anymore.

Re:What's the point?

[JoeMerchant]

What would slashdot be without arguments over semantics?

A hell of a lot smaller.

Re:What's the point?

[Giant Electronic Bra]

LOL, I don't know what sort of disasterously bad Java shop you work for... I've got a VERY large Java code base. We use a number of the tools you mention and they are quite powerful and useful. There's nothing in the 'steaming mass' category about it. Perhaps you need some new developers! OTOH The last big project I did with a dynamic language became hideously complicated with constant undocumented dependency issues and bizarre almost untraceable bugs that it was finally just literally delivered by the prime contractor as it was. Luckily the whole issue became largely moot as external forces cut the project back. It IS still in use, 7 years later, but if I were to do that sort of project today I wouldn't even consider a dynamic language. Not with the schema complexity and other aspects of it as it was. Java has a vastly more powerful infrastructure for dealing with complex data for one thing.

Re:What's the point?

[gbjbaanb]

which is, ironically, exactly how Java got to be so popular in the first place.

Re:What's the point?

[sjames]

Virtual base classes are VERY limited in comparison.

Unless calling functions when you don't know what they are has become common practice these days, why do you need the IDE to tell you what the docstring says. If you program with the assumption that whatever the IDE doesn't reject is permitted, bad things will happen.

Re:What's the point?

[Giant Electronic Bra]

Yeah, I'm a fan of QT, always have been. I haven't done a lot of C++ stuff in many years (it predates even QT1 if you can believe that). Our Java stuff in general doesn't have a desktop UI with a couple minor exceptions, so for my particular use case Java makes sense. I think in general C++ can often replace Java, but it CAN be a lot of work. Our apps are very long running stuff that churns through vast amounts of data constantly and requires high reliability. So if we do something in C++ then there's an added 50% "C++ Tax" just to find the 500,000 memory leaks and such. In GUI apps they don't matter much unless their really serious, but in my line of work if you loose 4 bytes per UDP datagram you'll be out of 32 gigs of RAM in a pretty short time! And each one of those suckers runs through probably 20-30k LOC worth of logic, so there's a lot of chances for fuck ups.

Re:What's the point?

[narcc]

An allergic reaction to good languages?

Not at all. We're talking about Python here.

Re:What's the point?

[sandertje]

I have to agree with him, and I use Python on a daily basis. When using Python for anything larger than a few thousand lines of code, it really becomes necessary to switch to something more, well, stable. There's several options, and Java is one of them. When you start typing assert statements everywhere, that kinda defeats the purpose of using a dynamically typed language, and tells you it's time to switch to something more robust to begin with.

That doesn't mean Python is a bad language. I, in fact, love it. But it's not suitable for every use case. Just like Java ain't. Using the correct tools for the job is a better paradigm than sticking to your favorite language just because.

Re:What's the point?

[RabidReindeer]

The problem is what's the point of Java?

If speed is absolutely critical, you're going to go with C/C++/ASM/whatever native-compiled-language works well for your problem.

The 1980's called and they want their outdated assertions back.

One thing that Java does that "native-compiled" languages do not is provide an environment where code performance can be monitored and optimized automatically on the fly.

An example: Back when instructions typically took a determinate number of CPU cycles, a conditional branch instruction might take 2 cycles for no-branch and 3 cycles for a branch. If you were clever, you coded for the case where the no-branch result was the default. But if you guessed wrong or conditions changed, you were stuck with the "wrong" code and thus sub-optimal. A good JVM can sense that and rewite the code, flipping the branch to the more optimal state.

A JVM is no light thing to crank up and operate, so you cannot expect benefits from small simple programs. But as apps get bigger, more complex, and longer-running, the balance changes. It's prohibitively expensive to re-optimize a complex system by hand, but doing so automatically can be much cheaper as you scale up. The same sort of result improvements have been benchmarked between brute-force manual SQL and ORM systems.

Yes, Java is cumbersome. I don't use it for quick-and-dirty stuff. I do use it for industrial-grade work where robustness, security, and scalability are important, especially since there is an extremely rich add-on and support environment for it.

And, of course, for Android, since Android is optimized to run Java.

Scripting languages are my bane. As I mentioned elsewhere, they make you look more productive than you are. And they're almost universally terrible at preventing many common errors that a more rigorous (a/k/a/ less "productive") language can easily detect before they infect something critical.

But, speaking of outdated assertions, a lot of scripting languages also compile to machine code these days. And when not, often to something quite close to it.

Re:What's the point?

[putaro]

OK, that's bullshit.

Re:What's the point?

[RightwingNutjob]

Exactly. Java programs aren't multiplatform. They're single platform: the JDK/JVM that you compiled with/for. If you're done everything on Sun Java 1.5, and suddenly Oracle changes it to "Oracle Java" 1.6, you're SOL.

Re:What's the point?

[BitZtream]

Doesn't mean we have to choose C for new development.

Yet its still done, often, for reasons that are obvious if you've got a clue and the right requirements.

Re:What's the point?

[Wootery]

It has it's niggles (if I were king I'd change oh so many things)

You're not the only one.

Re:What's the point?

[putaro]

The question is, who is "you" and when does that checking happen? I don't do a lot of work in Python, Ruby, etc. and all of the programmers that I know who do are fairly young and working on fairly small projects so they don't have a good answer for refactoring.

If I change the arguments to a method in a statically type language any place where I forgot to change the call to that method will be exposed at compile time. As far as I've been able to learn so far, in most dynamically typed languages that check won't happen until runtime. The pat answer to that is "you should have unit tests that cover everything" - but getting complete code coverage is hard and for large projects, the test suite takes a non-trivial amount of time to run - usually much, much longer than compile time. So, you wind up with bugs at runtime. Or is there a better solution?

Re:What's the point?

[CauseBy]

I like C# a lot. I wish people used it outside of Windows. Alas. I'll retire happy if I never touch Windows again, so C# is dead to me.

Re:What's the point?

[Actually, I do RTFA]

Duck typing is a mixed bag.

Curious, let's see how.

You can make the requirements clearer in comments and the doc string.

I suppose that's the admitted disadvantage? That I can type more to have limitations enforced by humans instead of machines.

t also has great advantages in being more concerned with attributes than declared type or lineage. It allows modules to deal with classes that weren't even imagined when they were written.

You mean like interfaces would let you do?

Re:What's the point?

[Bill Dog]

Heh, so Java itself is multi-platform, because each version of it is its own platform! ;)

Re:What's the point?

[Jeremi]

So if we do something in C++ then there's an added 50% "C++ Tax" just to find the 500,000 memory leaks and such.

Just wanted to say that if you are careful to use a smart-pointer class (e.g. shared_ptr) rather than raw C-style pointers to hold dynamically allocated objects, 99% of your memory leaks (and other object-lifetime-managment related problems) will "magically" go away -- and without the overhead or random execution-pauses seen in languages that rely on a garbage collector.

Re:What's the point?

[sjames]

Actually, no, they work much better. I can pass the latest whizz-bang object that just happens to have the right attributes in to the old library code and get it back out the other side without having it cast to a crippled shadow of its former self.

As for the typing, if your project is big enough that you're actuallu worried about any of these issues, you should be properly documenting everything anyway.

Re:What's the point?

[sjames]

And Python was meant to be used to teach people how to program. Both languages' capabilities have grown far beyond what they were meant to be.

Actually Python was meant to be a general purpose scripting language for Amoeba. It was not a teaching language.

Many things in the computer world end up used in ways that were never envisioned, and that's good. My comment on Perl was mostly one of fairness. It is certainly used beyond it's original purpose, but it isn't fair to blame it for any difficulties that may entail.

Re:What's the point?

[julesh]

The typical Java project is a big steaming mess of factory classes, wired beans, annotations, aspects, xml, and all the other workarounds that are needed to give the same functionality that's built into dynamically typed languages.

OK, I'll bite. What built-in feature of ... let's say python ... allows you to replace the functionality of a factory class without needing to implement something that either is a factory class or is very similar to one?

Re:What's the point?

[julesh]

Java isn't available on iOS

Yes, it is.

it isn't really available on Android

Bullshit. Android's implementation may not be completely up-to-date, but it is absolutely a version of Java. Only trademark and licensing issues prevent Google from claiming that it is.

OSX comes (used to come?) with outdated versions where a lot of Java programs don't run properly

Who cares what version is installed by default? OSX can be upgraded to the latest version, and any application that needs it ought to provide an installation package that does precisely that, or at least clear instructions to the user on how to do it.

Linux comes with OpenJDK which doesn't run quite a lot of Java programs either

As of version 8, OpenJDK is the reference implementation. Any Java program that doesn't run on OpenJDK is not a conforming pure Java application. Besides, it is perfectly possible to install Oracle Java on a Linux system if you prefer it. Depending on your distribution, it may be as simple as a single command, or you may need to add an update source first (which turns it into 3 commands on Ubuntu, for instance).

It's "cross platform" only if your definition is "it's a huge pain and doesn't work properly on any platform without extensive workarounds"

I'd hardly call any of these "extensive workarounds". Yes, you may have to refrain from using the latest APIs if you want to target certain platforms. Or you may have to have the end user install an upgrade to their preinstalled Java system. Neither of these is actually that hard.

Re:What's the point?

[julesh]

If you're done everything on Sun Java 1.5, and suddenly Oracle changes it to "Oracle Java" 1.6, you're SOL.

??? I've been writing Java applications since 1.1 was the current version, and I've never had one stop working with a version update.

The only experience I've had with such failures are 3rd party applications where the developer has used the deprecated com.sun.* APIs. The guidelines on using these have been quite clear from the very beginning, though: don't, unless you want to create compatibility problems for your users.

Re:What's the point?

[dgatwood]

I've got a VERY large Java code base. We use a number of the tools you mention and they are quite powerful and useful.

Yes, and I have some relatively large Perl scripts that are readable and maintainable. These are the exceptions that prove the rule.... :-)

Re:What's the point?

[julesh]

Of course, it's not clear that there is any sensible numeric rating scale for programmers, and it would be interesting to argue about what the modal average would be

Or even, indeed, that there exists a total ordering, the lack of which would make the notion of a median meaningless, too.

Re:What's the point?

[dgatwood]

My biggest problem with Qt is the same as my biggest problem with Java. It's okay for in-house test tools, but it should never be used for actual end-user apps. You'll invariably end up with an application that doesn't quite behave like a native app, doesn't perform as well as a native app, and can't take advantage of advanced features of each OS without losing portability. In short, cross-platform apps written in this way almost invariably take advantage of only the least-common-denominator functionality common to all OSes, resulting in an app that sucks equally everywhere.

There's only one right way to create a cross-platform application: by separating the core logic from the UI, and then hiring people who actually know how to write software for each target OS to designing a custom UI that conforms to the way that users on that particular platform expect an app to behave. Anything less will always be substandard on one platform at best, and on all platforms at worst.

Now you could write that core logic in Java if you really want to (though you'll run into portability problems if anybody ever asks for an iOS port), but chances are, you're better off writing it in C or C++. Either way, using Qt or Java for the UI is IMO invariably a mistake unless you're just writing an app to meet your own personal needs.

Re:What's the point?

[julesh]

Unless calling functions when you don't know what they are has become common practice these days, why do you need the IDE to tell you what the docstring says.

Because it is well known that on any large project staffed by any but the most conscientious of developers, documentation has a tendency to become outdated. The type specified in statically-typed code, however, *cannot* be wrong.

If you program with the assumption that whatever the IDE doesn't reject is permitted, bad things will happen.

You don't program with that assumption: you program explicitly towards that goal. This is the Liskov Substitutability Principle, one of the most basic tenets of object-oriented programming: if an object of a given type is allowed in some operation, any object of any sub-type of that type should also be allowed. Code that violates this principle should be actively removed from your project whenever it is found.

Re:What's the point?

[julesh]

I can pass the latest whizz-bang object that just happens to have the right attributes in to the old library code and get it back out the other side without having it cast to a crippled shadow of its former self.

You can also pass any object that happens to have attributes that have been coincidentally named the same but don't necessarily have the same semantics, and wait for the entire system to blow up (which it may or may not do in simple test cases, depending on how closely the semantics happen to match).

In reality, I don't find that unrelated classes tend to have methods or properties that share both a name and exactly the same semantic definition except where that similarity is intentional. When it is intentional, then usually the two classes will share an explicitly defined interface. On rare occasions they do not, it is trivial to write a wrapper for the objects, and the necessity of doing so is a good prompt to think about whether the definitions are in fact exactly the same.

Re:What's the point?

[sjames]

You question the conscientiousness of the programmers in the first paragraph and assume it in the second.

You should see the crazy type casting that happens in production code to please the IDE and/or compiler. It may or may not be the right thing.

Then there's the cases where it is actually OK if not all objects passed in support all of the methods. Not Applicable might be the right outcome of a method call if the caller is prepared for that possibility.

Re:What's the point?

[sjames]

You can also cast things around until the compiler and IDE buy it and wait for the SEGV.

It's on the developer to know when they can and cannot get away with it.

If you don't KNOW if class A and Bs X methods are actually compatible, what in the hell are you doing passing them around? You're supposed to know that. If you have a case where it may or may not be true and it's all OK, wrap it in a try..except and pick up the pieces at runtime.

This would be a lot less of an issue if multiple inheritance was better supported, but it's not.If it was, I could write the module explicitly around class A. Later, given a class B that should work fine with the module, I could derive Bprime inheriting from A and B and it would be fine.

Re:What's the point?

[mcvos]

The problem is what's the point of Java?

If speed is absolutely critical, you're going to go with C/C++/ASM/whatever native-compiled-language works well for your problem.

If speed is not absolutely critical, there's plenty of "scripting" languages that get the job done more easily with less code. And if you're talking about something cloud-based, you can probably handle the lower speed of these options by adding another server node.

Java seems to be in the middle ground where it's more cumbersome than the "scripting" options, yet slower than the "native" options

It's a pretty good middle ground, though. Java is almost as fast as C++ (10% slower back in the days of Java 5, I seem to recall). If you want speed in a managed environment, Java is a pretty good choice.

Re:What's the point?

[cheekyboy]

I beg to differ, if a large solution requires say, 20 processes running, with common libs, and config files.

Yeah do it in java, you could just as easily do it in perl, code it cleanly to look like java, no corrupted files. ie no short cuts.

IF its requires 400 functions in java, then its equally possible in Perl. Doesnt have to be one file, you can make modules to do each task.

A good design will be equally good in Perl and in Java. Just about every problem is really either converting large amounts of data from A -> B. or triggering events based on rules when processing any data.

Re:What's the point?

[LordWabbit2]

Couldn't agree more - worked at a settlement and clearing company and their messaging systems where java based, every now and then they would freeze up and stop processing messages. Logs were ~500mb of text - java devs would spend hours pouring through them trying to figure out why the system was hanging on occasion, AFAIK it's still hanging.

Re:What's the point?

[drolli]

I talk about devices, you talk about microntrollers/processors.

You can not program 1B android devices in ANSI C. You can not program java smart cards in ANSI C.

Hypothetically, you could modify parts of all devices in ANSI C, but this this you essentially disassemble the device.

I agree, if you interested in firmware development, ANSI C is probably the right choice.

Re: What's the point?

[tandavanadesan]

I agree. Binary compatibility has always been 100%, and source code compatibility 99.99%. We did have some really code where someone had a variable called 'enum', the classes still ran but the variable needed to be renamed before r recompiling.

Re:What's the point?

[JoeMerchant]

One thing I have learned to love about QObjects is their family tree and how it (mostly) garbage collects for you, when you use them properly. I really like the fact that my objects clean up their entire child structure as soon as they go out of scope - without a bunch of delete code required.

But, yeah, a testing team with valgrind will usually find a bunch of (trivial) "leaks" in my code, too - I'm talking about single objects that are created once and not destroyed before exit - technically, I don't call those leaks, but valgrind does.

Re:What's the point?

[JoeMerchant]

I suppose it depends on your target market. I've written mostly for medical and military, and they never had complaints about Qt's ui. Even did a server based app with no UI, and Qt still made sense as the library because of the cross-platform requirements - lots of shared memory and other stuff is "wrapped up" and platform details handled by the library. I guess I've always been in small enough companies that "outsourcing to the trolls" was the better option - we'd never have delivered anything cross-platform if we had to hire multiple teams for implementation on each.
   

Re:What's the point?

[Wdomburg]

It also turns out you can implement everything in plain Java libraries. In fact it is a heck of a lot easier, since you don't need to wrap the C modules; everything Just Works.

Re:What's the point?

[Wdomburg]

Java has a vast ecosystem, excellent threading and concurrency support, robust monitoring and debugging tools, and can rival (or exceed) the performance of traditional compiled languages.

This is true for both small scale and large scale problems. For example, I wrote a little tool to do LDIF transforms in perl. Six hours later, it wasn't even half finished. Rewrote it using a Java library (UnboundSDK) and it finished in about twenty-five minutes.

On the other end of spectrum, I wrote a load-testing application that scaled cleanly to tens of thousands of threads. In a couple of hours. With no experience writing anything to that scale before.

(And the idea that Java is strictly Android these days is absurd. Your cable box runs Java. So does your blu-ray player. Along with ATMs, cash registers, voting machines, any number of enterprise applications, webservices, etc, etc. It is an incredibly pervasive language.)

Re:What's the point?

[TheRaven64]

Medical and military sounds like mostly Windows shops, with maybe a bit of Linux thrown in. Qt apps on OS X tend to be garbage - you can spot them within a few seconds of launch, because they look vaguely like OS X but don't behave at all like it (e.g. modal dialog boxes, incorrect shortcut keys for text field navigation, preferences that need buttons hitting to take effect, and so on).

Re:What's the point?

[TheRaven64]

You can not program 1B android devices in ANSI C.

Yes you can and most of the most-downloaded apps in Google Play use a significant amount of C (often everything except a basic launcher).

Re:What's the point?

[Assmasher]

I don't particularly care for Java primarily because it really is verbose, but the reason Java is so prevalent is that it is an excellent middleware language solution that made it possible in the late 90's and early aughts for companies that would never have managed to build these systems with C++ (just not enough C++ people who don't hang themselves and your company 5 times a day.)

You could argue that if they couldn't do it with C++ they shouldn't have been doing it anyhow, but there'd be hundreds of thousands fewer jobs in the software industry as a result.

Re:What's the point?

[JoeMerchant]

You might be surprised, my first medical app on Qt was targeted to OS-X, for a whole year, but as Director of Software Development, I chose Qt to hedge my bets against the day that OS-X got thrown under the bus for "business reasons." And, yes, especially in 2006, the Qt App was still in Carbon, while Cocoa was what all the cool Objective C kids were doing that week - and our in-house OS-X champion threw a hissy fit about it. Nobody else cared - it was a good looking app, just not quite up to the minute with latest OS-X styles.

So, two things happened by mid-2007. One, Qt updated to use Cocoa, and 95% of the OS-X champion's complaints about the app were solved for us by the trolls - zero code changes required by us. Two, the suits decided that we were merging our design efforts with a larger project that was Windows based, so OS-X did get thrown under the bus, as predicted. It took about 8 man hours to convert our Qt App from one that was written on OS-X, exclusively for OS-X, never tested on anything but OS-X, to running identically on Windows - and 7 of those man hours were wrapped up in converting OpenGL code....

I'm in medical now, and the primary target is Linux - but lots of use cases call for operation under Windows too....

Re:What's the point?

[Assmasher]

I can't use a statically typed language without being constantly pelted with reminders of their limitations. No, you can't compile that, you didn't use quite the right punctuation in the type name. Sorry, I couldn't protect you from that null pointer, even though I have decades of research and all the source code available to me. Oh, you want a type that could be one of several types? Have fun with those runtime downcasts, or null pointers, or whatever.

Personally, it sounds like you want to be as sloppy as you like... Nobody should be protecting you from null pointers except yourself.

Re:What's the point?

[Assmasher]

One of the overlooked advantages with using Java on the server/middleware side is that long running processes in real production environments often have to deal with memory fragmentation, with C++ this is often a very serious, and sometime virtually impossible situation to deal with (writing a pre-allocating memory manager is a non trivial task and you have to worry about people misusingit.) In Java (which I don't personally enjoy working in, but can appreciate), this issue is, for the most part, gone - and in those rare cases where you have to directly intervene, it is trivial to do so.

Given the skill of the average "I work at a bank building IFX/OFX software" developer, I'd rather they stuck to Java...

Re:What's the point?

[Assmasher]

This.

I've written services/daemons using Qt simply to make it easily extensible because the framework I built was multi-process with IPC and each process could be heavily multi-threaded.

Qt abstracted away a lot of things that would have made the project difficult to build on many *nix platforms.

Re:What's the point?

[drolli]

Program an App in ANSI C does not equal to programming a part of an app in ANSI C.

"most of the most-downloaded apps" is so vague that it's a non-information. My viewpoint is not "why knowing C is cool" but "that is the shortes route to delivering software to many platforms". If i would be in the business of making a "most downloaded app" then probably i could easily spent a few man-years for platform specific optimizations.

Re:What's the point?

[TheRaven64]

Actually, C is used in these cases specifically because it is cross-platform, not for 'platform-specific optimisations'. The core of most of the popular apps on iOS and Android is the same, with a thin layer of platform-specific code, which is Java on Android or Objective-C on iOS. For games, the amount of Java code is typically tiny - create an OpenGL context and pass it to the native code, which is identical on both mobile platforms. This is a big part of the reason why there are so few apps for Windows Phone compared to the other platforms: by forcing WP apps to be entirely managed code, they make it hard to port apps.

Re:What's the point?

[Giant Electronic Bra]

Well, yes, but did all the 100 different library vendors you rely on do that? One hopes that libraries are free of leaks but reality is they aren't, and they often use DIFFERENT frameworks for smart pointers etc than the one you happen to be using, which can create its own headaches. At best its an entire extra category of stuff that has to be mastered.

I know a lot of people talk about all the 'random execution pauses' and such that a GC brings, but in my lengthy Java experience (10 years now) with high performing applications I've not found it to be a huge impediment. I think if you are really down to caring about sub-microsecond latancies and such then perhaps Java isn't the solution for that particular problem, or you need a hybrid solution or something (at which point you've probably lost a lot of the advantages of going with Java to start with, admittedly). There just really aren't that many such applications in the world. I run some pretty big market data processing applications and I don't see millisecond variances. Since most of the data being published is coming across at least leased lines from halfway around the world and often over the 'net sub-millisecond or even a couple milliseconds is not actually something anyone will care about. So the utter reliability and stability of the application (processing up into the 100's of thousands of packets per second with 100% reliability for weeks on end without human attention) is the paramount consideration. I have competitors that try to sell to my client base SPEED! They succeed for a while sometimes, but they always come back after the big ugly crash :)

Re:What's the point?

[Giant Electronic Bra]

Yeah, it takes a lot of work to maintain those, though I admit it was kind of fun writing them... lol.

Re:What's the point?

[Giant Electronic Bra]

Its not the design. Like I've said I've done some pretty large perl programs. The work involved in dealing with the bugs that arise that just can't exist in Java generally overcomes the advantages of using perl, and by the time you stick rigidly to classes and modules in perl why not use Java? Frankly I avoided all the one-line amazing wonder-code in my maintainable perl anyway unless it was necessitated by performance reasons, so its not like there was a big difference. There isn't even really that much less type casting in perl vs Java, it is just somewhat obfuscated into the reference syntax.

The one GOOD example of an application that I still maintain in perl is our build system. Its a pretty good sized set of perl modules a couple simple parsers, and some dependency graph tracking code. This is where perl IS great though, I can invoke specific command line utilities and muck around with files and such without a lot of hand-wavy abstractions. Maven used to suck up half our time working around its built-in limitations, Builder barely requires any attention at all at this point and if you need to do some weird thing you can write a new perl module in 5 minutes and do it, assuming the 40 existing ones don't do it already. However, even my most experienced Java guys quail at the thought of understanding the core Builder code, lol.

Re:What's the point?

[Giant Electronic Bra]

LOL, right. I guess it would hate any C++ code I wrote! It never ceases to amaze me that QT and its tools haven't totally dominated the desktop application market. Why WOULD you use anything else? I mean its been portable to all desktop OSes for years, and even if you need a license it is dirt cheap. GTK in its various flavors is OK, but far behind QT and you can run on windows, macs, and I guess now Android and iOS too? Seems like a no-brainer to me. I think developers just hate conformity...

Re:What's the point?

[prionic6]

OSX comes (used to come?) with outdated versions where a lot of Java programs don't run properly

Who cares what version is installed by default? OSX can be upgraded to the latest version, and any application that needs it ought to provide an installation package that does precisely that, or at least clear instructions to the user on how to do it.

As the person responsible for packing our commercial desktop Java app and maintaining its installer, I suggest just bundling the JVM with your product, but not as its own Installed package but inside your installation. It takes a bit of additional hard drive space if every app has its own JVM but it saves so much confusion and different version failures. The end user also doesn't have to worry about the abysmal Oracle updater because our JVM is not registered to handle browser applets or other stuff, so that security risk is just not there.

Re:What's the point?

[Giant Electronic Bra]

Yeah, that's true. There are of course SOME pitfalls that Java won't help you with, like just allocating bazillions of short-lived objects, though in the last 4 or 5 years the GC has gotten so good that I've abandoned all the allocator tricks I used to use back in the 1.4/1.5 days. That and modern CPUs just have vast numbers of cycles to burn. Feeds that were barely possible to parse 5 years ago now take up 5% or less of the CPU. A lot of it is probably better caching and etc too, but nowadays the limits seem to be pretty much I/O. Even that is solved mostly if you want to throw multi-thousand-dollar NICs at your problem and spend weeks tuning.

There certainly are plenty of hacks in all industries. I worked in Aerospace for a few years and most of the people there were really pretty mediocre. They usually had a very complete support system, so their job was pretty low level and they did fine. I mean we made 747's fly and not crash, and obviously we managed even with some coders that you really had to watch. I think its mostly the same in the banks, except the culture isn't quite so rigid, so now and then they have a big problem. I'm not sure Java helps much with that, but I guess it doesn't hurt...

Re:What's the point?

[drolli]

So which of the most used apps on android use openGL?

Re:What's the point?

[Actually, I do RTFA]

You can also cast things around until the compiler and IDE buy it and wait for the SEGV.

You can do a lot of things. But having a code that says "danger, this code requires a lot of care to touch." is a good thing. Casting things through a void* or something like that is an excellent example of how you can detect that when reviewing or working on code. Plus, that's the exception. So when I see a void*, I know that the documentation is really important.

It's on the developer to know when they can and cannot get away with it.

I don't understand why. Fundamentally, it seems superior to have a computer check for bugs for you. That's what static code analysis is all about.

If you don't KNOW if class A and Bs X methods are actually compatible, what in the hell are you doing passing them around? You're supposed to know that.

Because I'm human, and made a mistake? Because when I wrote the code they were compatible, but then someone changed the definitions of one of the classes without knowing it would break my assumed usage because they weren't aware of everywhere that the code would be used in the entire codebase. Because there are multiple developers on a project?

This would be a lot less of an issue if multiple inheritance was better supported, but it's not.If it was, I could write the module explicitly around class A. Later, given a class B that should work fine with the module, I could derive Bprime inheriting from A and B and it would be fine.

But it actually is pretty well supported, especially in this case. I mean, actual multiple inheritance is always a shitshow. But interfaces are totally well supported and easy to use. I don't understand what issues you think arise from using interfaces. But I can say that what you describe is pretty much what should happen. Although really you should write the module around Aprime, an interface, and then say that both A and B implement interface Aprime.

Re:What's the point?

[DoofusOfDeath]

You question the conscientiousness of the programmers in the first paragraph and assume it in the second.

You should see the crazy type casting that happens in production code to please the IDE and/or compiler. It may or may not be the right thing.

Then there's the cases where it is actually OK if not all objects passed in support all of the methods. Not Applicable might be the right outcome of a method call if the caller is prepared for that possibility.

FWIW, I was never trying to argue that a language like Java is better than a language like Python in every circumstance.

There are tradeoffs, and I'm just saying that for some systems, especially large complicated ones, I've found the benefits of static typing to outweigh the greater effort that's needed to make certain kinds of changes.

As I'm sure we all know, a badly designed program in either kind of language can make the grass on the other side of the fence look greener.

Re:What's the point?

[sjames]

As I'm sure we all know, a badly designed program in either kind of language can make the grass on the other side of the fence look greener.

True enough. As they say, it is possible to write a Fortran program in any language.

Re:What's the point?

[sjames]

So when I see a void*, I know that the documentation is really important.

def pickymethod(self, pickyobject):

"""Here there be dragons, beware"""

Although really you should write the module around Aprime, an interface, and then say that both A and B implement interface Aprime.

Problem is, A and the module that handles it is existing code used in multiple projects. IO don't want to do a cut/paste job and I don't want to risk breaking the other projects. B is from another existing module used by other projects. I REALLY just want to derive a Bprime that can serve as an A or a B as needed by the legacy modules.

Python does a decent job with multiple inheritance, but even so, it can get ugly so I might prefer duck typing and a compatible class.

Re:What's the point?

[Xest]

People do use it outside of Windows, it's become the defacto primary language for indie game developers nowadays developing on engines like Unity, or game development frameworks like MonoGame. Both of which support iOS, Android, Linux, MacOS X, and of course Windows.

As a Windows developer I never saw Mono as a viable option for development on Linux/MacOS X so I always reverted back to C/C++ or Java, but when I started fiddling with MonoGame and used it on Linux I was actually incredibly pleasantly surprised as to how good it is - it's good to the point of being a perfectly viable option, which is not something I expected.

Re:What's the point?

[Xest]

What efficient methodology is there to write a large codebase using a scripting language that can't be used with a compiled language exactly? The "you need better developers" fallacy is exactly that, a fallacy - it doesn't matter how good your developers are, all developers introduce bugs, certainly the number decreases as you increase the skill of developers but there is not a developer on this earth that does not introduce bugs.

So there lies the problem with scripting languages, because many scripting languages don't have any kind of toolchain that prevents bugs from creeping all the way through until runtime, you have entire classes of bugs that a compiler would catch creeping through to your executing application at runtime, as the codebase grows scripted applications therefore by and large almost entirely all become much more time consuming to debug, as bugs only appear in fringe cases and it is not immediately obvious how to reproduce them. Often you find yourself having to implement tremendous logging infrastructure and so on and so forth to have confidence that your application is solid and the net result is that it's just way more efficient to develop large projects with a compiled technology. Also, whilst it's not a fault of scripting languages per-se, you tend to find that compiled languages have far superior toolchains for developing large projects in the first place anyway.

I don't say this as someone spouting opinion and theory, I say this as someone who has had experience as both a lead developer and technical architect in implementing large projects in both compiled (native and managed) and translated languages (which is usually what people mean when they say scripting, though it's getting muddier with more use of just in time compilation etc.), and even some projects mixing it all together.

For anything large the amount of time spent debugging scripted applications just gets too large for it to be worth it, at that point you might as well have used compiled because any early benefits of getting up and running quickly have long been lost.

Which isn't to say I'm of the opinion that scripting languages are always useless, not at all, I think they're fine for small non-mission critical tasks such as task automation, and for prototyping, but I think the larger a project gets, the less worthwhile scripting languages become - that's not to say you can't use them, as I say, I have myself been involved in such projects, but the project is always much more costly. This is evident at companies like Facebook with their use of PHP - last time they released server specs they had equivalent of 8gb of RAM per user of Facebook which is insane, even if a lot of that is being put into big data type processing and analytics, and the amount they've spent trying to turn PHP into something compiled similarly paints the same picture. So yeah, sure, Facebook is there, and it works, most of the time, but it's also costing them way more to run than it should if it was a properly planned project using something like Java, C++, or even C# from the outset. The flip side is, someone like Zuckerberg who was just hacking a de-facto prototype together may also never have been bothered, (or potentially even competent enough?) to do so with a compiled language and a more professional architecture, so it's a double edged sword in that respect, and I can see why many startups like to just get something developed no matter how crappy using the quick to launch (but poor to maintain) benefits of scripting languages.

The Google approach (well, it's probably unfair to call it the Google approach, other big players were doing it long before them) of writing the mission critical or speed critical stuff in Java or C++ respectively and using something like small manageable chunks of a scripting language like Python to string it together is not a bad option.

Re:What's the point?

[julesh]

You question the conscientiousness of the programmers in the first paragraph and assume it in the second.

Yes. Most developers I've worked with pay an awful lot more attention to the code than to the documentation. It may not be desirable, but it's what happens in almost all cases. I know I'm guilty of it at times, even though I try not to be. If I see a problem with the code, I'll refactor it. Problems with documentation, (1) I'm less likely to notice them and (2) I'm less likely to actually fix them if I do notice them.

Re:What's the point?

[rdnetto]

I like C# a lot. I wish people used it outside of Windows. Alas. I'll retire happy if I never touch Windows again, so C# is dead to me.

I'll second this. C# is a beautiful language with a terrible execution. Java is a terrible language with a much better execution (at least it has closures now...).

Having found myself in the same situation, you might want to take a look at D. It has very similar syntax to C#, but works just as well under Linux as Windows.

Re:What's the point?

[bingoUV]

Problem is, A and the module that handles it is existing code used in multiple projects

A mistake has been committed - any important "data types" being passed around across large/many areas should have been interfaces, not classes. On large systems, bridge pattern is typically indispensable. A decent, not even genius, developer used to static type languages would not have committed this mistake.

Re:What's the point?

[sjames]

And yet, I see it happen. Nice to have a good clean recovery.

Re:What's the point?

[david_thornley]

Your C++ is a bit old.

std::string is a string class*. It's not really well designed, but it's a string class and works just fine. C++11 added threads. Exceptions have been in the language since the first standard

What C++ lacks is ease of parsing, and that leads to the tool issues. That's left over from C.

*Okay, a template class, so std::string is more like std::basic_string. It works.

Re:What's the point?

[Actually, I do RTFA]

Python does a decent job with multiple inheritance,

Eh, so does C++.

The only time C++ really has trouble is if A and B share the names of methods/variables. And the reason they will have trouble is that there is no solvable way to not have trouble. Not for a computer. Not for a programmer.

Although, I don't see how you can possibly go wrong, if you can write to the module that contains A creating an interface A implements, and changing the code that the module uses to use said interface.. There's no difference for backwards compatibility. (Unless you don't believe in namespaces, and have to worry about truely unique names everywhere.)

"""Here there be dragons, beware"""

See, that's not something that is easy to search for in code reviews. Because, there is no validation that I did not write: *** Off the edge of the world: Sea Serpents Around ***

And if you cannot trust other programmers to use fucking interfaces, you cannot trust them to use the right magic strings.

Re:What's the point?

[WuphonsReach]

And a lot of Java "boilerplate" can be handled better by things like GRAILS, Spring Roo, and/or AspectJ - things like automating getters/settings becomes trivial with AspectJ. They don't clutter up your .java source file.

Re:What's the point?

[bingoUV]

That is correct. So it boils down to bad designs in either system leading to people thinking that system itself is bad. Something like the other guy in this thread was saying.

Re:What's the point?

[sjames]

Or it means the system has grown and evolved over time in ways not anticipated when it began. That is the nature of software. In fact, some of the most useful bits of software are that way (of course, so are some of the most useless).

Re:What's the point?

[sjames]

The thread is about Java being/not being an appropriate mid-point between Pyt hon-like interpreted languages and C++ like compiled languages.

See, that's not something that is easy to search for in code reviews. Because, there is no validation that I did not write: *** Off the edge of the world: Sea Serpents Around ***

Someone thinking of calling the function should certainly see it.

Ideally, it would then lay out the necessary attributes of the object if it's non-obvious.

Re:What's the point?

[sjames]

Sometimes the casting is actually the right thing though. An unfortunate side effect is that the IDE can't hold your hand anymore, you have to actually understand the code.

Re:What's the point?

[bingoUV]

Not really, there is no excuse for not following bridge pattern and getting bitten. At soon as 2 people use a "data type", it is not too soon to separate out interfaces. If good design were difficult, I would agree with you that anticipation of evolution is necessary for making the extra effort. But this is trivially easy to do.

Only developers not used to the static-ness of the language they are developing in can miss it. And developers not used to "dynamic" , in this sense, languages can cause shudder-worthy events, so this just boils down to bad design.

Re:What's the point?

[Actually, I do RTFA]

The thread is about Java being/not being an appropriate mid-point between Pyt hon-like interpreted languages and C++ like compiled languages.

Well, first, C++, Java and Python all have multiple inheritance. Java just only does it with interfaces. Which you objected to by stating no one did multiple inheritance except Python.

But at a higher level, this sub-thread seems to be about your assertions that duck-typed and interpreted languages are superior to compiled languages.

Someone thinking of calling the function should certainly see it.

Really? Cause I can think of a lot of reasons that's not the case. Just in like 2 minutes:

1. It got autopopulated in my IDE, and *sounds like* the function I intend to use. Possibly even one I've used before and am mis-remembering the name of.
2. The "Here be Dragons" got added later, when the signature of the function didn't change (or it did, but duck-typing, so no-errors, let's go!)
3. I was told about the function verbally, so I never read the docs. I then told someone else. At some point, the oral tradition drops the "Here be Dragons".
4. In a less formal code review (maybe someone in charge of many programmers, who cannot do a full read of all of their code) there is no way to easily have them find it all using grep.

Your solution is really fragile. It requires never changing classes once they are created (at least the public members thereof) because you never know if they are used. Which, in some languages, or with some programmers, is all the members.

Further, the only situation you seem to be able to suggest where it is useful is when you have, I'm assuming read-only, access to two modules, and need to create some code that hacks both of them together. And at least one module declines to use the proper method of defining interfaces and using those.

To get that feature, you're willing to jettison a ton of compile time checking, make the codebase fragile and hard to change.

Honest questions: Have you ever worked on a large codebase? Multiple developer? Multi-year? Cause what you write makes me assume that you, in fact, do not. That your big issues are hacking together two JQuery modules, and you make websites where you're the sole coder.

Re:What's the point?

[sjames]

It got autopopulated in my IDE, and *sounds like* the function I intend to use. Possibly even one I've used before and am mis-remembering the name of. The "Here be Dragons" got added later, when the signature of the function didn't change (or it did, but duck-typing, so no-errors, let's go!) I was told about the function verbally, so I never read the docs. I then told someone else. At some point, the oral tradition drops the "Here be Dragons". In a less formal code review (maybe someone in charge of many programmers, who cannot do a full read of all of their code) there is no way to easily have them find it all using grep.

If any of that happens, you absolutely positively deserve everything you get. DO NOT call a function if you don't know what it is!

My actual assertion, BTW is that duck typing has advantages to go with the disavantages.

I have worked on a number of large projects with multiple coders. I presume you use the old cut'n'past code 'sharing' method with a significant appearance of the cargo cult antipattern?

Your solution is really fragile. It requires never changing classes once they are created (at least the public members thereof) because you never know if they are used. Which, in some languages, or with some programmers, is all the members.

You need to RTFC as well. Surely you don't recommend unilaterally changing code used in other projects!

Re:What's the point?

[Actually, I do RTFA]

I presume you use the old cut'n'past code 'sharing' method with a significant appearance of the cargo cult antipattern?

Clearly the only reason you would say something like that is a particularly stupid ad homenim. I'm talking about using interfaces and code review. I'm talking about best design practices. Clearly, since I'm advocating for using interfaces, I'm not copy-and-pasting code. But advocating for what you are advocating for is actually really compatible with cut-and-pasted-code.

But that level of intentional misunderstanding may bleed into my responses below.

If any of that happens, you absolutely positively deserve everything you get. DO NOT call a function if you don't know what it is!

At this point, I wonder how your "everything in comments" system architecture works, since you seem to have issues reading. I mean, nothing I wrote says "call functions randomly".

I talked about an obvious human error (incorrect memory of a name); I talked about being given information from a collegue; I talked about coordination issues where function signatures changed; and I talked about how hard it made code reviews.

The fact that you don't seem to recognize these possible issue makes me question your experience. Because these are all things that happen.

Surely you don't recommend unilaterally changing code used in other projects!

I'm not going to make an argument here, because this is obviously going to lead to a conversation derailing where you don't address my valid points above.

Re:What's the point?

[sjames]

At this point, I wonder how your "everything in comments" system architecture works, since you seem to have issues reading. I mean, nothing I wrote says "call functions randomly".

No, you just called whatever the IDE autopopulated with, apparently without bothering to check what it was. Or at least that's what you said may happen.

You also talked about calling functions based on oral lore that has changed over time. That sounds pretty cargo-cultish to me especially since you apparently believe that might be a fair reason to have never looked at the doc string.

Re:What's the point?

[Actually, I do RTFA]

you just called whatever the IDE autopopulated with, apparently without bothering to check what it was. Or at least that's what you said may happen.

Right, because you thought that the function was a different one because you misremembered the name. Or because you would assume a function like "getCurrentHealth()" would return the health of a character, and not, I don't know, concatenate two Strings randomly. Especially if that's what similar, or identically named, functions do throughout a library.

But, yeah, it may happen.

And oral lore is really "consulting with collegues" Which totally happens in real situations. If I ask someone, for example, how to get an arctan value outside the -pi/2 to pi/2 range, them explaining quickly how to use atan2f is more valuable than telling me a function name and "GTFO;RTFM".

Bottom line, I'm advocating for computers doing the work instead of comments (which may be unread, or out of date, or literally written after the code that referred to them). I posit many, many, reasons why having a computer check for errors instead of a human being. Your only response is that "Dude, but then I cannot hack two systems together using magic glue that happens to work, and enforces on everyone a requirement of never even optimizing their code, because any change could break my system. And could be avoided if I followed best practices."

When every advantage you suggest can be done in a superior way without using duck typing, I'm blown away. You have argued that perfect programmers don't need the fuckin' IDE, they can check their own work. Well, perfect programmers don't need the fuckin' comments either, they can read the entire code and know what happens.

I can only assume you're trolling, because while I've heard people defend duck-typing before, I've never heard such a malformed argument.

Re:What's the point?

[sjames]

I could as easily pick apart your arguments. I find it hard to imagine never using code that is shared with other projects for example. Why re-invent the wheel? Are you declaring code re-use dead? What about the system libraries? Do you hack those without notice too?

And what happened to unit testing where you should easily enough shake out cases where people called a function they shouldn't have?

I have argued that the programmer who just takes the IDE's word for it will eventually end up in deep trouble.

You seem to be arguing that duck typing is bad because shoddy practices rule.

Re:What's the point?

[Actually, I do RTFA]

I could as easily pick apart your arguments. I find it hard to imagine never using code that is shared with other projects for example. Why re-invent the wheel? Are you declaring code re-use dead? What about the system libraries? Do you hack those without notice too?

You could move the goalposts like that. I explicitly didn't respond because that is trying to derail the conversation.

But what the hell. You've stopped actually responding to the points I make.

So, I would contend that code reuse is helped, not hampered, by compiler-verified interfaces. I would contend that your "code reuse" is so stifling that it is literally inferior to copy-and-pasting... at least with copy-and-pasted code you can improve the module you copied without worrying that it breaks things.

And what happened to unit testing where you should easily enough shake out cases where people called a function they shouldn't have?

Why do you want to re-invent the wheel. Now, unit testing is good, but using unit testing to re implement (imperfectly) interfaces is, well, crazy.

I have argued that the programmer who just takes the IDE's word for it will eventually end up in deep trouble.

No, you've argued that programmers are perfect, that the comments will always be accurate, functions you call will never change, and the comments always need to be read for every getter and setter. And that's just to reject my examples.

And I categorically reject any of the above.

You seem to be arguing that duck typing is bad because shoddy practices rule.

Since the only example you have been able to give as to why duck-typing has any benefit, is as a patch to shoddy use of interfaces, this seems a remarkably dumb statement. I contend that duck-typing hurts the ability of the computer to detect errors, and your only response is that some people didn't properly use interfaces in legacy code. Not that interfaces are somehow a bad way to program. But a shoddy programmer may not have used them.

Well, fuck that. A paradigm that gives up useful features to paper-over shitty work, or allows code reuse between kinda existent modules via unspecified hack code that works 95% of the time is bad. Heck, any code that would need to be papered over like you suggest probably shouldn't be trusted. Duck typing is bad, it encourages bad practices and bad coding, and allows bad programmers to continue programming with silent errors as opposed to either fixing their shit or quitting their job and flipping burgers.

Re:What's the point?

[Aighearach]

No, Dilbert is an engineer who is good at math but too socially retarded to get a real job for a company that respects him. It is presumed that he was rejected by all the companies that are desirable to work for, and feels trapped.

He is the Sub-Genius.

Re:What's the point?

[Aighearach]

The "you need better developers" fallacy is exactly that, a fallacy - it doesn't matter how good your developers are

It is widely understood to be true that Java has, as an actual, real-life thing in its "pros" column (and in its "cons" column) that it is easier to use by low quality, replaceable programmers. That is not an original claim, or something that is disputed by mainstream sources. That is true both for people who support Java, and those who are against it.

Here is a video interview with Larry Wall, one of the most respected (and qualified in linguistics) language designers, who says, "because it is sort-of considered an `industrial language,' and programmers are sort-of interchangeable parts, managers like it for that reason..."

https://www.youtube.com/watch?...

Re:What's the point?

[Xest]

"It is widely understood to be true that Java has, as an actual, real-life thing in its "pros" column (and in its "cons" column) that it is easier to use by low quality, replaceable programmers."

More so than systems languages like C/C++? Sure, more so than other mainstream languages used for business development like C#, PHP, Python? Absolutely not, so I don't really know what your point is. If anything I'd argue that Java developers are, on average, better than developers of scripting languages, because there's a higher barrier of entry. Java developers at least have to have a basic grasp of object oriented structure, and to be able to write something compilable before they can even get their application to execute - PHP programmers can have anything execute no matter how tragically badly structure or written it is. This is why big companies like Java - it enforces a baseline of quality so that even the worst programmers have to adhere to some baseline, that's barely true with scripted languages at all. Those interchangeable parts Wall is referring to are interchangeable without a reduction in quality to the level you will see with a change towards scripted languages where much more problematic code can reach a point of execution.

None of which of course addresses the point I've made and the question I posed that you've conveniently dodged - what methodology exists to allow scripting languages with no compile time checks to be inherently better quality than compiled languages that force entire classes of bugs to be dealt with before execution that can make it through to execution in scripted languages? I'm intrigued to know what this methodology is because I've never heard of it despite years of working with both large compiled and scripted projects.

Fact is, as a project gets larger, you cannot build something with a scripted language in the same time frame and for the same cost to a better quality level than with a compiled language like Java, or C# - the inherent disadvantages of scripted languages over managed languages make this a certainty. The performance disadvantage of translated languages over JIT compiled languages alone makes sure of this, the inherent quality difference and resultant increase in maintainability costs in large code bases just adds further weight to guarantee it.

Not meant to be cool

[Anonymous Coward]

Java (and C#) arent meant to be cool, they're meant to get the "menial" work done
Software engineers can use their choice of language: from Assembly to Ruby\Python and other languages to accomplish what they want
Java and C# are meant for us programmers to accomplish the "boring" tasks, writing business specific code,etc... Club Java with SAP rather than other programming languages IMO

I don't care about Java

[Rinisari]

Java is moving into archaic irrelevance faster than ever. That is, the language itself.

The JVM, however, is now more useful and relevant than it ever was. It used to be naught but an implementation detail. Now, rather, it's central to an entire ecosystem of languages that will inevitably send Java the way of C: used only when the greatest speed is necessary.

Scala is basically a next-generation Java. Java with functional programming, or really, vice versa. JRuby make Ruby actually scalable, given the presence of native threads and interoperability with existing enterprise libraries that commonly only ship in the form of Java or C# libraries. Clojure enables LISPers of yore and Schemers of new import explore functional programming as it used to be, without having to drop the wealth of Java libraries available. Ceylon, Groovy, Jython, and dozen of others are paving a way to give the JVM much more to do after Java becomes obsolete.

Java will never die - it'll just become like COBOL, Fortran, and C before it: used in enterprise software, operating systems, and outdated educational assessments.

Re:I don't care about Java

[buddyglass]

Java is moving into archaic irrelevance faster than ever.

This seems like it should be quantifiable. That is, you seem to be saying that the rate of decrease in Java's popularity is at an all time high. The slope of its decline is steeper than its ever been, so to speak. Do the popularity metrics bear out that claim? After some cursory googling, the TIOBE rankings are the only one I could find online that has historical data. If you look at their chart it looks like Java's rate of decline in market share is approximately linear, with a fair amount of fluctuation. If you focus only on the period from April 2014 to August 2014 then the decline is indeed rather steep, but it's no steeper than, say, the period from February 2013 to July 2013. So while Java may indeed be waning (gradually) I'm calling B.S. on the claim that it's "moving into archaic irrelevance faster than ever".

Re:I don't care about Java

[qbast]

It is interesting how badly C# has been doing in TIOBE recently. It had been rising to become 'new java' until 2012, but then it went into decline steep enough to leave it behind BASIC.

Re:I don't care about Java

[buddyglass]

Possibly related to Microsoft's failure to gain a foothold in the mobile / app space? Since we're talking about "market share", if a new market materializes and C# isn't used at all in that market then its relative share should appear to decline.

Re:I don't care about Java

[buddyglass]

Also worth noting is that the downward trend in Java's market share is mirrored by downward trends in the share of other "highly popular" languages. This possibly indicates the market is becoming more diverse. TIOBE's chart goes back to June 2001, which, according to their numbers, is the high water mark for Java at 26.5%. In that month the shares for C and C++ were 20.2% and 14.2% respectively. In August 2014 Java had declined to 15.0%. C and C++ declined to 16.4% and 4.7% respectively. Woe is C++. In fact, of the top ten languages in 2014 the only ones to gain market share over the past year are Javascript and Objective-C. Javascript has been more or less flat; Objective-C spiked earlier this year but has since dropped back to 2013 levels.

Python? Peaked in February 2011 when it reached 7.0% in TIOBE's index. It's currently sitting at 3.1% in August 2014.

Ruby? Peaked at 4.0% in December 2008. Currently at 1.2% in August 2014.

I can't get info on Scala, Go, Haskell, Scheme, Erlang, Groovy, et. al. because they aren't used widely enough for TIOBE to even report stats.

Re:I don't care about Java

[sproketboy]

Scala is a disaster and probably will need a rewrite for it to be usable outside the hipster crowd.

Backend of many sites

[WilliamJozef]

Many websites run on Java based systems (tomcat, JBOSS, WebSphere, etc.). I'd really miss it there. Also, many mobile apps are Java based (android). But where I really would not mis it: in my browser or on my desktop.... or at least, after Burp Proxy becomes be available in some other platform-independant language....

Language VS The Virtual Machine VS Client

[Kagato]

There almost needs to be two separate considerations. From a language standpoint Java is a bit middle of the road. It has some well known pain factors, but more or less it's one of the easier OO languages to master. It's used in a lot of high profile web site.

The VM on the other hand does a lot of interesting things under the covers that make the language quite fast. When JRuby hit the scene it was faster than the core ruby project at quite a few things because the VM was doing all sorts of optimizations behind the scenes. Also, because the Java OP code is so stable with relatively few changes per major release you have a bit of a boom in languages you can run inside the Java VM. You get all the benefits of the R&D Sun and Oracle put into JIT, while retaining the ability to do interesting and contemporary things with your language.

Clojure, Groovy, Scala, Python being the primary languages with another 16 that can compile to Java Op code.

Were Java fails mostly is as a client application, running with some sort of Windows GUI. Sure, you can do it, but it realistically people who do Java Swing apps are writing some sort of thick client that could almost always could run inside a contemporary browser without any plugins.

Re:Language VS The Virtual Machine VS Client

[StormReaver]

Sure, you can do it, but it realistically people who do Java Swing apps are writing some sort of thick client that could almost always could run inside a contemporary browser without any plugins.

Swing is where I do all of my Java GUI programming, and I find it to be an excellent fit for that purpose (and so do my customers). I find running Java inside a browser to be, to put it politely, fucking retarded.

Re:Language VS The Virtual Machine VS Client

[Adam Jorgensen]

Great summary.

For me, Java the language is disgusting whereas the JVM is wonderful.

Re:Language VS The Virtual Machine VS Client

[Kagato]

To clarify, when I say run I'm talking about as HTML/CSS/JS, not using the Java web plugin.

Re:Language VS The Virtual Machine VS Client

[prionic6]

I find running Java inside a browser to be, to put it politely, fucking retarded.

You're talking about applets, he's talking about having an application server serve HTML. I suppose.

Java is the new COBOL

[techfilz]

Its been around for ages (in IT terms) and has caused more heartburn to developers than bad doughnuts. Used a lot in the monstrous systems that run the Corporates but not so much for developers looking to have a bit of coding fun. Java is as cool as Vanilla Ice was back in the early nineties.

All that packaging

[Animats]

The strange thing about Java is that it still uses a virtual machine. There's so much "packaging" associated with Java that compiling to machine code and linking would almost be simpler.

Re:All that packaging

[Animats]

Need your software to work on a wide variety of platforms and run mostly the same on all of them

Except nobody actually does that. The whole JVM thing was done to make browser "applets" work. Nobody uses those any more. Most Java is server-side, running on farms of x86 machines.

Re:All that packaging

[NormalVisual]

Except nobody actually does that. The whole JVM thing was done to make browser "applets" work. Nobody uses those any more. Most Java is server-side, running on farms of x86 machines.

Those farms of x86 boxes aren't necessarily running the same OS on each, necessitating different JVMs. I've personally worked in server environments where the same code had to run on x86 machines under Windows, Linux, HP-UX, and Solaris simultaneously.

Re:All that packaging

[peccary]

I'm perplexed - with a low id# like 122034 I'd imagine you must be old enough to have been around when Java was still new. The JVM was developed in 1991, before Mosaic, and long before the notion of applets. The goal was portability across a wide range of hardware platforms. Had nothing to do with browsers.

Re:From a users perspetive

[maliqua]

Then you get to enjoy the unbearably slow performance, and HP-UX style UI from 1992.

Ahh good ol' CDE i never drew the comparison but that's bang on lol, i wonder if java's ui elements were modeled after CDE

Re:From a users perspetive

[Georules]

You use Java in a lot more things than you think. Java Desktop Apps are terrible and the updater is annoying as hell, but it's also likely the language powering most every device you use and many web applications you use day to day.

A stupid consideration

[DoofusOfDeath]

What good engineer gives a f**k about what language "cool", aside from considering his/her ability to hire hipsters to staff the project?

If you're worried about the "coolness" of a language when doing your day job, you're almost certainly doing your job poorly.

Re:A stupid consideration

[Kohath]

Agreed. It's time for some people to grow up.

Re:A stupid consideration

[Sam36]

Also agreed. Seen plenty of startups go down because they want to use the latest when the latest doesn't solve anything.

Re:A stupid consideration

[afgam28]

As mentioned in the summary this has been discussed a few times on Slashdot, and the original discussion was kicked off by Paul Graham's assertion that the cool hacker kids were into Python and the only people using Java were boring corporate types who had no passion for their jobs and were often mediocre programmers. In this sense, "coolness" does matter a little bit - if you're starting a new project, you don't want to choose a language where the labor pool that you're recruiting from is full of crappy programmers.

And yes, I know good programmers can pick up new languages quickly. But it can take months or sometimes years to master all the libraries and frameworks around the language. Someone with relevant experience can hit the ground running and have a shorter ramp-up period than someone without. I'm not saying that this is more important than general coding ability - it's not - but this is valuable to a lot of smaller companies and startups who don't have lots of time to train up new hires.

What makes Java uncool isn't so much the language itself, but rather the community around it. I actually like Java as a language better than Python, but there's a real culture of overengineering in the Java community, and people there really value convoluted architectures that are (ostensibly) maintainable and extensible. In the Python community, people value simplicity and hackability, and you can see it when you do things like file I/O or compare popular frameworks from both languages.

Not directly related to Java, but a while ago the tech lead for OAuth 2.0 resigned citing cultural differences between the "web" and "enterprise" communities. The "cool" languages are definitely the ones that are favoured by the web community, and the uncool ones favoured by the enterprise community.

So as much as people might think that it's just language syntax, it's not - it's also about communities, culture and different ways of thinking.

Re:A stupid consideration

[hey!]

Exactly. If you want to regard yourself as an engineer, you have to start by accepting you are working to serve the interests of the client, not your career. I've seen so many problems occur because programmers want to have a certain technology on their resume. And the sad thing is that it works to get them through the HR filter. If HR is told to look for experience with a particular technology, it doesn't seem to matter whether the candidate's experience with that technology is failure.

Re:A stupid consideration

[pchasco]

I also have to disagree with programmers who think learning a new language is just syntax, but for a different reason: Semantics. Sure, any programmer who knows a language could probably pick up the syntax of another language with relative ease. But knowing the semantics of a language is what separates the wheat from the chaff. Programmers who don't understand the semantics of the language are the ones who create the subtle, hard to find bugs. This is especially true with JavaScript: 2 == "2" (true), 2 === "2" (false), 2 + 2 == 4, 2 + "2" == "22", 1 (true), 0 (false), "1" (true), 0 == "0" (true), "0" (FALSE), "true" (true"), "false" (TRUE), [1, 2, 3] (true), [] (TRUE), I could go on. With the explosion of new web sites thousands of programmers began churning out crappy JavaScript because they thought," hey, I know (VB/C/Pascal/PowerBuilder/DreamWeaver/etc). Coding a website should be no problem!" Boom. Now this guy just wrote some crappy code which goes further to sully the name of JavaScript, which is not without its own warts but overall is a capable scripting language.

Re:A stupid consideration

[pchasco]

Oops -- "0" (TRUE) is what I meant to write. "0" evaluates to true in boolean expressions in JavaScript.

Re:A stupid consideration

[Aaden42]

This is why I LOVE working for a place where coders interview coders. You can put whatever you want on your résumé to play buzzword bingo with HR, but a couple of übers with finely tuned bullshit detectors are going to lay down the gauntlet at your tech phone screen, and doubly so if you make it to a face to face.

If you put a tech [that we care about] on your skills list, and you can’t wax poetic about its finer points in a room with two or three folks who eat, sleep, live, and breath whatever it is, your prospects are looking rather dim.

We’re especially tough on people who are “tech collectors,” choosing new toys with every project just to mess around with them and gain “experience.” If you picked something new and knocked it out of the park on the project, we’re listening. Why did you take the risk in picking a new thing instead of using something established? Show your work, your justification is more important than your results in this case.

If you’ve left a legacy of barely functional piles of duct tape and baling wire behind you, we can usually see right through you. You *might* be able to pull it out of the fire if you can really convince us you did your best within constraints that are out of your control, but it’s not looking good for you at all.

Performance improvements have helped it survive.

[BitterOak]

One of the main reasons Java may be "cooler" today than when it was first introduced is performance.

In the early days of Java, it's VM architecture meant that it was significantly behind fully compiled languages like C/C++ in terms of performance. People were supposed to sacrifice speed for portability. Even for non-speed critical applications, slower languages were thought to be "less cool". Real men used C, and real, real men still coded in assembly language.

But the VM technology in Java has gotten so sophisticated that it isn't significantly behind languages like C/C++ in terms of performance, and that can't be ignored. This is allowing some of the advantages of Java over C/C++ such as garbage collection, dynamic class loading, a certain degree of reflection, various safety systems, etc., to win over some programmers. Java may well be cooler today than it was 10 years ago, because it's really grown up and become a fairly useful language.

Re:Not hip?

[lucm]

Thank you for ruining my day. I don't know what JavaZone is but I now hate it.

Re:From a users perspetive

[lucm]

I prefer java desktop apps to adobe air apps.

Talk about horrible stuff and annoying updater...

Why Java? PASCAL is THE learning language

[Sauce Tin]

I really wish the academic world would go back to the actual proper learning languages, such as PASCAL. In my university, the introductory course for programming is C++ (as a freshman.) C++ has little 'English logic.' However, if you know English, you should be able to read PASCAL code much better than C/Java code. PASCAL is closer to pseudocode, which is (usually) the first assignment in these classes. Why would you jump from pseudocode to a 'stricter language' like Java? What does /. think?

Re:Why Java? PASCAL is THE learning language

[BitterOak]

I really wish the academic world would go back to the actual proper learning languages, such as PASCAL. In my university, the introductory course for programming is C++ (as a freshman.) C++ has little 'English logic.' However, if you know English, you should be able to read PASCAL code much better than C/Java code. PASCAL is closer to pseudocode, which is (usually) the first assignment in these classes. Why would you jump from pseudocode to a 'stricter language' like Java? What does /. think?

If you want a more English-like language more closely tied to pseudo-code than C++ or Java, why not a language like Ruby or Python? At least that way students could learn object oriented programming as well. Pascal really doesn't have a niche anymore. It was a good teaching language in it's day. As a more up-to-date Algol it was a good language for teaching structured programming, but by today's standards, it's structures are not as flexible as they need to be, and classic Pascal is not object oriented. (There may be object-oriented versions of Pascal now, but that's not the original language any more than C++ is C.) Ruby and Python are both very easy to start programming in (one line "Hello World" programs) and scale well to more sophisticated projects. And they both remain very close to pseudo-code type designs at each step of the way.

Re:Why Java? PASCAL is THE learning language

[FlyingGuy]

There may be object-oriented versions of Pascal now, but that's not the original language any more than C++ is C.

Wow have you been living under a rock? Delphi first released by the now defunct Borland and now released by Embarcadero Technologies is probably the best RAD language on the market, bar none.

On top of that it now generates native code for Windows, OSX, IOS, and Android. They even had a Linux version for a while called KyLix.

It is OOP Pascal and it is the fastest compiler on the market and generates native binaries for all the platforms. The resulting binaries are amazingly fast and are generally on par with C,C++ AND Java. You can write them as GUI apps or console apps, take your pick. The runtime is royalty free and their ultimate version comes with drivers for just about every SQL database on the planet.

Just don't try to write an OS in Java

[zieroh]

I'm in the process of hiring software engineers right now, so I've been exposed to a lot of resumes and had the opportunity to talk to a lot of people on the phone (standard phone screen). Invariably, all recent CS graduates list C on their resume as one of their languages. One of the things I ask every candidate to do on the phone is to describe how C strings work. This is my "marker", the test of how much time they've spent in C (vs Java, or ObjC, or whatever). If you're a serious C programmer, you know how C strings work. No exceptions. If you've spent your entire time in college (or even professionally) programming within an environment where strings are handled by object abstraction, you've probably never had to deal with C strings directly. A suitable answer to the question is as simple as "A C string is an array of chars with a null termination at the end".

You'd be surprised at how many people fail the screening process (and thus are rejected) based on this single question. Probably close to 75%, and every single one of them has a CS degree.

Re:Just don't try to write an OS in Java

[LetterRip]

That is surprising that folks that claim C knowledge don't know that.

Re:Just don't try to write an OS in Java

[narcc]

It doesn't surprise me in the least. Kids today don't care about learning details, they just go straight to the first library or framework that promises to hide such "arcane" details from them.

They'll put C on their resume because they used C++ in an intro class. zieroh's test seems perfectly reasonable to me.

Re:Just don't try to write an OS in Java

[DamonHD]

My favourite related Java question to ask in the context of security is: "What's the difference between char[] and String, eg if I have one in a critical API as a public static?"

I'm quite happy to hear slightly 'wrong' answers as long as someone understands a little about wrapping/immutability and so on...

Rgds

Damon

Re:Just don't try to write an OS in Java

[ljw1004]

It's crazy to solve this with a for loop O(n) when you can solve it with a direct formula O(1).

What exactly are you looking for in your candidates?

Re:Just don't try to write an OS in Java

[Bite The Pillow]

Think about it from the perspective of the CS graduate. The one who doesn't know how to tune a C.V. to be a good picture of what they know. They have experience and can prove it, as CS300 and 305 were all C, all the time. That's a year of C experience right there!

But it's also the perspective of not knowing what you don't know. If you use standard C functions to find length, append, but never get into truncating because you make a new array and copy instead, you may actually get through 2 courses without ever needing to know there is a zero.

You were told once, but you never wrote a line of code that needed to know about null-termination. Even writing the code "while(*p++ != '\0')" does not communicate the idea of null-term. It could be just a magic way of getting the compiler to do what you want, without conceptualizing the behavior.

Pro tip: People who claim knowledge often don't know how much knowledge to claim.

Re:Just don't try to write an OS in Java

[DamonHD]

Hi,

That is a different and also interesting case, and just by bringing it up you'd pass my test.

No, I meant something like:

public static final String CRITICAL_ID = "whatever"

in a secure API. If I use char[] instead what happens if a miscreant overwrites the content of the array; what BadThings might happen?

Rgds

Damon

Re:Just don't try to write an OS in Java

[RightwingNutjob]

A good programmer would know to return an unsigned long long int (not an unsigned long int, because that's only 32 bits on 32 bit unix), and use one internally.

Re:Just don't try to write an OS in Java

[ebonum]

I'm partly in agreement with you. If someone puts something on their resume, if they say: "I know C", then I consider C questions fair game. If they can't answer your very simple question about C ( It is a good C Language lead-off question. I will use it in the future. ), I might get the impression that the person was being deliberately deceptive when they wrote up their resume. The most likely explanations are: Either they did use C and they are an idiot OR they are pumping up their resume with bs.

That said, eliminating someone on one question is a bit harsh. People become nervous in interviews. Anyone can have a brain freeze for 20 seconds. I would want to see some form of pattern before turning someone down.

Re:Just don't try to write an OS in Java

[zieroh]

He is talking about CS graduates, not people with experience.

I'm talking about both, though I probably didn't make that clear enough. Generally, I'm talking about people who have graduated with CS degrees within the last 0 to 4 years, and who (for values greater than 0) have some professional experience writing code.

Re:Just don't try to write an OS in Java

[zieroh]

If you use standard C functions to find length, append, but never get into truncating because you make a new array and copy instead, you may actually get through 2 courses without ever needing to know there is a zero. You were told once, but you never wrote a line of code that needed to know about null-termination.

I can put a finer point on it: very few good programmers are created in college programs. The good ones were writing code before they ever entered college. Even very prestigious schools, I've found, turn out downright shitty CS graduates if they weren't already programming before their freshman year.

Oh, and to put this back on topic: if you've spent the bulk of your college education writing Java code, I'm not interested in hiring you.

Re:Just don't try to write an OS in Java

[drewm19801927]

If you copy and paste in "while(*p++ != '\0')" without figuring out exactly what is going on, that's a pretty big red flag that you're not ready to work in C. I absolutely agree RE the difficulty of not knowing how to precisely convey how much experience you have in a given language on a CV though...

Re:Just don't try to write an OS in Java

[jareth-0205]

To be fair, CVs are beasts that end up being read by people who are just keyword searching so you have to put every word you've ever vaguely come up against just to get past HR. There's a bunch of stuff I wouldn't want to be pushed too far on my CV... I figure I can work it out on the fly if necessary.

You have to trust the interviewer has a good idea what is actually necessary for the job and isn't just on a catch-them-out power trip. Hopefully the original poster does actually need C knowledge.

Re:Just don't try to write an OS in Java

[istartedi]

LOL, Bad newbie candidate: "C strings work just like Java strings, but in C". Good candidate: "C strings are arrays of characters that use the null character to mark the end". Experienced candidate: "C strings work???".

Re:Just don't try to write an OS in Java

[Daniel Hoffmann]

If they have both Pascal and C on their resume ask them to compare the strings on both languages and then ask "which one is better?" If they say one over throw the resume away.

Re:Just don't try to write an OS in Java

[rdnetto]

I'm curious why you think that neither is better than the other.
I'm not familiar with Pascal, but as I understand it:
C strings are a series of characters, followed by a null terminator.
Pascal strings are a series of characters, prefixed by their length. If the implementation uses more than one word/byte to store the length, then you aren't limited to 255 characters.
Given how many security problems there have been in C programs due to incorrect handling of strings, the Pascal approach seems much safer (at the cost of a few additional bytes of memory per string, but I suspect each character is stored in its own word anyway for performance reasons).

The C++/D implementation seems to be the best so far though, since storing the length of the string with the pointer enables creation of substrings in constant time.

Re:Just don't try to write an OS in Java

[Daniel Hoffmann]

Pascal strings are better in most cases, but C strings are not without its merits, for example you can not write a one line string copy in pascal (just kidding).

Re:Just don't try to write an OS in Java

[GiganticLyingMouth]

Except that the original question only specified the parameter to be an integer, not whether it was signed or not (nor what range of values it could take)

Re:Performance improvements have helped it survive

[Sauce Tin]

"But the VM technology in Java has gotten so sophisticated it isn't significantly behind languages like C/C++ in terms of performance, and that can't be ignored." I highly disagree. First, For every level of abstract sophistication you add, you may increase the 'agility' of the language, however you are still farther away from raw machine code. Java is notorious for stacking crap on top of crap on top of crap. Second, Java is far behind in performance. Any true huge performance gains are usually done with the aid of a third-party library, coded in C/C++. Java still can't do integer math anywhere near the speed of C. Java WILL NEVER be as fast as C/C++, because C/C++ isn't run as interpreted bytecode. It compiles straight to machine code. In these terms, this is more a physics problem, not (just) a code problem.

Still not cool, *but* ...

[djbckr]

Java as a language isn't fun - I haven't used it for many, many years now - but the advent of JVM-targeted languages makes the Java ecosystem fantastic.

Starting with the JVM - a very good machine that runs on pretty much anything, without having to re-compile your program. Perfect, no, but is anything? And the performance (given that it's a virtual machine) is top-notch.

Then there are the JVM-targeted languages: Scala, Groovy, JPython, BeanShell, etc, etc... Pick your poison.

Then there is a crap-ton of very useful libraries out there, and they can be used with any of the above targeted JVM-targeted languages.

So, we can whine about Java (the language) but really, I use it (the JVM, the other languages, and the libraries) to get stuff done. Cool, no. Productive, yes.

Because there is much need at the middle ground

[bigsexyjoe]

Yes, the middle ground has some disadvantages of both extremes, but it has some of the advantages to both.

C++ maps to hardware well. An enterprise web solution, doesn't need that. It should have automatic memory management. The scripting languages are not strongly typed. That makes the code a little less maintainable and a little slower.

When Twitter used RoR, it was a nightmare. It just wasn't performant enough. When they went to Scala things got a lot better.

Would Twitter ever want to use C++? I doubt it. They are probably a bit hardware agnostic and they don't want to deal with the classes of bugs that C++ has.

Re:Because there is much need at the middle ground

[Aighearach]

Twitter uses C++, Java, Scala, Ruby.

There is some storied history to their Ruby use. Basically, they didn't know how to scale databases, couldn't grow fast enough, and spent 3 months falsely blaming Ruby before bringing in some real db people and fixing their architecture. Ruby was never the problem. And they were still using Ruby for years. Over time, they wrote more and more parts in other languages, which is natural because they're big and they want each piece to be optimized.

So you wrongly doubt something which is already widely reported and discussed. ;) They're "hardware agnostic" but that means using any commodity hardware. That is not a problem for C++, certainly not in the last 10 years, and twitter isn't 10 yet.

Re:From a users perspetive

[maliqua]

As i look around *my* room, i see embedded linux devices that are running mostly binaries primarily written in C, many smaller electronics with simple micro controllers, even a windows CE embedded device running software written in .NET and one java based device my phone..

If i think about whats in my car, its a windows CE embedded device running native applications.

java does a lot of enterprise, android and a decent % of webapps. other than android apps rarely do i see something that is java that behaves as well as the non java equivalents

Debating "cool" is for teenagers

[bigsexyjoe]

What the fuck is this? Is it "cool"? Cool not a term that has a sharp definition, so it's kind of pointless to talk about what is cool. I think A is cool, you think B is cool, that's the end of it.

Java highly used. It solves problems that people want to solve and some people would even say are interesting to solve.

About ten years ago Java 5 came out making it a little more modern and relevant. Then it stalled. However, Oracle has picked up the momentum and it is releasing new versions again. It now supports Lambas and it is expected to have new versions with new features being added every couple of years. I believe that if Oracle keeps releasing new things it won't be relegated to being the language of legacy code. Eventually when there is too much cruft, Scala or something else will start to take over. But that could take a very long time. Look at C++. It's still going strong.

hmm...

[buddyglass]

It bugs me that we're using words like "hip" and "cool" to describe programming languages. That anyone would choose to learn (or use) a language on the basis of it being "hip" is dumb. I'm looking at you, Ruby.

Re:hmm...

[styrotech]

It bugs me that we're using words like "hip" and "cool" to describe programming languages. That anyone would choose to learn (or use) a language on the basis of it being "hip" is dumb. I'm looking at you, Ruby.

Heh, I think that crowd has mostly moved on to Go (via Node for some of the earlier ones).

Re: From a users perspetive

[Redbehrend]

You forgot the updater tried to install toolbars every 2 weeks to the common user...

How to make any programming language seem cool

[stevez67]

Create a calendar showing scantily clad beautiful women reclined on cars and motorcycles writing code, and it will appear to be cool. To 12 year old boys.

Re:How to make any programming language seem cool

[sg_oneill]

Hah. Remember the "Fuck Perl" cheerleader image for PHP. Sure was an enticing image, but holy schmoly was PHP3 a disaster of a language.

What is cool?

[lophophore]

What is cool? Programming isn't cool. Programmers aren't cool. Being a guitar player in a great band is probably cool. Being a chick magnet might be cool. When has being a Java dev gotten anybody laid?

The only people who care about how "cool" a language is are posers. A professional developer is going to choose the tool that is going to let him/her build what he/she wants with the least fuss. For a lot of today's applications, that tool may well be Java.

What's uncool is a skill that won't get you a job. Java can get you a job, help you buy a car, a house, live your life.

Re:What is cool?

[DamonHD]

When has being a Java dev gotten anybody laid?

Umm, I don't think you're holding it right. WORKSFORME.

Rgds

Damon

Re:What is cool?

[blaster151]

Programming languages CAN be VERY cool. Maybe not by the benchmark of getting laid, but by the feeling of elegance and power that can arise from languages and frameworks that hand you new paradigms to play with. Languages should not merely be evaluated by their utilitarian function; there is an aesthetic component to it as well (though beauty/simplicity in a language can often yield great utilitarian benefits).

Re:Performance improvements have helped it survive

[buddyglass]

Since moving to Android development (from the back-end Java world) I'm a little surprised that ProGuard doesn't get used more in the non-app space. That gives you another round of optimization before your byte code even hits the JVM.

Re:Java?

[buddyglass]

If you've used a credit card or done any banking in the past 10 years you've probably made use of Java. Or if you've used an Android phone. If you're speaking narrowly in terms of desktop apps then sure, I'll buy the 10 years stat.

Re:Performance improvements have helped it survive

[DamonHD]

"WILL NEVER": gosh, not true and never has been unless you know the exact CPU and execution paths and data sets that you are compiling for, for all executions of the statically-compiled code. Please don't regurgitate this stuff.

When maintaining a C++ build system used internationally by a large bank I had to guess what the optimal target instruction set variant, cache line size, etc, would be over the lifetime of the output code, which was always a compromise over London/NYC/TOK/etc and a huge range of dev and production hosts of various ages. And with most/much of the library stack unsafe for C/C++ threading even though almost none of our machines (eg desktop or server-farm) where single CPU you could not then and could not now say whether C++ or Java would be necessarily faster on a given machine, given all the CPU- and run- specific optimisations the JVM has available to it that C++ does not.

I currently work on a Java low-latency high-frequency trading platform in the day job and an ASM/C/C++ based microcontroller platform for my start-up. And I think that I've been using C++ and Java for most of their existences, amongst other languages (I've been writing ASM for >30y); I have a fair idea of what is fast and what is productive.

Rgds

Damon

Oracle

[Anonymous Coward]

So for part of the past ten years I have maintained a commercial software package written in Java. And the biggest issue with Java is Oracle. Users hate the way the JVM treats them... always has an update always wants to install software that is a detriment to their computer. I hate the bugs in Swing and the poor integration on the Mac side. I also hate the functional programming is cool so let's make Java more functional stuff that is happening. Not because I have a dislike for functional programming but because it seems to be just more bloat. It's the reason I hate PERL. I don't need another way to do something, I just need the obvious thing to work. So really the best thing that could happen to Java would be for Oracle to give it to Apache and be done with it.

PS Programming languages are a tool. Tools should be boring. Boring means it is comprehensible, reliable and just plain gets the job done.

Is COOL a new acronym?

[ubersoldat2k7]

When you search for jobs for developers, Java/.Net devs are in general better paid than the "cool" script-kiddies. There are also some C/C++ jobs but not as many. I've also seen a decline in RoR jobs lately, so there you go.

The thing with working in "cool" projects based on the technology used, is that you'll have to keep on learning the new fad every two or three years. We had this with PHP, then it was RoR, now it's Node.JS. If you chose Python, tough luck because it hasn't been mainstream yet. It doesn't matter what language you're using, probably the project is a CRUD application and believe me, doing user authentication, input validation, database operations or sending emails is a PITA in Ruby, in JavaScript, in PHP and in every freaking language.

OTOH I've been developing software for the last 15 years using different languages/platforms and I don't see where all this hate for Java comes from. I mean, it's everywhere, it's free, it has great tools and libraries, lots of documentation and lots of people working on or with it and big names behind it. Name one language/platform that has all of this and we can have a talk.

Re:Is COOL a new acronym?

[gweihir]

The TIOBE index does not agree with you at all on C/C++/Objective-C, and Pythin is almost as high as the highest places .Net thing (C#):

http://www.tiobe.com/index.php...

One word: Minecraft

[stereoroid]

If Java can be made to do that, that's got to mean something ...

Re:One word: Minecraft

[kthreadd]

Take an extra look at your Minecraft folder. There's lots of native libraries there. Java is only used for the top UI layer.

Re:Performance improvements have helped it survive

[DamonHD]

+1 for ProGuard; I use it for my main Java Web app and apart from anything else PG vastly reduces the size of the .war I'd otherwise have to ship.

Also, not all of my target hosts have a full server-class JVM/optimiser, so getting stuff done up front is a good thing.

Rgds

Damon

that depends

[anomalous cohort]

I remember attending a meet-up on this very topic within the past year. It was held at the offices of a small startup recently acquired by twitter. The presenter made the distinction between Java as the programming language and Java as the runtime environment (i.e. JVM).

In his opinion, Java the programming language was on its way out whereas Java the runtime environment was here to stay.

Why is that? The JVM reflects countless man hours of stability fixes, performance improvements, and scalability work. It's a real big investment that only mega corps with deep pockets can make.

In my experience, what I have found is that there is a certain breed of programmer who doesn't like Java the programming language. It seems to me that it is because Java is statically typed. This means you have to type out all these interface and class names with every method signature. It's a lot of typing. You add in all those getters and setters boilerplate and you find that you have a larger, some would say cumbersome, code base to maintain.

If you find that you resemble that description, then check out Clojure which is a version of lisp that compiles to Java byte code running in the JVM. It can, but doesn't have to, be pre-compiled and it is dynamically typed. You can provide type hints but you don't have to. For this reason, Clojure programs are much more dense than Java programs. Less typing in order to get the job done.

Be careful what you ask for. All that typing means that you can find and fix a lot of bugs in the compile step. With dynamically typed languages, you get to find those bugs at runtime. Maybe that is why other posters here believe that Java is for the B programmers.

Re:that depends

[RabidReindeer]

Be careful what you ask for. All that typing means that you can find and fix a lot of bugs in the compile step. With dynamically typed languages, you get to find those bugs at runtime. Maybe that is why other posters here believe that Java is for the B programmers.

Precisely. The problem is, that if you design things out ahead of time, it takes longer before you are at the point where you can show "results".

The spirit of the times is instant gratification. The faster you can get from basic premise to displayed web pages, the better you look.

Your actual architecture may be paper-maché over balsa wood and chicken-wire, but if you can show something visible to the PHB and the users ASAP, you're "productive". Even though in a month's time, the whole sysem may end up crashing and destroying vital data. Or worse, sharing it with various unsavory people who broker such things to even less desirable people.

Re:that depends

[mcvos]

In his opinion, Java the programming language was on its way out whereas Java the runtime environment was here to stay.

Absolutely. Java the language is a chore, leading to very verbose code. The JVM however is one of the best things since sliced bread. A managed environment like that is extremely useful.

If you find that you resemble that description, then check out Clojure which is a version of lisp that compiles to Java byte code running in the JVM. It can, but doesn't have to, be pre-compiled and it is dynamically typed. You can provide type hints but you don't have to. For this reason, Clojure programs are much more dense than Java programs. Less typing in order to get the job done.

Another good option is Groovy, which very easy to get into for Java programmers, since 99% of legal Java syntax is also legal Groovy syntax. But for everything, there's also a better, more readable way to do it. Best interaction with Java of any JVM language. It's basically what Java should have been.

Be careful what you ask for. All that typing means that you can find and fix a lot of bugs in the compile step. With dynamically typed languages, you get to find those bugs at runtime. Maybe that is why other posters here believe that Java is for the B programmers.

No, if you're a competent programmer, you don't rely on the compiler to find all your bugs, because it won't. You rely on unit tests, which means your basic bugs will be found at build time. The percentage of bugs that a statically typed compiler will find for you is small. You still need extra tests to find all your other bugs, and those tests will also find your basic type errors.

Re: that depends

[blippo]

I don't think the language itself is bad - there is not much bloat left in java8. The bloat is coming from code coventions and jee. And perhaps some retarded APIs - most of the core APIs are rather nice. Maybe low level programming is a bit awkward but doable, and i suppose you need C and assembly for AAA game engines.

There are a lot of architecture astronauts and other complicators using Java, that's for certain.

The JVM is rather fast once it's started, but that takes a while.

Java Is Corporate

[Baldrson]

Java has stuck around for the same reason Cobol stuck around for so long: It's corporate.

Does that mean Java isn't cool? No. But are we going to say Cobol is cool because it stuck around for so long?

Re:Performance improvements have helped it survive

[buddyglass]

You should run some benchmarks with and without Proguard. I'm curious to know what performance benefits it provides (if any). I was actually thinking more of running things like the web containers themselves through ProGuard. Tomcat vs. Tomcat+Proguard. JBoss vs. JBoss+Proguard. Or Eclipse, for that matter.

why a programming language needs to be hip?

[umghhh]

I thought a programming language is just a tool to do some job. Some tool are better some other are not so good and some cannot do particular task. Sometimes we work with a tool that is not suited for the job because of bad choice made long time ago by a person long gone and the change to more suitable tool never happens because it costs money and time. Sometimes the tool we have to work with is just good enough. I know none that is perfect for the job and by nature of things doing next project with the same tool may feel uncomfortable in slightly different then it used to. Other than that you still need to know about memory management even if you use a system with GC. But for all purposes the language is just a tool no need for it to be hip or cool. In fact I felt certain coolness about a programming language only once in my life. It was long time ago and when I look at this now then I wonder how silly I was back than.

Java & C#

[Qbertino]

Java combines the wonderfull readability of C++ with the blazing speed of smalltalk. C# is an innovative language from Microsoft that takes those two features of Java and adds in the portability of Visual Basic.

Re:Java & C#

[gweihir]

Well said! But I think Java has managed to be even more wonderfully readable than C++.

You Answered It Yourself in Your Question

[curmudgeon99]

Java was originally the free alternative to the Evil Empire--Microsoft. Because everything Microsoft sold was serious green--and because everything in the Java world could be found for free [Eclipse vs Visual Studio], [MySQL vs SQL Server], [Tomcat, JBoss, etc vs IIS] it was a no brainer.

Now, the single reason that Java is allegedly uncool is because it's the incumbent. It has been kicking ass, dominating the Enterprise Tech stack for so long that it's obviously not going to be hip and cool.

.NET is dead or dying while Java is the bearded king, hanging on and going strong.

Sure you have Python or Perl or Ruby or Go or Hack or Node.js or whatever but they just never seem to catch on in a big way. Sure, you'll find somebody who swears by Python or who thinks that Facebook's Hack abortion is the shit but they just don't catch on and they become curiosities.

Java remains the shit because it was the Anti Microsoft. Write Once, Run Anywhere [which of course was never totally true] but at least it's not Microsoft. Now that Microsoft is dead you have all these companies that tried to dethrone it but they have not been able. Google's "Go"? Even Google chose to base Android on Java. Java is not cool but it still owns the marketplace. For the foreseeable future.

Re:You Answered It Yourself in Your Question

[hibiki_r]

Java is uncool because it moves at a glacially slow speed, and has an ecosystem full of enterprise tools that do nothing but slow us down.

The first real shock came from Ruby on Rails. I'd never use the thing for anything large or requiring much customization, but it sure showed many Java programmers how the state of the Java art, full of Spring and Hibernate, was pretty unproductive, all things considered. To write production code, you don't really need the mess of AbstractFactoryProviders that Java had become. After this, we started seeing people writing JVM languages that cut some of that madness.

So now Java has been playing catchup to Scala, Groovy and Clojure, because you have the same Write Once, Run Anywhere features, but the code is 1/3rd of the size. Even languages that try to work on closed ecosystems try to mimic that kind of style: Just look at how much Swift looks like Scala's reference-counting cousin.

Java's inability to evolve the language will remain an issue for the foreseeable future. Just look at all the things java 9 is supposed to offer: The roadmap could be sold as a cure for insomnia.

Re:You Answered It Yourself in Your Question

[curmudgeon99]

I have done production work using Ruby on Rails (but the back end was still all Java). You are free to use any language you want. Learning Java has turned out to be the best career decision I have ever made. I have never heard any employer say: "The API on that language is too big!" You are free to use whatever language you want.

Re:You Answered It Yourself in Your Question

[curmudgeon99]

Danged interesting. Thank you for this.
My primary beef with Go is the same one I had with .NET and now with Facebook's Hack language. When the language name is a common word, it makes it hard to search on. If you go to stackoverflow and search on "Hack", you get everything but what you want. Try "Facebook Hack" and you get articles on ways to make things work on Facebook. It isn't until you go for "Facebook Hack Language" that you get what you wanted. So, how do you search for "Go"?

On Stackoverflow.com, when you search for "Go", you get:

1,488,459 hits and none dealing with the language.

Searching on "Google Go" gets you:

52,546 hits.
It takes a search on "Google Go Language" to yield fruit.

But I guess you already indicated the hack for getting those results, ala "dot-net": GoLang

Why should it be "cool"?

[nurb432]

Its a programming language, not a car.. It should be treated like a tool. What should be 'cool' is what you do with it..

Re:From a users perspetive

[gbjbaanb]

oh shit. that means all those devices are stuffed full of unpatched vulnerabilities.

I think you're believing the Oracle hype they sell you in the installer. Most devices are written in C.

Trash sticks around

[gweihir]

Until somebody makes a real effort to get rid of it. Juts look at PHP, JavaScript, etc.

Re:"coolness" is a stupid measure

[gweihir]

In fact, the last is true, as Java never could measure up. The thing is that Java made the dumbest programmers able to produce bad, but runnable code because the language is so bad that you cannot do anything with it without a modern IDE. That does remove the need from programmers to actually understand the language tough.

And no, reliability of Java with the typical Java programmers is actually far, far worse as C with the typical C programmer, and so is productivity.

Re:I am sure.....

[gweihir]

Except that I do not like Java as a programmer one bit, I completely agree.

The language you want today is Swift

[Applehu Akbar]

[Ducking from a cloud of hurled, sharpened WIndows 8 install discs.]

JavaBOL

[bwcbwc]

Yeah Java is the COBOL of the 21st Century. It's the lowest common denominator, almost every programmer knows at least the rudiments, and the tool and support ecosystem around it is huge.

Not Java, but the people who write it

[Gothmolly]

It's a product of its times - with many more "computer science" people in the field, math says you're much more likely to run across crappy ones than you were before. (Not a bell curve issue, the bad ones are more memorable) Add in the H1B headwobble factor, and you have a lot of shitty java code, doing things because it can not because it should. Add in a corporate culture where time to market trumps reliability or maintainability, and you have a management philosophy that rewards the above behaviors.
Java is shitty because the world has turned.

It's not Java, it's the JVM

[MillerHighLife21]

Java as a language is a pain to develop with. Java selling points have always revolved around the JVM itself and a bullet proof, over-engineered backbone that is needed for "enterprise" workloads. In big company's who don't have urgent timelines where they are willing to invest time to micro-engineer solutions it's used very heavily. For applications under heavy workloads, the high stress parts are usually built in Java for maximum efficiency but it's been the JVM, JDBC, server infrastructure and the polished library of tools around it that have buoyed it's success.

With the ability to run other languages on the JVM and get ALL those benefits without actually being required to code in Java though...now that's pretty cool. jRuby, Scala, Groovy, Clojure, etc are making the Java world a heck of a lot more interesting. If the early rumblings around the dramatic gains that jRuby is making with Java 8 are true you might just see the world implode at the idea of Java performance with Ruby development timelines. Early public benchmarks on Techempower are already looking about 30% faster than Scala.

Re:It's not Java, it's the JVM

[DickBreath]

The JVM does some pretty amazing things. It has some pretty amazing optimizations. You can run a lot of languages on the JVM.

Most modern languages now take garbage collection for granted. If you build your new language on the JVM, you get GC for free. And a GC that has been researched, developed and optimized for almost two decades. You get a choice of GC algorithms. Each GC has many tuning parameters. (More than you need.)

You're right. It's not Java that is cool. It's the JVM.

The JVM compiles the JVM bytecode to machine code. On the fly. It continuously dynamically profiles your code to determine what needs to be compiled to native code. It aggressively inlines functions. Even though all methods are virtual functions, if the JVM can prove that there is only one implementation that exists for this method, or only one implementation that could be the actual one that would be invoked at a certain point, then it compiles it as a direct non-virtual call.

But, classes can be dynamically reloaded during runtime. So other code that inlined methods from the class being reloaded now has inlined code that is obsolete! The JVM will ensure that those methods are recompiled (possibly re-inlining, or not) the code from the newly loaded class. And it will ensure that this recompile happens before the stale inlined code can be executed again.

All of this is cross platform. Because your code is compiled by a compiler that knows about the actual hardware you are running on, it can do optimizations that are impossible in an ahead-of-time compiler like C. It can use extended instructions from the instruction set of the actual processor you are using. Furthermore, since it knows the entire set of code making up the application, it can do global optimizations that are also impossible with ahead of time compilers. An ahead of time compiler doesn't know anything about the implementation of the libraries that your program will link against at runtime. If the compiler knew about the actual implementation of the libraries that your application code was calling, there are optimization opportunities that an ahead of time compiler cannot make assumptions about.

With the JVM you can have heaps that are tens of gigabytes (or hundreds with some third party JVM implementations) and have max GC pause times in the tens of milliseconds.

That is what makes 'java' cool. It's the JVM. It's also the JVM that makes Java so darned fast. Not the Java language itself. Nor the Java compiler to JVM bytecode. The JVM has a unique perfect storm of amazing features that make it so attractive.

Re:It's not Java, it's the JVM

[DickBreath]

It's not just the JVM. It's the fact that Java (and all JVM languages) have Garbage Collection.

When people (even in this Slashdot comments) talk about non-GC languages and compare then to GC languages such as Java, they are missing something important.

I have seen comments here comparing the language features, and concepts computer science students learn from either C or Java, etc. But they miss something very important.

When you have GC, you have something that deeply enables the ability to create vast libraries of code that interoperate well together. It is something so deeply implied in the source and binary ABI and APIs that you don't see it. Because of GC, there doesn't need to be any 'contract' in APIs about who owns what data structures. Who is responsible to delete what. What the protocols are for who is responsible for disposing of what, etc.

This cannot be overstated. This enables the creation of libraries that can create, or be passed external data structures, and can create and return data structures, without any concern for who owns what or who is responsible for disposing of what.

This is true whether the language is Java, Python, Ruby, etc, etc, etc. The GC languages are in an entirely different class than C or C++. Yes, I know that those languages have GC grafted on. But which GC mechanism? Do all of your libraries support it? Universally? What about some libraries use this memory management protocol and contract (maybe even non GC), and other libraries use a different memory management protocol and discipline?

Insightful point on communities; thanks!

[Paul Fernhout]

I'm moving more of my own work from Java to JavaScript, but that is mainly because JavaScript is easiest to deploy almost every where. I generally like Java+Eclipse better for big projects otherwise. However, with tools that compile other languages to JavaScript, and browsers that can get near native performance from JavaScript if written in a certain way, I'm hoping the "JavaScript" approach will continue to gain in benefits because it is just easier to deploy than Java. It's too bad Java app deployment to the desktop was never a real priority (even with Java Web Start). As an example of the difference (including in sandboxing), some school teachers can get fired for installing new software without permission (which could include a Java app which can do anything), but they can use a web browser to load up an educational web page which uses JavaScript to run a simulation without too many worries.

I fought against Java back in the late 1990s compared to using Smalltalk. Back then Java was just a mess and a mass of hype. But I can accept Java is now a half-way-decent solution for many things now that many of the worst rough edges of Java have been smoothed off. I still miss Smalltalk though, and to some extent (not all), JavaScript recaptures some of the Smalltalk flavor and community -- if I squint just right, I can kind of see the entire Web as one big multi-threaded Smalltalk image. :-)

Re:Performance improvements have helped it survive

[DamonHD]

I promise you that it was worth saving many MB in the .WAR and associated thumb-twiddling time, plus showing me in the logs which library and other routines were actually being used. I never felt the need to time stuff (since performance was at least not visibly worse). Shame on me!

If I get a chance I'll do as you suggest, though it'll be tricky with all the many things going on concurrently.

Rgds

Damon

Re:Performance improvements have helped it survive

[DamonHD]

Except that once JIT/Hotspot is involved all or most of the executions *are* of compiled machine code, optimised to the particular CPU on hand and the particular data set for this particular job. So things like dynamic inlining *for this particular job* can allow the JVM to produce *better* machine code which will execute more quickly than statically-compiled code.

The translation takes time, but for long-running tasks that may well be easily amortised away.

So single-threaded Java can beat single-threaded C++.

But I can also bring more CPUs to bear on the code safely with Java for a given level of code complexity (well, now C++ finally has some sensible volatile semantics, that's a little less true).

And there are other factors such as the generally forced synchronous nature of C++ heap handling which can work against it.

Rgds

Damon

Re:Ten years ago

[NormalVisual]

Ten years later, XML has been largely superseded by REST and Web Services is basically gone

I think you might have meant SOAP, not XML. There are plenty of people writing REST services that speak XML.

Ecch

[Enry]

As a non-programmer, Java stinks.

The idea of it being sandboxed and thus 'more secure' is blown out of the water every time there's an update, of which there are many. Each update from Oracle wants to install the Ask toolbar.

In its earlier days applications had to be distributed with specific versions of the JRE. Even more recently there were plugins that only worked with Java 6 and the vendor had no intention of getting them to work Java 7. The idea of 'write once run everywhere' is mostly dead.

On the server side (Tomcat) it's okay. On the embedded side (Android) it really seems to have finally found its stride..

Re:Ecch

[martin_dk]

The bundling of AskToolbar with Java is a prominent example of browser hijacking, and Oracle does this in the open without even bothering to comment on the issue.

Until the end of 2014 danish citizens have been forced to use Java in order to access our banks and public accounts. The automatic updates install the AskToolbar. Even if you manually succeded in uninstalling it earlier.

In the attempt to create a secure channel of communication via Java, everybody was served a third party browser toolbar which scrapes your pageviews and records your every move on the internet.

This is how much Oracle cares about security and privacy on the internet.

Re:Ecch

[Shortguy881]

As a non-programmer, your points hold no weight here.

Java or JVM?

[iamacat]

As long as the later is adequate, success of the former is immaterial. A language like Scala that runs on top of JVM can make full use of availability of the platform and libraries of existing code. For me, the biggest limitations of JVM seem to be 2^32-1 limit on array indices and no option for explicit, real time memory management. Perhaps experts greater than me can comment more. Does byte code provide enough information to support vector instructions of modern CPUS/GPUS?

Anyone remember, "Write once, run anywhere"?

[chaoskitty]

Sun's slogan for Java used to be, "Write once, run anywhere." Remember that? Sun didn't make JVMs for many platforms, and didn't even have an official JVM for GNU/Linux for ages. Add to that the fact that each major version of the JVM deprecated features and introduced incompatible ways to do things previously done other ways, and it's no wonder it has become the case that we (meaning IT folks) have to keep around an older (perhaps virtual) machine which has an older and certainly insecure JVM to talk to some hardware device or application which requires older Java. Qlogic switches come to mind.

Since the JVM isn't portable, Java isn't portable. Since software written for one JVM version can't necessarily run on another version, it's not very backwards compatible. Since it has so many security issues, you either have to hope that whoever makes your JVM keeps it up to date or that you're very careful about how it's deployed.

I can't personally think of anything more precarious than trying to deploy real software using Java.

Re:Anyone remember, "Write once, run anywhere"?

[sproketboy]

Dude stop talking out of your ass. You clearly have no idea what you're talking about and your smelling up the place.

Re:Anyone remember, "Write once, run anywhere"?

[Daniel Hoffmann]

Just to nitpick one of your wrong comments, deprecating features is a healthy thing to do. Languages without proper deprecation mechanics built-into them quickly turn into a clusterfuck.

Re:From a users perspetive

[julesh]

Then you get to enjoy the unbearably slow performance, and HP-UX style UI from 1992.

Ahh good ol' CDE i never drew the comparison but that's bang on lol, i wonder if java's ui elements were modeled after CDE

When running on X11, Java's default UI is based on the motif toolkit, which is the same toolkit that CDE was based on, so the answer to your question is "indirectly".

Re:From a users perspetive

[julesh]

As i look around *my* room, i see embedded linux devices that are running mostly binaries primarily written in C, many smaller electronics with simple micro controllers, even a windows CE embedded device running software written in .NET and one java based device my phone..

If i think about whats in my car, its a windows CE embedded device running native applications.

java does a lot of enterprise, android and a decent % of webapps. other than android apps rarely do i see something that is java that behaves as well as the non java equivalents

Do you have a BluRay player? A DVB-based set-top box or a TV with integrated DVB decoder? Either of these would typically include a JVM.

Still going strong, huge community!

[pchenden]

My workplace provides Java consultants for hire, and is doing quite well.
Recruiters are in contact with me every week.
The amount of Open Source Java software available and actively developed, especially libraries, is amazing!
All Android apps are Java-based too.

To balance this out, some of my colleagues and I are looking into other languages and consider ourselves polyglot programmers, not Java-only.
Especially other languages on the JVM like Groovy and Scala are popular.

bah

[sociocapitalist]

Because there's nothing quite like a nice cup of hot java....

Performance improvements have helped it survive.

[Kartu]

Note that there is nothing that makes JIT compilers generate slower code.
On the opposite: JIT compiler can gather profiling data, and improve code over time. (e.g. knowing which branch would be taken most of the time) what static compiler can not.

Inherent "slowness" and "memory hungriness" comes from the automatic memory management (garbage collection) and additional runtime type/boundary checks. Also a bit because of "write once run everywhere" (e.g. sin/cos functions are like 100 times slower than in C/C++, because CPU's features aren't used, to get exactly the same result on all platforms)

From my personal experience, Java's speed was on par with C/C++ code, while having much bigger mem footprint.

fat cow?

[PC_THE_GREAT]

Maybe because when one think of Java, one automatically thinks of a heavy framework and bad user experience. That is the general feeling about anything associated with java.

It's an unavoidavle pain in the ass now

[gelfling]

It's Microsoft

Poorly Phrased Question

[fygment]

When I read "_how_ C strings work...", I began to think of what I knew about how the C language is actually implemented. And frankly, I don't know how C is implemented (eg. what happens after parsing, how things get converted to CPU instructions). Even though I've spent a fair bit of time writing in the language, I would have stumbled on that question and perhaps have asked you to clarify (something a younger person is less likely to do).

When I read your answer, I realized you were asking "how are strings defined in C" or "how do you use C with string types".

See the difference? On that alone, I guess you may have screened out a lot of good people.

Tangentially, this is also a good reason to not pay too much attention to survey results unless you have actually read the questions that were asked in the survey.

Cool? No. Common? Workhorse? Yes.

[mr_mischief]

I doubt too many people think a cast iron pan is cool. Yet it can be used to bake, broil, fry, sauté, reduce, and more.

Is mergesort cool? Are linked lists and hash tables cool? They are common building blocks, but are very useful.

Is DRAM cool? Are x86_64 processors sexy?

Is the Honda Accord or the Toyota Camry "bitchin'"?

Are asphalt shingles as impressive as a slate roof?

When your job calls for a sturdy workhorse, you don't need a thoroughbred racehorse. You don't haul gravel in a Huracan. If your project calls for Java, or C++, or Fortran, Ada, or even for COBOL then you use what gets the job done. If it calls for rapid deployment from a small team, you might use Perl, Python, Ruby, Javascript, or even a shell script. If you need Erlang, Forth, Swift, some assembly language, or some Basic dialect due to platform, existing code, etc then you just suck it up and do that. If you have a chance to do greenfield development and can pick your language, pick anything that works.

If you're in a Java shop working on a Java project, you write and debug Java. Sometimes there's more than one right tool for the job, but you use the one everyone in your workshop has and can use.

Learning a language is easy; but a paradigm is not

[CraigCruden]

Learning a language is easy, but learning a paradigm is not. I usually pick up a language in a matter of days and can program fairly competitively pretty soon.... but I found that most developers that came to Java programmed how they did before because they failed to grasp the paradigm that the language was designed for. Programmed in Java for 15+ years, but prefer programming in Scala over Java. Java ecosystem is scattered with "advancements" that only later did we learn was holding us back. I am sure Scala will eventually be the same way. I found that moving to Scala with it's full support of object-oriented paradigm and full support of functional paradigm has allowed me to produce cleaner more concise code.

Had the best jobs when I looked...

[evanthx]

I prefer C# honestly. I live in Seattle, so I figured a C# job would be easy to get. And it was...but the Java jobs paid a lot more. So I am still a java programmer.

Exactly

[bigsexyjoe]

As you said, they use Java.

You don't really have any citations for anything you said. But I doubt they did huge amounts of refactoring in three months and then stayed with their new solution even after they found out the language wasn't the problem.

"Over time, they wrote more and more parts in other languages, which is natural because they're big and they want each piece to be optimized."

Exactly. I didn't say Java was one language to rule over all. I said it has it's place and companies such as Twitter and Google agree.

Re:Exactly

[Aighearach]

You don't really have any citations for anything you said.

I didn't cite it because their blog posts, first blaming Ruby/Rails and a few months later, retracting that and explaining the problems, are some of the most popular blog posts in the history of Ruby, and a major milestone in the public discussion of these issues.

If you don't even know about it, you're too far outside the developer community for my comment to have been targeted at you. Sorry, I only worry about the nerds when I post. Everybody else can suck it. And if a nerd didn't know, they'd find a search engine, and ask, instead of whining at the internet to contain citations.

Re:Exactly

[bigsexyjoe]

No. It is not on the people who read your comments to research your claims. It makes more sense to just doubt them than try to find out if what some random guy on the Internet says is true.

In any case, you admit they use Java, so I have no idea what your point is.

Java is obnoxious

[rhyous]

1. Java is obnoxiously verbose. Despite having an example of properties from C# and cries for them to support them, they have failed to do so. So the syntax for creating getters and setters takes so much longer. Everytime I wrote code in Java over C#, it takes so many more lines. C++ compiler should support properties by now too.
A few years old but: http://www.slideshare.net/jeff...

2. The IDE. Besides having the look of an app from the 90's, Eclipse is a mess. It takes hours and hours of plugin research to get the same feature set as the default install of VS. Even basic features, like basic font size and themes, are unacceptably difficult. Then you have to add plugins to do anything worth while. Netbeans seemed to work better for some things but have less plugins.

3. The java installation is a pain. Both java and the IDE. Microsoft has the benefit of .NET embedded by default. And if a new version is needed, it comes with the IDE. The install of Visual Studio is simple and easy. You download and install it and it will install the needed .NET version and everything just works with one install. With Java, you have to find the right JRE/JDK and heaven forbid you get the one that doesn't have that enterprise feature. Eclipse is just a zip file. It isn't even an installer. So you have to manually add options to the Start page yourself if you want them. Not to mention the pinning issue. You pin it, but when you run it, it doesn't run under the pinned icon.

4. Oracle. Enough said.

 

And it's still a disaster

[whitroth]

As witnessed by the 100+line stack traces when tomcat crashes....

                    mark

Re:Java?

[pezpunk]

really? how do you maintain a path through the internet that doesn't include any java-based back ends? impressive feat, that.

Re:I hope not, de-facto

[LinuxFreakus]

Why is java obscure? Sure you need to write a bunch of boilerplate code, but it is just a programming language which happens to be widely used. There is nothing about it which makes it particularly hard to learn or "elite". Python is not "easier". It just takes less boilerplate to do a lot of common things (although in many cases the performance suffers). There are certainly things in the Java language which I'm not fond of, but show me any language and I'll tell you about its flaws. I have yet to find a perfect one.

It's still a turd

[ebvwfbw]

No two ways about it. PIA to develop in, PIA to debug in, PIA to maintain. Still it seems we're in the critical patch of the week club. Fix it ORACLE! Tired of you guys band aiding it and then patches to the patch and patches to that patch instead of fixing the base problem. Might be painful to fix code once the base problem is fixed, however it seems like we're dying of a thousand cuts.

For Java programmers only

[paulo.ortolan]

If Java is not cool, when Java was?

Re:I hope not, de-facto

[bbsalem]

Why is java obscure?

What is the very first thing you have to say to write a Java program as required by Sun's Class Libraries?

It is:

public static void main(String[] args)

This has to be shown to a complete and utter novice in the very first program he can write, and it is "biolerplate", as you put it, which that person will not understand at all without knowing quite a bit about object hierarchy and method prototypes. The design of acm.jar hides this nonsense, behind an object console. The interface for the novice is much simpler.

Sure you need to write a bunch of boilerplate code, but it is just a programming language which happens to be widely used. There is nothing about it which makes it particularly hard to learn or "elite". Python is not "easier". It just takes less boilerplate to do a lot of common things (although in many cases the performance suffers).

Java has been taught as an introductory programming language, and not necessarily to CS majors, only. It is widely used, especially by business, and I think that the way it was designed and sold to them was as a language that was intentionally designed to be hard to learn; only for people who could tough it out through a steep learning curve; lots of up-front concepts and details to learn before you can write your first useful program. I know, I took Sun's Java courses in the 1997 time frame. The most difficult part is not the language design, you can eventually learn the rationale for the way main is called, it is the complexity and number of class libraries. As proof of that note how fat the Java in a Nutshell book from O'Rieley is. Last time I looked it was close to 600 pages of dense text, Like PL/1, I think the language was designed to be obscure and to select for an elite that worked for a bank or financial company in their Glass House, and it was sold that way by Sun as a form of security by obscurity. Java will be used for a long time, but if you note the number of other languages with totally different syntax that use the JVM, that tells you that others think they can readily design a better language. The alternative interface in acm.jar, written by the ACM in 2006 should inform you as to how much it needed improvement as soon as Sun open sourced the class libraries.