Why is Java Considered Un-Cool?

jg21 writes "After the Slashdot discussion on Paul Graham's 'Great Hackers' essay, it had to happen. Java developers have taken umbrage at Graham's assertion that "Of all the great programmers I can think of, I know of only one who would voluntarily program in Java. And of all the great programmers I can think of who don't work for Sun, on Java, I know of zero." Now in JDJ Sachin Hejip pinpoints the Top Reasons Why Java is Considered Un-Cool and to tries to debunk them. He levels some of the blame at the Java compiler for "too much chaperoning" and speculates that Java fails the geek test precisely because "it's such a language-for-the-masses." But isn't he missing the point? Enterprise-grade apps and "coolness" may be inapproriate bedfellows. Besides, does any language offer both?"

Comments

What is this responding to.. exactly?

[Defiler]

I'm not sure the article author has actually read the Paul Graham essay that he is responding to.
He almost entirely fails to discuss any of the attributes that Graham assigns to languages that 'Great Hackers' like to use.
In particular, Graham claims that terser languages are more powerful, because studies have shown that coders churn out a pretty constant number of lines per day, regardless of the programming language. Java is anything but terse.
I could go on, particularly since the Sun JVM isn't open source, and Graham makes a point of claiming that Great Hackers prefer to use open source tools. I think frantic defensive articles regarding Java aren't helping anyone. The managers that choose Java don't read Paul Graham articles, and I doubt Paul Graham much cares what a Java-oriented business journal has to say about his articles. Please note that I am just relating the opinions that Graham has put on his website. I do not necessarily share his views.

Re:What is this responding to.. exactly?

[skaffen42]

Yeah. Java really sucks and is uncool. No open source programmer would ever use it.

Hell, could you ever imagine an orginization like Apache producing Java code. If that ever happens I'm giving up and moving to Jakarta.

Re:What is this responding to.. exactly?

[LWATCDR]

I do not find java all that verbose. Terse or not the really key to getting real work done quickly is a large collection of libraries so you do not spend your life reinventing the wheel. Look at Perl it is not a pretty language but cpan makes it so useful that it has yet to be replaced by Python or Ruby.

Re:What is this responding to.. exactly?

[telbij]

I'm not sure the article author has actually read the Paul Graham essay that he is responding to.

I'm not sure either.

The reason Java is considered 'uncool' in a majority of cases is a lot like the reason certain people are considered uncool in high school. It's mostly prejudice from people who are desperate to be accepted by their peers. Certainly some people have given Java a fair shake and decided they hate it, but the majority are just jumping on the bandwagon.

Frankly I expect better from geeks. It's come to the point where I don't even listen anymore because every diatribe against Java is based on some small pet peeve or overly specific scenario. Everyone rehashes the same old arguments ad nauseam. Quit yer bitchin' and write some goddamn code and you might be useful for once.

Re:What is this responding to.. exactly?

[putaro]

Well, I learned to type long ago. I tend towards long, descriptive variable and method names because they cut the amount of time I spend trying to figure out WTF "i" is doing in this loop and I can search for them. This fits in well with the naming conventions in Java and is one of the reasons I like using it. Using an IDE such as Eclipse and method/member name completion speeds me up even faster. I've churned out 40K lines of Java by myself in the last year.

This "Is Java Cool?" stuff is amusing. When I was organizing a startup in 1998, putting the code together in Java was a major draw for engineers as there was a definite coolness factor then. I'm not sure what would have that kind of buzz today.

Re:What is this responding to.. exactly?

[mwood]

"the managers that choose Java"

Hey, waitaminute, who let the *managers* choose?

"Fred, here's a saw. Go pound some nails in."

Re:What is this responding to.. exactly?

[iabervon]

I have to agree that terseness is good; I've found that the changes in Java 5 make it much faster to write. If you don't count lines with nothing but single braces, however, Java is getting pretty good. The main thing that sucks is small callbacks, where you have to have a couple lines of junk around the code.

Hopefully, Java will get parameterized types with a variable number of parameters, and then can have methods as first-class objects.

The thing that makes most Java verbose these days is that the standard libraries, while extensive, are often awkward. It's actually pretty easy to make a library of wrappers that reduces an unreadable 10 lines of code to "ReflectUtils.getStaticFieldValue(cl, name)" and such.

Re:What is this responding to.. exactly?

[jimfrost]

studies have shown that coders churn out a pretty constant number of lines per day, regardless of the programming language

This is true, but that is not the whole picture. One of the things that was obvious right away is that minimizing the number of things the programmer can do wrong causes a significant jump in the effective productivity of the programmer.

Brooks talks about this in the Mythical Man Month as it related to assembly versus high level languages, but we do see the same effect when moving between a language like C and something like Smalltalk or Java. It has been my experience that a good programmer writes more and higher quality code in Java versus C or C++, largely due to three factors:

1. Mandatory exception handling forces error handling down into the code where it can best be dealt with. In other words, you have to work harder to not handle abnormal situations.

2. Garbage collection eliminates whole classes of memory mismanagement problems.

3. Standard libraries contain many useful classes that had to be written independently in C/C++ (leading to a variety of different container classes, for instance, of widely varying usability and quality).

All three of these affect both time to deliver and quality of delivered code. We're not talking about minimal changes in productivity, either. I've been watching and working with Java and C++ since ... well, pretty much since they made it out of the laboratory. The improvement in real world productivity seen with Java is a factor of two to four greater on average versus C/C++ (measured by "how long does it take to get this feature to work", which is not necessarily the same as "how much code did I have to write"). Often lower for GUI work (depending on which GUI toolkit/tools you're using) but much higher for network code. Moreover, bug counts in released code are dramatically lower, like one tenth as many, and they tend to be less serious (a feature may fail, but seldom does the entire application fail).

In any case I guess I would have to vehemently disagree with Graham's contention that great hackers don't use Java. I suspect that is more a matter of which circles you run in, as that certainly doesn't hold true in my experience. There are fewer using it today than three or four years ago, but I surmise that that is mostly a matter of language maturity; the best programmers tend to sit on the bleeding edge, and that's not Java anymore.

Your mileage may vary, contents may have settled during shipping, etc.

Re:What is this responding to.. exactly?

[ArbitraryConstant]

meh

The Java API is so large that wheels often get reinvented because no one can bloody find the 19" wheel with a particular bolt pattern an the type of treads they want.

Re:What is this responding to.. exactly?

[Tim C]

Graham claims that terser languages are more powerful, because studies have shown that coders churn out a pretty constant number of lines per day, regardless of the programming language. Java is anything but terse.

So, use a decent IDE, one that features code completion - type the first few characters of the name, hit ctrl-space (or whatever, as appropriate) and it completes the symbol for you. Meanwhile, having more descriptive names improves code readability (and thus maintainability).

Next argument agaisnt Java, please.

Re:What is this responding to.. exactly?

[LWATCDR]

That is an interesting idea. Too many choices? Better to spend the time hunting for a 19 wheel with the right bolt pattern than having a chunk of ore, a forge, and an anvil handed to you.

Re:What is this responding to.. exactly?

[philipborlin]

Check out https://sourceforge.net/softwaremap/trove_list.php ?form_cat=160

When I looked at Sourceforges projects by languages it came up with:

• C++ - 13440 projects
• C - 13254 projects
• Java - 12436 projects
• PHP - 9201 projects
• Perl - 5321 projects
• Python - 3316 projects

This hardly supports the argument that open source programmers prefer open source languages since none of the source forge crowd's top 3 languages are open source.

Re:What is this responding to.. exactly?

[mav[LAG]]

Paul Graham points out why this happens in another of his essays, Revenge of the Nerds.

The pointy-haired boss miraculously combines two qualities that are common by themselves, but rarely seen together: (a) he knows nothing whatsoever about technology, and (b) he has very strong opinions about it.

Suppose, for example, you need to write a piece of software. The pointy-haired boss has no idea how this software has to work, and can't tell one programming language from another, and yet he knows what language you should write it in. Exactly. He thinks you should write it in Java.

Why does he think this? Let's take a look inside the brain of the pointy-haired boss. What he's thinking is something like this. Java is a standard. I know it must be, because I read about it in the press all the time. Since it is a standard, I won't get in trouble for using it. And that also means there will always be lots of Java programmers, so if the programmers working for me now quit, as programmers working for me mysteriously always do, I can easily replace them.

Well, this doesn't sound that unreasonable. But it's all based on one unspoken assumption, and that assumption turns out to be false. The pointy-haired boss believes that all programming languages are pretty much equivalent. If that were true, he would be right on target. If languages are all equivalent, sure, use whatever language everyone else is using.

Re:What is this responding to.. exactly?

[TheWanderingHermit]

Java is anything but terse.

I know there's been a gazillion comments, but there's one thing I don't see mentioned that I want to mention. Before I do, a brief note on my background: I learned BASIC in high school in the '70s, then Fortran and Vax 11/780 Assembler in college, then taught myself 6502 Assembler and programmed a lot on my Apple //e. For over a decade, I didn't touch anything to do with programming. Then I had a chance to put some programs together and start my own business. I had to learn languages that weren't even around when I had programmed before. I've had some formal classes in programming, but I'm mostly self-taught. I've had some coder friends tell me that I seem to automatically follow a lot of "good programming practices" that I was never taught.

I started with (and hated) Tcl. I found a book on Perl that was about 75% off, bought it, and was writing useful Perl code in under a day. When I had to learn Java, it took several books and was 2-3 weeks before I could write anything useful (in part due to needing to get used to the API before I could do anything I needed).

When I code in Java, I'm always reminded of the scene in Spaceballs where Col. Sanders keeps saying, "Prepare for..." and Dark Helmet interrupts and says, "Why do you have to prepare for everything?" In Perl, if I want to do something, I do it. It takes a line or two of code, and I'm done. In Java, to do something I have to prepare for it AND do it. I often have to create from 1 to 3 objects to finally get the object I need, then I can finally do what I wanted to do. For example (and please don't get picky -- I'm picking a simple, quick example and there are thousands of others), if I want a list of files in a directory, in Perl it's:

@file = glob($filename."/*");

In Java, I have to do:

File myFile = new File($filename);
String[] myList = myFile.list();

It's a small example, and I know I can combine creating the myFile object with getting the file list, but the point is I can't just DO it, I have to prep it and do it. I'm always going around my thumb to get to my elbow. In Java, I'm too busy keeping track of object types, creating objects (and sometimes creating objects, using that object to obtain another, then using the obtained ojbect in creating a third...) that I feel like a lot of my focus is on taking care of Java's needs rather than on writing my own program.

I like working in Java. I like the cross platform abilities. I like Swing, since it is (to me) an esay GUI to write for. I like the class structure. But I don't like writing in Java as much as Perl and, given a choice, I'll take Perl whenever possible. I've found I can put a program together in Perl in a day and it'll take 2-3 to write the same thing in Java.

Re:What is this responding to.. exactly?

[Tassach]

[N]one of the source forge crowd's top 3 languages are open source

Can I have some of what you're smoking? C and C++ are ANSI- and ISO-standard languages with multiple independent fully open-source toolchains. The Java language specification is still controlled by Sun, so it isn't an open standard; however, there ARE open-source implementations of that standard.

Re:What is this responding to.. exactly?

[ArbitraryConstant]

And yet... other languages with smaller APIs let you do all the same things, without more effort (often with less) with a smaller API. The Java API is bloated because the architects were in love with abstraction.

Re:What is this responding to.. exactly?

[LWATCDR]

The only languge I have seen that even comes close would have to be Perl. I use perl but I can not say that I really like it all that much. I have found Java to be very usful if sometime frustrating language to work in.

Re:What is this responding to.. exactly?

[Quantum Jim]

In particular, Graham claims that terser languages are more powerful, because studies have shown that coders churn out a pretty constant number of lines per day, regardless of the programming language. Java is anything but terse.

That is an insightful essay, but I disagree with a few of Graham's assumptions. For instance:

I think a better measure of the size of a program would be the number of elements, where an element is anything that would be a distinct node if you drew a tree representing the source code. The name of a variable or function is an element; an integer or a floating-point number is an element; a segment of literal text is an element; an element of a pattern, or a format directive, is an element; a new block is an element. There are borderline cases (is -5 two elements or one?) but I think most of them are the same for every language, so they don't affect comparisons much.

I think that this isn't broad enough. Whenever I read an novel or something, I tend to parse the text in discrete blocks. As a programmer, I tend to do the same with source code. It is almost trivial to convert any small code block between any language (normalized for one's familiarity with the language's syntax, of course).

However, the really hard part about programming - the part that requires skill - is understanding what small blocks of code to write and how to connect them together. Languages, which have features that help identify the relationship between code blocks, are easier to read. And I'm more productive in languages where it is easy to reconcile the ever-chaning model in my head with the code on the screen.

So instead of measuring terseness in code-elements, I perfer to use "natural" code-blocks built into each language. It doesn't really matter how many elements are required to implement a loop. In fact, I usually write code with "idiot-proof" variable names and verbose comments (though balanced with convenience). IOW documenting as I write. However, support for tying code blocks together - i.e. functions, objects, classes, prototypes, aspects, iterators, templates, and others chunks of code - is the real power of a language.

Re:What is this responding to.. exactly?

[Paradox]

The reason Java is considered 'uncool' in a majority of cases is a lot like the reason certain people are considered uncool in high school. It's mostly prejudice from people who are desperate to be accepted by their peers. Certainly some people have given Java a fair shake and decided they hate it, but the majority are just jumping on the bandwagon.

BS. Java is eclipsing Cobol now. Everyone has used it. If you've written code, you've probably at least written one small app in Java. Ubiquity is a double-edged sword.

Now, people hating Haskell might just be jumping ona a bandwagon. People who hate Lisp might be jumping on a bandwagon. People who hate Ruby might be jumping on a bandwagon. These languages are comparitively rare.

But Java? No.

Frankly I expect better from geeks. It's come to the point where I don't even listen anymore because every diatribe against Java is based on some small pet peeve or overly specific scenario. Everyone rehashes the same old arguments ad nauseam. Quit yer bitchin' and write some goddamn code and you might be useful for once.

How about this then? Java's type system sucks. It sucks, sucks, sucks. Java generics are only marginally fixing the problem. You cannot design your program up front. Heck, to refactor Java most programmers say you need tools. If your language is so intractable that it requires a tool to make refactoring reasonable, then you have a crappy language.

Java's primary GUI API, Swing, is not "brilliant." It's obtuse, lacks many features, and is unnecessarily slow.

Java's "Native Interface" (or FFI, "Foreign Function Interface") is hideous. It's difficult to get much of anything done at all. Ruby and Python provide much better models.

Are these complaints general and clear enough? Java is so riddled with flaws that it's amazing it's gotten this far. A living testament to the fact that marketing overcomes all.

Re:What is this responding to.. exactly?

[andy55]

1. Mandatory exception handling forces error handling down into the code where it can best be dealt with. In other words, you have to work harder to not handle abnormal situations.

By this logic every [C] OS API falls short of the "quality" of exception handling schemes. This is to say that exception handling seems to affect only devs that don't care (ie, a dev that cares will handle a C error scheme just as well). You are right that it's harder to blow off errors in Java, but if you have a dev that has a low care-level, he's going to write crappy stuff in *any* language.

2. Garbage collection eliminates whole classes of memory mismanagement problems./

Perhaps, but a well-designed and documented C API also "eliminates whole classes of memory mismanagement problems", using your words--look at the OS APIs. Separately, the upcoming generations of devs are failing to manage memory well b/c they're not responsible for its management. I've seen plenty of twirps chew through more RAM than you can shake a stick at because they don't realize the kind of memory they've (unnecessarily) tied up.


Silly as this may sound, I don't prefer java for the following reasons (keep in mind that I'm a dev who does performance-sensitive software on only Mac OS and Windows and is self-employed):

1. Lack of universal presence. As a shareware author, it'd be a nightmare to deal w/ problems of users having a bad or out-of-date version of java present (or not at all).

2. Low-level management. The graphics stuff I do in my stuff is low-level at times and would be otherwise impossible (or performance-deadly) in Java.

3. Ridiculously long class and method names. This one is a little silly, but it's true (for me). Code with short identifiers (but yet still well descriptive) that doesn't span an absurd line width due to long class and method names is much easier to read and comprehend (rather, as I've seen in Java, statements becoming far from readable because of the ridiculously long class and method names). Obviously, this point is more for me and less than ligament, but I'm curious to see if anyone responds to it.

Re:What is this responding to.. exactly?

[ArbitraryConstant]

While it lacks CPAN, Python modules for various things are easy to find with Google. It's a little more annoying, but having a language that's not annoying makes up for it very quickly.

Re:What is this responding to.. exactly?

[TheWanderingHermit]

There's always one who doesn't read the post, but responds to it anyway...

1) I said that was ONE example, just a simple one, and there were many more.

2) I also said I know you can do it in one line.

3) The point was NOT that it could be condensed into one line, but that it was a pain to have to keep thinking about Java's requirements INSTEAD of focusing on getting the task done.

4) Okay, that's one example, it's one step. I've had times where I had to create an object, use it to get another object, then use that object to create a third. While this could be done in one line, it makes for hideous reading if you ever troubleshoot it -- much worse than reading some lines of Perl. Showing a solve for one example does not mean the problem doesn't exist on a larger scale. It is a literal reading with a narrow focus of a much larger issue. It's like saying, "We fixed this one bug in Windows, so it's safe now," but still leaving tens of thousands of other bugs out there.

It's not that your way is wrong, it's that it has nothing to do with the overall point: that Java requires you to have to continually add steps to do something simple. Instead of just doing it, you prepare to do it, then do it.

Re:What is this responding to.. exactly?

[buster_dog]

Paul Graham think LISP is the be all and end all of languages. Any arguments about C vs Java miss the point

Re:What is this responding to.. exactly?

[zipwow]

Col. Sanders keeps saying, "Prepare for..." and Dark Helmet interrupts and says, "Why do you have to prepare for everything?"

This is an interesting example, because I think in the real navy, there's a straightforward answer: Sometimes your preparation fails.

In the example you gave, there are *two* points of failure. The first is that you can't find the directory you pointed at, and the second is that you can't get a listing of it. Making those things be separate forces you to consider the failure cases.

A large part of what Java is about is failsafe enterprise-level applications. When you write to that level of safety, you need to identify the different causes of issues.

In the same way, your day-sailer on a 12' boat doesn't shout to his crewmate "Prepare to tack!" because there isn't any reason to. If you're sailing an 80' schooner, however, you do shout to your crew of six "prepare to tack!" And then you wait in case someone shouts back, "Port side winch is jammed!".

-Zipwow

Re:What is this responding to.. exactly?

[Jerf]

Ignore the other two replies to your post as of this writing; they fall into the trap of "countering the opponent at all costs", even if it isn't the best idea.

The real problem with your post is that nothing in it is specific to Java. A lot of other modern languages do those things without the other weaknesses of Java, like Python. The only difference is Python doesn't have checked exceptions but that's a good thing.

Like the Fine Article seems to be (I can't read it, server hosed), that's a fine defense of Java in general, but it only reinforces Paul's attack, IMHO, by listing the "good things" about Java that are in no way unique to it. Paul didn't compare Java to K&R C like you implicitly do, he compared it to Python. You're going to have to work a lot harder to defend Java against Python... in fact I don't think it can be done as I'm basically with Paul here, but if you want to try, that is the real challenge, not defending Java as "better than C". (What isn't? If it isn't better than C somehow, it's dead.)

(The only other major point to make that I am aware of is the so-called "benefits" of static typing, which are also dubious if you actually examine the issue instead of swallowing what the theorists have pounded into your head. Both of the links to Eckel are only samples, there's a lot more on both topics; "eckel " + "static typing" or "checked exceptions" will bring up a lot more in the Google hits below #1.)

Re:What is this responding to.. exactly?

[Jack9]

Useful Perl code probably means, you were able to mimic sed/awk operations. It's always been easier to whip up an interpreted script over a series of fault tolerant GUI functions.

(As per AC)
String[] myList = new File(filename).list();

@file = glob($filename."/*");

I dont have to be a Java programmer to guess what the first one does. I specifically have to be a Perl programmer to know what the second does.

This is a large part of what Java was trying to accomplish. What's really disconcerting is that practical experience teaches that Perl ends up more like

@name = glob($var."/*");

where you have to recognize the syntax to understand the operation.

The reason people dont program in Java is having to set up a VM to run it as the standalone programs are too slow and large.

Re:What is this responding to.. exactly?

[Ba3r]

I think that encapsulation and inheritance are best used in concert, not in parallel. By this I mean that within an encapsulated module, inheritance can provide a valuable method of structuring and conceptualizing the tasks. At the same time, between encapsulated modules, it is useful to 'trade' objects with robust inheritance schemes. However, I doubt many would disagree that the modules themselves should incorporate inheritance (And this is why java has 'Interfaces').

And I wouldn't start declaring that history has shown anything about a language that has only been around 10 years in an industry that has been (effectively) around for 30.

Re:What is this responding to.. exactly?

[TheWanderingHermit]

I haven't had to work on anything as big as enterprise, so I can't speak (with any experience) to that situation. It seems to me part of what you are saying is that Java forces a coder to be safe, whether he/she wants to or not. I can see that for something on the scale your talking about, since you have many coders working and you don't know what the others are doing, you have to count on them being forced to maintain certain standards.

Not to drag out Perl again, but it has the nifty ability to add "use strict" to make sure you declare all variables and play by the rules. I think I'd use Java more often if I could use Java more if there were a similar setting so I could, for example, write a class that bypasses all the safety enforcements, strict types, etc., but could not if I turned on the "strict" or "safe" mode. Not that it would happen, but I just don't like being forced to "be safe." It makes me feel like I'm an adult, driving my own car, and being in a child protective seat.

Your example about the 12' boat is good. It also made me consider that even on a 12' boat, if you want to be safe, you could shout "Prepare to tack!" Just as, in Perl, if you want safety, you could add a line or two to make sure the directory exists. Personally, I like not having the extra overhead. Many times I've already verified, upfront, that all my resources are available, so once I write the start of the program, I can spend the rest doing what I need to do.

I also have to admit that all my programming is focused on one large project, which, although complex and multi-part (and multi-os), does limit my experience a bit.

Re:What is this responding to.. exactly?

[jimfrost]

if you have a dev that has a low care-level, he's going to write crappy stuff in *any* language.

While true, such a developer cannot implicitly ignore such errors in Java. He has to handle them or pass them off. This raises the effort level enough that in general they get handled at the point of the problem.

This does help, I've seen it in practice over some eight years of working on large Java projects.

a well-designed and documented C API also "eliminates whole classes of memory mismanagement problems"

Yes, that's true. And yet in practice you almost never see such code. Look, for instance, at the poor quality of string management in C and standard C++. How many programs manipulate strings? What's that? Almost all of them? Huh.

But the problem is actually worse than that, C and C++ arrays are inherently dangerous to use. Ever see a C or C++ program that avoids the use of arrays entirely, deferring them to container functions/classes? Me either.

The rest of your arguments are pretty good ones, although rather specific to particular kinds of applications. Nobody ever said Java was the best tool to use all the time.

Well, except for the "ridiculously long method names" comment. Learn to type, or use an editor with autocompletion. It is more important that the code be understood at a glance, even by someone not familiar with the codebase, than it is to save a few characters per line during development.

I do realize that this opinion is not widely held in the industry. Then again, an appalling number of programmers don't know how to type, despite the keyboard being their primary input device.

Re:What is this responding to.. exactly?

[TheWanderingHermit]

Actually, I think you have to understand the syntax with Java as much as with Perl. I learned Java for 2 reasons:

1) It was cross platform, so I could write it on Linux and know it would work on my client's Win32 systems (and eventually OSX, as well as Linux). It was also easier to learn Java and be able to do a cross platform GUI, than to learn C or C++ and all the changes I'd have to make for each OS. (At the time, there wasn't a GUI toolkit for Perl that operated on Mac, Linux, and Win32, except maybe Perl/TK and I forgot why I rejected that.)

2) I needed to control OpenOffice and, after several days of studying code for StarBASIC (which I could write in) for OOo macros, and looking over Java and C info on bindings for OOo, I realized the OOo API seemed to behave like Java's API, so it was easier to learn Java than another language.

While pouring overcode, and having not been taught about strict types (at least that I could remember), I found the extra declarations and several other features of Java confusing, but when I studied Perl, even before/without a book, I found it quick to pick up. Maybe that's atypical. All I can speak for is my experience.

There are some things in Java I like, such as the ease of having each class in its own file, which is easier in Java than Perl. I like the blackbox nature of classes, so I can spend days writing (in this case) a wrapper for OOo API functions, then never have to think about what goes on inside that class again -- just call the methods. Perl does that with modules, but it doesn't seem quite the same.

And you make a good point, with your example, about variable names. I've noticed that happens a lot, but I make sure I use clear variable names, since it makes life easier a few weeks later, when I'm debugging something I haven't had time to work on for a while.

Re:What is this responding to.. exactly?

[drmerope]

I think my point was that you are mistaken to believe that they can be used in concert. They are two very incompatiable concepts--their objectives conflict. As regards history, the past 40 years are full of projects that failed because of inadequate encapsulation.

Re:What is this responding to.. exactly?

[Brandybuck]

who let the *managers* choose?

Welcome to the real world.

While there are some exceptions, the real world of commercial software development doesn't let the lowly software developer decide on the language. While the developer can lobby for a particular language, ultimately it's a manager (or system architect) who makes that decision.

This is a Good Thing(tm). You want a system that is maintainable. You're not going to get this if two dozen developers each use their pet language du'jour. When you have Java, C#, C++, Python and Ruby advocates all working on the same project, you don't want them deciding what language their individual components will use. That way leads to chaos. Even if the framework allows it, such as .NET, it's still chaos.

If you think you have enough discipline to avoid this, you may be right. But you will be wrong if you think your coworker's do as well.

Re:What is this responding to.. exactly?

[KillerCow]

if I want a list of files in a directory, in Perl it's:

@file = glob($filename."/*");

In Java, I have to do:

File myFile = new File($filename);
String[] myList = myFile.list();

It's a small example, and I know I can combine creating the myFile object with getting the file list, but the point is I can't just DO it, I have to prep it and do it.

That's because Java is object oriented. You get the file list for an instance of a directory. The directory represents an ADT that you want to get the attributes of. You don't say "get me a list of files, here is a starting directory" you say "directory, give me your files."

If you want to do it in one line, do:

String[] dirContents = new File($filename).list();

In Java, I'm too busy keeping track of object types

Strict typing prevents many kinds of bugs.

I've found I can put a program together in Perl in a day and it'll take 2-3 to write the same thing in Java.

80% of the cost of software is maintenance (figure may vary depending on who you talk to.) If you are writing programs that can be written in a day, yes, a scripting language is going to suit you better. If you are writing something that is going to take several man-years, then a robust language that focuses on ease of maintenance is going to suit you better.

Re:What is this responding to.. exactly?

[jimfrost]

The real problem with your post is that nothing in it is specific to Java.

Certainly not. There's nothing whatsoever new in Java, it inherited every single feature from somewhere else. That in no way makes Java less interesting, since it does a pretty good job of combining a lot of good features in one place -- and being popular enough that you can pretty much count on an implementation being available, too.

Regarding Paul's article, you might notice that I didn't take issue with any part of it other than the idea that the best hackers avoid Java. His clique presumably does, but it's plenty easy to find high power hacks who either are building or have built significant amounts of code using Java.

For that matter, it's been my experience that the best are relatively language agnostic -- writing code in e.g. C, C++, C#, Python, and even -- god help 'em -- Perl. Pick J. Random Hacker and ask 'em what languages they've made significant use of over their career and you'll almost always get a laundry list.

Whatever gets the job done, right? The relative "goodness" of the language has little to do with it, which is easily proven by looking at how much work gets done in C and C++.

Re:What is this responding to.. exactly?

[thunderbug]

Good point. I suspect you'd like Python even more. Consider it.

Re:What is this responding to.. exactly?

[Maltheus]

"Why do you have to prepare for everything?" In Perl, if I want to do something, I do it. It takes a line or two of code, and I'm done. In Java, to do something I have to prepare for it AND do it.

Well you have to prepare your computer by turning it on. You have to prepare your typing by lifting your fingers. Each language has it's own "steps" to complete any task and your Java example make a lot more sense to me than your perl example. That saves me a lot more time in the long run.

I guess I once felt the way you did when dealing with java streams. You're always constructing streams by passing a stream into another stream's constructor. But now I love it. It offers such tremendous flexibility and it's akin to unix piping. Do you complain that cat doesn't have a 'cat only lines with a certain pattern' option or do you use the cat command to prepare the grep command for a more elegant solution?

Re:What is this responding to.. exactly?

[jimfrost]

I guess I'd have to disagree, the two are useful in tandem. One very common combination is an adapter implementation of an interface; your class inherits from the adapter in order to get a basic implementation of the interface.

But I suppose it's arguable that you only do that as often as you do in Java because the language makes encapsulation too hard. It should have something to specify that a particular member is intended to provide the implementation for an interface, eg:

interface IFoo
{
void bar();
}

class MyClass implements IFoo
{
IFooAdapter adapter implements IFoo;
}

In this case the compiler would automatically provide void foo() { adapter.foo(); } in MyClass. This would save the programmer a lot of time writing trampoline code, and make it easier on the optimizer too (though of course the concept of "Java optimizer" seems to be one of deliberate neglect on Sun's part).

If you want to complain about something Java has historically not done that it really should have done a long time ago I think I'd go with generics.

Re:What is this responding to.. exactly?

[LWATCDR]

I have yet to find a library that works with postgres under windows for python. I have for Perl and like having my code run under windows and Linux

Re:What is this responding to.. exactly?

[Brandybuck]

One of the things that was obvious right away is that minimizing the number of things the programmer can do wrong causes a significant jump in the effective productivity of the programmer.

You mention Fred Brooks, but somehow I don't think you've read his essay . In essence [sic] Mr. Brooks said that no single technology, management style, or methodology would provide an "order-of-magnitude improvement" in productivity. All we would see from then on would be incremental improvements.

While your use of the word "significant" is a far cry from "order-of-magnitude", you're still expecting something more than an "incremental" improvement. Java *PLUS* other stuff might get you significant improvments in productivity, but Java alone will not.

the best programmers tend to sit on the bleeding edge

Huh? While it's true that the "coolest" programmers use the bleeding edge languages, I do not see the best programmers doing the same. The two best programmers I know use assembly, C and C++. One of them is really excited about C#/.NET, but to be honest he gets really excited about any free CD arriving in the mail. He still programs in C though.

Of course, there is a correlation between the youthfulness and productivity of programmers. Older programmers get burnt out or move up to non-coding roles, and newbie programmers tend to explore the bleeding edge. Thus you are likely to find more cool, hip twenty-something programmers working sixteen hours a day in C#, than old, square, been-there-done-that progammers writing C for eight hours before going home to phone the grandkids. That doesn't mean the kids are better programmers though.

Re:What is this responding to.. exactly?

[Brandybuck]

Sorry, that link should be http://www.virtualschool.edu/mon/SoftwareEngineeri ng/BrooksNoSilverBullet.html

One of these days I'll learn to preview...

Re:What is this responding to.. exactly?

[drmerope]

"But I suppose it's arguable that you only do that as often as you do in Java because the language makes encapsulation too hard. It should have something to specify that a particular member is intended to provide the implementation for an interface," This was the point I was intending to make. Java does make encapsulation too hard and many the benefits of inheritence can be more safely achieved via encapsulation. I am not arguing that inheritence is useless. Rather, my point is that encapsulation is clearly important and that Java should be faulted for stressing inheritence over encapsulation. "This would save the programmer a lot of time writing trampoline code, and make it easier on the optimizer too (though of course the concept of "Java optimizer" seems to be one of deliberate neglect on Sun's part)." Yeah, basically it is syntactic sugar. "If you want to complain about something Java has historically not done that it really should have done a long time ago I think I'd go with generics." For a langauge that gets these things "right" take a look at DECs modula-3.

Re:What is this responding to.. exactly?

[William Tanksley]

In any case I guess I would have to vehemently disagree with Graham's contention that great hackers don't use Java. I suspect that is more a matter of which circles you run in, as that certainly doesn't hold true in my experience. There are fewer using it today than three or four years ago, but I surmise that that is mostly a matter of language maturity; the best programmers tend to sit on the bleeding edge, and that's not Java anymore.

Sounds like you agree with the point of his article, but his headline was a little too sensationalistic to allow you to "get" the point of the article :-). He's making the point not that good programmers don't ever program in Java, but rather than good programmers learned Java, got good at it, and moved on because there are now other leet things.

I have some respect for his position, partially because that's how I myself behave (so I want to believe that this makes me a good coder); OTOH, I know many good coders who learned one language and stuck with it. They're good in a different sense.

I don't know which group I would hire from in which situation. My manager hired me, so I guess he agrees with Paul. But then I'm also an expert in C and very good in C++, so perhaps he disagrees.

I myself know how to take this essay -- it's not directed towards me. I'm not going to learn any more languages because of it; I'm already learning languages constantly. I hope some managers read it and see me in it.

-Billy

Re:What is this responding to.. exactly?

[Kierkan]

The language is already forcing you to catch every posible exception the preparation could throw. You already have the tools to identify the different causes.

Re:What is this responding to.. exactly?

[pthisis]

This is a Good Thing(tm). You want a system that is maintainable. You're not going to get this if two dozen developers each use their pet language du'jour. When you have Java, C#, C++, Python and Ruby advocates all working on the same project, you don't want them deciding what language their individual components will use. That way leads to chaos.

Disagree, strongly. If the system components are well isolated, picking the right tool for each job is going to make the development and maintenance both much less chaotic than trying to shoehorn one tool into attacking each task. And using heterogenous languages can often be helpful to enforce good isolation of independent systems and identify where the actual interdependecies are.

To take one example that is fairly representative in my experience:

The system I wrote at a top-50 web company to do dynamic content generation is written in Java, C, C++, Python, Perl, and sh--and this in a house that uses ASP/VBScript for the web development side of things. It's been running fine for the past 3 years with less than 4 weeks of maintenance/feature-add time allocated to it from the coding side (there were another 5 days of sysadmin time for a server upgrade at one point). Not only have they not had problems with new programmers maintaining it (despite 3 of the 4 programmers who wrote it moving on to new jobs, and the 4th moving into management), it was also delivered on time (meeting an 18-month deadline).

[At last check it's served over 10 billion requests. It's a pretty complex system consisting of 10-15 seperate programs, everything from a GUI interface for the content developers to a publishing system to network server for content delivery to reporting tools and integration with external systems/databases/web servers.]

I would hate to have done most of the data summarization work in Java, or the GUI in C, or the TCP server in Python, or...you get the idea.
I firmly believe that a management decision to use exactly one prescribed language would have made the system take longer to develop and be more costly to maintain.

IOW, Pick the right tool for the job. I've even picked VB as the right tool once recently (mainly because the system in question had some VB hooks in place already and the task at hand was manageable even in a basically crufty language).

Re:What is this responding to.. exactly?

[jimfrost]

You mention Fred Brooks, but somehow I don't think you've read his essay

Well, you'd be wrong, it's one of my favorites. But I hardly think that my saying there is a 2-4x improvement over C/C++ equates to Brooks' hypothetical "silver bullet".

As for what the best hackers use, I will take some lumps on that since it's certainly true that many are still using C. 'Course many are happy to use other stuff when appropriate, too.

Re:What is this responding to.. exactly?

[random_static]

java is verbose for pretty much anything interesting precisely because of those fancy-ass libraries of its.

because everything requires library calls in java, whether or not that makes sense. want to use a list? use this library. want to use a dictionary? import that library. want to add or delete items from your collection-like data type? do tedious method calls on objects created using those tediously imported libraries.

meanwhile, in sensible languages, i'm trivially iterating over the members returned from the list comprehension i used to eliminate the irrelevant items from my collection. one line, no inherent method calls, perfectly succinct and - in any sensible language - perfectly readable. in java i already gave up long ago, because i had a real problem to solve that didn't involve learning the various APIs of umpteen jillion libraries, no matter how standard. it didn't have to involve butt-ugly syntax using method calls to do what should have been done with operators, either.

creating basic structured data types and assigning them some initial data should be pretty much a one-liner. decent languages have built-in syntax to make this easy, natural, readable and even good-looking. it's a personal litmus test of languages for me; if creating a dictionary and populating it involves jumping through hoops, the language is too low-level and obtuse to bother with.

i've used java. i have also, i will shamefully admit, studied COBOL. it's a toss-up which of the two is more verbose, and if java is any more powerful, it certainly doesn't present its power any more succinctly or aesthetically - java code just seems naturally butt ugly for some weird reason, to an extent that even COBOL doesn't necessarily approach. weird, that last, but true.

Re:What is this responding to.. exactly?

[TheWanderingHermit]

I have a book on Python. I've started to read it a few times, but I am having a LOT of trouble getting past the point that whitespace is part of the language. -- Actually, it's more precise to say that this is what stopped me at first when I was deciding between Python and Perl. Then I got going on Perl, and haven't had time to invsetigate anything that isn't directly part of what I do.

I've heard comments about Python, though, that make me think you're right, and the people I know who like Python seem to think like I do. I guess I'll have to check into it when I have the time.

Re:What is this responding to.. exactly?

[TheWanderingHermit]

Re-read the whole post, and look at what I'm saying. And try not to take it literally. Then read my comments to the other poster that said this.

Then there is a CHANCE you'll see what I'm saying, but, to be honest, your comment shows that you didn't get the point -- you missed the forest because you were fixated on one tree.

Re:What is this responding to.. exactly?

[Brandybuck]

But I hardly think that my saying there is a 2-4x improvement over C/C++ equates to Brooks' hypothetical "silver bullet".

Yes it does. His term of "order-of-magnitude". A 200% to 400% improvement certainly counts as that. Perhaps Mr. Brooks is unaware of Java. Perhaps you should point it out to him, so he can issue a retraction to his article.

Do you sense a bit of sarcasm above? Good, that was intended. Anyone who claims a 200% to 400% increase in productivity by switching to the Java language from C/C++ has some serious reality problems. I'm not talking niche projects, but normal mainstream generic programming projects.

Re:What is this responding to.. exactly?

[Yaztromo]

in Perl it's:

@file = glob($filename."/*");

In Java, I have to do:

File myFile = new File($filename);
String[] myList = myFile.list();

No you don't. You can achieve the same end by simply calling:

String[] myList = new File(filename).list();

That's one line. So long as you don't need to re-use the File instance, what's the point in reserving memory space for another pointer?

Yaz.

Re:What is this responding to.. exactly?

[mellon]

(1) I'm pretty sure the previous poster was being sarcastic.

(2) There is no open source JVM of which I'm aware.

(3) Even if there were, there is no complete open source Java API implementation, where complete means you can write a useful app with it.

So for all intents and purposes, despite the presence of several good open source compilers, Java is not open source. This is in fact one of my biggest objections to using it - because Swing is so buggy, and I can't fix the bugs, I can't use it.

Re:What is this responding to.. exactly?

[NoOneInParticular]

As you mentioned C++, a few words:

std::string
std::vector
std::auto_ptr
boost::shared_ptr
boost::weak_ptr

I can't remember the last time I actually needed to write 'delete' in C++.

Re:What is this responding to.. exactly?

[TheWanderingHermit]

No offense, but, to be blunt, you're the third person to say the same thing. You're also the third person to miss the forest through the trees. You're taking the one example to literally.

I'm replying because this leads me to wonder if Java programmers and Perl programmers (that is, when given a choice of languages) think differently. Perhaps Java is a more literal language, which works better for people that think literally, and maybe Perl works better for people like me (I'm also a writer) who think more symbolicaly and are more used to simile and metaphore. I noticed this because I've had (as I said) 3 responses, all stating the same thing, and all seeming to miss the part where I said, "For example (and please don't get picky -- I'm picking a simple, quick example and there are thousands of others)," and afterwards I address this case specifically by saying, "It's a small example, and I know I can combine creating the myFile object with getting the file list, but the point is I can't just DO it, I have to prep it and do it. I'm always going around my thumb to get to my elbow."

It's interesting that there are 3 posts about Java that probably read just the examples, without reading the context, yet there isn't a single post talking about Perl where it seems the poster did the same thing. That's what leads me to my thought above, about Java coders being more literal minded, and perhaps not interested in alternatives, where Perl coders seem to like the ability to write in their style, which seems easier in Perl than Java.

Re:What is this responding to.. exactly?

[jimfrost]

Yes it does. His term of "order-of-magnitude". A 200% to 400% improvement certainly counts as that. Perhaps Mr. Brooks is unaware of Java. Perhaps you should point it out to him, so he can issue a retraction to his article.

I guess I have two rebuttals to that.

First, a factor of two to four is a lot less than an order of magnitude (by definition a factor of ten to one hundred). If you think Brooks didn't think so, then you need to read more closely because he talks about small integral factors of improvements in his dissertation on high level languages versus assembly language. Go look it up.

Second, you are making the presumption that using C/C++ in some way represented high-productivity practice prior to Java. That is emphatically not the case. C in particular was nice for low-level programming but it is and always has been a poor general purpose programming language. It is just too easy to make serious mistakes doing everyday things like manipulating strings. C++ adds a lot of sugar but doesn't really fix any of the problems of C (and, in fact, its attempts to retain C compatibility interact poorly with some of its new features -- like automatic type promotion in combination with overloaded methods). What makes C++ particularly bad in terms of productivity is that from its inception some really bad practices were touted as standards (e.g. iostreams.h use of operator overloading) and it had no standard container classes for years and by the time it got them (via STL) they sucked.

This is independent of the fact that C++ the language is so overcomplicated that there's a two-inch-thick reference to explain its finer points. Stuff like how an overloaded virtual method is hidden in the subclass if a subclass overrides one of its other signatures (gee, doesn't that defeat the point?). If you've used C++ for very long you've almost certainly wasted remarkable amounts of time here or there because some venomous corner of the language bit you.

C++ with a really nice class library, studious avoidance of some of its more dangerous features, and error detection tools ala Purify can yield a nice, productive environment. Too bad all of those are exceedingly rare in practice. Instead, we have millions of C++ programmers trying to be productive with MFC. Ha-ha!

Anyone who claims a 200% to 400% increase in productivity by switching to the Java language from C/C++ has some serious reality problems.

Or perhaps it is the case that they used both enough to know for sure. Nah, that can't be it, we all talk out our ass here don't we?

Re:What is this responding to.. exactly?

[javaxman]

I really wish we could mod stories. Like this one is -1 Lame.

I'll have to say, though, regarding the 'powerful languages are terse' claim:

1) any language can at some level be terse- if the APIs providing the functionality you want to use are designed correctly. Or is the complaint about standard library APIs, not the language itself ?? When libraries don't give you the API you'd like, it's usually a good idea to wrap them in a layer that provides the API you need, regardless of what language you're using.
2) since when is C ( IMHO the ultimate "Great Hacker" language ) terse ? It's the most verbose high-level language out there.
3) Lines per day == BS. Talk to me about correct, easily maintained, reusable lines per day.

Please note I'm not trying to defend Java per se here, as much as I'm trying to discredit this silly notion that a 'compact' notation is a 'better' notation. Even if your language of choice is powerful enough to let you write a function in one line, it's sometimes better to write it in 6 lines with comments...

Re:What is this responding to.. exactly?

[pileated]

I have to agree with you, or I shouldn't say have to I'm happy to. Though I've greatly enjoyed other Paul Graham articles the one line that jumped out as manifestly wrong in his article was the notion that great programmers don't use Java.

This strikes me as exhibiting a type of hotdogging that I hadn't come to expect from him. I say hotdogging for two reasons: one, Perl readily allows for hotdog programming; Java really doesn't; two, it seems like a thoughtless, off-the-cuff, hotdog type of remark and I wonder if he really means it. Who knows but let's assume that he does.

In that case he makes a hotdog, showoff type of remark in favor of a language that can, but doesn't have to be used in a hotdog manner. That sounds like someone who hss a bias towards the frisson of creativity and away from the satisfaction of a job well done, or maybe art versus craft. I'm obviously just thinking out loud here but it does make me think that I ought to go back and reread his essay on painting and programming to see what type of art he likes.

I had liked much of that essay but now I wonder if re-reading it I won't find the same type of hotdogging.

If so then I'd have to come to this conclusion: he favors the frisson that comes with a stylish slap of the brush across the canvas rather than the restrained satisfaction of a more carefully built painting, a Hals versus a Rembrandt, or perl versus Java. I don't say this to slight perl. I use and love it, as I do Java. A person who goes more for thrills than substance may prefer Perl. But then they'd probably prefer Hals to Rembrandt.

Re:What is this responding to.. exactly?

[rolling_bits]

"A large part of what Java is about is failsafe enterprise-level applications. When you write to that level of safety, you need to identify the different causes of issues."

And you can guarantee that every Java program lives to the "failsafe" myth, right?
No. But you can at least guarantee that your programs are failsafe, right?
And of course, that all the other libraries that your program uses should be guaranteed to be failsafe by someone, who could be you, 'cause you trust everything Java, right?

The problem is, I don't have the perfect environment either. :-)

Re:What is this responding to.. exactly?

[MemoryDragon]

Python has its own share of problems. The non declarative approach is a matter of taste, but in the end you have to write much more unit tests than with a declarative approach, thus nullifying the loc argument basically to a negative factor. The other thing is the speed claimed by python. Face it the VM is rather slow (until parrot or another VM takes over), most modern vms including the java one (which is one of the best) runs circles around Python. I would never program a bigger system in Python, there are too many problems which are totally ignorable for smaller stuff but can become deadly for a bigger system.

Re:What is this responding to.. exactly?

[Brandybuck]

Brook's article came at a time long after the switch from assembly to higher level languages. He was arguing that there were no more silver bullets, and was not denying that any had come before in history. In fact there were several that had already occurred, and the industry was expecting that others would arrive.

It doesn't really matter whether a two- to four-fold improvment is an order of magnitude are merely "incremental". Regardless of measurement, such an improvement would have been one of the most momentous improvements in the last decade. But development houses using C/C++ are just as productive as those using Java or C#.

In certain domains, Java will of course be the more productive language. But in others it will fall flat on its face. I'm *still* waiting after a decade for the Java office suite. I'm still waiting for the all-Java operating system. Heck, I'm still waiting for an all-Java desktop, because the one that has Java in its name certainly isn't it!

Java has found several niches, and large ones at that, but it still hasn't proven itself as a general purpose language. This isn't a put down of the language, just a statement of what I see in the world. Java's proponents have simply been too optimistic.

Instead, we have millions of C++ programmers trying to be productive with MFC

That is an indictment of MFC, not of C++. That's the equivalent of saying C sucks because no one is productive in Motif. I will agree with you that MFC sucks big green donkey balls, and will join you in a parade holding a banner so. But that says nothing about C++.

When I use C++ I don't have to use templates. I don't have to use exceptions. I don't have to use operator overloading (and I agree that iostreams weird overloading is confusing). But that's not an indictment of the language, only an observation that it's an extremely rich language with a few potholes for the unwary.

While I still have problems believing a quadrupling of productivity by switching from C++ to Java, it's quite easy for me to believe it switching from MFC to any sensible framework.

Re:What is this responding to.. exactly?

[random_static]

talk to me like i'm stupid - how is your example any different at all from structured exception handling anywhere else? what, in your description, is the "checked" part, and why's it so damn great?

because, in case you weren't aware, even .NET applications can try/catch/throw/finally these days. there's nothing to stop them from logging their errors and continuing on, either.

Re:What is this responding to.. exactly?

[Trinition]

Unlike boats, programs tend to have the strange ability to grow from 12' to 80' in a short amount of time.

Re:What is this responding to.. exactly?

[wurp]

I think frantic defensive articles regarding Java aren't helping anyone.

I don't care what the topic is, *this* I disagree with completely and utterly. It is really pretty silly to assert that when someone expresses an opinion with which you strongly disagree, it's "frantic" and "defensive" to show why you think they're wrong.

Re:What is this responding to.. exactly?

[gnovos]

n particular, Graham claims that terser languages are more powerful, because studies have shown that coders churn out a pretty constant number of lines per day, regardless of the programming language. Java is anything but terse.

I've noticed that a lot of hard core programmers are the ones using such excellent programming environments as vi and emacs to get thier work done. That's fine and all, but using a modern IDE can give you a WHOLE lot of additional speed. Not just popping up methods, but they can wipe out huge swaths of boilerplate code in seconds.

Instead of System.out.println("variable x = " + x);

I just type s[tab]. It's got a macro to go find whatever variable is closest and make a println of that variable, with a little drop down box to pick a different variable.

I can't remember the last time I wrote a for loop header by hand, or actually had to write out a new method signature.

I just write a method that I want to exist, like object.foo("hi", "mom", 5); Hit Alt-Enter and bam, the signature is created in the right place with the right parameters.

Java is verbose when you have to write out every line by hand, but in an IDE a couple of letters is enough to pop up a list of possible choices, and good IDEs will make excellent guesses as to which one you plan to use next. This cuts down the verbosity of WRITING java to almost nothing, but the verbosity of READING java is still there, making it quite easy to read what's going on six months later when you've forgotten what you did.

Terse languages may help you write something quickly, but they don't provide legibility when you return to that language many moons later. THAT is where they fail miserably.

Most, if not all, of my Java code can be understood by a new employee very quickly, in minutes, without any need for documentation. That's because every variable and method is descriptivly named and, again thanks to the IDE, there is agreat deal of standardisation in what I write. All loops look the same, they use similar variable loop names in similar ways. There are no backwards counting jump all over the place for loops, for example. All the code is formated and checked for compile time correctness on th efly, so there is no way I can write code that doesn't compile.

Re:What is this responding to.. exactly?

[pizza_milkshake]

nice to hear this :) it's not the language that matters, but that the project is scoped correctly, the interfaces are planned out and implemented correctly. why should the server and client have to be the same language? as long as they can speak to each other it's a benefit to use each language for its strengths. a big project like this can be stronger if done properly in multiple languages, though sadly often it's worse. my employer has a similiar but lower-scale project going on now but of course they've chosen the wrong tools for the job and the wrong people to do it. *sigh*

Re:What is this responding to.. exactly?

[Saucepan]

The AC you're replying to isn't the most coherent writer around, judging by his somewhat.. enthusiastic.. posts elsewhere in the thread, so I'll try to clarify their scenario and answer your question for you.

In Java IOException is checked, meaning when SearchForKiller's search method opens the file it must either catch IOException itself (thereby promising to deal with it*) or declare that it too might throw the IOException when called. In the GP's example, the programmer evidently chose to declare and hence propagate the checked exception. So far so good.

Later, when the call to SearchForKiller is written into SearchManager, the programmer's IDE will remind them to deal with the exception (and the compiler will force them to even if they somehow forget). Since they are forced to think about the problem, they may conclude that they are better off catching the exception and logging it (perhaps saving enough information to retry the failed operation another time), rather than allowing a single missing file to cause an expensive and lengthy batch operation to abort.

In .NET, or even in Java using an unchecked exception, SearchForKiller would not have had to declare the IOException. From experience, unchecked exceptions fall through the cracks much, much more often.

For example, have a look at an example method whose contract documents both checked and unchecked exceptions (it's Example #2, WriteTextFile.setContents()).

A developer calling this setContents() method from a new initializeFile() method may reasonably choose not to handle the unchecked IllegalArgumentException thrown by setContents() when the file is a directory, since they know this will not occur in their current situation.

Later though, perhaps when initializeFile() is reused in a situation where the file argument is now derived from user-supplied data, the maintenance programmer is very unlikely to notice the lurking timebomb of an IllegalArgumentException when a directory is passed into initializeFile(). When this eventually happens it will probably propagate all the way up to a high-level application catchall, aborting the current operation or otherwise handling the error in a generic and suboptimal way.

Had setContents() instead used other subclasses of the checked IOException to report incorrect file type or permissions the end result would have been a more robust application overall.

* The compiler can't force you to keep your promise to deal intelligently with the error, but at least it can put the problem on your radar, power that a footnote in the documentation just doesn't have.

Re:What is this responding to.. exactly?

[LittleDan]

That is a straw-man argument. Java isn't just more verbose than Perl; it's more verbose than just about everything short of Ada. Take the extremely simple example of a mutable record with 2 fields (we'll make them integers for this example). Here's how it might be done in Java:
class TheRecord {
private int first;
private int second;
public int getFirst() {
return first;
}
public int getSecond() {
return second;
}
public int setFirst(int value) {
first = value;
return value;
}
public int setSecond(int value) {
second = value;
return value;
}
}
In other languages, this would be much shorter than the 18 lines required to do that in Java. Take, for example, the scheme version:
(define-struct the-record (first second))
(it's not restricted to ints, but if you wanted it to be statically type-checked and you have bigloo, you can change it to (define-struct the-record (first::int second::int)), which is still much shorter.)
all of the getters and setters are automatically generated, and it was all only one line! Nevertheless, the Scheme version is perfectly readable provided you know what the define-struct macro does (for Java, you just as much have to know what the class keyword does, so...). What could be cooler than reducing 18 lines into a perfectly legible 1 line? I think instead of asking why Java is uncool, we should ask why Scheme is uncool.
Daniel Ehrenberg

Re:What is this responding to.. exactly?

[Zaak]

I have yet to find a library that works with postgres under windows for python.

psycopg

TTFN

Re:What is this responding to.. exactly?

[pthisis]

The non declarative approach is a matter of taste, but in the end you have to write much more unit tests than with a declarative approach, thus nullifying the loc argument basically to a negative factor.

Do you have any evidence to support this claim? In my experience, it isn't true; the unit tests tend to look much the same whether I'm using a statically typed language or a dynamically typed language.

The other thing is the speed claimed by python. Face it the VM is rather slow (until parrot or another VM takes over), most modern vms including the java one (which is one of the best) runs circles around Python

OTOH, the libraries are extremely fast, especially compared to Java's (especially for file I/O), and in real life the overall benchmarks seems to favor Python over Java for largely I/O driven tasks (e.g. dynamic web page generation or database-driven applications). Java wins over standard CPython for many computational tasks, though Psyco often tips the balance back toward Python.

I would never program a bigger system in Python

Fair enough. I would personally never program a bigger system in C++. On the other hand, the 30,000+ lines of Python we have at work seem to work very well and I would choose the same language if I had to implement the task over again (indeed, this is the third company I've worked for in the past 8 years that has developed successful bigger systems in Python, though at one of those Python was only one of several languages used).

Re:What is this responding to.. exactly?

[BigBadDude]

of course, you could write it like this:

class TheRecord {
private int first, second;
public int getFirst() { return first; }
public int getSecond() { return second; }
public int setFirst(int value) { return first = value; }
public int setSecond(int value) { return second = value; }
}

but on the other hand, you dont seem to have programmed on anything but tiny VB or php projects, or have you?

It is really surprising to see how few on slashdot actually do work on real software projects. it seems that most of the people here are sys/net admins who spice up their boring job of watching logs by visiting slashdot 25 times a day...

Paul Graham?

[LimpGuppy]

Here's a hint: Paul Graham's view of the development world is fairly myopic.

Re:Paul Graham?

[kfg]

And the Java developer's world view is over focused.

Both are flaws of vision.

KFG

Re:Paul Graham?

[LimpGuppy]

Here's another hint: not every Java Developer looks at the development world the same.

I've never met any of the Java developers that slashdot likes to use as the stereotype, for example.

Re:Paul Graham?

[kfg]

Here's another hint: not every Java Developer looks at the development world the same.

Of course not. Nonetheless there tend to be certain commonalities off viewpoint. You don't find many people advocating Java who dislike object oriented programing, for instance.

I've never met any of the Java developers that slashdot likes to use as the stereotype, for example.

Oddly enough, about the only place I've met them is on Slashdot, and my neighbor.

KFG

Why is Java Considered Un-Cool?

[illtud]

...I'd love to tell you, but I'm trying to fix my $CLASSPATH

Re:Why is Java Considered Un-Cool?

[Frothy Walrus]

Try translating it into Hindi.

Re:Why is Java Considered Un-Cool?

[CountBrass]

1) Java in OSX (as an example) doesn't require a classpath at all.

2) Two problems with pointers: a) even "real" programmers make mistakes. b) in real, rather than one-developer toy, development who owns an object/lump of memory and therefore can/must delete it is an issue.

Re:Why is Java Considered Un-Cool?

[chez69]

3) leet programers love to bash java for lacking pointers but suffer segmentation faults when they fuck up a reference.

oh please. Most programmers can deal with pointers just fine, but like using a high level language to get more done.

Re:Why is Java Considered Un-Cool?

[mark_lybarger]

let me go verify my LD_LIBRARY_PATH has everything it needs before i get started.

Re:Why is Java Considered Un-Cool?

[Aardpig]

2) No pointers. Real programmers know how to use memory properly. That is all.

Real programmers also know how pointer aliasing can absolutely kill optimization. They therefore avoid pointers wherever possible, resorting instead to constructs such as Fortran 90/95/03's ALLOCATABLE(:) arrays.

Re:Why is Java Considered Un-Cool?

[das_cookie]

CLASSPATH for sure, but how about the lack of upward compatibility of the various runtimes? Who hasn't had to install yet another jre because this app doesn't quite work right with the latest runtime. Take a look at Oracle for an example. Long after java 1.4 was out, Oracle 8i STILL required 1.2. I think the latest Oracle (10g) runs 1.4.

Hey, I *like* java, but this kind of crap is definitely shooting yourself in the foot material.

Re:Why is Java Considered Un-Cool?

[Mr. Slippery]

a) even "real" programmers make mistakes.

"Real good" programming teams use code reviews to catch all sorts of mistakes, and memory debuggers to check for leaks.

b) in real, rather than one-developer toy, development who owns an object/lump of memory and therefore can/must delete it is an issue.

The issue of object ownership is independant of language. "Real good" programming teams fully document APIs.

Re:Why is Java Considered Un-Cool?

[BeBoxer]

Bingo. That's why I hate it. The whole "platform independence" is pretty much a load of crap in Java. Yes, in theory, it's there. In practice, all of the real Java apps I end up having to deal with require some specific runtime. Then I fight with CLASSPATH stuff.

I understand that truly cross-platform programs are a difficult problem. But that doesn't change the fact that Java is pretty bad at it. And don't even get me started on the fact it has multiple GUI API's.

Re:Why is Java Considered Un-Cool?

[mwood]

"I'm trying to fix my $CLASSPATH"

There's something to think about. Java does need some things to make the app.s a little less fragile.

Every sizable app. needs a custom-built CLASSPATH long enough to climb to the moon. Java needs a *standard* place to drop stuff so that all the libraries are "just there". I've fallen into the no doubt disreputable habit of dropping .jars into jre/lib/ext, which is probably gonna bit me some day.

Java needs a *standard* place to put systemwide settings (and not Preferences, 'cos the standard classes don't use those). I'm tired of typing -DTHIS -DTHAT -DTOTHER -DKITCHENSINK.

Oddly enough, the Java environment seems to have been designed more for the lone hacker than for those who work in a shared environment and need shared libraries and defaults.

Re:Why is Java Considered Un-Cool?

[mwood]

Oh, yeah, the other ugly thing I've done w.r.t. CLASSPATH is to set up a directory /usr/lib/java and put it on the CLASSPATH bequeathed to all login shells by /etc/profile. Then I *unzip* .jars into that directory. (I can hear the souls of a million Java fans crying out in torment.)

Wouldn't it be nice if there were a way to express "ALL .jarS IN THIS DIRECTORY" as a CLASSPATH element? "export CLASSPATH=/usr/lib/java/*" sounds good to me.

Re:Why is Java Considered Un-Cool?

[TheRealMindChild]

You talk like pointer aliasing is something common within an application. I must say that in the HUNDEREDS of applications Ive written, and the hundereds I was simply part of a team on, ONE used such a device, and the task was specialized enough that we even disabled byte padding.

You make me worry

Re:Why is Java Considered Un-Cool?

[jaoswald]

Code reviews and debugging tools can be used for any language.

The difference is that code reviews, and management resources in general, for more powerful languages can focus more on high-level issues that make a difference, and automated tools can be used for useful end goals such as improving run-time performance and adding features.

While the C++ guys are still crawling around in the dirt playing a game of "who dropped the pointer."

Re:Why is Java Considered Un-Cool?

[Aardpig]

You talk like pointer aliasing is something common within an application.

That's missing the point. If I have a C/C++ routine taking two pointer dummy arguments of the same type, then there is no way of guaranteeing that the pointers won't be aliased (i.e., point at the same object). Therefore, notwithstanding whether they are aliased in a given program which uses the routine, the optimizations that can be performed when compiling the routine are severely limited, in order to allow for the possibility that the arguments might be aliased.

Re:Why is Java Considered Un-Cool?

[allenw]

FWIW, you can avoid LD_LIBRARY_PATH issues by properly linking with -R (at least on Solaris). Rod Evans'recently blogged on the topic.

I don't think there is an equivalent with Java... but there should be.

Re:Why is Java Considered Un-Cool?

[daBass]

Real java apps are packaged in a Jar file with a manifest file that takes care of everything...

Re:Why is Java Considered Un-Cool?

[brianjcain]

The stupid $CLASSPATH. Since I don't do a lot of Java work, I don't actually set this stuff up in .profile or .cshrc or anything, but any time I want to try to compile

How is this any different from LD_LIBRARY_PATH or gcc -I/some/src/path?

No pointers. Real programmers know how to use memory properly. That is all.

That's total BS. Real programmers make mistakes. Real programmers benefit from the abstractions that C provides over assembly. When you write Java, do you find yourself wishing that you could address members by adding pointer offsets? Or do you long for the days when you could conditionally branch to a label instead of writing a for() loop? Pointers are a necessity for many computing environments, but I don't think that PC application software is one of them. You gain nothing, IMO, and risk everything.

Re:Why is Java Considered Un-Cool?

[Max Threshold]

I had a section in my ~/.bash_profile that went through ~/java/lib and added all .jars fouind there to my classpath.

Re:Why is Java Considered Un-Cool?

[Max Threshold]

1) Oh, please. The $CLASSPATH is not that freakin' hard. It's just the #1 n00b question because n00bs don't understand what a path is. 2) Show me something you can do with C pointers that you can't do in Java, and I'll show you something you didn't know about Java.

Re:Why is Java Considered Un-Cool?

[pjt33]

1) Java in OSX (as an example) doesn't require a classpath at all.

Yes it does, unless you're talking about running executable jars.

Re:Why is Java Considered Un-Cool?

[dnoyeb]

Platform independence is not a load of crap. Its a Job that somebody has to do. And in the case of Java that somebody is Sun, or whoever writes youu JVM. So while you may have to make some allowances, using Java simply means you have a whole team of people working to make the JVM itself cross platform, and you can easily piggy-back on that effort. Or you can roll your own in another language. Choice is yours.

I'll take CLASSPATH over header files _ANY_ day.
Sure, both are just as workable, but I find CLASSPATH issues easier to diagnose than header ones, especially in libraries.

I can NOT disagree with you where the Java versioning is concerned. Sun is FOS. They publicly claim backward compatability, but when you submit your bug report and ask how in the hell its backward compatible with this altered behavior, don't expect a response...

When they say backward compatable they mean the specifications. But they completely ignore the ongoing deviations.

Re:Why is Java Considered Un-Cool?

[Nept]

at least it's not your %CLASSPATH%

Re:Why is Java Considered Un-Cool?

[Slick_Snake]

Try programming in python. I've written many applications that run without hitch on both Solaris (Unix) and Windows. Many of these have GUI interfaces and run without modification on either system.

Re:Why is Java Considered Un-Cool?

[Elwood P Dowd]

How about, "Because it's a programming language, you fucking geeks."

Re:Why is Java Considered Un-Cool?

[AstroDrabb]

Why not just drop all the jars into your /usr/lib/java/ directory? Your /etc/profile can then just do a simple for loop and add all of them to the $CLASSPATH

for JAR in /usr/lib/java/*.jar; do CLASSPATH=$CLASSPATH:$JAR; done
export $CLASSPATH

Re:Why is Java Considered Un-Cool?

[jhunsake]

ONE used such a device

You don't use pointer aliasing, it's a concept. Pointer aliasing does occur quite commonly by the way, evidenced merely by the existance of memmove() and memcpy().

Here's pointer aliasing that most people wouldn't even recognize:

void swap (int* a, int* b)
{
int temp = *a;
*a = *b;
*b = temp;
}

int v[40];

swap(&v[20],&v[21]);

You make me worry

No, you make me worry. Especially after the HUNDEREDS of applications you've written. You can't even spell "hundreds" correctly for Christ's sake.

Re:Why is Java Considered Un-Cool?

[BeBoxer]

I personally love Python. I only use it under Linux, but that's just me. What are you using for a GUI toolkit? wxPython? I've been using PyQt but I'm not sure how easy it would be to actually get that running under Windows.

Now if I can just convince Cisco, HP, Remedy, etc. to drop their crappy Java interfaces and write in Python.

Re:Why is Java Considered Un-Cool?

[mwood]

That's a possibility, but see my "lone hacker" comment.

If I do this in ~/.profile, it only works for me.

If I put it in /etc/profile, it only works on the one host I did this to.

If I put it in /etc/profile on every host in my organization, it only works inside my organization.

If there was a standard way of expressing this idea built into the JVM, it works everywhere and I can depend on that mechanism when distributing code.

Right now I have to choose between instructing the user to do profile surgery wherever my product runs, or the usual gaseous shellscript wrapper (which is not portable) that locates the JRE, then goes into Karnak the Great mode to try to divine the location of dozens of libraries, conses up an immense CLASSPATH and even larger 'java -DTHIS -DTHAT' command, and runs it.

Re:Why is Java Considered Un-Cool?

[AstroDrabb]

1) The stupid $CLASSPATH. Since I don't do a lot of Java work, I don't actually set this stuff up in .profile or .cshrc or anything, but any time I want to try to compile it's a matter of mucking around in /usr/java/ trying to figure out what the classpath needs to be. Then, naturally, I'll be using some shell other than CSH and forget how to set the local var ;).

Huh? Have you ever compiled C/C++? -I/usr/include/foo -L/usr/lib/foo, etc. There is just as much cruft to compile a C/C++ app. Real C/C++ apps will use a build system like Make/autoconf. Just as real Java apps will use an IDE that handles the CLASSPATH for compiling or a great Java build tool like Apache-Ant (and most IDE's will export ant build scripts for you. Also, any good Java Server or GUI app will be packaged into a jar file with a manifest that will handle everything for you.

Re:Why is Java Considered Un-Cool?

[roror]

"...I'd love to tell you, but I'm trying to fix my $CLASSPATH"

Then you don't really know java, do you ?

Re:Why is Java Considered Un-Cool?

[jdiggans]

And don't even get me started on the fact it has multiple GUI API's.

And C/C++ doesn't? What language has only one GUI API??

Re:Why is Java Considered Un-Cool?

[Maltheus]

Gimme a break. It is not bad at all at cross-platform. Where I work, we're moving jars from windows to solaris to linux all the time without a hitch. I'll even go as far to say that we don't even consider cross-platform problems because they never come up. It just works -- yes, in reality too.

Multiple GUI APIs. How sorry I am for you that you have a choice. You do know that you don't have to use them all at the same time, right? Oh, but I don't want to get you started on that. I guess you can stick with C and it's 'single' GUI API.

I think people who bash java don't really use it professionally. But everyone I've met who does use it wouldn't go back to anything else (except maybe the former Smalltalkers). I'm really at a loss to explain all of the Slashdot antipathy towards Java other than some people prefer to do things the hard way. I've got too much work to do without wasting time on C, assembly or punchcards for that matter.

Re:Why is Java Considered Un-Cool?

[BeBoxer]

And C/C++ doesn't? What language has only one GUI API??

Most languages have multiple GUI API's, but that isn't necessarily a strength. Java was aiming for true write once, run anywhere. But by coming out with multiple GUI API's, Sun has only managed to further fragment it's own platform.

Re:Why is Java Considered Un-Cool?

[BeBoxer]

It just works -- yes, in reality too.

Maybe for your stuff. I speak as an end user, and I can count at least three major java products we have that are cross-platform (or cross-JVM) for shit. Your stuff all works? Great! But in reality lots of major products don't. Installing a full JRE for each application seems to be a common-place solution for a lot of Java developers. All the spin Sun want's to put on it doesn't change the fact that it's a PITA to deploy Java applications and get them to work reliably.

Re:Why is Java Considered Un-Cool?

[TheRealMindChild]

That's missing the point. If I have a C/C++ routine taking two pointer dummy arguments of the same type, then there is no way of guaranteeing that the pointers won't be aliased

Sure there is. C99 specifies __restrict__ and __restrict for just this case.

Re:Why is Java Considered Un-Cool?

[CountBrass]

No. It. Doesn't.

Re:Why is Java Considered Un-Cool?

[TheRealMindChild]

see http://dictionary.reference.com/search?q=device

device Audio pronunciation of "device" ( P ) Pronunciation Key (d-vs) n.

1. A contrivance or an invention serving a particular purpose, especially a machine used to perform one or more relatively simple tasks. 2. a. A technique or means. b. A plan or scheme, especially a malign one. 3. A literary contrivance, such as parallelism or personification, used to achieve a particular effect. 4. A decorative design, figure, or pattern, as one used in embroidery. See Synonyms at figure. 5. A graphic symbol or motto, especially in heraldry. 6. Archaic. The act, state, or power of devising.

You certainly "use" a technique. You also certainly "use" a concept.

It never fails when some troll has nowhere to go, they go straight for the spelling/grammer/typing. You obviously knew what I meant. I also find it extremely ironic that someone incapable of understanding "use" and "device" would jump on me for slipping an extra "E" into a word.

Re:Why is Java Considered Un-Cool?

[butane_bob2003]

Branch to a label? like this?:

label: while(true){ break label; }

I agree, nothing gained here. I never use it, although I see folks doing it now and then.

Re:Why is Java Considered Un-Cool?

[jhunsake]

When did I say anything about "technique" or "device"? It's quite obvious to me, the other guy, and everyone modding this discussion that you had no clue what "pointer aliasing" even was.

It never fails when some troll has nowhere to go

Hmm, who is more likely the troll? 743925? or 81920? The fact is, I simply called you on your statement and made you look stupid. Now that makes me a troll?

Re:Why is Java Considered Un-Cool?

[jhunsake]

That's missing the point. If I have a C/C++ routine taking two pointer dummy arguments of the same type, then there is no way of guaranteeing that the pointers won't be aliased

Sure there is. C99 specifies __restrict__ and __restrict for just this case.

You simply do not know what you are talking about. The keyword "restrict" in C99 makes a recommendation or statement, if you will, to the compiler that it can safely perform an optimization because there isn't pointer aliasing in the function call. It does not *guarantee* that that is the case. It simply makes a recommendation, which could be wrong.

See http://www.cbau.freeserve.co.uk/Compiler/RestrictP ointers.html for more details.

Re:Why is Java Considered Un-Cool?

[brianjcain]

Those are compile-time issues, not run-time issues.

That's not true. I explicitly included both LD_LIBRARY_PATH (runtime linking) and -I/some/src/path (compile-time) so that I could capture both the runtime and compile-time cases. Java's classpath is used at both runtime and compile-time.

Re:Why is Java Considered Un-Cool?

[Wraithlyn]

I think people that love to trot out the old "Java has no pointers" line have no grasp of the language whatsoever. Of COURSE Java has pointers. WTF do they think a "NullPointerException" refers to?

The fact is, EVERYTHING (except primitives) in Java is a pointer. Everything is a reference. What they really mean to say is that Java has no direct memory access. Which is an acceptable tradeoff for robust, secure, and fault-tolerant memory management in high-level applications.

Re:Why is Java Considered Un-Cool?

[TheRealMindChild]

Your UID is meaningless. Thanks for pretending to be important though.

As for making me look stupid, there isnt a qualifying statement anywhere that I have made that "makes me look stupid". Much on the other hand, it seems everyone in this topic is spewing regurgitated crap they read from a webpage or a book... not from actual practice.

Re:Why is Java Considered Un-Cool?

[bwt]

What is wrong with all you people? The classpath is no different than the path you use in good old bash.

You need classes because you've got code that depends on them? Good, put them on your classpath so that they can be found.

Re:Why is Java Considered Un-Cool?

[MemoryDragon]

Actually java is not perfect but it is quite good. I recently developed an application with including the frameworks had about several hundred thousand lines of code. The system was developed for an AIX RS6000 with Oracle on it. I developed the thing on Linux, later ran it on Windows without a single line of code that had to be changed and I ported it to the IBM SDK on Linux. One line of code had to be changed due to a bug in the IBM sdk. One line of several hundred thousands. The application was delivered in binary form to the customer and ran on the RS6000 without a problem. The day I delivered tha app I saw the RS6000 for the first time.

Re:Why is Java Considered Un-Cool?

[aralin]

On the other hand, my PERL scripts work fine cross-platform without even trying... well, unless its AIX, of course, all bets are off when you come to AIX :))

Re:Why is Java Considered Un-Cool?

[JamieF]

You might as well blame HTML for the fact that there are web sites that only work in IE.

The problem is that you bought some big complicated apps, then tried to do something with them that the vendor doesn't support and for which the vendor didn't QA their product. Amazingly, it didn't work.

Re:Why is Java Considered Un-Cool?

[AstroDrabb]

I agree, it would be perfect if there was a standard location for jar files and class files by platform.

As far as distributing your apps, you can use a self-contained jar file that has everything it needs and execute that. I have ran plenty of Java apps that were just a single jar with all needed class libraries and the manifest file.

Re:Why is Java Considered Un-Cool?

[JamieF]

No, you just need apps that have a startup script (or double-clickable runner icon or whatever). If you're running "java -Dfoo -Dbar -Dbiz" you're doing it wrong, or your app supplier is lazy.

Dumping all your libraries in the JRE lib dir for autoloading is risky, unless you're careful to avoid duplicate libraries with different versions.

Java as a platform suffers from "jar hell" (kinda like "DLL hell") because there isn't a systemwide package management concept for Java itself. Most OSs at this point have a central package management scheme that includes manifests that say what dependencies exist as well as installers that know how to put the files in the right place. The Jar manifest file has entries for relative URLs of dependencies and a pacakage version number, but that's not really enough to build a package manager around. That stuff was really designed to solve applet requirements, not app requirements.

So, you take a risk when you upgrade a library to a version that didn't ship with the app you're using, because there's no declarative structure that tells you that the new library uses the same API as the old one, or which packages depend on the old one and thus need to be upgraded at the same time, etc. like you'd find with RPM, APT, etc.

It's better (where "better" is defined to mean "more stable", not "more efficient in terms of disk space usage") to just install the libraries you need multiple times - once per application. If you consider that disk space is cheap and sysadmin time is not cheap, it really doesn't make a lot of sense to obsess over pointing a bunch of Java apps on the same box at a shared copy of a .jar file.

A couple of things could fix this problem. One fix would be to have each OS package management organization start to "own" Java libraries along with native libraries. That's not very cross-platform, though. So maybe Sun should propose a new Jar manifest format that solves this? Or maybe it's in a JCP committee somewhere that I'm not aware of. :)

Re:Why is Java Considered Un-Cool?

[Minna Kirai]

The $CLASSPATH is not that freakin' hard. It's just the #1 n00b question because n00bs don't understand what a path is.

That'd be fine if CLASSPATH were only a developer concern- but it's not. The end-user must understand how to setup CLASSPATH to run Java apps. That necessity weakens the cross-platform promise of Java.

Look at any major desktop application written in Java- they all come in platform specific forms with a BAT file, shell script, or whatever, just to setup the CLASSPATH.

Re:Why is Java Considered Un-Cool?

[pjt33]

I've made my living programming Java under OS X for more than two years. In that time I've had occasions where my CLASSPATH has become screwed up and needed repairing.

Re:Why is Java Considered Un-Cool?

[CountBrass]

Two years and you STILL haven't found /Library/Java/Extensions ? I guess your one of those developers who spends too much time reading /. and too little time reading about how to do your job.

Re:Why is Java Considered Un-Cool?

[blackwater]

I can't say I've had the same experience. I've written and run stuff on Windows, Linux and OS X without a hitch. Maybe I just got lucky.

I think the multiple GUI thing is a bit of red herring too. You could quite justifiably extend your point to most of the Java platform classes (e.g. IO versus NIO) but in my experience it's very difficult to get these things right first time. How many stabs at database access have MS tried? Strictly in GUI terms I think Java has done OK. AWT was quickly abandoned and replaced with Swing. Now Swing has a lot of critics but I think the basic design is reasonably sound. Performance is an issue unless you are an expert but (a) I think that will be largely resolved with Java 5 and (b) I'd rather have a sound design but less than optimal implementation than the reverse.

Re:Why is Java Considered Un-Cool?

[pjt33]

If your solution to avoiding using CLASSPATH is to put everything into the Java extensions folder then you should be claiming that CLASSPATH isn't needed on any platform, because they all have an extensions directory. It is, however, a crap solution. It doesn't allow you to switch between different versions of a library unless you want to keep replacing a symlink. Moreover, unless you do your development in /Library/Java/Extensions (which is _really_ crap) it forces you to cd to the directory into which you compile before running anything.

Re:Why is Java Considered Un-Cool?

[Slick_Snake]

I use tk for GUI. It comes installed by default on windows and is available on Linux/Unix, and Mac. On Solaris which is the Unix I use as long as you have tk installed first and use the binary at sunfreeware.com it sets it up for you. The look of the GUI matches the OS you run it on. I do have a few complaints about tk but no language is perfect. I've been meaning to try some of the other GUI toolkits, but I've been too busy with work and Grad. school.

Re:Why is Java Considered Un-Cool?

[mwood]

Yup, I could simply pack up all the stuff that my app. might need and not find, and cram it all into the .jar. The thought of a single host with twenty-seven slightly different versions of a given JDBC driver rattling around inside is a bit unnerving, though.

In the long run, though (which is what I was addressing), if the design is made right then workarounds would no longer be needed. And that's what these suggestions are: kluges to overcome the apparent fact that nobody on the architecture team ever thought of Java app.s as living in a larger context on a multiuser host as part of a centrally-managed network.

Re:Why is Java Considered Un-Cool?

[AstroDrabb]

There are pros and cons to each method. I think a global place to place jars and classes would be great. For example, in .Net when you compile an app, all the libs it uses go with an application and put in a /bin directory. So each application will have it's own copy of libs. This is good to prevent apps from installing their newer libs and breaking older apps. Though .Net does offer a global place to install .Net assemblies so that all applications can use them. As I said, there are pros and cons to each method. What I don't want to have to do with Java is have 5 different JVM's on my system, one for each app.

Re:Why is Java Considered Un-Cool?

[mwood]

If installing a newer library causes an older app. to fail, it is the new library which is broken. Balkanizing supposedly sharable libraries just papers over the real problem, which is undisciplined development.

How about

[antifoidulus]

people just concentrate on the best tool for the job instead of worrying about things like, "coolness".
These, "my programming language is better than the rest and here is a list why" arguments are BS. Every situation is different, every problem requires different tools/methodologies to solve. You wouldn't go into the carpentry business and claim your hammer is the best hammer for every single job would you? You would be laughed at and possibly hit in the head with said hammer. Same goes with programming languages.

Re:How about

[black mariah]

It goes hand-in-hand with the social ineptness of the typical geek. An inability to fit in with the majority of society gives way to a need to fit in with SOMEONE, SOMEWHERE, and the tools one uses are the most apparent thing. This doesn't apply only to geeks though. Think about the old woman with fifty cats, or the obsessive housewife that fills every room in her house with frickin' Beanie Babies despite not having any (or perhaps BECAUSE she doesn't have any) kids. Same thing, different level.

Re:How about

[Takeel]

You wouldn't go into the carpentry business and claim your hammer is the best hammer for every single job would you?

Sure I would! You wouldn't want an inferior hammer working on your carpentry, would you? That could result in costly downtime.

Re:How about

[antifoidulus]

Clearly you aren't a mac owner! Not everyone wants a beige box on the corner of their room, even if it is cheaper and faster than the equivalent PC.
Actually, within the past year I bought an iBook and a g5........
I bought them because of the functionality. I like the UI much better than the available Linux ui's(though OS X runs a bit slow on the iBook, thinking of loading linux on it), and I refuse to run windows. The little glowing apple on the iBook and the nice metallic casing on the g5 are just bonuses for me.

Re:How about

[ceeam]

Claiming "what I use is the best 'cos I picked it up 10 years ago and never looked sideways since" is really BS. No arguing. But having discussions is not at all BS. And if there's "a list why" is an ok-ish type of a discussion. Anyway - usually programmers trying to play around with "exotic" (for them) languages tend to be better programmers in their "mainstream/default" environment. And denying that Java (or C++ for that matter) is cumbersome for _all the tasks_ is a sign of people not knowing better.

Re:How about

[kfg]

An inability to fit in with the majority of society gives way to a need to fit in with SOMEONE, SOMEWHERE

Oddly enough, that's also exactly how the majority of society becomes the majority of society.

KFG

Re:How about

[Neomar]

I second that most of the programming languages have been developped with a certain area of application in mind.
e.g. C is the classical system programming language, used to code mainly OSes
In prolog you can design expert systems and some AI related things very easily, although it does not very well when used to code a webserver
Java is mainly used for applications nowadays, most often combined with enterprise java beans (ejb) and web frontends, for which it is very well suited. But it is impossible to write an OS for a x86 with it.

Right tool for the right job. You don't use a hammer to cut wood, even if its possible and the result might look awful

Re:How about

[black mariah]

Slight correction, it's how the minority of society infect the majority of society. Fashion trends are a prime example. A small group of elitist pricks convince a larger group that they're not as cool because they don't wear the same clothes. The larger group, trying to fit in with the 'cool' people, jump on the bandwagon and start talking shit about things they themselves wore no more than a week ago. In general, this is healthy behaviour. When you get to the point where you're arguing over which fucking TEXT EDITOR is better you really need to go outside.

Re:How about

[Bastian]

people recognize that using the best tool for the job every time isn't the way to do it, either. It's good to be comfortable with a lot of languages, but if you're constantly switching between FORTH, Perl, C, C++, Java, SmallTalk, VB, Ruby, Common Lisp, Python. . . you're never going to actually get good at anything.

There are cases where you want to choose the best tool for the job because some options are just terrible. There are also cases where you should stick with what you know. If I'm banging out a quick workflow integration app that needs a GUI on a Mac, AppleScript may be the 'best' language for the job, but it's also true that I don't work with AppleScript much and my level of expertise in it is low enough that I would probably get the job done faster and better if I did it in Objective-C despite its not being the best language for the task.

This "best tool for the job" analogy shouldn't be taken too far. Comparing hammers to programming languages is like comparing hammers to engineering contractors.

Re:How about

[spif]

But what if you had this hammer?

Re:How about

[kfg]

Q.E.D.

KFG

Re:How about

[Gorath99]

In my experience there's a hierarchy that goes something like this (expand as you like):

1. Assembly
2. C
3. C++
4. Java/C#
5. VB

People who use language X consider people who use languages < X to be freaks and people who use languages > X to be lusers.

Re:How about

[LocalH79]

But it is impossible to write an OS for a x86 with it.

Sure?

Re:How about

[randallman]

"people just concentrate on the best tool for the job"

This is said time and time again. I don't think anyone would disagree and for many of us, it is not the issue. I don't write GUIs with Bash nor browse my filesystem with assembly (I wouldn't know how anyway). I use Python INSTEAD of Java and never consider Java the right tool for the job. I have yet to need something that Java does that Python is not well suited. It is not true for everyone, but has been the case for me. The only reason I would use it is if I was forced to work on something already written in Java. It is my PREFERENCE. There are reasons other than 'best tool'.

Sun, a publicly held company, who's primary objective is profit, owns Java. That's a problem for me. I prefer Python's lack of brackets, dynamic typing, and non-verbose syntax. I find the majority of the Python community that I communicate with in mailing lists to be on average more intelligent, open-minded, and more friendly than others I've had experience with.

All this to say that there are many reasons for choosing one language over another. And saying pick the 'right tool' doesn't help much. Or from another perspective, there are many factors in considering the 'right tool'.

Re:How about

[mschaef]

"people just concentrate on the best tool for the job instead of worrying about things like, "coolness"."

Given that a programming language is the one tool a programmer can't escape, selecting a language that "feels right" is as an important consideration (for the programmer) as any other.

"You wouldn't go into the carpentry business and claim your hammer is the best hammer for every single job would you?"

Nice strawman, but I don't exactly see anybody claiming that their language is the "best for every single job". More likely, they're pointing out specific flaws with Java or comparing it with another, which are common experiences, even in woodworking circles. Just go onto a woodworking newsgroup and ask for advice on the wonderful "tabletop" table saw you're shopping for. You'll rightly be shot down for a whole variety of reasons, and lo, folks will even advocate alternatives.

Re:How about

[AndroSyn]

How nice a link to a dead sourceforge project.

Re:How about

[the quick brown fox]

Actually Paul Graham really does believe that Lisp is the right tool for every job, except for implementing Lisp interpreters (sometimes).

Re:How about

[anomalous cohort]

I second this observation. In this domain, coolness is synonymous with difficulty. The desire for things to be easy is considered to be some kind of weakness. You need for it to be easy because you're not good enough to handle it when things get hard. This isn't just for geeks. Folks who bicycle to work look at car drivers as weak.

I've also noticed that, from a geek perspective, it's not cool to wrap your head around the application domain too much. It's fun to talk about the latest programming language, tool and/or development platform feature but it's work to talk about features in your app. I've even seen it where coders will brag that they don't know a thing about the industry or vertical that they're coding for. I'm not preaching, by the way, as I am totally guilty of everything I am saying here.

The coolness = difficulty observation is not universal, however, as coolness tends to get co-opted by margeting departments as a kind of bandwagon device. In that camp, the hierarchy is reversed.

Re:How about

[GoofyBoy]

>It's good to be comfortable with a lot of languages, ... Common Lisp, "

I refuse to believe that any sane person can become comfortable with LISP.

Re:How about

[mukund]

Ok here is a live one.

Re:How about

[haystor]

I believe if you read about how he wrote the store front system that eventually became Yahoo Stores, he goes into what languages they used. If I remember correctly, they used LISP, Perl and C. They also didn't really use a database so much as they used the filesystem.

It would be hard for me to come up with any languages better at manipulating files on a Unix filesystem than Perl and C. I know his critics will say he should have used a database. It seems the Java crowd and the everything-must-have-a-database crowd have a large intersection. He said that was one of the points he worried about in selling the stores to Yahoo, but it turned out that's how they did stuff too.

My personal experience is that I've been on a lot of projects that have "replaced" legacy systems (Perl, COBOL, C, VB) with Java. I haven't seen a single one turn out better because of the language. I have seen a lot turn out worse because there is a much lower ratio of good programmers in Java than in the other languages. The companies I was at bought into Java big time, had to have everything Java, spent 5 times the resources of the legacy system to replace it and ended up with something worse. The consistent lesson to me is that the right programmer is more important than the right language. If you don't know how to pick the right programmer, you have better chances getting one if you hire a Perl or Python or LISP programmer than if you hire a Java programmer.

Re:How about

[the quick brown fox]

I watched a webcast of a panel discussion he was on at the MIT AI Lab, and he stated that he basically refuses to work with any language but Lisp (or maybe what he said was any language that doesn't have true closures, but what he really meant was anything but Lisp). He'd rather switch jobs than compromise his choice of programming languages and tools. (Of course, with his Yahoo! money, he probably has that luxury...)

Also from what I understand, the Perl/C at Viaweb were written by others. Everything he wrote was Lisp.

I'm not saying he's crazy, or even wrong. Just that he feels really strong about Lisp. :)

Re:How about

[Anonymous Coward]

I absolutely disagree.

The more languages you know, the better you are at choosing the right tool for the job - and the better you are at programming in any of those languages.

Sadly, the best (practical) tool for the job is often decided by secondary factors (availability for the required platform, availability of third-party libraries) rather than the nature of the language itself. However, the knowledge of multiple languages (especially fundamentally different languages) is always an advantage.

As an example - if you need to write your code in C, the knowledge of assembly language can help you figure out what's efficient, and the knowledge of functional and/or OO languages can help you design the right kind of abstractions for the task.

Seriously, once you know sufficiently many programming languages, writing code well in any language not entirely inappropriate for some task comes naturally. I'm saying this based on experience.

Sufficiently many means assembly language, at least one of (C, C++, Pascal, Ada, Modula*), at least one of (Lisp, Scheme, Python), at least one of (Standard ML, CAML, Caml Light, OCaml), at least one of (Haskell, Clean, Miranda), at least one of (Oz, Erlang, Concurrent ML), at least one of (Java, C++, Simula), at least one of (Smalltalk, BETA, JavaScript), at least one of (Perl, SNOBOL, Icon), at least one of (APL, K), at least one of (Forth, PostScript), at least one of (Lisp, Dylan, Scheme).

Each category could be expanded, since I was thinking of a particular paradigm/feature in each case, and admittedly there are a couple of categories that are not that critical (I'd say the string processing - Perl, SNOBOL, Icon - and stack based - Forth, PostScript - are the least relevant).

The thing is, anyone interested enough in programming to be a Really Good Programmer(tm), will want to learn and understand as many languages and paradigms as possible.

Re:How about

[Ian Bicking]

people just concentrate on the best tool for the job instead of worrying about things like, "coolness".

Graham was saying that great hackers have motivations besides just getting the job done, that a great hacker cares about the aesthetics of what they create, about the process of coding itself, not just about the result.

He's never claimed that there's one best tool -- after all, he ended up talking about Python, when his personal love goes to Lisp. His point was that for some people there's more to it than the job (and these people tend not to choose Java).

Re:How about

[Bastian]

I honestly believed that, back when I was in college.

Now I've learned that there is a lot more to a programming language than its syntax. Different languages have all sorts of details you need to get used to, function and/or class libraries you need to learn, etc.

I may have been able to learn the syntax to C++ in no time flat, but getting into the habit of using iostream instead of stdio took me some time, and learning to luse (no typo) the STL took forever. I still wouldn't say I'm a particularly skilled C++ programmer.

It's not about whether or not I can develop proficiency in a given language. It's about whether it's less costly to learn the new language or figure out how to do it in the old language.

Re:How about

[mibus]

I would argue that your familiarity with the language can change if it's the "best tool" or not.

Lisp may be the best tool for $PROJECT for Alice, but Bob here only knows Python and it's not worth getting him to learn Lisp for this ten-minute project.

Same goes for group engineering - A JSP / Servlet may be the single best way to do something... except everyone else in the company uses only PHP, and your contract runs out at the end of the main development cycle.

a few reasons

[becauseiamgod]

Firstly, most applications written in java run awfully slow which sends a lot of people to other languages. Secondly, virtual machines running byte code creates an extra step in compiling/rolling out programs which can stray away a lot of beginners. In general, not a lot of production software is written in Java, and a lot of people get into programming because they want to emulate something that already exists and make it better. C/C++ are languages of choice of the industry so they tend to go into them.

Also, i remember someone saying, saying java is good because it works on more platforms is like saying anal sex is good because it works on both sexes :-P

Re:a few reasons

[skaffen42]

not a lot of production software is written in Java

So all those guys getting hired as Java programmers are doing what? Sitting around playing with themselves while the C programmer chained in the basement writes all the production code?

Somehow I don't think so...

Re:a few reasons

[becauseiamgod]

where do people get off on not reading posts? I addressed why Java doesn't get a lot of beginners to go into it, and im sorry if most beginners don't fiddle with custom business software, and please don't assume about what others have experience in since I did not mention anything about my past history in coding. Also, if you are a good and careful C/C++ coder those 'obscure' bugs will be at a minimal level. Those that claim that java isn't slow obviously don't actually use software written in it. Sure you can make all the benchmarks you want, but when it comes down to it, it does feel much slower.

Re:a few reasons

[lmsig]

In my career I've written more C then anything else. Followed by PERL for test automation. Recently I'm working a new program that is 100% Java. It has been a pleasure. I do not see any huge performance problems that people seem to complain about. I'm not just writing a database/forms program either but doing REAL work in image processing.

I have no idea what you mean about byte code making it harder. You compile things into a JAR, in most OS's you can double click the JAR and run it. How is that difficult?

Tons of production software is written in Java. Especially server side.

C/C++ are out there but the reality is that they are too hard to use for very large project. It can and will be done successfully but it costs a fortune. I can do so much more using Java with so much less budget that its amazing.

As far as being multiplatform. It comes close. I've never had any huge problems outside of cosmetic differences that might need to be tweaked, but that it easy. I was even doing 3d graphics on the mac and demoing them blindly on a windows PC without testing on Windows (I refuse to own one of those) and had no problems.

Re:a few reasons

[Everleet]

They're still trying to debug each other's code, in preparation for a rollout that will never come.

Re:a few reasons

[lmsig]

I still don't understand why beginners would not want to go to Java first. It is easier not to shoot yourself in the foot. The tools are free. Additionally a beginner has no need to worry about performance in the first place. C has its place. I use it when I need to. Its not a great language; especially for beginners. Don't get me started on C++.

No matter how good and careful you are in a massive multi developer C/C++ environment there will be memory leaks and pointer errors all over the place.

I use Java software every day. From the great JEdit to build tools like Ant, to all of the in house built tools. Runs fine for me and I'm crippled with Windows and the corporate mandated virus scanner.

Re:a few reasons

[drago]

For an interpreted language java is damned fast, that's right. Especially due to JIT there is almost no difference between C++ and Java regarding speed any more.

The only thing still awfully slow is Swing GUI and all efforts in making that faster result in making it less portable. I remember an article linked from slashdot some weeks ago, where the author promised fast and platform independent Java GUIs, which turned out to be JNI bindings for GTK+ ... not really what you want on one of the stranger platforms.

The one real problem I see with java is the high amount of memory it needs which is no problem on PC hardware, but can be much of a problem on embedded devices where due to the huge quantity of sold units every cent you spend on memory can cost thousands of US$. Even JavaME still consumes more memory than an app written in C.

Having said so much in favor of Java I must still say that I personally do not like it, and that's not because of having less experience with it.

Re:a few reasons

[bwt]

C/C++ are languages of choice of the industry

This is flat out wrong.

More people are being employed today to use java than any other language. As of today, monster.com lists 4233 java positions vs 3315 for "C or C++".

Development in java is much faster than either C or C++ because there is a larger base of easily reusable code, and because you don't have to deal with memory management. Unit testing, automated builds, and automated documentation are vastly superior in java, not to mention that portability is guaranteed.

I am continually baffled by people who knock java for its speed. It is faster than perl, python, ruby, and PHP, but nobody ever knocks these languages for their slowness. Most applications sit there with their CPU idle most of the time anyway.

Re:a few reasons

[Neophytus]

Azureus uses SWT and is fast, responsive and cross platform.

I'd use it

[immakiku]

I'd use Java for whenever I have a project that's a little bit higher than simple but doesn't require high performance. To me, it's very useful in the right situations.

Re:I'd use it

[pcraven]

I use java for applications that require high performance. I have one java app that moved over a billion dollars worth of transactions is a few short months.

Where I see performance problems is from programmers that don't realize what happens 'under the covers'. Web services, distributed computing, XML services, these are what kill performance on projects I've seen. People use them and don't realize the cost. They don't really know what happens under the covers. Without that, you can't do a cost benefit analysis.

And those types of problems happen in every language.

Its just a tool

[hoofie]

Java is a tool - just like every other programming language.

People do/don't use Java for many reasons - the choice of a programming language in a commercial environment depends on many different factors.

I work in Java - I can't say it excites me but it does the job.

Re:Its just a tool

[Lodragandraoidh]

We have replaced several Java apps at my job with Perl. It runs faster, uses less resources, and is simple to modify (no compilation needed).

Most web based apps I build now are either Perl CGI or Python Zope - and I am leaning more and more toward Python as the language of choice for large applications.

I don't think the problem is so much the language itself, or its implementation as much as the lack of understanding of developers in the IT shop to use Java as a matter of course - rather than a logical selection.

As stated elsewhere, using the right tool for the job should be developers number one skill. With the emergence of 4GLs and web development and presentation frameworks, coupled with the increase in computer and network speed capacity, there is little impetus to waste time offloading CPU cycles to the user's computer (via Java applets). To add a final straw to the Camel's back, the emergence of the CSS, and script standards as deployed in modern browsers and leveraged in modern development frameworks, provides more lightweight (and thus faster) options, particularly in concert with backend server processing.

Finally, all of the applications I build anymore are strictly web based - which puts a premium on efficiency - difficult to achieve using Java.

Re:Its just a tool

[dffuller]

Mod parent down. This is not insightful. He is comparing perl scripting to java applets. This is an apples to oranges comparison.

Re:Its just a tool

[Lodragandraoidh]

It is not an apples to oranges comparison if the desired outcome of the applications is the same.

If I do X with Java and I similarly do X with Perl/CGI or Python/Zope - and the result is faster using the 4GLs - then it seems clear to me that the best approach is to not use Java.

A process is a process - regardless of whether it runs on the server or the client. What differentiates them, then, must be performance.

Re:Its just a tool

[Anonymous Coward]

This is just messed up.

Are you talking about replacing Java applets with Perl scripts? What? And who does serious web development with Perl CGI!? I'm a full-time perl programmer and won't touch CGI. CGI.pm, sure, but not unless it's under mod_perl.

And Java not good for web-based applications? Have you not even considered the enormous rise of Java as a popular back-end server language purely for large-scale websites? And hey, in some cases Java's regexps are faster than Perl's!

I love perl. I make money writing perl. I teach people perl. But I also know Java (mostly from college) and can tell you don't know what you're talking about.

Re:Its just a tool

[Hulfs]

If I do X with Java and I similarly do X with Perl/CGI or Python/Zope - and the result is faster using the 4GLs - then it seems clear to me that the best approach is to not use Java. A process is a process - regardless of whether it runs on the server or the client. What differentiates them, then, must be performance.

Actually, your parent poster was precisely correct. You're trying to compare completely seperate entities. Applets were meant to be a way to deploy thick client applications to end-users as opposed to your perl scripts which are completely server/thin client based deployments.

If you truly want a closer apples to apples comparison you really should check into using jsps. On any decent application server a jsp deployment will outperform cgi based perl script (I can't speak for a mod_perl based deployment). I'm not trying to bash perl here, I love it. I'm just pointing out your error in comparison of applets (which are all but dead -- replaced with java webstart [.jnlp files]) to server side perl scripting.

Re:Its just a tool

[Anonymous Coward]

Have you heard of Servlets/JSPs at all?

Have you actually tried integrating with not just one RDBMS but multiple RDBMSs (Oracle, DB2,etc.) and going to the mainframe and tons of other Unix boxes (Linux, Solaris and AIX) all at the same time to aggregate data and present it into one coherent interface either using WAP or HTML based on the web request? That's the kind of issues enterprise developers deal with. Enterprise application development involves much more than just hacking together app in a a few hours or week.

Re:Its just a tool

[ShelfWare]

Do carpenters think a Stanley hammer is cool vs. a Craftsman hammer?

I agree with parent, it's just a tool.

Re:Its just a tool

[Lodragandraoidh]

Python/Zope will allow me to interface with multiple RDBMSs easily. The key is to use the tool that best fits the job. One size does not fit all. There is room for Java solutions; however, I have seen no pressing need to change from the perl/python I am using now for those server-side solutions.

Enterprise application development involves much more than just hacking together app in a a few hours...

My job is to make my customers (be they internal or external) happy. If that means hacking together something in a few hours - then I am going to do it. I am going to use every tool in my arsenal to deliver the solution when (before if possible) they need it - and then factor out any bottlenecks not anticipated (something you will still have to do regardless of what environment you use).

This goes to the core of the difference between classic 'waterfall' development techniques, and more progressive agile software development. The focus in classic design is to have everything defined up front and is reflected in the tools chosen for particular jobs. In reality, unless the application is trivial, this is not attainable in practice. Given that - I can't see any convincing argument that will bring me to embrace Java (on the server or client side).

I liken the difference between classic development methodology and agile development as the difference between a boxer and a streetfighter. The boxer is constrained by the rules, whereas a streetfighter will hit you with a brick if that is the most effective way to bring you down. Results are the touchstones of successful software development projects. I have seen enough projects go massively over budget and fail to deliver the promised functionality to know that classic 'authorities' do not trump results.

Re:Its just a tool

[bwt]

We have replaced several Java apps at my job with Perl. It runs faster, uses less resources, and is simple to modify (no compilation needed).

Actually, all three points are probably misinformed.

First, java is faster than perl according to nearly every benchmark I've ever seen. For example:
http://www.caucho.com/articles/benchmark.xtp
http://shootout.alioth.debian.org/craps.php

Second, you obviously aren't using Ant to automate your java buid and deploy process. If you were, the version control, compile, test, document, and deploy steps are a single click. Instead, you make it sound like you are making ad hoc changes to your production code. Bad. Oh, and finding bugs at build time instead of "in the field" is a good thing, not a bad thing.

You've got to be kidding when you say java isn't good for web applications. What exactly is wrong with JSP and servlets? There are several dozen very high quality application server components written in java over at the Apache Jakarta project. I suppose that all the people out there using Oracle and IBM tools to run their intranet enterprise apps on web based java platforms don't know what they are doing?

You seem to be thinking of java development as applet development. That is 7 years out of date. Go check out the following pages to see java in action on the web:
http://www.homedepot.com/prel80/HDUS/EN_US/pg_inde x.jsp
http://www.delta.com/home/index.jsp

Re:Its just a tool

[Lodragandraoidh]

Perhaps to settle this once and for all, we should have a 'shoot out' - a test to implement 10 specifications using our respective tools of choice:

1. oneliner specification (or verbal) do X
2. implement grep (man page serves as spec)
3. implement a web based database application that has X functionality
4. etc....
(all 10 acceptable tests for all parties)

First team to finish all projects (testplan based on specification given) wins a $25 gift certificate from ThinkGeek... :)

Re:Its just a tool

[hoofie]

The poster has made a valid comment about replacing Java apps with Perl. A lot of our 'maintenance' tasks could be done in Perl without all of the Java overhead/gubbins.

However, our organisation needs a scalable website, tied in to Oracle [in particular Oracle IFS], with a structured environment that can be deployed on Sun, Linux and Windows boxes [Note : Windows for development only !]. We're also developing two allied desktop applications which tie back into the same database for resale to large companies.

When you are talking about ENTERPRISE solutions, perl CGI, Python, Zope etc is not good enough. They might be great on a small scale or for 'hard-core' development, but then you have a development team of 20 people, with a website that is the organisations bread and butter, Java fits the bill.

uncool vs ....?

[Anonymous Coward]

How can Java be considered un-cool when you stack it side-by-side with such horrors as VB6? I'd much rather be forced to use a decent object-oriented language then a very poor .... I don't even know what to call the abomination that is VB6

Re:uncool vs ....?

[Ignorant Aardvark]

Amen to that! VB6 versus Java is no contest. Hell, the next generation of computer science majors is being taught Java (that's what the AP test uses), so it's the wave of the future, whether you like it or not.

Re:uncool vs ....?

[Taladar]

Cause we all know the people teaching at big Universities have vast amounts of real world experience.

Re:uncool vs ....?

[Ignorant Aardvark]

Yeah, but if Java is the only language that tomorrow's programmers know (if it's the one they're most familiar with since that's what they learned on), they'll be programming in Java.

Wait

[Lord Grey]

The title of the article is "Top Reasons Why People Think Java Un-Cool - Debunked" (emphasis mine). I did RTFA, and I saw no debunking. Just a list of reasons why people might not like Java.

This is news?

Re:Wait

[Technonotice_Dom]

This is news?

This is Slashdot...

Re:Wait

[DA_MAN_DA_MYTH]

Yeah that and when's the last time anyone from the tech world dictated what is hip and cool. Leave cool to MTV. If we were so worried about being "cool" we all would end up emulating the losers on G4TechTV... Cause they know what's "cool."

Re:Wait

[Trinition]

If it wasn't for all those damned security lock downs in Java, I'd infect you with a 100% Java virus just to prove you wrong! :)

COBOL

[sql*kitten]

Java is the new COBOL. No, I mean that quite seriously. COBOL means "COmmon Business Oriented Language". Java is the language of choice for modern day corporate application development. In the corporate world - which probably accounts for more actual lines of code than anything else - applications fall into two categories, forms (inputting data into databases) and reports (getting data out of databases). The corporate world wants legions of cheap, interchangeable programmers to work on these applications. Kids are taught Java at college or learn it themselves. The language makes it very easy for one person to work on another person's code, and it makes it quite painless to document your work as you go. That's the reason "hackers" don't like Java - they've just transferred their traditional dislike of COBOL to it.

Re:COBOL

[Marlor]

Java is the new COBOL. No, I mean that quite seriously.

Well, considering what COBOL programmers are earning these days, Java might be a valuable skill in the future.

Re:COBOL

[krog]

The language makes it very easy for one person to work on another person's code, and it makes it quite painless to document your work as you go.

Yes, because everything you do is broken into baby steps. If you look at Java code and you can't figure out what it is doing, you have no business programming.

Personally I don't like holding a program's hand as I write it. That is the #1 reason I think Java is uncool.

Re:COBOL

[halowolf]

You may wan't to add "background batch processing" to your list, like the business app i'm writing at the moment to process member bonus payments. In Java of course ;)

But more seriously, I fall into the right tool for the right job programmer category. Java isn't the be all and end all of programming languages and it has properties that I dislike. But there are some very good tools available now to overcome some of those disadvantages. I find these types of articles quite pointless as they only seem to be used to fan the flames of lanuguage elitism/fanboyism that incite arguments that really don't mean anything at all in the end.

Re:COBOL

[TopShelf]

I read articles like this and just get depressed. I actually long for the days when I worked on COBOL! The last couple years I've had to work with RPG *sob*. For many companies, it's not about the latest & greatest, but rather the cheapest that still gets the job done...

Re:COBOL

[Jonny_eh]

I'd have to disagree, one of my favorite apps is http://azureus.sf.net/Azureus Bit Torrent client. It works, on all major platforms no less, and has the same look and feel. Plus it operates with a similar memory/CPU footprint of the offical Bit Torrent client.

Re:COBOL

[RetroGeek]

COBOL was developed the way it was to allow managers to look at the code and have some reasonable chance at understanding what it does.

Which is why you have "sentences" and "paragraphs" and why COBOL is so damned wordy.

It is supposed to read like English. And if you go to some trouble with the naming of your variables you can almost make it like that.

Perl is the opposite of COBOL. Succinct to the point of incomprehensibility.

Re:COBOL

[MAXOMENOS]

Coming from an AI background and now working as a COBOL programmer (thank you dot bomb), I feel your pain.

Re:COBOL

[Epistax]

I agree entirely. Java is slightly akin to Visual Basic, just with more control and (obviously) wider compatibility. If you want an interfacing program, especially one with a GUI, more traditional approaches (C, C++) fall flat due to coding overhead. In Java this is traded for execution overhead, which largely doesn't matter given the speed of modern CPUs (although I hate to say it) and the fact that a user interface doesn't have to be any faster than the person using it.

Last summer I worked for Rutgers University in the genetics department. One person had a piece of software someone else had developed in java, which interpreted the results of a machine output. Without understanding the output, or how the program worked, or anything about biology what so ever, less than a day's time I was able to implement changes that a graduate student wanted to assist in his operations, namely, enhancing the GUI with some specific features. If it had been written in C/++, it certainly would have taken me much longer (although I don't have any sort of proof, what I can say is Java is easy).

Re:COBOL

[iGN97]

So...

"Huh-huh, Beavis, look. It's written in COBOL," will one day be "Huh-huh, Beaviz0id, look. It's written in Java. Jaaah-vaaar."

For many of us, I guess that day is already here.

Re:COBOL

[TeknoHog]

So true, it's not even funny. I think the last big demand for COBOLers was in the Y2K problem, and the next similar event could be the unix time overflow in 2038.

Re:COBOL

[dinog]

Assembly language is considered "cool", and yet talk about baby steps ! Indeed, CS as a whole is mostly finding the simplicity in a seemingly complex task. For large tasks, there is nothing wrong with stepping through a task in a simple, logical, and above all maintainable manner.

We need to require new academic standards for programmers. First, CS majors need to have at least one class where they are required to debug, maintain, update, and add new features to someone else's uncommented 10000 line perl program. The second part of the course would be writing a new program. Students have the choice of commenting or not. If the student turns in a well organized and commented program, they will be given a well organized an commented program to debug and modify on the final. If they turn in an uncommented and/or poorly organized program, they will be given such a program (but not their own) to debug and modify on the final. (Yes, I do maintain code for a living, why do you ask ?)

That said, why don't you like Java ? It has the obtuseness of C, the verbosity of COBOL, and even more compiler restrictions than Pascal. What else could you ask for ?

Dean G.

Re:COBOL

[animaal]

Everything is broken into "baby steps" because at each of those steps, there are a number of ways to accomplish the next step, achieving a different level of efficiency, error handling, thread synchronisation, etc.

Think of reading from a file. A less verbose language (like C) would just say something like int h = fopen("myfile", "r")

Java might say something like :

BufferedReader r = new BufferedReader(new FileInputStream("myfile"));

Definitely longer. But probably less than the equivalent code in C if the C programmer had to do the same buffering of input from the file.

Java code in general is easier to maintain, since it's easier to read. Not a big issue for leet programmers, but a big issue for their employers who have to find somebody to maintain the code after they've jumped to another employer.

The java code also won't puke up a GPF if there's a runtime problem.

Re:COBOL

[Anonymous Coward]

On the other hand, lower level languages like C and Assembly break everything into even smaller steps... but Java haters don't dislike them with the same vigour. Why is this? My theory is that the simple steps in Java are too easy. In C or assembly, in every single step there is the danger of making a subtle mistake that crashes the program. In Java, the abstraction works well enough that you need to write a lot more code before reaching the same level of bugginess.

Thus, a C programmer can look at each step and find his brain occupied by arcane minutiae, while in Java he would get bored by the slow advancing of the program logic where every single step is logical and predictable. Even though this means that you can accomplish a lot more in Java in less effort, the C programmer cannot be comfortable with it.

This same theory explains why people find Perl interesting -- there are so many interesting details in every character that it is easy to maintain fascination with code. Now, I wonder if this theory could be tested somehow...

Re:COBOL

[Cro Magnon]

Yikes! I didn't know anyone still used that! I learned RPG at DeVry, but I've never used it since.

Re:COBOL

[mwood]

If you dislike COBOL, may I have your share?

Re:COBOL

[Taladar]

Whenever anyone asks for a fast Java-App with nice memory-footprint we get one of two answers:
-Azureus
-Eclipse

One might come to the conclusion there are only two Programming Teams out there with the Skill to turn Java into a working Programming Language.

Re:COBOL

[Epistax]

1) Scripting won't give you any sort of interactive graphical display.
2) Not everyone wants to sit in front of a prompt all day.
3) Especially in genetics colored graphs are important.
4) Scripting won't even accomplish anything because the analysis is done by the user, not the program. The program presents the results, the person analyzes them.

Re:COBOL

[javaxman]

Funny, I somewhat recently met a COBOL programmer who works for a well-known investment-services firm. He seemed to indicate that his salary wasn't very good, and asked if they were hiring where I work ( as a client-side application developer ). I'm not so sure COBOL is really in that much demand...

given the chance that our future will see cheap memory, faster processors, and ( hopefully ) multiple computing environments ( you know, like cell phones and... oh, look! it's the future! ), it's likely that Java skills *will* be useful for many, many years to come.

*Especially* given the large number of business apps being implemented in Java and related technologies. And that's no joke.

Re:COBOL

[butane_bob2003]

I agree. You could do lots of cool stuff with Java, but most of the jobs out there for Java programmers are on the boring side of IT. I interviewed a programmer the other day who was the classic example of a not-cool Java developer. He started out his career as a COBOL programmer for a financial services company. His last job was dealing mostly with EJBs. When asked what the most interests him, he replied that he liked working closely with the data itself - JDBC,databases,XML etc. Just like a COBOL programmer.

Re:COBOL

[forgetmenot]

Those are all good points but you're missing two of the most important ones: Multi-Platform capability and large ready-to-use library.

Large corporations tend to have multiple environments that applications are required to run on. Java solves this. Secondly, software development is not the bread-and-butter of the corporations that use Java. It's just an IT tool and Java comes with a very rich library. It's also very easy to plug-in third-party libraries (yeah, trying doing that with Cobol). Less reinventing of the wheel means faster development times means cheaper IT expenditures. It's hard to think of any other language that solves these two problems as effectively as Java.

Re:COBOL

[aled]

You may have some point here, but I know COBOL, or at least knew it many years ago and I can assure that Java is a very general purpose language, unlike COBOL that was business specific. It sometimes doesn't fit well for business because it has nothing business like builtin (forms and reports as you point it) but its general advantages make it worth anyway. After all "makes it very easy for one person to work on another person's code, and it makes it quite painless to document your work as you go." never hurt any kind of development.

Re:COBOL

[BinxBolling]

I think you've nailed it. While there may be people out there doing interesting work with Java, by far most of the Java coding being done is of the "web or GUI interface on front of a business database" variety.

It's pretty dull stuff, and that dullness has shaped how the language of choice is perceived. While Java jobs may outnumber C/C++ jobs a bit, I'm betting that once you limit the field to jobs that offer real technical challenges (i.e. the hardest part isn't figuring out what the PHBs want) or that otherwise involve doing something really novel with software, Java doesn't look nearly so hot.

Making an interface

[ynnaD]

I had to take java as part of my degree and from what I saw, making any halfway decent GUI involved giving your soul to satan. Maybe it's better now, but the mere act of creating and making a usable button involved more steps than lazy programmers like me are willing to follow.

Re:Making an interface

[nb caffeine]

nope, no better now. Took a UI class in the spring, and dear lord, even with RAD tools, i spent more time learning how to program a button than learning REAL UI issues. Of course, i was too cheap to buy the book, maybe thats why i had no idea what was going on.

Re:Making an interface

[cs02rm0]

What would you recommend as an alternative? I've found it hard to stray from Java to other programming languages, even though I'd like to learn a few more, simply because building a GUI with anything else means learning not just the language but an unrelated toolkit or something. I can't find anything else to program in that isn't harder to learn to create GUIs with!

(It needs to be a viable linux option for me though... having just wondered if you're talking about something like VB).

Re:Making an interface

[CountBrass]

Agreed. Swing is truly awful. However, and at the risk of appearing condescending, experience of writing code as part of a course isn't actually that useful in determining a language's worth in producing code to do a job. Firstly because the examples and exemplar solutions are written by academics who too often write worse code than the most naive and inexperienced of professional developer (it's the old amateur/professional thing: there really is several orders of magnitude of difference between the two). And because in academia you have different goals in writing code: you're either learning stuff or demonstrating you've learnt stuff. In the real world neither are important: you have to deliver good-enough functionality to a deadline.

Having cut my teeth on assembler then C then C++ I can categorically state that as a language Java has all of them beat in pretty much every situation except where a small footprint is absolutely critical. And yeah I have written tiny footprint applications that have to be dynamically relocatable: relying on loaders to fix up addresses is for pussys ;-)

In every other situation Java wins because ease of maintenance trumps every other consideration.

That said and for exactly the same reasons I think that Java is often used where other languages (eg PHP, Perl) would be much, much better. I also think some major elements of Java (in the broadest sense) are premiership crap: all EJBs except Message Driven Beans fall into that category.

Edward

PS I see you've been modded flamebait: I think that's grossly unfair. I love Java and I think you're 100% spot-on: GUI development in Java sucks and always has: AWT was just embarassing. Swing was barely adequate when it came out and hasn't noticably improved.

Re:Making an interface

[kannibal_klown]

I'm a novice at Java; I was cast into the fire to learn it for a project (when I really didn't want to). Until then, my Java experience had not been a fun experience.

UI is very easy now, a LOT more than MFC (Visual C++). First off, there are GUI editors out there (even a plugin for eclipse), which embed the normal java code into the frame init code. It's the same code you'd type yourself with a text editor (if you wanted to).

Adding a button is simply dragging a button onto the fame and entering the name / text into the property panel. To add the action code, you usually have 3 choices:

1) Double click on the button, brings you to normal action code.

2) Click on the "Event" pane (usually tabbed with the property pane) and select which event you wish to code.

3) Manually code the event, which isn't that bad.

*Pretty much the same as VC++ and VB.

It's really a decent programming experience. I like coding in Java more than C++ now.

My only problem is deployment; deploying a Java application can be a pain in the a$$ when dealing with a mixed environment, while standard a VC++ binary is pretty simple. Even though JBuilder allows you to make an executable, it's pretty much just a wrapper to call the JRE to run the classes correctly.

Give it a shot, and install the JBuilder trial or Eclipse and the Visual Editor plugin.

Re:Making an interface

[Steve Cox]

> I had to take java as part of my degree and from what I saw, making any halfway decent GUI involved giving your soul to satan.

GUI programming from scratch is a pain in the arse for most languages. Thats why there are a miriad of IDEs available for pretty much any languge takes your pick.

Being a 'lazy programmer' would you rather code an X11 or MSWindows GUI up in C using nothing more than a text editor?

Steve

Re:Making an interface

[JavaLord]

I had to take java as part of my degree and from what I saw, making any halfway decent GUI involved giving your soul to satan.

Uhh, making a GUI is always a pain in the ass. Ever use C++ to make a windows GUI? It's still a pain in the ass.

Re:Making an interface

[The Snowman]

Took a UI class in the spring, and dear lord, even with RAD tools, i spent more time learning how to program a button than learning REAL UI issues.

JButton button = new JButton ("Button Text");
button.addEventListener (myButtonHandlerObject);
this.add (button);

Yep, that was tough.

Saying that it is difficult to add buttons and other elements to a JPanel is ludicrous. Saying that it is confusing to organize all your event listeners and other event-driven code is a valid argument. After all, that is one of my major gripes with VB, everyone's favorite straw man.

Re:Making an interface

[Steve Cox]

> AWT was just embarassing.

Damn right.

> Swing was barely adequate when it came out and hasn't noticably improved.

I'd have to half disagree with this. I'd say that Swing has improved vastly over the years (I'm talking from the time when Swing was a separate download).

Sure - there is a *lot* of room for improvement, but it *has* been getting consistantly faster. It certainly fast enough for the software I write (satellite network management - lots of graphs, world maps, diagrams, mimics, etc.). Things seemed to get a great deal faster with Swing around 1.2 when Java2D was added. Before then, I would never have attempted some of the GUIs I write today.

As for you comment about GUI development sucks in JAVA - well, I just don't seem to understand that. GUI development is easy. I can knock up a GUI FAR quicker in JAVA than I can in C++ (I know three languages - English, JAVA and C++ :) GUI development in most languages is a pain, but when you use an IDE with a GUI builder life is made easy(ier).

Steve

Re:Making an interface

[CountBrass]

I have just four words for you:

validate()

invalidate()

paint()

repaint()

Check and Mate ;-)

Re:Making an interface

[mwood]

Depends on what you want to do. If you want to do a lot of shell-like stuff, Tcl is a shell on steroids and Tk adds some of the nicest UI primitives I know. If you want to build your world around regular expressions and basic string mashing, Perl is a good choice and you can get Tk for it too.

Re:Making an interface

[Steve Cox]

I'll give you [in]validate(). For the beginner they take some getting used to and invariably don't do what you want them to do. Just leave them alone unless you really need to use them.

paint() and repaint() on the otherhand are trivial. Whats difficult about having a function that you can overide to draw your custom component and a function that will queue up an event to repaint it on the screen.

For me GUI design in JAVA is quite pleasant - certainly a lot more so than Visual C++. All that message passing and MFC(MotherF**kingC**t) macros gives me nightmares :)

I guess at the end of the day you either like it or not. There are some tasks for which JAVA GUIs are very well suited and others for which they are not. Even for the tasks which JAVA suited, it would still be just as valid to use something else.

In fact the whole thing is almost as pointless as Linux/*BSD or Gnome/KDE - everyone has their own opinion.

I don't dislike Swing (ie. it could still be improved).

Steve.

Too verbose

[random_culchie]

Some of the things in java are terribly verbose. especially when going to design GUIs.
Using the language you just "feel" as if there should be an easier way.
I'm no fan of microsofts products but I think C# is an excellent language to program in. It addresses alot of Java's shortcomings and it is a joy to program in.

Re:Too verbose

[MarkoNo5]

Requiring the keyword 'virtual' to be added to almost every method is not verbose ? I think my definition of verbose is out-of-date then.

Re:Too verbose

[CynicTheHedgehog]

I agree. I especially love the concept of "properties", which address the concept of getters and setters without the need for naming conventions. I also like the foreach( ) loop syntax, and the way Collections are handled.

But with Java you'll find that things are more verbose because they are more extensible that way. There are tons of places where the object model can be optimized to suit your needs at the moment, but they are they way they are for a reason. A good example is the JavaMail API. It's a pain in the butt to add attachments to E-mail (because the MIME stuff is so complicated), but I've used the JavaMail API to parse multipart-encoded form elements to write a file upload Servlet. It wasn't the intended purpose for JavaMail, but the MIME stuff was so well-written and abstracted that I could easily apply it to another (unrelated) MIME application.

I think probably the real problem is that some people prefer procedural languages (C, badly-written C++, Perl, etc.) than object-oriented languages. If you're one of those people, you're not going to like Java or the Java APIs. Java takes OOP to the extreme.

And with Java 1.5 (Java5) you get generics, enumerations, and that new funky for loop, which should make Java slightly less verbose while making it more robust.

Re:Too verbose

[famebait]

Swing is terribly verbose. And complex, unintuitive and simply a pain to use. Java itself isn't bad. There are some areas where C# improves the language and its compactness itself: I'd love to have delegates in stead of using inner classes that do basically nothing except work around a missing fundamental language feature for event-based programming, and not having to explicitly call get/set-functions is a bit addictive.

But mostly C# is such a joy to use because the newer APIs from MS are much slicker. Plus: everyone starts using C# in a proper IDE that helps you figure out what objects can do in stead of leaving you to wade through slow HTML docs looking for simple things like what that member variable was called again. Sure, there are brilliant IDEs for Java that can do the same and more, but they're not part of everyones first impression of Java like they are for C#. Same with interface builders: .Net's may be hell to do advanced layout in, but at least you can get going with the easy stuff straight away. Never seen a java-based one that does that.

Not that I would imagine that Paul Graham considers C# cool either, but who cares?
OK, so he does present some very sharp and well reasoned insights in his essays sometimes, and has the talent to convey them well. I'll give him that. Unfortunately he seems completely incapable of separating those from his own pretentious gut-feeling post-rationalisations. And I held that position before he published that eloquent but ultimatley pathetic "java sucks" drivel.

Java had a lot of good stuff, but has been superseded by C# (if one considers the language itself only), which had the opportunity to keep al trhe good stuff and fix the glitches that Java has to keep for compatibility reasons.
There are other language directions to eveolve in, that help with different types of tasks.

That website is uncool

[forgotten_my_nick]

I try to read it (I guess it is being hammered by /.) and the stupid webpage reloads itself.

Re:That website is uncool

[LabRat007]

Just for you buddy...


Paul Graham's Great Hackers essay has really touched a lot of people's nerves. The wires are choked with people giving their point of view.

Yet again, though, I have had to stop and think - what is it about Java that makes people brand it as the most un-cool language on earth? I have had friends look at me like I was a poor sod for "having to" develop in Java. So, let me list all the reasons I can think why people consider Java un-cool.

Java has considerably fewer surprises and prefers not to add complexity to the language for rarely used features thereby resulting in a language where you cannot really make your friends go ga-ga at amazingly brief programming constructs. You need to write something substantial [like Gosling's Huckster] for them be to impressed with your programming abilities and not your language knowledge. This is probably the biggest reason Java is un-cool. It's too easy (although programming or software development remains as tough as ever). Java was always touted as the language that the "average" IT programmer can use. It's such a language-for-the-masses that yet again, it fails the "geek" test. And if you use Java, so do you.

Java has been considered slow for ages. The earlier allegations (1995) were true. However, with the recent advancements in the JVMs from Sun and IBM, Java runs pretty close to C/C++. Check this benchmark. Contrary to this, there are other benchmarks that prove that Java is slower. All considered, it would be fair to say that Java cannot be considered "slow" anymore, yet its stuck with the label. How cool is to be the jock with the second fastest race-car in the block?

Swing disasters continue to give Java a bad name. Swing is a brilliant, although hard to learn, API. But the vast majority of Swing applications are so bad that they give Swing and therefore Java a bad name.

Java is a strongly typed language therefore you have to tell the compiler exactly what you intend to use. And if you make a mistake in the way you use it, the compiler has the guts to tell you that you were wrong. Too much chaperoning?

Java has a vast library that is available to all Java developers without any ambiguity. Thus, if you wrote yet another Map you would not be considered a data structures guru by Java programmers but a guy who hasn't heard of java.util.*.

Java did not have a good IDE that compared with MS Visual Studio. I think this one was true. I am not so sure it is any more with IntelliJ. The absence of good tools probably pushed away a lot of good programmers.

Java is popular. Anything that is popular has lost its elite status and therefore is not cool.

Java is an application programming platform. You cannot do cool things like device drivers and games, etc (until recently - but Java gaming is coming in a big way).

Re:That website is uncool

[JavaLord]

Java is an application programming platform. You cannot do cool things like device drivers and games, etc (until recently - but Java gaming is coming in a big way).

Huh? There are a lot of games written in Java. Java gaming is here. A huge part of the mobile phone gaming industry is based on Java, plus a lot of games on the internet. There have been full scale MMO's written in Java.

Also Speed

[mfh]

> Java is anything but terse.

I had to use Java back in school and I won't touch it unless my superiors threaten the branding iron (again). Java loads too much overhead and it doesn't have the same responsiveness as C based apps, IMHO. I don't think Java is optimized enough, and it shows. All the cross-platform support comes at a price and that price is speed.

Re:Also Speed

[Ignorant Aardvark]

I had to use Java back in school and I won't touch it unless my superiors threaten the branding iron (again). Java loads too much overhead and it doesn't have the same responsiveness as C based apps, IMHO. I don't think Java is optimized enough, and it shows. All the cross-platform support comes at a price and that price is speed.

Java is optimized ... for security. Java has all sorts of neat features built in like automatic bounds checking on arrays that simply don't exist in languages like C. This means that it may run slower, but in a computing environment where processor speed doubles every 18 months, would you rather have a little bit slow execution for now or a fundamentally flawed security paradigm? Programming in C leaves you wide open to buffer overflows and other attacks, and it takes a security-oriented programmer to overcome those problems. And guess what, once you get all of the code in there necessary to make it secure, it runs at about the same speed as Java. Java just puts all of the security stuff in by default, which I don't think is a bad decision in this age of computer worms and viruses.

Re:Also Speed

[Neomar]

Java is no system programming language. So it is not really an option for OS programming. ( It's an interpreter and you can't code an OS without memory access that is)

Re:Also Speed

[Stephen Williams]

in a computing environment where processor speed doubles every 18 months, would you rather have a little bit slow execution for now or a fundamentally flawed security paradigm?

"They who would trade essential CPU cycles to gain a little temporary security deserve neither CPU cycles nor security."
-- B3nj4m1n Fr4nx0rlin

Hmmm, it seemed considerably funnier in my head...

-Stephen

Re:Also Speed

[Brother52]

I'm sorry, but .NET has pretty much invalidated this "speed in the sake of security" argument. It has all that security and not a fraction Java's sluggishnes and memory appetite.

Re:Also Speed

[Ignorant Aardvark]

+1 for the effort of trying.

Re:Also Speed

[jinxidoru]

This could be a reason that Paul Graham states that he doesn't know any great Java coders. What you're saying is that it takes a better programmer to code in C properly. Great programmers ideally do not need these extra security features, so they choose a language where they are not present.

Re:Also Speed

[dfj225]

Actually, Java can be just as fast as C or C++ code in the right situations. I think the best place for Java is on the server. Here apps run for long times and overhead doesn't have to be a huge issue. Java VMs are capable of predicting the code's branches after it has run for some time, so it seems that it can be quite efficient on a server. Also, I don't think that the cross-platform support is what would necessarily make Java "slow" since each VM can be fined tuned for the platform that it is designed for.

Re:Also Speed

[putaro]

Nonsense. You can provide a nice, safe, memory access with the right native classes or by modifying the JVM appropriately. Sun turned out a Java OS back in 1998.

Re:Also Speed

[Gr8Apes]

Might that be because .NET is (partially) loaded already?

Re:Also Speed

[bjk002]

"would you rather have a little bit slow execution for now or a fundamentally flawed security paradigm?" No!!! As you point out so clearly, processor speed and environment changes every 18 months. Apps I write have an equivalent lifespan. Few apps I know of have much more of a lifespan than that. I want it as fast, and as capable as need be to meet: a) deadline b) customer expectations c) budget 'Not necessarily' in that order. Java is a GREAT, robust language, but there are penalties to it. Give me FAST, flexible, RAD, design with a security hit any day. Personally, I love Python, though admittedly I do not do much work in it. Borland Delphi is nice for the quick and dirty apps, I like the company, and it saves me the time having to muck with all the low-level C. Can I do it... sure... but why would I reinvent the wheel over and over and over and over.....

Re:Also Speed

[smcdow]

..., but in a computing environment where processor speed doubles every 18 months, ...

Oh, that old strawman again. "Yeah, Java runs kinda slow, but just upgrade the HW, and it'll be OK." Lame, lame, lame.

I don't know where you work, but we don't upgrade machines that often. In fact, some of our customers' platforms are more than 10 years old, and they ain't gonna change platforms no matter how much faster the newer ones are. (Aside: Can you even get Java for HP-UX 10.20?)

IOW, it's not a foreskin conclusion that upgradea are an options. Besides, why use a language/environment that forces you to upgrade?

Re:Also Speed

[Gr8Apes]

I think it really depends on what you're programming for. For user applications, especially small ones, it doesn't really make sense to program in java unless portability is your overriding concern. For business applications, especially server applications, java makes much more sense precisely because of the security features inherent to the language, not to mention the maintainability of the code, provided that programmers with half an ounce of knowledge are working on it.

If Paul thinks lots of "great" programmers work for MS (they code in C, hence they must be "better" than java coders) I'd like to know how he explains the never ending list of bugs, many of them security bugs/buffer overflows that seem to permeate the entire set of MS code?

That aside, yes, a great programmer will be able to code something fast in the terse language of choice. That same code will most likely be unmaintainable when the poor maintenance guy comes along to attempt to track down the buffer overflow or whatever other error has cropped up in said code.

And just because you use a language like Java doesn't mean your code has to be verbose. You can approach C's terseness with Java, although you cannot utilize some of the pointer variable morphing attainable by C. But you certainly can approach C or Perl's unmaintainability with ease with Java, all it takes is 1 or 2 people that don't understand the language, architecture, nor OO. (Think 14K line "classes" here with 20 or so methods, 5 "inner" classes, and lots of circular dependencies)

Re:Also Speed

[recursiv]

IOW, it's not a foreskin conclusion ...
[snip] (ouch)

Foreskin conclusion? You mean like new parents weighing the merits of circumcision? Ahahaha. Good stuff my droogy.

Re:Also Speed

[the quick brown fox]

I've been using .NET for the last 18 months and Java for the last four years, and they seem about the same speed and take about the same footprint.

Re:Also Speed

[Tassach]

I agree. Java is not a language for systems programming. The question is, what percentage of programming tasks entail low-level systems programming versus high-level applications programming?

The VAST majority of software being written is high-level business applications; hence there are at least an order of magnitude more JOBS available for application programmers than systems programmers. For virtually all business apps, programmer productivity, code maintainability, and predictable scalability are FAR more important than raw execution speed. This is where Java puts C++ to shame.

Re:Also Speed

[4rest]

There is no excuse for not being a "security-oriented programmer". There are tons of tutorials on the web. Avoiding overflows is a simple task that anyone can learn to accomplish.

Re:Also Speed

[happyfrogcow]

this is deserving of going into "fortune" or some other QOTD app.

Re:Also Speed

[Ignorant Aardvark]

You make it sound so easy. If Microsoft, largest software company in the world, can have many, many overflow exploits, how in the heck is a single programmer supposed to avoid them?

Re:Also Speed

[4rest]

Microsoft has problems because they employ a large number of programmers that have just recently been educated about secure programming techniques.

I believe the problem was educational institutions bracing for the impact of the dot com bubble, throwing together CS curriculum that cuts out the needs for bounds checking when moving data around memory, and then pumping students through their program.

To be honest with you, I do believe that writing code without buffer overflow vulnerabilities is an easy thing to achieve. Furthermore, if a company's programmers can't avoid them, simple checks can be placed into their compiler to throw warnings when they're detected.

With security being as important as it is today, ignoring the idea that code one authors might be insecure is plain negligence, IHMO.

Re:Also Speed

[AstroDrabb]

BS. I have been building .Net and Java apps for the past two years and they both have about the same runtime performance and memory foot print. .Net GUI apps seem to have a slightly faster startup performance over swing GUI apps but not over SWT GUI apps. Also JSP/Servlets vs. ASP.Net are both on par with performance from my experience with the two for web apps. .Net GUI apps probably have a little startup performance gain over Java because more of the MS DLL's/etc are loaded by the OS, where Java apps are usually a full cold-start.

Re:Also Speed

[Nevyn]

Java is optimized ... for security.

And python and perl aren't? At least I can write a secure "rm -rf" in the later two ... in Java security is sacrificed for "portability". And it even fails at that due to every deployment of Java I've seen having the most fucked up env setup scripts I've ever seen, which make it a major PITA to move from one machine to another.

Re:Also Speed

[MoneyT]

Bullshit. That's like saying that people who program in assembly are better programers because they don't need predefined functions.

Just because new technology makes old skills obsolete does not imply that people with newer skills are worse than the old people.

Re:Also Speed

[dnoyeb]

Let us also not forget that Java JVMs are written in C or C++ or objective C or whatever you like, so the whole Java vs. C speed comparison is illogical.

Re:Also Speed

[dnoyeb]

Actually, Java can be just as fast as C or C++ code in the right situations.

Java is exactly as fast as C or C++ because its JVMs are written in C or C++.

Its like arguing that assembly is faster than C. Its not because they are not comparable.

Re:Also Speed

[chaoticset]

Java is optimized...for security.

Flippant response: So is the security screening process at major airlines, even though they wouldn't have prevented 9/11 and don't prevent anything now.

Historical response:

Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety.

Percieved security lowers actual vigilance and actual freedom, providing no actual security.

Re:Also Speed

[chez69]

I guess I can see why some people hate java now. It allows a larger percentage of people into the programming 'club'.

Re:Also Speed

[Anonymous Brave Guy]

The VAST majority of software being written is high-level business applications; hence there are at least an order of magnitude more JOBS available for application programmers than systems programmers.

I'm sorry, but that simply isn't true. Take a quick on any jobs board, or ask around in any hi-tech area, and you'll find far more jobs in areas like embedded software (particularly telecomms), scientific/engineering apps, and instrument control. The bubble on everything being a web-enabled database burst a couple of weeks ago, in case you missed it. ;-)

In fact, looking at some respectable local IT job boards, Java appears to be a skill very much in decline, as is VB. C and C++ are as strong as ever, as is SQL. Then there's a surprisingly strong showing for Perl and also Python, considering their relative obscurity. Sure, there are also quite a few Java and .Net/C#/VB things, but an order of magnitude more jobs for applications programmers? Not unless you're counting all those high-performance, low-level jobs and everybody's system admin scripts as applications.

Re:Also Speed

[Mad Bad Rabbit]

Aside: Can you even get Java for HP-UX 10.20?)

Yes, at the very least JDK 1.1.8 is available (looking at what's on our ancient HPUX 10.20 box).

Not the latest+greatest, but adequate for simple XSLT/XML stuff.

Re:Also Speed

[Theobon]

When will people stop just waiting for computers to get faster so their bloat code will run and design good code?

Re:Also Speed

[Bob Uhl]

Ummm...have you ever read any of Graham's work? He doesn't advocate C over Java: he advocates Lisps over everything. He's quite convincing, actually.

Re:Also Speed

[a_n_d_e_r_s]

I've run java on older HP-UX than that.

PS 10.20 is only something like 8 years old... remember I got it in 1996.

Re:Also Speed

[greenrd]

Furthermore, if a company's programmers can't avoid them, simple checks can be placed into their compiler to throw warnings when they're detected.

Please explain how to do that in C. It's not possible, with all the pointer-fiddling magic you can do.

Re:Also Speed

[junkgui]

java web start... you are dumb...

Re:Also Speed

[aled]

I would stated it the other way:

"They who would trade essential security to gain a few CPU cycles deserve neither CPU cycles nor security."

It remind me the joke:
-Quick! tell me 2+2?
-5!
-Wrong! 2+2=4.
-How do you wanted it? Quick or exact?

Re:Also Speed

[musicmaker]

Wow - I am so sick of this argument.

But computers get faster, so it's ok to produce slow crappy code.

It's not that java is better, it's that java is easier, so you get more monkeys with no education who think they are programmers writing code.

Java can be fast, but there are too many idiots who think slow code is okay because computers will just get faster.

HELLO! Computers do 2.4 billion cycles per second, what possible excuse can any programmer have for anything but very complex scientific operations taking more than a couple of seconds to complete. Even network latency these days is low.

Get a grip people.

Waiting 60 seconds for an app to start is UNACCEPTABLE!!! It's pure crap.

Java promotes CRAP.

C++ means you actualy have to have a clue about what you are doing!

I'm tired of working in java going back over people's code who didn't have a clue and having to recommend to management that we have to re-write from the ground up because all we have is a stinking pile of mess.

My company spent $2mil developing an app that has to be re built because even the DB design is rubbish.

Language for the masses?

[Anonymous Coward]

Java is exactly the opposite of a language for the masses. Overcomplicated APIs, quirky virtual machines... doing serious development using java requires a huge amount of resources in hardware and education. It looks more like it was designed to provide job security for Sun.

Not responding

[gr8_phk]

The site must use a lot of Java code.

Re:Not responding

[duslow]

sys-con's servers are actually running cold fusion.

Java's uncool image

[PhysicsGenius]

Java started out seeming cool because it was the Write Once, Run Anywhere language. And it was Somehow Internet Related back when that was cool.

After a while, though, people started noticing that Java is slow as mole asses. And it's a huge memory hog. But worst, I think, was when it started to dawn on programmers who actually think that Write Once, Run Anywhere doesn't have anything to do with the language you write in. It has to do with thinking portably.

It's very easy to write a non-portable app in Java. You have to make sure you use architecture and OS independent functions and algorithms if you want to be portable. And if you are going to do that, why not just choose any language you want (that has a compiler for the target OS)? Like C, which is fast? Or a scripting language, which is easy?

And of course finally, Java is uncool because it is a buzzword that non-programmers use.

Re:Java's uncool image

[HermanAB]

Write once, debug everywhere, has been touted as a feature of every programming language as far as I can remember - all the way from Cobol, C, Pascal etc. to Java and C#...

Probably the most portable language is Fortran, since nobody ever writes a GUI in Fortran.

Re:Java's uncool image

[mwood]

"nobody ever writes a GUI in Fortran"

Is my memory failing, or is MUSIC* such a system? I know the thing is written in Fortran.

--------------
* McGill University System for Interactive Computing

The Horror!!!

[Meostro]

Does it bother anyone else that this page has 65 ads on it? It frickin' hurts to read, it's almost as bad as http://www.seizurerobots.com/!

Also it bugs me that this guy has to rant and rave about Java, but he can only come up with eight "uncool reasons" to debunk. C'mon man, the standard Top Ten list has TEN items.

Re:The Horror!!!

[foobsr]

... it's almost as bad as http://www.seizurerobots.com/!

In cases like this a warning would be fine.

CC.

Re:The Horror!!!

[mwood]

He must've been counting in octal.

IMHO

[AviLazar]

Java is uncool because it just eats up my cpu. I run a java program (PcGen) and the thing is insane in its resource use. I am also constantly crashing it. The fact that it can port from one OS to another - big whoop if it does it SLOWLY!
But the API's are nice (I am the eLearning industry and we utilize SUN LMS)

Re:IMHO

[ruckc]

If an application in a language constantly crashes, its 99.999% of the time not the languages problem. This actually brings to light one of the benefits of using java, you know exactly the kind of errors you can get if you read the API. Based on these errors you know you could get, you should make the program recognize and handle the exception.

Re:IMHO

[AviLazar]

I may have phrased it badly. The application does not crash on its own, I have to crash it (task manager) because it is unbearably slow. If i shift out of the program to go to something else, when I come back I am sitting (longest time I sat was about 5 minutes until it caught up).
So most of the time I crash the program, and re-open it. Yes I think the program (PcGEN) is a bit clunky, but it is not entirely the fault of the program.

Re:IMHO

[AviLazar]

OK someone needs to explain to me what qualifies as a troll. How is my original post listed as a troll?
Jesus, whoever gets to metamoderate this person - i HOPE marks it as unfair.

Re:IMHO

[hesiod]

> whoever gets to metamoderate this person - i HOPE marks it as unfair.

I did.

Re:IMHO

[AviLazar]

Come on now, its open source - you would think amongst all of their developers they could optimize it. So yes I am.
Oh and the "hobbyist app" can run you over mint after getting all the extras.

Why, Python, of course.

[Russ Nelson]

Python is an enterprise-grade programming language because its code is so readable. Sure, you can write a perl program faster, but six months later you won't be able to read it.
-russ

Re:Why, Python, of course.

[JSkills]

Won't be able to read your Perl program? Isn't that blanket statement? Does it really depend on who's writing the code?

Anything I write in any language is extremely readable by anyone - because I code that way. Period.

Re:Why, Python, of course.

[cafard]

And that's precisely why Perl is so much more cool ;)

Re:Why, Python, of course.

[EricWright]

You can write PERL that is completely illegible, or you can write PERL that looks just like C++ with extra $, @, and % strewn about. It's all up to who is writing it and what coding standards they have to live up to (if any).

I have PERL scripts written years ago that I haven't touched in quite some time... they're still very legible though (and I rarely comment my own code... only my employers!)

Re:Why, Python, of course.

[TeknoHog]

You can write PERL that is completely illegible, or you can write PERL that looks just like C++ with extra $, @, and % strewn about. It's all up to who is writing it and what coding standards they have to live up to (if any).

That's exactly the problem of Perl, having more than one way to do one thing. It's fine when you're the only one who reads your code. People tend to learn a subset of Perl that does everything. But what if you're collaborating with other people who know a different subset, and generally a different coding style?

Of course style can be enforced, like the Linux or GNU guidelines for writing C. But at that point you could just as well make the language itself clear and consistent, which is just what Python does.

Re:Why, Python, of course.

[spike2131]

I love Python, but find its object oriented features to be lacking. Having to pass methods references to "self" just pisses me off.

Re:Why, Python, of course.

[Anonymous Coward]

Umm, you don't have to pass references to self unless you need to be explicit about what self is. Otherwise, you only need to add self to the method definition (which I do think is a bit silly when it could easily be implied).

class bla:
def method1(self, str):
print "spike2131 is", str

b = bla()
b.method1("confused") # no self reference passed

What's not to love about Java?

[wayward_son]

It's got the simplicity of C++.
The freedom from corporate interference of Visual Basic.
The speed of an interpreted language.

And you wouldn't believe how efficiently it uses RAM and CPU power.

I don't see why everyone doesn't use Java!

Re:What's not to love about Java?

[julesh]

Very funny. But I think a good joke should be at least based on the truth.

Java is a lot simpler than C++. I'm not aware of any 'corporate interference', and the Java Community Process ought to ensure that such things don't happen.

And it's substantially faster than most interpreted languages I've ever used. Particularly if I compile it to native code (which you can do, if you want), although this isn't necessary.

RAM usage isn't that bad, either, if you don't use AWT. CPU power is just another speed comparison.

Re:What's not to love about Java?

[moonbender]

Java is a lot simpler than C++.

Amen to that.

Java is bloated

[cperciva]

Recent benchmarks have demonstrated that, once running, a well-coded Java program is about as fast as a well-coded C program.

However, the "once running" issue is a big problem. Java startup time is slow, simply by virtue of the time it takes to load everything off of disk. And, unless you're running a server -- which most people aren't -- the startup time is by far the most important performance criterion in determining subjective performance.

Give me back my <20kB executables, and I'll consider using Java.

Re:Java is bloated

[michaelggreer]

Some recent benchmarks show it is as fast as C++ (not C).

As for the startup time, you are right. However, I think you underestimate the amount of programming done for servers, and the ubiquity of server-based programs. Counting the websites and web applications you use every day, I would suspect that you use many more Java programs than you think.

Re:Java is bloated

[deragon]

If this is true, why then is Swing so slow while running? Does Swing purpusly run unnecessary loops? I mean fill up a list with 50 entries and scroll it down. Its so slow!

I never understood why Java is as fast as C for server apps but compares badly for GUI. I mean, how much of bad coding you have to do to get a set of Widgets as slow as Swing?

There are a bazillion sof native widgets for Linux out there (Gtk, KDE, TCL, wxWindows, etc...) and they all run fast. I doubt that they all have been tweaked up to the assembly level. After all, widgets should not take that much CPU (GEOS on a C64 was snappy, running at 1 MHz). So why is that Swing on a 1Ghz machine is so slow?

This has always been a mystery for me. Server side, Java is fast, Desktop it is slow. Must be a "if (desktop) { slowdown = true; }" statement in the VM.

Re:Java is bloated

[bwt]

If this is true, why then is Swing so slow while running?

My favorite text editor is jEdit, which is a swing app. I don't find it slow at all. I use it constantly, typically with 15 to 20 files open for editing.

I'm completely baffled by people who still use vi and emacs. Yuck. Alt-Meta-No-Way. ZZ

Slow

[lukewarmfusion]

When I was in school, I did some Java programming. It was great for teaching programming for many of the reasons it's considered "uncool." For real programming, though, I find that the compiled programs run unbelievably slow. For a time I thought that it was my fault - that I didn't know enough to make my programs run any faster. But I've noticed it with pretty much every Java program I've used, including ones written by Sun's Java developers.

It's too big of a drawback.

Re:Slow

[vasqzr]

Yes, I'm going to agree with you. Let 100 people chime in and say Java is the same speed, or even "Faster than C++". It might be the case on a benchmark or two, but I've never seen it happen in real life

One example would be some software that our company uses to produce contract Documents. The old program was a Windows application. The new version of the program is Java based.

We use Pentium III 500MHz desktops with 128MB of ram.

The new program is VERY slow, and takes up nearly 190MB of RAM by itself. We've had to upgrade each workstation to 384/256MB. Guess what, it's written in Java. Exact same end result (this documents haven't changed much in YEARS) but the 'new' program is a hog.

Re:Slow

[Coppertone]

Have you tried Azureus, the most popular bittorrent client recently?

http://sourceforge.net/projects/azureus/

It's written in Java...

Re:Slow

[Coppertone]

That's because it's quick to prototype...

Would you write the ref. inmpl. in C? nope, because it is wrong tool for the job.

Re:Maybe because it's slow ?

[tedgyz]

Please, do we have to hear this comment every time Java comes up? It was cool to say that in the 1990's, but it's a little out of fashion now.

Enterprise-Grade

[A55M0NKEY]

"Enterprise-Grade"

Is that like "Downers and organ meat destined for ALPO cans"?

Re:Enterprise-Grade

[joib]

"Enterprise-Grade"

Is that like "Downers and organ meat destined for ALPO cans"?


LOL. Pretty much, I guess.

"Enterprise-Grade" is just a BS term invented by people faced with the prospect of spending their entire careers doing the utterly boring, dredging work of "read stuff from database, show it to the user and write changes back to DB", that constitutes the vast majority of all programming.

Real Programmers, as we all know, write programs to simulate the end of the world as we know it (or perhaps control the systems designed to bring said apocalypse about). And they use FORTRAN.

Re:Maybe because it's slow ?

[Anonymous Coward]

Java is slow when you are starting something up and the Java vm isn't started. When the vm is started, Java is outright fast. Many people fail to realize this is what's going on, but it's simply the way it works. The first time it's going to be very slow, every time after (until the vm is killed) it will be comparable to a C/C++ application in speed. When you're developing enterprise applications, that first time slowness doesn't outweigh the benefits of using Java.

This isn't to say Java is perfect for everything, but it is for some things.

Who cares?

[Anonymous Coward]

Who cares if it's cool or not? From my point of view, it pays the bills.

From my employer's point of view, it makes me more productive than (most) other languages would, since I spend less time worrying about crap like header files, pointers, memory leaks, and so on.

So everyone wins. "Cool" stopped being important when I turned 18.

Re:Who cares?

[imbaczek]

From my employer's point of view, it makes me more productive than (most) other languages would, since I spend less time worrying about crap like header files, pointers, memory leaks, and so on.

Just like about any other language in the world except C, C++ and assembly. IMHO 'it pays the bills' is the only good reason to actually learn Java -- and that is not cool. Or fun, if cool is not important for you.

Re:Who cares?

[dfj225]

"Cool" stopped being important when I browsed /. for the first time.

Re:Who cares?

[pHDNgell]

From my employer's point of view, it makes me more productive than (most) other languages would, since I spend less time worrying about crap like header files, pointers, memory leaks, and so on.

What are these languages? There really aren't that many languages that require manual memory management, or use header files, or have pointers, etc...

You've basically said it's more productive than most other C based languages. Well, yeah.

I'm far more productive in python or ocaml. They're both higher level. Python has more APIs available, but ocaml is safer, faster, and more expressive.

Even in java (which the majority of my job requires), I will often implement classes in jython and then port them to java for deployment (which makes them much, much larger).

Re:Who cares?

[quelrods]

try again, just because java has a gc does not mean no memory leaks. Quite the opposite. There are many companies that have products to look for memory leaks in java applications. In fact IMO it is more tedious than malloc'ing and free'ing the memory. You don't allocate it but you better be sure to drop all references (such as closing db connections.) Oh and i'm sure fiddling with getting the neccessary jars and adjusting your classpath is lots easier than worrying about such tedious things as header files, please!

Re:Who cares?

[ttfkam]

C'mon. Are you really going to assert that finding dangling pointers and making sure that all malloc/new calls match up to a free/delete call really matches up to the memory management in a garbage collected language? Yes, you must make sure that you don't keep unwanted references around. And this is different from any language (including C) how? With C you have to not only watch for memory accumulation, but that the memory is freed AND that you don't reassign a pointer before "free" is called.

And as far as "fiddling" with jars and classpaths, exactly how are you not fiddling with shared libraries and LD_LIBRARY_PATH?

Re:Who cares?

[ttfkam]

Could you please show me an example of a dangling reference in Java? I'd greatly appreciate it.

And what about the GC is esoteric? You no longer reference an object. The GC reclaims it. Seems straightforward to me.

Is a modern GC more complicated than that? Sure. The implementations are truly mind-boggling. But whether it's a mark-and-sweep or a generational garbage collector, as a coder, all I see is "set to null and it goes away." I admit, when tuning for performance, other issues may come up with the garbage collection implementation (usually not), but by and large the issues with software development are not governed by garbage collector behavior.

No unsigned ints!

[Zo0ok]

Lack of unsigned integer types makes java really uncool!

As I write this I feel I somehow must have got this completely wrong...

Paul Graham isn't Cool, Duh.

[freality]

See how easy it is to assert that something isn't cool?

When I read Graham's article, I was disappointed. It had that air of someone being passed by, by a lot of fun. Saying Java isn't cool is like saying Scheme or ML isn't cool. It's just a personal preference, and when you express it, you run the risk of sounding anal and/or ignorant. His older articles were better considered.

Here's my utterly ignorant statement of the day: No matter how many ultra-cool hackers I know tell me that Lisp and Scheme and ML are cool, I never have fun using them. They force my brain into such an unpleasant state of nerdliness that the only thing I can program in them is a mathematical proof or some sort of logical system.. in short, I'm forced to become a boring CS professor using them.

Don't bother debunking reasons why Java isn't cool. The only path to cool is the acceptance of luserdom. Only when you have nothing to lose will you dare to do something audacious.

Look at punks. The only time they're cool is when most of society considers them fringe lunatics with no social graces. And then the rock happens again. It's when they're "cool" that the music invevitably begins to suck.

Being called uncool is a blessing in disguise. Thanks Paul.

Re:Paul Graham isn't Cool, Duh.

[awol]

No matter how many ultra-cool hackers I know tell me that Lisp and Scheme and ML are cool, I never have fun using them. They force my brain into such an unpleasant state of nerdliness that the only thing I can program in them is a mathematical proof or some sort of logical system.

Er, that is every single computer program you have ever written. First let me disclaim that I make my living writing in C (a little C++ and some interpreted languages). But I firmly believe that until we approach every program as the "proof of a logical system" we will be burdened by the inexorable piles of poo that is the vast majority of the software written today.

Functional programming is the way forward. I don't mean this as a personal criticism of the parent poster, just a general comment. The fact that they (most programmers) cannot see that every program they have ever written is a logical system is an indictment of how most people get into the industry. Code is just applied mathematics and most coders do not have the mathematics to apply. The sooner we fix this the better the quality of the programs we write will become.

Re:Paul Graham isn't Cool, Duh.

[Fnkmaster]

Well, you hit on an interesting point, but I think your expectations are unrealistic. Humans just don't do a good job thinking in that way. There are a very few people who do, and they are mathematicians - and it even takes them a long time to write successful, logically complete proofs.

You could take the approach that every piece of software you write has to have that level of detail and accuracy, proof-like precision if you will. I think you'd find that your productivity would be far lower in terms of logical constructs completed per unit time. This is probably an acceptable trade-off if you write control systems for nuclear power plants or if you work for NASA where budget and time-frame are vastly greater than for your average business programming problem.

But for most applications, there is not only a set of requirements, things it needs to do, but a very short period of time to make it do them in. And if you go to the boss and tell him it's going to take 14 months and cost 1.3 million dollars because everything has to be written as a logical proof, he's just going to fire your ass and get a team of third-world guys to puke it out in Java in 3 months.

I'd love to be proven wrong here - if you can show me a study that indicates that use of ML or some other language type results in substantially more bug-free code _without_ sacrificing development speed, then by all means, I'll admit that I'm wrong. My own personal experience is limited to small apps I've written in OCaml, which were cool and everything, but OCaml isn't purely functional, and I found several aspects of its use quite painful, despite feeling very "elite" as I hacked away in a semi-functional language.

Most particularly, the idea of not specifying an explicit contract between chunks of a system with the types of information passed between them really irks me - to me this makes a development language unusable by more than one person, or even by one person in a sizeable programming project. I constantly refer back to other chunks of my code to see what type of data I need to feed to some function or method - and when using somebody else's code I'm far more likely to be interested in the interface than the implementation. Without that kind of separation, I don't see how this stuff is usable (I can't "keep the whole proof" in my mind at one time when I'm doing mathematics either, that's why you have lemmas and theorems and other mini-proofs that you call out to).

Maybe somebody can point me to a more usable version of a functional language that doesn't "feature" static typing, or that was designed with real programming tasks in mind and thus would be worthy of more study re: the development speed and team usability characteristics I mentioned above?

Re:Paul Graham isn't Cool, Duh.

[CanadianCrackPot]

I always think of my programs as a bunch of logic. Why the hell are there if statements and the such if it isn't. Now the math part, sure when I do math operations into an assignment. Also, if I'm trying to figure out will this algorithm be faster than this one, or should I go recursive and suffer through the migrane.
This in mind there are two major ways in which I WILL NOT under any circumstances code

1. Functional programming (Scheme, Lisp, et al) these are evil from my point of view (too much recursion arrgh my head)
2. Assembly with recursion (last time I snapped and didn't come out of it for a day, and then had to waste a months supply of Rum to get over the damage)

Re:Paul Graham isn't Cool, Duh.

[putaro]

But I firmly believe that until we approach every program as the "proof of a logical system" we will be burdened by the inexorable piles of poo that is the vast majority of the software written today.

Your software is only as good as your requirements. Even if you approach it as a "proof of a logical system", in general the requirements that we start with are crap(that is, we don't really know what the hell the application is supposed to do) which is which is why the end result ends up as crap.

Re:Paul Graham isn't Cool, Duh.

[bladesjester]

heheh.

I can understand #1. I can generally program in Scheme and have it work, but if I try to think too much about *how* I got it to work, my head hurts.

As for #2, the main thing I gained from learning assembly was a better understanding of how things worked down at the bare metal. Believe it or not, it helped me figure out things that I had problems with before.

Re:Paul Graham isn't Cool, Duh.

[gnuLNX]

Ahmen to that. Programming is pure logic...nothing more nothing less. Yeah you can do lots of logic without higher math, but at some point (ex. scientific code, games, graphics, ai, pretty much all the really cool stuff) you need the math....lots and lots of it. Yeah

Re:Paul Graham isn't Cool, Duh.

[mmusson]

I could not agree more with your post. There was another quote that went something along the lines of: a cool language is one that teaches you something by learning it. I thought learning and using Haskell and Lisp were very useful for a different and complementary mindset that they help create. I think my C++ programs are higher quality because of my functional programming experience.

Languages like Java or Basic are not cool for me personally because they did not teach me anything. These languages are primarily designed to protect the computer from the programmer. I think the proliferation of buggy programs is due to languages like Java or Basic that make it easy for a person without the proper training to program. Engineers need to go through very rigerous tests to certify their expertise before they are allow to design and build a bridge. Why should programming be different?

Re:Paul Graham isn't Cool, Duh.

[TheWizardOfCheese]

... every program they have ever written is a logical system ...

You mean, every program is a logical system, except for the side-effects. I am sympathetic to the sentiment of your post, but as side-effects are usually the point of a program, this is an important caveat. It gets worse: until the day arrives when end-users specify their requirements in a formal system, formal correctness will have little application.

Re:Paul Graham isn't Cool, Duh.

[Have Blue]

Functional programming disdains stored state, which is an important part of far too many applications (not in the software sense). How would you write a database program in a functional language?

Re:Paul Graham isn't Cool, Duh.

[RAMMS EIN]

Wow. Someone here who cares more about the theory than the application. I'm impressed. Explain one thing to me, though: what does it mean to approach a program like a logical (or mathematical, if you prefer) proof?

I mean, if I want to write a server that reads messages from each client and then relays them to every other client, I would just write a program that does that. I don't think there is any mathematical or logical proof to be considered here. In fact, since the server doesn't terminate, I don't think it proves anything at all.

Of course, I am very inexperienced with logic and functional programming, so I might be missing something here. That said, functional programming is very elegant and efficient - though sadly it cannot do everything.

Re:Paul Graham isn't Cool, Duh.

[pkhuong]

Yes, that is a problem with pattern matcing. Appel et al discussed solutions to this (interface badly abstracted in pattern matching -based languages). In short: people are aware of the problem (but i doubt the solution will be used in ML or haskell). However, in the meantime, it seems like you would only need some discipline (xyz only does abc, no matter what i feed to it) to alleviate the problem. As long as i don't define a ring where + is * and * +, i can still expect theorems to be true (as long as other properties of the ring don't affect that).

As for your last question, i'd try Common Lisp with a decent editor(eg emacs+SLIME). You can do both imperative and functional programming, have powerful macros, and dynamic strong typing. It is also the result of real people using Lisp in real life getting together to build a standard, so, while it carries a lot of seemingly historical baggage, the baggage is there because it was once useful, and often include unexpected solutions.

Re:Paul Graham isn't Cool, Duh.

[pkhuong]

Monads, linear objects. Read.

Re:Paul Graham isn't Cool, Duh.

[poot_rootbeer]

But for most applications, there is not only a set of requirements, things it needs to do, but a very short period of time to make it do them in. [...] I'd love to be proven wrong here

Well, in my experience, applications don't even have a set of requirements; just a short period of time to make it do... something... in.

Re:Paul Graham isn't Cool, Duh.

[pkhuong]

Statefulness & update-in-place can be implemented using monads (Moggi) or linear objects (Girard's Linear Logic), which are mathematical objects with known and proven properties. I think monads are more easily adapted to regular programming (where copying & deleting is free), and so are usually used to implement state. Someone with better a theoretical grounding will hopefully reply :)

Re:Paul Graham isn't Cool, Duh.

[Abcd1234]

Engineers need to go through very rigerous tests to certify their expertise before they are allow to design and build a bridge. Why should programming be different?

Absolutely agreed. But once those engineers are trained, we don't force them to use slide rules and abacuses instead of high-end graphing calculators. You give them tools which make their jobs easier, and make it harder for them to make mistakes.

In the same way, a programming language is a tool, and that tool should exist to make the programmer's job easier. So, if the language allows me to avoid dealing with memory management issues, great! If the compiler does a lot of work double checking what I've done in order to prevent me from doing something really stupid, fantastic! Does that mean that the barrier of entry into the field is a little lower? Sure, but at least the really skilled guys can get their jobs done a little quicker, and with fewer errors.

Re:Paul Graham isn't Cool, Duh.

[bugbear]

It's a bit misleading to say that I called Java uncool. I said in Revenge of the Nerds that hackers think Perl and Python and Ruby are cooler than Java, but I'm not claiming that that's how one should decide what language to use.

I dislike Java because (a) it lacks abstractions I need, (b) it is horribly verbose and bureaucratic, and (c) it is another Frankenstein in the C++ tradition of languages created by bolting features from dynamic languages onto a C substrate.

I'm often accused of being a language bigot because I violate the taboo against comparing one language to another. But if you think about it, anyone who works on language design *has* to do that, taboo or no. If you can't compare alternatives, how do you decide what direction to go in?

Re:Paul Graham isn't Cool, Duh.

[master_p]

Functional programming sucks big time. It is only good for using other people's libraries. Programming is about modifying state, and that is avoided by functional programming languages, severely limiting what one can do. It is not a coincidence that functional programming languages always use non-functional libraries for their basic stuff (I/O and GUI).

Re:Paul Graham isn't Cool, Duh.

[CanadianCrackPot]

True it helped me there too, but having to do so many things manually was a big headache for me. Then the one time I had to do recursion, oi I wish there was a couple of layers of abstraction there...

Re:Paul Graham isn't Cool, Duh.

[mmusson]

This was more or less the argument behind Case tools in the 80s. Only it didn't work because the benefits didn't outweigh the tradeoffs.

People overstate the protection afforded by languages like Java and then ignore what you give up for that protection. And no I'm not talking about performance.

For instance, none of the standard synchronized collection classes are thread safe. They only give the illusion of safety.

People like to point to the lack of pointers as a positive but then dismiss the lack of a deterministic destructor as a minor problem. Meanwhile serious resource leaks are common in Java programs because people fail to adequately test all their exception paths to make sure things are freed correctly in all cases. In C++, for instance, this problem is handled using a coding practice where the constructor allocates and the destructor deallocates. In Java the burden is on the programmer to get this right, in C++ the programming practice puts the burden on the compiler.

I don't really think a language can be the "safe" tool you are describing. The safety comes from how you use the language; your practices and habits. In the same way that a calculator will give you the result you asked for but will not tell you that you applied the wrong formula.

Re:Paul Graham isn't Cool, Duh.

[freality]

My friend forwarded me your article last week, and though i thought some of the rest of it was typically interesting, that comment about the lack of Java programmers... well, I'm less likely to click on the next link to an article of yours. Your mindshare, you do what you want with it ;)

btw, in java i've programmed a desktop env., statistical natural language processors, neural nets and bayesian learners, a 3D solar system simulator, a Wolfram Automaton renderer, PIC controllers for robotics, a predicate logic system and a whole lot of middleware/JSPs.. off the top of my head. Now that's not a bad language. The only other languages I know that I have personally seen used for such various applications are C/++ and Lisp.

Re:Paul Graham isn't Cool, Duh.

[Fnkmaster]

The only blurb I was able to find from Software Development magazine online quoted some guy as saying, without proof, that LISP was 3-5 times "faster" to develop in (than what was not clear, presumably than your average imperative language). If you can find a better source to back up this assertion (that doesn't require me to fish up an old issue of a dead tree publication), I'd love to find it.

I do believe that in some cases, LISP could be faster to develop in than, say, C or C++. Maybe even than Java - which despite being annoying in many ways, is quite fast to develop certain types of apps in, due to its class library and documentation quality, and much faster to read other people's code in since it's much more constrained than C++ for example.
I mean, this issue was addressed to a certain extent in the classic "Worse is Better" series of essays. But I still think it's one that's ripe for more work.

In sny case, I mentioned OCaml because I've used it in the last 3 years. I last used Common LISP about 7 or 8 years ago, freshman year in college when I was apparently quite proficient in it. So my memory of it is pretty poor, other than the paren-matching madness, car, cdr, cadr, et. al., and vague remembrances of passing anonymous lambda functions as arguments. I've implemented fairly complex algorithmic problems with LISP, even wrote a large portion of a LISP interpreter in LISP (in fact, we used Paul Graham's LISP book at Harvard), but I've never tried to write a real business application from a 40 page requirements document with a team of 5 programmers using LISP, and can't even imagine how to begin doing such a thing.

Re:Paul Graham isn't Cool, Duh.

[duffbeer703]

Interesting how nearly all of the security exploits that you hear about occur with programs written in C/C++.

Re:Paul Graham isn't Cool, Duh.

[Mark_MF-WN]

Algorithmically speaking, servers are abominations since they loop and never terminate. They are the very antithesis of the functional and imperative paradigms. That's why the imperative paradigm is so successfull -- it matches up more closely to what programmers really need to do.

Haskell and Prolog and stuff are nice for mathematical problem solving and AI, but even only as a subsystem of a larger C++ or Java application.

Re:Paul Graham isn't Cool, Duh.

[mmusson]

Do a google search on: java security hole.

Just because you don't hear about the vulnerabilities doesn't mean they don't exist.

Re:Paul Graham isn't Cool, Duh.

[MemoryDragon]

Java Smalltalk and others are cool by your standards, you just should apply a little bit more focus on what you learn. VM OO languages are extremely good testbeds for patterns and OO design, because they allow a rapid development for large scale apps, where you have to apply those techniques constantly. As for functional languages, old stuff, which basically is going back 20 years... Neither cool not that relevant outside of theory anymore, and totally unsuitable for modern software architectural problems. Modern problems are not caused by the semantics but, by the layer which is already again becoming too low, functional programming does not help in this regard. Anyway If you really want to see something cool, then look at the Beta system from Mjoln, or at AOP, which at least are new angles to old Problems.

Re:Paul Graham isn't Cool, Duh.

[angel'o'sphere]

Hm ... the parent poster of yours was mainly about Lisp and Scheme and functional is only a side note, IMHO ... and he is right! Lisp and Scheme are a bit functional but mainly they are "recursive". And that means you have to think a bout programming differently.
Functional is hard enoug, but recursive and reduced ti lists ... no hashtables, no arrays, no ... hu hom ... everything ... thats tough.

angel'o'sphere

Re:Paul Graham isn't Cool, Duh.

[obsidian head]

He warned you he was controversial.

Re:Paul Graham isn't Cool, Duh.

[angel'o'sphere]

Languages like Java or Basic are not cool for me personally because they did not teach me anything.
This makes me wonder and is astonishing. Especially in relation to your comment about Haskell and Lisp before.


Engineers need to go through very rigerous tests to certify their expertise before they are allow to design and build a bridge. Why should programming be different?


Hm, probably you are jsut to young?

The difference between an engineer buildin a bridge and a programmer is very simple:
A Bridge is made from wood, stone, concrete, steel, aluminium ... choose any or combine as needed. All those things have known properties.

A programe is made form:
lines of code
lines of code making classes
lines of code making methods
lines of code in assembler, basic, lisp, haskell or what ever.

All those lines of code have no known properties. A engineer can "calculate" how his bridge will behave under certain wind or earthquake conditions before hand. Because the raw maerial from which teh bride is build have known properties. furthermore you use thousands of bricks in abridge where it does not really matter if one brick has a flaw.

In programming you most of the time you use hand crafted "lines" (instead of bricks) which have most of the time planned, but not known, properties. Further more, if any sinlge "line" (aka brick) has a flaw it matters!

So you have to spend far more than simple "best engineering practice" in coding than you have to spend for building a bridge. Using a language like Java helps a lot as it makes sure that one kind of flaw can not happen: memory problems like dangling pointers or some kinds of leaks. Its like building a bride and being sure that not one of 1000 bricks but only 1 of 10000000 bricks have a flaw. Now you can build much bigger bridges without changing the methodology.

angel'o'sphere

Re:Paul Graham isn't Cool, Duh.

[dollargonzo]

go look at enumeration machines. they never terminate either; all they do is spit out stuff once in a while. you can think of an enumeration machine emulating a lambda calculus if you prefer functional programming. the looping of the server says little about its mathematical value.

for example, it is possible to construct an enumeration machine that will output all multiples of 2 (provably). similarly, it may be possible to prove that the output of your program respects some rigorous properties. in fact, there is a whole field of computer science/mathematics that deals with reasoning about programs

People are afraid of Interpreters being too slow

[Neomar]

This was the main concern among fellow students when I learned coding in Java some 6 years ago. But nowadays the execution speed matters rarely in a world of mutliple Ghz's. Maybe the shitty look of the Java GUI's like awt ( is this still in use?) and Swing might be a factor for uncoolness. Most people set cool == looks cool.
I personally like coding in Java since its syntax resemblences C++ and it's semantics is resemblences to smalltalk.
The only thing I miss in Java, and this is why I prefer C or C++, is that there are no pointers or any other means to play with memory directly butsince it's an interpreter there was no reason to implement it anyway, so i am pretty fine with it.
just my 0.02$

Java pays!!!

[KrisCowboy]

During the recruitment week in our university, one of the companies that visited was CA(Computer Associates). CA guys gave an options. The students can chose either one of C, C++ and Java for their exam. Well, 80% of the guys went for C, because it's their `first language'. Rest of them went for C++ and only 1 student out of 120+ students opted for Java. To cut a short story shorter, he got selected after a technical and HR interviews which were cakewalks compared to other guys' interviews. Well, if a language's gonna pay me 25,000 bucks(Indian Rupee) a month, I'd be more than happy to go for it. Cool or not.

Re:Java pays!!!

[mschaef]

To cut a short story shorter, he got selected after a technical and HR interviews which were cakewalks compared to other guys' interviews.

To be frank, it really concerns me when the interview process is a "cakewalk". It generally means that the interviewer is too lazy, thoughtless, or inexperienced to come up with challenging questions. If a company takes that attitude towards their most important fundamental activity (bringing in talent), it doesn't bode well for anything else they do. (Plus, I like working with people that can teach me things...) ObJava: I've seen some _tough_ Java interviews, so Java doesn't necessarily mean anything about the difficulty of the interview process.

Re:Java pays!!!

[DevolvingSpud]

Agreed. I work in the government contracting space in the Maryland/DC/Virginia area. Every contractor up here wants Java/J2EE right off because that's what the government is into. It gives them maintainable, cross-platform code that pretty much anyone can understand. Given the wide range in skill levels of personnel working on these projects and/or future versions of them, this is essential. Not necessarily *cool*, but certainly good use of taxpayer $$ over the long term, especially given the wildly heterogeneous server environment in the government (NT, XP, Linux, all 32 flavors of Un*x, AIX, Cray Solaris anyone?).

And in our area, it's much easier to say "what economic downturn?" especially if you know Java and have some kind of security clearance. Email me if you do, we're hiring :) The point is, here and now Java's popularity yields significant gains for those who can program in it.

Whether this is cool or not depends on the observer.

Re:Java pays!!!

[attam]

"25,000 bucks a month" in indian rupees amounts to $540 US a month, and that gets the poster excited! no wonder they are outsourcing to india. i made twice that working part time as an undergraduate..

Re:Java pays!!!

[Pfhreakaz0id]

yep. just got out of the government contracting end, and believe me, it is almost all j2ee.

Re:Java pays!!!

[sapgau]

That is so sad and at the same time so scary.

Re:Java pays!!!

[pottymouth]

You nailed it! I've become pigeon holed working in C and Fortran (engineering stuff) and even though I graduated first in my graduate class (MS CIS just 2 years ago) I've had a hell of a time moving from my current job to something else.

Everybody wants Java. There are some .NET and C# jobs but no where near the number of Java and C++ jobs (in this area, Cincinnati Ohio). I've got 15 years experience in some of the most technical types of coding and I still sit in interviews where they're concerned I don't have a Java certification even though I've been using the language (off and on) for 5 years. I'd love to work in it full time but it's tough to get in due to HR stupidity.

Re:Java pays!!!

[pottymouth]

Why do you think so?

I've done a lot of things in Java and C# looks like it's just a MS'd version of Java. I live in the *nix world anyway so C# wouldn't do me much good anyway.

Re:Java pays!!!

[KrisCowboy]

Well, for all practical purposes, 1USD = 10INR. Now do the math. I can eat a heavy meal for Rs.20. A coke costs me Rs.5 and a burger Rs.15. Wake up man. You sound like a typical Indian parent. When a son earns $500 in US, the parents here are happy because their son is earning Rs. 25,000 :)

Re:lame

[l0rd]

Amen. The best thing (and imho only reason to use Java instead of C++) about a java app is that it can run on any platform. The wordt thing about a java ap p is that it can run on any platform.

The above makes the libraries and interfaces klunky and ugly. Also, it is not always a must that an application has to be able to run on many platforms. In this case it is far better to use tried & trusted C as it's quiker and gives you a better feeling coding in (My opinion).

Uncool to me

[infinite9]

Want to know why it's uncool to me? This may be flaimbait, but it's the truth. A disproportionate number of Indians favor this language and environment. This makes it nearly impossible for me to take these contracts since it tends to drive down rates. Same thing for oracle related work.

Re:Uncool to me

[forgotten_my_nick]

They go where the work is. Plently of Indian workers programming in .NET and other languages. Your just not tendering for them.

Re:Uncool to me

[JavaLord]

They go where the work is. Plently of Indian workers programming in .NET and other languages. Your just not tendering for them.

or maybe it's because one of Sun's co-founders is an Indian, and favors Indian workers. This isn't speculation on my part, see Sun's co-founder says Sun favors Indian workers

The quote was:

"At Sun, people from India are favored over almost anybody else."

If Bill Gates said something like this about American workers, he would be called racist. God, I love the American media.

Re:Uncool to me

[michaelggreer]

That's one way to do it, but in my years of J2EE programming I have never done it that way. There are plenty of startup companies founded on 4 smart people in a room, using whatever language they feel meets the need (and interests them).

Re:Uncool to me

[Anonymous Coward]

Yeah, but how do you know when you're answering a job ad? Most of us aren't Paul Graham and don't work for k-rad startups all the time.

The key point is that Microsoft themselves uses the "smart guys in a room" setup, and has long promoted "1 Good Programmer is worth 10 bad ones" etc. Thus MS Technology projects tend to follow that model.

Sun Micro outsources tons of their own stuff, and Java projects tend to follow the Command-n-Control model.

Re:Uncool to me

[sapgau]

Your talking about rejecting AT LEAST 80% of corporate or government related contracts being tendered right now.

I understand Java is uncool but why include Oracle in the same boat? Oracle has been around way longer than Java.

my 0.02

Re:lame

[forgotten_my_nick]

>Java GUI is slower than native alternatives

Not really. Tried it recently? eclipse is a good example (eclipse.org) of fast java program.

>Java is not supported by all platforms

You can get a JVM for most if not all platforms. It also works on XP (don't confuse MS JVM as being a workable JVM, its years old).

>All the Java "binaries" I've tried relies on me having installed a local interpreter.

Actually you can get a program which will create an EXE for you, but then that defeats the purpose of Java doesn't it? Everyone moans about having to download the JVM, why don't people moan about the VBRUNxxx.dll and MSFC that you have to install to get EXE apps to run sometimes.

> Hey, I said this is MY list. I dislike object oriented languages,

Your basis of dislikes is hardly a good argument for what is wrong with Java.

...And the link is Slashdotted already.

[abkaiser]

I like Java. There, I've said it. It's easy and good for non-complex functions. When you start getting more complex, other tools have their uses. But for quick and dirty (or just simple) work, Java succeeds as an easy-to-implement solution. I think you can justify a tool that's a "language for the masses": Sometimes you just really need a good hammer.

Hello, my name is 744418 and I'm a Java user.

Pick your tools

[Hans1732]

What it really comes down to goes soemthign like this: programming languages are just tools to be used as a means to an end, not the end in themselves. Java is great if I want to write a highly dynamic and modular system (dynamic state modelling), but I would shudder at the though of using it to perform high performance reading (such as for MD5 or SHA* hashing). It all hinges on what you need to do. Don't use a sledgehammer to do finished carpentry.

Well...

[thrill12]

..on the laptop I use for work (a Pentium-2 ...) it's just like that. Don't understand me wrong: I have programmed in JAVA, I liked it.
But as corporations nowadays still have little budget left for buying their employees decent PC's, JAVA still has this practical limitation.

Re:Well...

[DrJonesAC2]

Agreed, I'm currently developing an RPG in Java (It's for school). I am doing it on an old IBM thinkpad 600e. It does have some slowness but nothing killing playability. On more modern systems the game FLIES!. I am in no way a pro Java developer so I know my code could be optimized quite a bit. Anyway my point is that I find Java can do anything that C/C++ can do and I have a very easy API to work with.

Re:Well...

[Rattencremesuppe]

Anyway my point is that I find Java can do anything that C/C++ can do

you never did device drivers or realtime systems, did you?

Re:Well...

[black mariah]

If you're doing device drivers in an interpreted language, you're a fucking moron. Conversely, if you program a web-based app in C, you're a fucking moron. Wow, different tools for different jobs... who'd have though?

Re:Well...

[AKAImBatman]

Oh, go jump off a (virtual) cliff. Java can handle "soft" realtime just fine, and extensions are being worked on for "hard" realtime support. And yes, some people actually write device drivers in Java. Java isn't slow because it's actually slow, it slow because:

1. C programmers write 10 lines of REALLY LOUSY Java code and decide that proves their point about Java being slow.

2. People like you WANT it to be slow. I'm sorry, comparing Java programming against device driver writing? That's the height of hypocrisy. Just because you're sore that *you* can't write high performance Java code while maintaining the beauty of an OO design, doesn't mean you have to take it out on everyone else.

BTW:

4k games
Amazing OpenGL game
More Java games
JDiskReport
Best BitTorrent client ever

etc, etc, etc.

Re:Well...

[AKAImBatman]

FYI, Java is Just In Time compiled, not interpreted. Otherwise, I agree completely.

Re:Well...

[Rattencremesuppe]

Wow, different tools for different jobs... who'd have though?

Yes, exactly. That's why it's inappropriate to say "everything you can do in X, you can do in Y"

BTW: of course you could write webapps in C (for example, if your target is a 8-bit micro and doesn't support different languages), but you cannot write device drivers in Java.

I don't have a problem with people who like high-level stuff, but they always seem to take the low-level stuff for granted.

Re:Well...

[struppi]

Exactly what has to be said about java. At the moment I'm working for a company where I have to write C++ code (since the data we handle is simply too large... our C++ apps use up to 2GB of ram), and it's a lot harder to write clean, secure OO code than with java.

So: if you can efford 256 MB of RAM and a recent CPU Java will run most of the applications fast enough. I know java has a long startup time compared to C or C++ applications (long as in 4 seconds compared to 1 sec), but this is a time I can wait.

Re:Well...

[Rattencremesuppe]

(...) extensions are being worked on for "hard" realtime support. And yes, some people actually write device drivers in Java.

It's interesting that people are working on this. But you wouldn't use that in production systems, would you?

2. People like you WANT it to be slow. I'm sorry, comparing Java programming against device driver writing? That's the height of hypocrisy.

I never wrote about the slowness thing, I just didn't like the "you can do anything in Java" statement made by the parent poster. Because you can't do the low level stuff in Java. If you disagree, there you are, but please don't take it personal.

Re:Well...

[davron05]

These guys use Java for real-time applications and there are for sure more.

Re:Well...

[AKAImBatman]

It's interesting that people are working on this. But you wouldn't use that in production systems, would you?

20 years ago, you wouldn't have used a C based Unix machine in place of a Mainframe, now would you? Back then, OSes were written in "safe" languages like ALGOL, FORTRAN, and LISP.

Because you can't do the low level stuff in Java.

You can, and you can't. Generally, you can't do it in Java because the API has been designed to prevent it. This is INTENTIONAL for security reasons. You wouldn't want an ActiveX control to install itself as a device driver, would you? But it *can* be done in Java as long as you have an appropriate API toolkit. JNode has one, and Sun actually provides such a kit for all the embedded Java development going on.

I never wrote about the slowness thing, I just didn't like the "you can do anything in Java" statement made by the parent poster.

I apologize if I misinterpreted, but your post did make it sound like you were referring to Java having too poor of performance to act as a platform for things like Device Drivers.

Re:Well...

[Kiryat Malachi]

Java is being worked on to deliver stable guaranteed time to interrupt? That being the chief characteristic making a "hard" realtime system useful.

I'll believe that when I see it.

Re:Well...

[AKAImBatman]

Java is being worked on to deliver stable guaranteed time to interrupt?

Exactly. It was the first JSR created as part of the Java Community Process. The final API can be viewed on the JCP website. The "reference implementation" being used for testing can be found here.

Keep in mind that the API is most likely to show up on hard real time systems and probably won't be available on your standard desktop OSes. (Windows? Hard realtime? *rolls eyes*)

Re:Well...

[Sj0]

If I ever find someone using an interpeted language for device drivers, I fully intend to laugh at the top of my lungs for a full hour.

Seriously, I wouldn't use VB or QB for those either, but that hasn't stopped the former from becoming quite popular. :)

Re:Well...

[the quick brown fox]

Are you purposely ignoring all the other benchmarks? For example, the one immediately preceding the one you cited.

In many situations, Java absolutely thrashes VBS/JS/Python/Perl. In other situations, it doesn't. The numbers certainly shouldn't lead you to conclude that Java is the slowest of them all.

Re:Well...

[RLW]

Not just that, I mean come on it's a cross platform Visual Basic. Granted Java is more flexible than VB but if you need to stray from the confines of the library you are screwed. Java is an excellent language for what it is. Don't try to make it something it's not.

But this part I don't get. If Java is supposed to hide pointers from the developer then why does object equality compare pointers and not objects ? This makes no sense. The equality operator should work like the compare function and pointer comparison should work through a function.

Re:Well...

[Kiryat Malachi]

Interesting. I'm unlikely to shift to it any time soon for our embedded stuff, but its good to know its out there. That said, its useless until the VMs start showing up for the processors we work with (mainly HC12s, Motorola 56xxx DSP, and the lower end PPCs - little bit with TriCore and some other funky ones). But interesting to know about. Thanks.

Re:Well...

[freedom_india]

Actually you can write device drivers in Java if your processor is a Java Virtual Machine hardware implementation.

Java is NOT just a language but a VM also. Most people forget that.

Re:Well...

[AKAImBatman]

You sir, are an idiot. I'm downright amazed at the chutzpah you display in posting this. You are comparing a Virtual Machine platform designed to optimize large and long running programs, against simple scripting languages? With a Hello World program no less!

Allow me to repeat: You sir, are an idiot.

Now go back to school for Comp-Sci, and learn about the tradeoffs programmers must make in order to make things "fast", "small", or "abstract". Hint: It's a lot like Physics. You don't get something for nothing.

Oh, and I love your web page. A "Windows Perl Hacker" you say? Lord save me.

Re:Well...

[black mariah]

I love you too. Are you the same tard that's been following me around from topic to topic complaining about how much I suck? Please, get a life.

Re:Well...

[aelfgar]

You may think it is the best bit torrent client, and I agree it has pretty bells and whistles, but when it comes down to it, it is a HUGE memory hog, because it is written in Java.

Java is a great language to teach code monkeys, because most people need tons of cheap software to be churned out for various purposouses. How many many people use photoshop or gimp? Most people use some stupid program which comes packaged with their digital camera, and don't care if it is slow or not, because they have not enough experience to know what slow and fast is. The computer world is not just for linux geeks. Java is not cool because it is great for many crappy applications like that, and those applications just aren't considered cool. I myself dont want to program for aunt tilly.

Java might have many other applications, but chances are as a Java programmer you will be a code monkey.

Re:Well...

[jrockway]

Because how do you know if an object is "equal" to another object. What does "equal" mean? Is 3 "equal" to 3.00?

That's why you implement the equals() or compareTo() methods, then equals works the way you want. Is a.equals(b) really that hard to type? If so, you should not be a programmer.

Re:Well...

[jcochran]

Huh?
If I remember what I've read in the past, the thing that made Unix unique was that it was written mostly in a fairly high level language like C with very little assembly. Before that point, OSes were written primarily in assembly or macro assembly. That is a major reason that Unix was ported across so many platforms so quickly.

Re:Well...

[chez69]

that takes you 5 or 6 weeks to debug before it displays the page

Re:Well...

[AKAImBatman]

The history books are wrong. An example from wikipedia:

The Burroughs Corporation's B5000 and its successors were and are stack machines designed to be programmed in an extended ALGOL; indeed their operating system, or MCP (Master Control Program) as they are called, is written in an extended ALGOL back in 1961. The Unisys Corporation still markets machines descended from the B5000 today, running the MCP and supporting several extended ALGOL compilers.

1961 predates the release of Unix by nearly 10 years. In addition, Symbolics LISP workstations actually gained popularity as workstations *before* Unix did. The only use of Unix at that point was as an environment for computer research. Companies like Sun, Digital, HP, and IBM didn't start fighting over the Workstation market until the late 80's, and didn't manage to make real inroads into the server room until the 90's.

Unix's success as an OS primarily extends from its use as an early networked computer. BSD, for example, was used by DARPA as a platform on which to create the TCP/IP protocol, and eventually found ARPANet (the internet we know today). This gave Unix a head start in business when the Internet became a realistic concern.

Re:Well...

[SillyNickName4me]

> Java Virtual Machine hardware implementation.

Somehow this sounds a bit like a paradox..

Re:Well...

[Rattencremesuppe]

Back then, OSes were written in "safe" languages like ALGOL, FORTRAN, and LISP.

Yeah, let's write task schedulers in LISP! ROFL

Generally, you can't do it in Java because the API has been designed to prevent it.

AFAIK, its not the API but the language features (VM and garbage collector) that don't allow deterministic behavior. I'm not saying that C/C++ are better languages but you don't have these problems there.

I apologize if I misinterpreted, but your post did make it sound like you were referring to Java having too poor of performance to act as a platform for things like Device Drivers.

It's not a question of performance, but deterministic behavior and guaranteed maximum latency.

Re:Well...

[nickos]

Conversely, if you program a web-based app in C, you're a fucking moron.

Please break it gently to Google!

Re:Well...

[RLW]

It's cumbersome and unnecessary, and yes 3.00 does equal 3. Just as the implementer of the equals function decides what equality between types means the implementer of an operator also decides what equality means between types.

Additionally, I don't need dweebs telling me what profession to be in.

Re:Well...

[Mr Z]

If you're doing device drivers in an interpreted language, you're a fucking moron.

I guess that's why OpenFirmware never really caught on. The IEEE withdrew the standard for it, because those "fucking morons" at the OFWG didn't reaffirm the standard. Maybe they wised up to your level?

--Joe

Re:Well...

[AKAImBatman]

Yeah, let's write task schedulers in LISP! ROFL

I don't know why you find that funny. That's exactly what Symbolics did. They beat Unix to the "Workstation" market by several years, too. Many Unix Haters were very upset when their LISP machines were replaced with Unix:

This is the fifth day I've used a Sun. Coincidentally, it's also the fifth time my Emacs has given up the ghost. So I think I'm getting a feel for what's good about Suns.

One neat thing about Suns is that they really boot fast. You ought to see one boot, if you haven't already. It's inspiring to those of us whose LispMs take all morning to boot.

Another nice thing about Suns is their simplicity. You know how a LispM is always jumping into that awful, hairy debugger with the confusing backtrace display, and expecting you to tell it how to proceed? Well, Suns ALWAYS know how to proceed. They dump a core file and kill the offending process. What could be easier? If there's a window involved, it closes right up. (Did I feel a draft?) This simplicity greatly decreases debugging time because you immediately give up all hope of finding the problem, and just restart from the beginning whatever complex task you were up to. In fact, at this point, you can just boot. Go ahead, it's fast!

Besides, it's not like a task scheduler is a hard piece of code to write. It's actually stupidly simple to write. The hard part is creating an algorithm that will most effectively extend CPU resources to running programs. What is effective depends on the purpose of the OS. See "The Dining Philosophers Problem" for an example of the issues that task schedulers must resolve.

AFAIK, its not the API but the language features (VM and garbage collector) that don't allow deterministic behavior.

1. VMs by their very nature are deterministic. If they weren't, your CPU wouldn't be either.

2. Garbage Collection is as deterministic as the algorithm behind it. Standard "mark and sweep" algos are indeed deterministic.

None of this has anything to do with compiled Java code, which runs in as deterministic a fashion as you code it. Do you even know what "deterministic" means?

I'm not saying that C/C++ are better languages but you don't have these problems there.

Yes you do. Any problem you code, you have in any language you code it. If you choose to write a device driver with a random timeout inserted, you must take responsibility for that behavior, no matter what the language. If you require that your device driver have an uninterrupted time slice of X milliseconds, then you must use the OS services available to ensure that you have a time slice of X milliseconds.

It's not a question of performance, but deterministic behavior and guaranteed maximum latency.

Maximum latency is not a determinable factor in ANY language, save for when real-time services are utilized. If you utilize real-time services, then it doesn't matter what language you use as long as you have access to those real-time services.

Re:Well...

[AKAImBatman]

You need to access an area of physical memory. JAVA has no pointers.. what do you suggest? (this is a memory mapped device so yeah, to write a driver for it, I do need to access its physical address space)

You use the APIs provided for Device Driver writing. Java allows you to access memory mapped areas (see the java.nio package). All that's needed is an API to obtain that area. Since you normally don't want to give that functionality to developers, it would have to be part of a Device Driver API like Sun's JDDK or JNode's OS services.

Re:Well...

[cakoose]

Java is not supposed to hide pointers from the developer. Haskell accomplishes such a thing, but it also doesn't allow side-effects. If you want to allow side-effects (i.e. mutable shared variables), hiding pointers is much more difficult.

You may decide to call them "references" instead of "pointers" but they're essentially the same thing. It's just that Java doesn't let you perform arithmetic on them.

Referential equality can be useful and so there's reason to give a programmer access to it, but value-based equality comparision is the common case and probably should have been assigned to the '==' operator. One reason they may not have done so is to avoid hidden complexity. In C, for example, you can look at a chunk of code and get a good sense of what's going on. In C++ (which is an extreme case) a chunk of code that looks simple might be doing a bunch of other crazy things using operator overloading and automatically-invoked destructors.

As for your comment about this "making no sense"... It makes sense when you realize the '==' compares the values of variables and does not go the extra mile to dereference pointers and invoke comparison functions. While it may have been a good idea to do all that extra stuff, the current semantics are not confusing.

Re:Well...

[AKAImBatman]

-1 Troll? It seems that someone around here doesn't like hearing how computers ACTUALLY WORK. *shakes head*

Re:Well...

[Anonymous Coward]

Yes different languages have their places. As usual ./ crowd missed the point. Java should be compared to C# not to C. Curioulsy, we haven't seen an article entitled "C# considered UNcool"! (Hmm...) C# is what Java should be compared to, NOT C or C++. The point is that Java is way cooler than C# because it's multiplatform (officialy supported) and has a lot of tools and code (including free). At any rate Java is highly prefferable than C# and if your problem fits the bill for Java or C#, the smart choice is Java. There is nothing more to this discussion.

Re:Well...

[RLW]

It is in congruous that in the spirit of hiding memory allocation, management and pointer manipulation for objects that equality operator doesn't perform its operation on de-referenced objects. This operation is the most common and should have the advantage of the simpler operator syntax.

Re:Well...

[ElGuapoGolf]

Great....

What if my first 3 is in Hex and my 2nd is in Dec?

Does 3 == 3? Yes.

Does 62 == 62? No.

Re:Well...

[Theatetus]

Because how do you know if an object is "equal" to another object. What does "equal" mean? Is 3 "equal" to 3.00?

Well, judging from your sig I'd guess you agree that the answer is manifest typing...

Re:Well...

[AKAImBatman]

This was extended in C++ to allow non-scalar comparisons so now one can write equality operators to do what ever one wants for a given pair of objects.

Which does the EXACT SAME THING as the Java function. The only difference is that C++ allows operator overloading while Java does not. Given the number of bone-headed ways operator overloading has been abused, I'm inclined to agree with Java's way of handling things.

So in C for instance the equality operator would promote 3 == 3.00 to 3.00 = 3.00. This is a convince.

Which is different from what you said. The original poster claimed that 3 and 3.00 are not equal. He was correct in his statement. You then called him a liar. Now you're doing an about face. Seems you owe the original poster an apology.

Dweeb.

Standing tall and proud. :-)

Re:Well...

[Theatetus]

Logically 3 does equal 3.00. In any reasonable language if one compares the two with a simple equality operator it will return true.

Umm, depends on what you consider a "reasonable" language.

C says 3 == 3.0
Lisp says (= 3 3.0) but not (eq 3 3.0)
Forth will just compare the most-significant word of 3.0 to 3, though you have to bend over backwords to get a floating point number on the data stack to begin with
The ML family will throw a type error
Scripting languages will for the most part either promote 3 or demote 3.0

I think there's a lot of variety in what a "reasonable" language will do in such a situation.

Re:Well...

[Anonymous Coward]

You are a tard. Let's see google, ebay, and (I think) amazon all do or have done web development in C. See, these guys know that being able to serve a large number of customers without breaking the bank on hardware is worth a little more development time.

Re:Well...

[dalleboy]

Java programmers write 10 lines of REALLY LOUSY C code and decide that proves their point about Java being fast.

Re:Well...

[RLW]

That's a stupid example. If your language has no way to distinguish between hex and decimal litterals then it probably has bigger problems.

3 == 0x03 == 03 == 3.00

62 == 0x3e == 076 == 62.00

Re:Well...

[RLW]

What the fuck are you talking about? 3 and 3.00 are not identical at the binary level: from a logical stand point they are the same. The equality operator works as expected in this case. So why should the equality operator behave differently for other types ? If I'm comparing objects I am most likely interested in a logical comparison and not in a comparison of their respective addresses.

Re:Well...

[black mariah]

Would that be my karma that constantly hovers on the good/excellent border despite all the *INTENTIONAL* flamebait I write? Yeah, that's really shitty. And please... nothing I write is worse than any of the other bullshit that's said on here.

Re:Well...

[RLW]

I agree with you on most points. Unless you are saying that Lisp is a reasonable language. My point is this, in the context of Java 3 == 3. It doesn't care that both literals in different memory locations. So why should the equality operator work differently for classes ? Ex. classTim jim(3), Jim(3); Jim == jim should return true.

Re:Well...

[AKAImBatman]

What the fuck are you talking about?

Tsk, tsk, tsk. As the old saying goes, "Profanity is the crutch of a small mind."

3 and 3.00 are not identical at the binary level

Which you claim to have understood.

from a logical stand point they are the same.

Which was fairly obviously not the original poster's point.

The equality operator works as expected in this case.

Which was not something the original poster mentioned.

So why should the equality operator behave differently for other types ?

Because it behaves differently for EVERY type. You have to tell the compiler how to compare them.

If I'm comparing objects I am most likely interested in a logical comparison and not in a comparison of their respective addresses.

Which is why Java has the "equals()" method on objects. Congratulations, you've taken about two hours of time to come to this simplistic conclusion.

Re:Well...

[angel'o'sphere]

Probably he did not ... but Java is well suited for Real Time Systems and Device Drivers, probably you should google a bit around :D

There are actually vendors for real time VMs ... there are vendors for Java native compilers, especially for the embedded market.

There is even an upcomming standard for Java real time extensions, a JCP.

There are native Java processors available with supporting light weight Java OS.

Finally: I think a mobile phone has enough real time and device driving on it, a lot modern mobiles in europe are programmed in Java, the rest is running symbian and programmed in C++.

angel'o'sphere

Re:Well...

[bani]

"Back then, OSes were written in "safe" languages like ALGOL, FORTRAN, and LISP."

no they weren't. they were written in assembler. or C.

Which OS is written in FORTRAN?

Re:Well...

[angel'o'sphere]

But you wouldn't use that in production systems, would you?

Well, as far as I remeber the Mars probe Path finder is programmed in Java. Not that this is "hard real time", but it is real time never the less.

I'm confident that futur probes will be use Java also for mission control.

And yes: if the environment supports it I will do production systems with Java and also real time systems like flight avionics etc.

angel'o'sphere

Re:Well...

[AKAImBatman]

You are truly a condescending bastard.

I can be. I try to reserve such behavior for special situations. :-)

The equality operator should be used to invoke built in user defined equality functions as in C++.

It does in Java as well. "boolean result = (3.00 == 3)" will produce "true".

The syntax used by Java is cumbersome and un-intuitive.

Nothing is intuitive. I believe you mean that it's "unnatural". Which is true of programming in general. Thus your complaint really amounts to more of "it's different". Which it is. But we (Java programmers) kind of prefer it to operator overloading.

Operator overloading seemed like a good idea when it was introduced. After all, it made ADTs absolutely transparent. Unfortunately, it's also one of the most abused features in history. Should the addition operator add an object to an array, or should it add the values of one array to another? And who wants to type so much? Just reuse the equality operator to test for some special condition other than equality. Never mind that no one will ever be able to decode what the code is doing.

If you've been a C coder since the 70's, then you know what I'm talking about. :-/

Re:Well...

[Bill Dog]

Operator overloading seemed like a good idea when it was introduced. After all, it made ADTs absolutely transparent. Unfortunately, it's also one of the most abused features in history.

Just because dummies can abuse something doesn't make it sensible to take it away from those who may wield it usefully. Remember, inheritance is one of the most abused features in history as well.

Re:Well...

[AKAImBatman]

no they weren't. they were written in assembler. or C.

You want to make a friendly wager on that? (HINT: Read through your sibling posts before answering. And for crying out loud, check some Google results!)

Re:Well...

[mrlpz]

JGoodies.com

Now there's a product ( Swing SUITE ) I want to invest my money on.....almost $900 for a "Platform Extension"....nevermind any new widgets. Essentially what SWT/JFACE are, but without the "Free-ness". Yeah, that's a platform to inspire confidence. And what's more, you don't get access to any of the code ! It's Closed Source. Yipee...

And...one..two..three, FOUR MORE LAYERS of CRUFT on top of SWING itself. That's great...sure...pile on the layers in the UI..I don't care, I have all the time in the world to wait while my little application loads...Screen Refreshes ? I'm not worried, with my GeForce 6800....I only get flicker SOME of the time.

Oh, and for the record....The next time you want to think of lousy implementations...let's talk about the use of keystores and key files for supporting SSL in Java...Geezus H You know who. If only it WERE only 10 lines of code ( lousy or not ) you had to write to support it efficiently.

Java may work for enterprise in the back orifice, but it's certainly nowhere near ready for prime time. You try putting a Java GUI application replacement for Quickbooks ( or Word, or Excel ) on a PC ( or a Mac ) in front of your grandma and tell her to use it for maintaining her records, or her email, or what have you. You can forget about those wonderful toll house cookies kiddies ! Grandma's on strike until that Caffeine-like named behemoth ( old school word for something really BIG ) is out of her pretty pastel colored computer. And you can forget about that new sweater she was going to knit for you, too !

Sure, you can put Java on servers, run enterprise processes with it efficiently ( not that there aren't other alternatives that will do JUST as well , perhaps even better. )....but none of those "novelty" item categories you mentioned in any way near approach "proof" level that JAVA APPLICATION UI performance, is anywhere near what would be considered RESPONSIVE ( Yeah, there's a word for you ) for the average home user. Yeah, maybe a few tech folks ( ok, maybe more than a few ), will tolerate it...but Joe SixPack won't, neither will Jane SixAbs.

Anyone can PUNCH a hole on the screen and draw pretty colors that look like explosions, Java 3D may even be a reasonable alternative to some other modelling and transform systems out there...but in DESKTOP applications..it's not there yet. Why do you think all you hear these days is "Rich Thin Clients", "XUL, XUL !"....GMAB. Not everything is "FORMS" based guys, and wait till you try to do a RTC ( Rich Thin Client ) in JAVA that approaches the level of functionality of a desktop application. Do you really think a user's going to sit there waiting for the UI to refresh itself. He'll be, "What in tarnation is this dang fool of a browser think it's doin' ? I keep clicking this reload button, but I keep just gettin' three buttons. Oh....so that's how they do circles on computers so perfectly round...Hoooooeee...just look at those dots drawin'. Aww shucks...erased itself. No...here are the buttons....shoot erased itself again......"

Re:Well...

[RLW]

The debate is not about how computers really work but rather why Java applies the equality operator in an inconsistent manner.

Re:Well...

[FyRE666]

Conversely, if you program a web-based app in C, you're a fucking moron.

Isn't Google a web-based app, written in C?

Re:Well...

[the quick brown fox]

If Java is supposed to hide pointers from the developer then why does object equality compare pointers and not objects ? This makes no sense. The equality operator should work like the compare function and pointer comparison should work through a function.

I didn't design the language, but one very good reason is, semantic equality needs to be class polymorphic while operators in Java are not. Thus semantic equality gets implemented via a polymorphic method, and the equality operator becomes pointer comparison. While the == behavior may be slightly unintuitive at first, it is actually much more consistent with the meaning of == when applied to primitive types.

One annoying consequence of == vs .Equals() is that you can't compare two values, either or both of which could be null, without explicitly checking for null:

bool AreEqual(Object a, Object b) {
return (a == null) ? (b == null) : a.Equals(b);
}

Re:Well...

[Breakfast Pants]

You're right. But you're out of context. The main context clue that was set here? "Anyway my point is that I find Java can do anything that C/C++ can do"

Re:Well...

[Kent Recal]

The == operator - quite consistently - tells you whether you're looking at two references to the same object. I personally find it quite useful and pretty obvious, don't you?

Re:Well...

[AKAImBatman]

The equality function can test for some special condition other than equality: this is not unique to the equality operator.

While this is true, the "equals()" function has (to my knowledge) never been abused in Java.

The equality operator in Java is inconsistent. For simple types it performs a logical comparison and for classes it performs a pointer comparison. So the correct syntax for clarity and conformity in Java should be 3.compareTo(3.00)

Actually, 3.compareTo(3.00) does work in Java 1.5. This is a compiler feature called "autoboxing" which automatically promotes a primitive to an Object and visa-versa.

Re:Well...

[angel'o'sphere]

Hm,

well as your argumentation has some merit, Javas == operato and its desire for an equals() function just behaves like in other languages as well!!

Everybody knows that you have references in Java (to objects) and that those are equivalent to pointers.

While you write this:
Person* person = new Person();
in C++
you only write this:
Person person = new Person();
in Java.

Only the '*' is gone. so if you write in C++:
personA == personB ? : ;
you are comparing pointers, that is object identity. And when you write the exact same 'string' in Java:
personA == personB ? : ;
you are comparing references :-D that is comparing identity as well.
IMHO it makes no sense to have C++ as master piece and write a == b there and have Java as poor mans replacement and write a.equals(b) there.

Of couree: you write it in Java as similar as possible as in C++ and: the native behaviour you want as programmer is identity, not equality. So the language defaults to identity and asks the programmer what he likes to define as equality.

Men and women are not identical, even so if they are equal!!

angel'o'sphere

Re:Well...

[angel'o'sphere]

Come on guy ... in Java its just the same!

(int) 3 == (float) 3.00 ....

So what the fuck you are talking about? Your first post was about OBJECTS, not scalar values.

angel'o'sphere

Re:Well...

[angel'o'sphere]

Sorry to insist and to answer again.

BTW: the flaimbait moderation is unfair and when I see it while meta moderating I will note it as such!

Back to the topic: you are mixing up two things:

C:

struct A *a1 = malloc(sizeof(struct A));
struct A *a2 = malloc(sizeof(struct A));

now you have two pointers ... a1 and a2.

a1 == a2 is just like Java: // note you compared pointers 32 bit values /* class */ A a1 = new A(); /* class */ A a2 = new A();

a1 == a2; // you are comparing 32 bit values, references aka pointers

Thats the same, and believe me, in 99% of your coding you want that C behaves like Java does.

now, what about C:

*a1 == *a2 ? // you are comparing CONTENTS

In C you are lost, the compiler descides about a bit wise comparision. In C++ you can define an operator== for the class/struct A. In Java you can do the same, but you use the method "equals()" for that as Java can not distinguish between:

a1 == a2 and *a1 == *a2 as Java has no notation for the later one and the first one is what you try to talk about.

angel'o'sphere

P.S.sorry, but if you are not able to understand that and not able to make up your mind I fear you get more bad moderations (besides your moderators are assholes as: not agreeing with a post is no reason to modding it down ... tz, I do not agree with 80'% or more of the posts of any thread ... and I even mod them as insightfull if they have a good idea)

Re:Well...

[angel'o'sphere]

Well,

and for my knowledge the == operator has never been abused in C++ ....

This operator overloading talk is IMHO bullshit.

I *never* saw C++ code where operator overloading was counter intuitive. And I programmed for more than 10 years in C++. I also know a really hughe bunsh of commercial C++ libraries where no one ever crafted stupid overloadings.

Operator overloading is a must, and I bet my house, my wive, my car and my horses that we will have operator overloading in 3 to 5 years in Java as well.

Besides: there are open source Java++ compilers like Kiev and Pizza which support operator overloading.

angel'o'sphere

Re:Well...

[aled]

Java works as other object oriented languanges. Nothing new in this.

Re:Well...

[bani]

Hokay...

"20 years ago, you wouldn't have used a C based Unix machine in place of a Mainframe, now would you? Back then, OSes were written in "safe" languages like ALGOL, FORTRAN, and LISP."

2004 - 20 = 1984

"Some operating systems from the 1980s include: AmigaOS, HP-UX, Macintosh, MS-DOS, and ULTRIX."

AmigaOS: 68k asm. check.
HP-UX: C. check.
Macintosh: pascal and 68k asm. check.
MS-DOS: x86 asm. check.
ULTRIX: C. check.
SunOS (1984): C. check.
Unix SVR2(1984): C. check.
OS-9: Asm, later C. check.

I know of OSes written in Forth and LISP (forth in the 1980s being basically a glorified macro assembler) and none of them were very successful, but i've never heard of one in the 1980s written in FORTRAN.

Re:Well...

[AKAImBatman]

Ah, I see. You missed my point. I'm not talking about *new* OSes in the 1980's. I'm talking about what business's actually deployed for mission critical work. For one, no one deployed Unix in 1984 for anything other than academics. However, businesses did deploy Unisys MCP (ALGOL), IBM MVS (???), and Symbolics (LISP). No business in their right mind would deploy AmigaOS, MS-DOS, or any of the Unixes.

Re:Well...

[bani]

actually business were using CP/M and MS-DOS. for mainframes they used VAXen. or HP.

MVS was used iirc a lot in banking. i'm pretty certain MVS is assembler.

afaik symbolics never saw wide use in business applications -- it mainly found success with AI research. symbolics didn't last long, that's for sure.

theres a lot of still-running business VAXen though. that really says something.

VMS was written in assembler...

Re:Well...

[kelnos]

i started looking over your list of links to what you're presumably saying are "well-written, fast java apps", thinking that i hadn't heard of any of them, but i'd give them a look to see how nice they are.

then i see you linked to azureus. i think it's a damned good BT client as well. but for its functionality, not speed. it eats so much ram (don't recall the figures), and so much CPU (50-70%), my machine (1.33GHz athlon, 640MB ram - not a powerhouse, but certainly respectable) gets totally bogged down if i try to run more than 4 or 5 torrents at once. and this is even considering that the whole app isn't written in java. on linux, at least, it uses SWT, which appears to be compiled to native code. SWT itself uses gtk, which is definitely native.

now, part of this is the fact that the BT protocol itself is rather CPU-intensive (a lot of SHA hash calculating, and often). but still, i have yet to see a usable, resource-friendly GUI BT client for linux out there. my personal opinion of this is that it's because no one's yet written one in C. ctorrent seems to perform well (thought it lacks a GUI and doesn't seem to get the same download rates azureus or theshadow gets).

Re:Well...

[MartinHartvig]

Just input from one of the people behind JNode. JNode can be found at http://www.jnode.org/ and is a OS mostly written in java. There is small parts in assembly, but this is very low level. Device drivers are written in java.

Re:Well...

[PastaLover]

Java 3D performance is pretty good but it seems to me it's the same thing like the java BigInteger support, eg they just wrote the library in C to make it go faster. Swing is fucking slow and anybody who has ever used a desktop app like say xnap knows that.

I've written a lot of stuff in java (not as much as a professional mind you) and I have seen how fast and how slow swing apps can be. If you have the time and dedication and the right libs for it, user apps are still better written in C for speed. I'd personally write them in C++ actually because of the OO design.

Off course I picked up somewhere someone is working on a java native compiler so that would probably balance it all a bit out.

Re:Well...

[DroningDromedary]

Most of the slowness people usually associate with Java is in the JVM startup time. Once it's been started, even on a slow machine like a P2, Java will fly along nicely.

Larger apps written in Java are still more memory-hungry than their C++ equivalents, so you shouldn't try running these sort of things on older machines with less than 128Megs or so, but I wouldn't expect larger C++ apps to run very well on machines with such limited memory either.

Re:Well...

[darkarena]

I agree with this assessment. The point is to use Java for what Java does well, and much like those little clever things you do in C/C++ to get everything to work correctly, programming Java is as much art as science. Is it a language that should be used for every purpose under the sun? No, absolutely not. But I would argue that neither is C/C++. When it comes to programming platform independent applications as well as online applications that include various character sets and the like, C/C++ implementations are ackward at best. I was a C/C++ developer for 4 years before I started in JAVA, and have been a JAVA programmer almost exclusively for 6 years now. The company I work for has both JAVA code and C/C++ Legacy code. In three years our JAVA solution has surpassed our C/C++ solution in speed, ease of use, realiability, and maintainability. We still use the C/C++ code to control out Legacy systems, but the JAVA client has become the preferred front end of our clients. Just my two cents.

Re:Well...

[Edie O'Teditor]

Yes, exactly. That's why it's inappropriate to say "everything you can do in X, you can do in Y"

What about X is assembler and Y is C, or X is C and Y is C++?

Re:Well...

[AdamPiotrZochowski]

--/ APOLOGIES /----
Please accept my apologies if I have spoken too harshly about Java. I have
not meant to insult you nor anyone who uses Java. I have not said Java
should not be used at all, nor that Java coders are morons. All I have
commented is that Java has worst starting times hence speed is not Java's
cup of tea, pardon the pun.

Before I make another error at offending you yet again: lets review the
discussion that has sparked this thread to maybe a conclusion in agreement:

--/ REVIEW /----
the original question: 'What does C/C++ do that Java does not??'. The
answer was 'Device Drivers'. to which you wrote quite properly that
\ Java can handle "soft" realtime just fine, and extensions are being
\ worked on for "hard" realtime support. And yes, some people actually
\ write device drivers in Java.

to which I have replied, to quote myself:
\ if java can not even simply start fast, how can it be speedy?

now, to get to crux of the problem, you eloquently have stated:
\ You are comparing a Virtual Machine platform designed to optimize large
\ and long running programs, against simple scripting languages? With a
\ Hello World program no less!

--/ THE RESPONSE - AKA : MEA CULPA , REALLY ? /----

Yes, Java Virtual Machine by itself is quite of a beast, but there are
reasons for that. JVM is large because it has many methods to optimize
the code as its running it. JIT (Just In Time) will reorder code based on
current code profiling to avoid branch misspredictions, wasted hardware
registers, etc. In some cases JVM/JIT can optimize the code its running
so well that it rivals unprofiled C/C++ code.

This is also where Java really shines, RAD world, not the actual program
execution time. Speed was never part of the Java's equasion, and you
yourself comment on that with:
\ tradeoffs programmers must make in order to make things fast, small, or
\ "abstract". Hint: It's a lot like Physics. You don't get something for nothing.
There are tradeoffs. Some need fast execution, while others will go after
clean code developed quickly that runs within required timeframe.

And although Java can do realtime device drivers its not really good at
it, kinda like PHP can bind to the GTK.

Some of the problems with JVM/JIT is that it can execute faster benchmarks
because it does not release used memory before benchmark finishes hence
it never incurs the Garbage Collector penalty.

This is quite evident in the Original Shootout comparison:

pure cpu report http://www.bagley.org/~doug/shootout/craps.shtml?x cpu=1&xmem=0
Java is at the top, considering real languages its third, behind the old
and venerable C/C++, not bad, right?

cpu+mem report http://www.bagley.org/~doug/shootout/craps.shtml?x cpu=1&xmem=1

Now we see a different picture, Java uses alot of the ram to avoid Garbage
penalty. C/C++ are still at the top, but now we also have lua (used alot
in games), Perl, Python and Ruby (out of the more well known languages)
that do better than Java.

As others said, doing comparisons between languages is bad, my bad.

now, I do admit to being guilty for delibratelly chosing a statistic that
is not in Java's favour at all, quite opposite to that, and for this
'manipulation' I am guilty. I am also guilty for overstating that Java is
the worst of them all, obviously Java is not as bad as I have made it
sound. However I stand by that Java is not as efficient as other Languages.
I stand by that Java slow JVM startup is an indication to not being best.

--

Re:Well...

[AKAImBatman]

Thank you for taking the time to type up this response, and for providing a more balanced viewpoint. You were my first and only enemy, but that has now been reversed. It takes a big man to admit when he's wrong. Thank you.

A few comments:

However I stand by that Java is not as efficient as other Languages. I stand by that Java slow JVM startup is an indication to not being best.

I think the difficulty that most people have here, is that Java runs on a virtual machine. What that means is that the Java VM should really be running as an OS component rather than a userland program. Unfortuntately, Java development was blocked by Microsoft very early in the game, so we have the sorts of VMs you see today. Sun gets around this problem on JDS by preloading JVMs, then distributing them as needed.

Another nitpick but I would not consider Perl and Python in a category of silly scripting languages. They both are cross platform. Both have a variety of libs (Perl's CPAN is unsurpassed).

Actually, I said "simple", not "silly". Perl and Python are designed to be scripting interpreters, and thus focus heavily on sacrificing performance for startup time. Thus they are really in a different class than Java.

However, it is worth noting that because the Java platform is a virtual machine, it is quite possible to create a Java based shell. Inside such a shell, scripts may start as fast (sometimes faster!) than equivalent Unix scripts. I have a project on my hard drive that reimplements the Unix environment in Java (including full telnet support). The performance characteristics of such a design are comparable to that of a normal Unix environment.

Or are you saying that C programmers are the best to write lousy code and that non C programmers can write better Java code than C prgrammers? I find your claim that its C programmers that are to blame hard to swallow.

Actually, my point was that C/C++ programmers tend to evaluate Java's performance by writing 10 lines of poor quality code (because they haven't learned the language/platform yet), then use the results as evidence of Java's poor performance.

The truly amusing part is that the Java community originally was populated and promoted by C/C++ programmers. Back in the early days of Java, we were so impressed with the platform that we switched over in spite of many of the performance issues of the time! Keep in mind that C programmers are always taught that performance is king. To make a switch like that meant that Java was a very compelling platform!

Most of the C/C++ programmers who didn't make the migration now talk about all the wonderful libraries they have that compare favorably to Java's APIs. Which is quite amusing given that Java's existence is what pushed these libraries into existence!

String x = ' Hello ' ; x = x + ' world ' ;

because when executed its the same as:

String x = ' Hello ' ; x = x.clone().concat (' world ') ;

its slow, + operator returns new instance of String, old goes to garbage
collection. Now lets do it the clean proper Java way:

String x = ' Hello ' ; x.concat (' world ');

Just a minor correction.

String x = " Hello ";
x = x + " world ";

produces:

String x = " Hello "; //Reference to static class resource
x = new StringBuffer(x).append(" world ").toString();

A more efficient way is:

StringBuffer buffer = new StringBuffer(" Hello ");
String x;
buffer.append(" world ");
x = buffer.toString();

Of course, in the case you listed, the performance difference is minor. It really only makes a difference when you're concatonating large strings, or performing parsing operations.

ouch, was this really necessary?

Given your apology, I do feel bad about my rather blunt manner. However, you do have to admit that you had it coming. In attempting to bait responders b

Re:Well...

[jrockway]

Look at QT. That abuses ==.

My take is this: an operator should do something "internal". Windows can't be equal to each other, nor can buttons. They can be _the same_, so the syntax should temind the programmer. Pseudocode:

button1 = button2
(button1 == button2) -> true

button1 = new Button("Hi", parent)
button2 = new Button("Hi", parent)

(button1 == button2) -> false

make sense? equal and equivelant aren't the same thing. i think a perl programmer would agree.

Re:Well...

[angel'o'sphere]

Well,

if two windows are the same, then they are equal as well.

That at least makes sense. So thre might be good reasons to need an == operator.

E.G. if you keep all your windows in a list, but for some reason you choose not to save pointers but references. Now you can not compare any window (ptr or reference) with the windows in the list except by calling operator == of the Window class.

So you need the operator. Supposed every Window has a unique "handle" the operator == can just compare on that.

So bottom line "equalness" of windows makes sense if your requirements are like that.

Furthermore: I would not call that abuse. Abuse is IMHO if an operator like + calculates / or something. The same applies for the shift operators on iostreams. For me the analogy is completely clear. As the author of the iostream library is writing a class, he is free to choose any operator he likes anyway, as all operators are unused.

angel'o'sphere

Re:Well...

[angel'o'sphere]

I forgot:

(button1 == button2) -> false


Of course, that makes sense. They are two different buttons, arguable they have the same contents, but in most real live circumstances you would never consider them as "value wise the same".

aos

Use What Works

[grunt107]

There are Java pundits, and LAMP lovers. Not to mention .Net-sters.

The real issue is use what works, regardless of 'cool' (hell, COBOL was probably cool once and is still used in some places).

As the story points out, Java is not used for low-level (device) programming. And Assembler is rarely used for data movement (ETL).

I say, for QuADs (Quick And Dirties), use a slower coding language that allows for quick development. For Enterprise-level Web/XML apps use something like Java or .Net (MONO). For low-level use C++/C/Asm.

Or try Bison...

Re:Use What Works

[Monofilament]

Totally agree, just to add to what grunt107 said here, just to make clear what i believe he means.

Use what works best for your application, and what you wanna do with it!!!

Re:Use What Works

[TeknoHog]

hell, COBOL was probably cool once and is still used in some places

It has 'business' in it, therefore it couldn't have been cool ;)

who gives a shit about paul graham?

[flacco]

he's a rich guy (wrote yahoo stores or something) who has never even *used* java.

i've read several of his articles, and none of them strike me as particlarly insightful. most are more of the "hey, i have this quirky idea, which i think is cool but is actually rather mediocre, and i have a lot of leisure time on my hands, so i'm going to flatter myself by dwelling on my quirky, mediocre idea in public" variety.

Re:who gives a shit about paul graham?

[bay43270]

I'm reading his book (Hackers and Painters), which is a collection of these essays you talk about. He has an entire chapter in his book called "What you can't say" in which he talks about how often extremely controversial subjects turn out to be correct. He explains his method of guessing which shocking thoughts are wrong and which are just unfashionable. This outcry against Java is just an attempt to put his name in history as being the guy who said it first (as are most of his essays). It does him no harm for several reasons:

1. Because of his personal programming style, he would never like java anyway
2. Eventually Java (like anything else subject to technological change) will become unpopular and he will be proven correct
3. He prides himself on his nerdyness and doesn't care what management types think of him. He is looking for acceptance from the slashdot geek, who will more often than not agree with his language preferences

Re:Maybe because it's slow ?

[Ignorant Aardvark]

Java is slower because it's safer: automatic bounds checking on arrays, which helps to prevent buffer overflow attacks, etc. A program made in Java without an eye to security is going to be more secure than a program made in C without an eye to security. Also, for simple things, like programming web game applets, the speed difference doesn't matter much. I'm proud to say that my language of choice is Java.

Another reason.....

[Ghengis]

Apparently it's easier to use than the English language.
From the article:
How cool is to be the jock with the second fastest race-car in the block? and Top Reasons Why People Think Java Un-Cool - Debunked.
It never ceases to amaze me that people can learn the grammar of a programming language, but not the grammar of a spoken language. To be fair, English DOES have alot of "exceptions" to its rules, but come on. The above are basic grammar mistakes which any editor worth his salt should pick up.

Re:Maybe because it's slow ?

[xer.xes]

It's really time to dump your 386 and move on to at least a Pentium.

Why is Java UnCool?

[DesScorp]

Most developers I know basically slam it for it's reputation for being slow, and frankly, because it's not C, the geek Gold Standard. Perl has the same difficulty and has it's own cultish crowd (Perl users are the Greatful Dead fans of computer science). Python is somewhat trendy as well.

But Java....Java was designed to be easily learned, and to especially be used in web-based apps. To Unix geeks, that makes it kind of the Visual Basic for the Slashdot crowd. Not something to brag on.

Fact is, it's a great language, and it's still growing. A friend of mine is a professional Java developer (mostly server side stuff), and he's one of the brighter bulbs in the lamp. He loves it, and still thinks Java's potential is largely untapped. Whereas we know what C can and can't do, Java is still growing. He thinks it'll be used (and used effectively) for things we can't even imagine yet.

Re:Why is Java UnCool?

[The Grassy Knoll]

It's "Grateful Dead"

Re:Why is Java UnCool?

[Atzanteol]

I never minded the language itself. It's pretty easy to use, but I've never found other languages terribly difficult. The one thing that makes Java so much more damned difficult is the environment! Settting up a system to run a given Java application can be a nightmare (CLASSPATH anyone?).

Especially with large applications or J2EE containers. Just getting things to work can take a long time.

As an aside, I don't know why in the hell CLASSPATH has to refer to individual .jar's. Stupidest 'feature' of Java ever. Let it reference a directory containing .jar files, and load them as necessary. Then we can have /usr/local/java/lib or some such.

Re:Why is Java UnCool?

[pthisis]

Most developers I know basically slam it for it's reputation for being slow, and frankly, because it's not C, the geek Gold Standard.

That's not it at all. First off, I'd say Lisp (not C) is the geek Gold Standard--most of your top-name geeks, from Mccarthy on through RMS to Jamie Zawinski and ESR have been LISP hackers, with the notable exception of kernel/systems guys. Even GIMP was written by LISP fans. But C is definitely in the running, primarily because it fits a (rather large) niche very well--it's the closest thing to a portable assembly out there when you need to get down to the nuts and bolts and still be kind of portable.

[Note that I am not supporting any of the following arguments, merely enumerating what I think some of the objections to Java are.]

What Java doesn't do, from a geek standpoint, is fill a niche very well. A true hacker wants a language that is committed; if you're going to be strongly typed, be VERY strongly typed and have a decent type inference mechanism a la Haskell or ML. If you're going to be dynamically typed, by really dynamic like Scheme and Lisp. If you're going to be OO, support it fully like Scheme, Python, and Objective C (and geeks tend to support the Scheme-world definition of OO). And if you're going to be functional, do _that_ full-out like Lisp and ML.

Note that these are all language features. Most geeks want to support a language based on the language itself, not on the libraries or the implementation ("those can be fixed" is the somewhat insightful and somewhat naive argument). As a language, Java isn't anything new and doesn't fit any of those areas as well as other languages.

I think it's almost secondary that Java is a B&D language; it's the failure to be pure about how it implements various programming paradigms and type structures that gives it the geek *yawn*. C++ suffers from the same thing.

Re:Why is Java UnCool?

[bkocik]

Perl users are the Greatful Dead fans of computer science

Dude...that quote is priceless. May I steal it?

=)

Re:Why is Java UnCool?

[j3110]

If you want to refer to a directory of jars, you need to use the boot class path parameter to the VM.

Most people, however, will either use a manifest file:
manifest.mf:
Class-Path: main.jar lib/library.jar lib/otherlib.jar
Main-Class: org.slashdot.example.MainClass

(Don't for get the blank line at the end).

And/Or they will use WebStart, where you declare what you need in XML, and it can be launched and is automatically updated through the internet when available.

All this is free of course, and so is Ant, which you can use to automatically compile and build your directory structure, including your executable jar file and any libraries you need.

If you have a hard time running a Java application, it's the developers fault. There are PLENTY of ways to make it easy... easier than installing software on any other system.

Re:Why is Java UnCool?

[Atzanteol]

Just because you do not know how to properly use a tool does not make that tool bad. Every single modern J2EE application server starts up first time as soon as it is installed. The reason for this is simple, the people who wrote them, clearly unlike yourself, knew what they were doing.

And people think Java developers are arrogant. The fools!

Sure, the app server starts up fine. What the fuck does that give me? A running app server. Great. Uh huh. Fantastic. How about RUNNING A FRIGGING APP IN IT huh? You get to fight with XML files forever.

Oh, and why do those app servers 'just work'? Not because they were well written Java applications. But because they are well-written *shell scripts*. All Java developers are forced to be good shell/batch script writers. Nothing like a language that constantly needs to be jump-started by scripts.

Re:Why is Java UnCool?

[CAIMLAS]

It seems that Java is the pop language of this decade. It's the programming equivilant of Britney Spears or Creed. It's cool to diss them because they're part of popular culture, but deep down there's some aspect of their music (or persona, etc.) that you like.

Re:Why is Java UnCool?

[neomac]

Thank you.

+1 informative :-)

Re:Why is Java UnCool?

[tolan-b]

What's so hard about copying a .war file to a directory? You don't even need to restart the server for most servers any more.

Perhaps you should ask your developers to try the 'export as .war' button in their IDE... or if they're to eleet for an IDE then to use the command line war packager.

Re:Why is Java UnCool?

[Atzanteol]

If you have a hard time running a Java application, it's the developers fault. There are PLENTY of ways to make it easy... easier than installing software on any other system.

This is partially true... To be a good Java developer also requires good shell/batch script writing (setting up the classpath, different java implementation specific switches, etc). I think it's a shame that Java is almost always jump-started by a script of some sort. It's "yet another barrier" to just writing Java.

Re:Why is Java UnCool?

[DesScorp]

"Dude...that quote is priceless. May I steal it?"

Gracias. Have at it, pard.

Just spell the band name correctly, as one guy pointed out. It's "Grateful". Sorry 'bout that, Deadheads.

The comparison just seemed logical to me. More than any other language (even LISP, I think), Perl seems to have it's own personalities and culture. If Larry Wall went on a speaking tour, I think Mongers would follow him city to city :-P

Re:Why is Java UnCool?

[dffuller]

But it doesn't have to be started with a shell or batch script. Check out this: http://jakarta.apache.org/commons/launcher/

Re:Why is Java UnCool?

[the quick brown fox]

First off, I'd say Lisp (not C) is the geek Gold Standard

A lot of geeks give Lisp props, but who actually uses it?

(BTW, I'm surprised you hold up Python as an example of OO purity. Perhaps you meant Ruby?)

Re:Why is Java UnCool?

[sapgau]

Starting from Java 1.4, it's ok not to specify the CLASSPATH in your environment (im not talking about JAVA_HOME or J2EE_HOME). When Java (the JVM that is) sees there is no CLASSPATH defined it will assume it to be the path where java.exe is being called and the current directory of the class file to execute.

so if you do:

c:\myProj>\java\jdk1.4\bin\java.exe MyProg

The implicit Classpath will be:

C:\java\jdk1.4\bin;c:\myproj

So if you don't have any previous java installations that need to define a CLASSPATH the suggestion is to first run your programs without that environment variable to see if the JVM will resolve it by itself.

Another thing, if you are declaring a CLASSPATH remember to include your local (current) directory with a . (dot), because nothing is assumed in Java!!

Re:Why is Java UnCool?

[TheGratefulNet]

java: going down the road, feeling bad.

C: nothing left to do but smile, smile, smile.

Re:Why is Java UnCool?

[the_Speed_Bump]

I'm certainly not everybody, but I don't like Java because it isn't very expressive at all.

Looking at the SWT source code, for instance, there's all manner of boring, uninteresting cruft laying around because Java simply doesn't offer a more concise way to express some extremely common notion, nor does it offer any syntactic mechanisms for alleviating the problem.

The best example I can think of is resizing an array: Java arrays cannot be resized, which leads to the "newFoos = new Foo[oldFoos.length + x]; for (int i .....)" pattern duplicated everywhere, and it doesn't even mean anything. Several lines of cruft, and, unless it's commented as such, or you recognize the idiom, there isn't anything that even hints that all this looping and copying is an append operation.

(Java 5 allows generic containers, but they don't count yet: it's still beta, and a project like SWT is unlikely to adopt it for awhile anyway)

I like Python (and Ruby, Lisp, C++, D, and even sometimes Perl) because it is much easier for me to write code that says what I mean. The code is shorter, clearer, and infinitely easier to understand.

Re:Why is Java UnCool?

[pthisis]

A lot of geeks give Lisp props, but who actually uses it?

Many people. (More than use Ruby, I would venture to guess, simply because of the widespread presence of emacs.)

Those I mentioned above--ESR, JWZ, Stallman--all have significant projects written in lisp, not just papers on "gee whiz, isn't it cool". Not a lot of it is system software, so it often gets overllooked by the Linux crowd, but check out the lisp repositories at CMU, MIT, and Stanford--since implementations aren't widespread, usage tends to congregate where implementations are in the default setup.

The main problem with Lisp is implementation availability, which is why many people writing lisp apps outside of a controlled environment tend to write them for Emacs. A number of those are fairly widespread. There are some serious CL apps out there (e.g. Allegro FTPd) written in lisp as well, not to mention GnuCash and GIMP and a number of other packages with significant functionality written in scheme. (And heck, you can find 4 or 5 different window managers written in lisp, scheme, or guile on freshmeat.)

(BTW, I'm surprised you hold up Python as an example of OO purity. Perhaps you meant Ruby?)

I'm more surprised you didn't notice my smalltalk->scheme braino.

Re:Why is Java UnCool?

[pthisis]

braino:
If you're going to be dynamically typed, by really dynamic like Scheme and Lisp.
Fine here.

If you're going to be OO, support it fully like Scheme, Python, and Objective C (and geeks tend to support the Scheme-world definition of OO)
Replace "Scheme" with "Smalltalk" here. Ugh, typing too fast.

Re:Why is Java UnCool?

[pthisis]

Neither Lisp nor ML is a full-out functional language:

You miss the point. Lisp and ML have full-out support for functional programming (unlike, say, Python, which is one of the big arguments against it--don't half-ass it, do it right if you're going to do it.

C++ and Java have sort of halfway-there OO implementations by the classic definition, and Java (forget C++) certainly doesn't have anything an ML (or Haskell) programmer would call "strong typing".

It's not that geeks feel a language should only support one feature/programming model, it's that if you're going to support one it should be done "right" and "with elegance" (which terms have somewhat nebulous definitions).

Re:Why is Java UnCool?

[the_Speed_Bump]

Dude, if you're resizing an array like this, you're using the wrong tool for the job. One word: ArrayList. Toot toot! Clue train departing! All aboard!

ArrayList is even worse because, instead of these ugly little repetitive idioms, you have casts everywhere. Not only are operations like a resize full of syntactic clutter, but every single read from the collection has this extra syntax that is completely useless to everybody and everything except the compiler.

Re:Why is Java UnCool?

[j3110]

Well, under Windows and Mac OS X, you don't need scripts. Under Linux you need them for Executable Jar format because in order to make linux run an executable jar, there are about 8 pages of instructions to do on every machine to make it work. It's not a failing with Java, but a snobbish attitude of distros, which hopefully with Kaffe, etc. that attitude will change. You can just double click jar files on every other platform. Linux's idea of a launcher forces you to use a shell script, even for perl and python, and it forces you to modify your file to support Linux instead of the more proper way of the OS supporting the program. Don't ever write a scripting language where # isn't a comment, else you'll be just as screwed.

If it were done right, all files would have a mime type attribute, and user specific table would specify how to run a file with that mime type.

There is a Java WebStart implementation for Linux that works great.

Re:Why is Java UnCool?

[the quick brown fox]

IIRC, ESR did most of his work in C and Perl, and now is a Python advocate. JWZ's main projects (correct me if I'm wrong) are Netscape/Mozilla and XEmacs, the former of which is written in C/C++ and the latter of which is pretty much inherently a bastion of Lisp.

I'm not saying that Lisp isn't cool, or that I wouldn't be thrilled if my next job involved full time Lisp hacking. But to me, the language that is considered the geek Gold Standard should be the one that most geeks stand up and proudly say "Yes, I am a _____ hacker," not "_____ is cool, and I've built some significant projects in it, but for that last ten years it's really been mostly C and Perl."

I'm more surprised you didn't notice my smalltalk->scheme braino.

That's funny, I actually read it as Smalltalk... twice!!

Re:Why is Java UnCool?

[pthisis]

ESR did most of his work in C and Perl, and now is a Python advocate

He did a fair amount of Lisp work as well IIRC. His resume now says "My high level languages include C, LISP, Pascal, APL, FORTRAN and several BASICS, Tcl, Expect, Perl, and Python; I am best, and highly expert, at C, LISP, and Python."

JWZ's main projects (correct me if I'm wrong) are Netscape/Mozilla and XEmacs, the former of which is written in C/C++ and the latter of which is pretty much inherently a bastion of Lisp

He also did a lot of work on Lisp machines which is still in the CMU AI repository somewhere under ftp://ftp.cs.cmu.edu/user/ai/lang/lisp/

Re:Why is Java UnCool?

[the_greywolf]

Fact is, it's a great language, and it's still growing. A friend of mine is a professional Java developer (mostly server side stuff), and he's one of the brighter bulbs in the lamp. He loves it, and still thinks Java's potential is largely untapped. Whereas we know what C can and can't do, Java is still growing. He thinks it'll be used (and used effectively) for things we can't even imagine yet.

i somewhat agree with this, as i'm quite sure Brainfuck could be used to great effect in Space Shuttle control software.

but the reason, IMO, Java remains largely untapped (keeping in mind i am in no way a fan of Java - i hate it nearly as much as Fortran) is because it is continually used in situations where it is largely inappropriate: Azureus, for example, while it is an excellent BitTorrent client and is IMO the most feature-rich and useful BT client i've ever seen, under my own personal usage continually and consistently uses more than 500MB of RAM - the sum total of my system memory. that is unacceptable, and until the Sun JVM reduces its memory footprint by a few hundred MB in this case, Azureus is an entirely useless application. i use ABC now solely because of its memory footprint. it has the functionality of Azureus but uses far less memory.

all of that said, yes, Java has its place. i can particularly see its use in server environments where memory is not quite so precious, but performance and portability is all.

give me a desktop JVM that does everything SE does with Micro's footprint and i'll be a little happier. but for now, i don't want to see another Java app for a long time.

Re:Why is Java UnCool?

[brank]

.As a language, Java isn't anything new

Actually, I'd say that's one of Java's strengths: it brought useful concepts and features to mainstream coders that used to only be in non-mainstream languages. C++ did the same thing.

Sure, they're both far from ideal, but for whatever reason the more perfect languages have (sadly) not succeeded in business. Since I have use an imperfect language on the job, I'm glad there are these less painful compromises.

As Guy Steele (one of those Lisp-loving geeks) says about his work on Java:

We had to make hard choices about what to fix before releasing it.

And you're right: we were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp. Aren't you happy?

Re:Why is Java UnCool?

[pthisis]

Actually, I'd say that's one of Java's strengths: it brought useful concepts and features to mainstream coders that used to only be in non-mainstream languages. C++ did the same thing.

Not sure I agree about Java. The only thing I can think of offhand that Java brought in that wasn't in mainstream language implementations was the sandbox.

We managed to drag a lot of them about halfway to Lisp.

I think this is exactly what geeks hate; as I said in the parent post, geeks want the language to support a feature fully or not at all. From that perspective, it's actually worse to have e.g. some support for functional programming (but not complete support) than none at all; it's also better to have them in C than halfway to Lisp even if all the way to Lisp is the ideal.

(and of course comparing a basically statically typed, object oriented language to a primarily non-oo dynamically typed language is a bit suspect...)

Seems odd to the non-geek to penalize something for having a partial feature, but I think it's part of the key to understanding why Java is "considered Un-Cool" (after all, C++ is mostly C PLUS additional features, yet it isn't considered cool either).

Re:Why is Java UnCool?

[Estanislao Mart�nez]

And C++'s template ugliness is better in what way?

Not many. Which means that your comparison to C is a strawman.

Two better things to compare it to:

1. Dynamic languages. No extra syntactic clutter at all.
2. A static language with non-broken generics. Good examples: ML, Haskell.

If you don't like to see lots of repetive casting, then write a class that either derives from or aggregates ArrayList and do the casting there. Programming 101.

Then you need to write a distict class of each sort for each type for which you want to avoid the casting, each with nearly identical code. You've increased the complexity and duplicated lots of effort. Programming 201.

My diagnosis: the fact that C++ is the sole the point of comparison you draw from to evaluate Java's collections support means that you can't understand the grandparent poster's point.

Enterprise grade and Cool

[DG]

Enterprise-grade apps and "coolness" may be inapproriate bedfellows. Besides, does any language offer both?

Perl.

No, seriously - properly written perl is both "enterprise grade" and as cool as hell.

Of all the languages I've ever worked in, nothing let me build systems as easily, as robustly, and as QUICKLY as perl did.

Remember the Daimler - Chrysler merger? Perl was the glue that unified the HR systems and LDAP directories. As far as I know, it still does. Our LDAP - LDAP replicator tool (written in Perl) was a damn sight more reliable than the native replicators, plus it would do schema translation, plus it had a smaller footprint.

Somehwere along the way, perl seems to have picked up a bad reputation for being illegible and obscure - and certainly one has the freedom to write the cliched "line noise" programs if one wishes. But perl done right can not only be legible, it can be beautiful.

DG

Re:Enterprise grade and Cool

[JSkills]

Well said. I'd mod up if I had the points.

Re:Enterprise grade and Cool

[michaelggreer]

Totally true, but Java does a better job of enforcing readable coding, so you never get into that (pretty common) obscure Perl programming. Lots of Perl code is one-off quick fixes, prototyping, glue, etc, so does not get the attention it deserves. Its not Perl's fault: its just so quick to code up.

Perl can be very beautiful. However, that's it problem: its so expressive that the code can be very individual and unique. Not good for the next guy who has to maintain the "poem" you wrote 3 years ago.

Let's not pretend Perl code is easy to read because it would be in an ideal circumstance. In the real world, I would hate to get handed a 5 year old, 1000 line Perl program to update.

Re:Enterprise grade and Cool

[smack.addict]

Perl is not an enterprise programming language. It is a system administrators tool gone mad.

The number one reason: Perl is a maintenance nightmare. This flaw is a result of its beauty, namely a given solution to a problem can be expressed in hundreds of different ways using syntactic elements from a variety of languages. Thus, if you bring in someone who is a Perl novice, they may have no idea what it is going on in Perl code written by someone else.

With Java on the other hand, any novice can come in and understand what is going on inside the code.

Re:Enterprise grade and Cool

[Paulrothrock]

if (!you(can_read_perl))
you = stupid.

Obfuscated:
if(!y(c))y=s

Re:Enterprise grade and Cool

[WhiplashII]

As someone who makes such decisions, let me tell you why (I believe) Perl is not as widely used.

Perl can be done right, as you say. But it does not enforce readability, and there are many programmers that will write illegible code in it. There is no one watching these programmers on a daily basis, so at the end of my million dollar project I may end up with something no one can support, which would then eventually have to be replaced. On the other hand, other languages force the programmer to follow certain rules that lead to more legible programs. I will always choose something that I have control over, since I am going to be fired if my million dollar project fails...

Re:Enterprise grade and Cool

[Taladar]

With Java on the other hand, any novice can come in and understand what is going on inside the code.

...if he has a Browser with Google handy to lookup all the weird Class- and Method-Names the Developers of Java put in their Libraries. Readability for Non-Java-Programmers is not exactly one of the strong points of Java. Most other languages invented around the same time as Java are easier to read if you do not know the language (e.g. Ruby).

Re:Enterprise grade and Cool

[ElGuapoGolf]

That may be true in some cases... but truly if something like...

String s = "Test";
String t = "test";

if (s.toLowerCase().equals(t))
{ ...
}

If something like that is hard to follow, and those are weird class/method names, then I dunno what to tell ya.

Re:Enterprise grade and Cool

[ecrips]

Yes, but something along the lines of:

writeData(collection(new DataItems[] {fred,bob,george}));

Is not very clear to a non java programmer - and that's exactly the sort of code I'm currently having to deal with in my job atm. 'collection' as it turned out was nothing to do with Java collections - it was a function defined in the class that took an array of objects (fred, bob and george) and produced a List to pass to writeData. Not to mention that Lists are not actual classes but interfaces (which stumped me for a little while).

The simple bits of java are simple - but in most languages the example you gave is obvious for a programmer not used to that language (C is an exception I would argue).

It's quite possible to write bad Java in the same way it's possible to write bad code in other languages. Perl it one of my favourite languages mainly because things like variable sized arrays (which can be used as queues and stacks) and hashes are fundemental parts of the language.

Re:Enterprise grade and Cool

[ElGuapoGolf]

I agree with you there, it's possible for poor code to be produced in *any* language. But what I thought you were saying in your original message was that the core java classes were not intuitive.

Not that they're all easy to follow... but if you know a bit about what you're working with they should be easy to follow.

Re:Enterprise grade and Cool

[Pentagram]

Thus, if you bring in someone who is a Perl novice, they may have no idea what it is going on in Perl code written by someone else.

That's not entirely fair. Quite often, you can bring in someone who is a Perl expert who will have no idea what is going on in someone else's Perl code.

Re:Enterprise grade and Cool

[smack.addict]

Honestly, this bit of code was fairly obvious to me. Though the programmer did make one mistake. The collection method should have been named toArrayList() or something like that.

Methods in general should reflect some action. No language on earth, however, forces people to name their methods properly.

The real problem with Java is.

[JollyFinn]

Swing programming in Java is Pane in the ass.

Re:The real problem with Java is.

[JollyFinn]

Id elaborate exacly, I got a bug that everything appeared and disappeared mystically all the time, and all the locations of the things on the screen jumped around randomly when scrolling. I went through ENTIRE swing documentation of EVERY single class in my application and ALL their superclasses and wasn't able to find single reason WHY it happened the way it did. I went through all the tutorials I could find on swings. Finally I decided to do random code transformations and suddenly after I changed the order of declaring JLayeredPane and JScrollPane That correct I was hoping of putting LayeredPane inside Scrollpane but it just didn't work as simply as documentation said it was supposed to work. To put things worse, the documentation was so huge that looking for it took weeks. No the worst problem isn't speed, the worst problem is undocumented features of HUGE system that cause bugs that are impossibble to hunt down based on available information and only randomaction was able fix that. Its sheer size of documentation to read for finding IF there was feature in documentation at SOME level where I inherited it where the cause of pain would be found. So in overlla ITS PANE IN THE ASS.

Bad Progammers == Bad Experiences

[ckotchey]

In my experience, being on the user-side of Java applications, it's not so much the quality of the language itself, but of the (apparently) poor programmers they must have developing these Java applicatiosn I have to use (typically internal-use-only tools within my place-of-business). Bad/non-intuitive user interfaces, illogical layouts, slow performance, and if I had a nickel for each time I got some sort of incompatibility problem based on what Java VM my browser is configured to use (or WHICH browser I'm using)!!!!

Re:Maybe because it's slow ?

[Nakkel]

I cant speak but for myself, but we use some Java applications at my work. Some work just fine while others literally grinds the computer to total halt. IANAP (I am not a programmer) but somehow I get the feeling that some Java applications are just badly programmed. Why else the variation in performance?

More missing features...

[Zo0ok]

Java lacks structs (I hate to get an extra .classfile for each inner class), gotos and enums. Those are cool features.

However C# is even less cool since you cant fall-through inside a switch (without the use of goto).

Re:More missing features...

[Muad'Dave]

Java lacks structs...and enums.

Not to pick nits, but a class with only public data members is essentially a struct, and J2SE 1.5 will have enums.

Re:More missing features...

[CountBrass]

Huh? You trolling or something.

goto is bad, the fact that Java doesn't have them is a good thing.

Java is an object-oriented language: you shouldn't split data and function therefore there is no need for structs. Although if you're a really crap developer you can replicate the effect in Java:

public class MyStruct
{
public int someValue;
public String someString;
}

As to separate .class files: why do you care?

Re:More missing features...

[norkakn]

goto is a tool, it is neither implicitely good or bad, but merely a tool that can easily be misused.

That being said, gotos are sometimes the best and simplest solution and should remain.

Re:lame

[Seahawk]

FFS people - how is this insightfull???

Look at the arguments in the supplied link!

Mod this as the flamebait it is, and dont bite! :)

Oh come on

[Phaid]

It's just not that hard to understand this. For good or ill, programming has always been an ego-driven profession. You hear stories of punch cards and marathon hacking sessions, and how cool it was that some guy arranged all of his code so that memory accesses were precisely in alignment with the rotation of the memory drum. You do not hear about how cool the fact that someone's applet can't crash because of automated bounds checking and lack of explicit pointers.

Java is seen as uncool precisely because it protects you from your own mistakes -- it's an attempt to make programming approachable to the masses, and the fact that it's forgiving makes it look like programming with training wheels. And just like the 50 year old MBA will never fit in with the Harley crowd, Java programming will never be seen as cool as "real" hackers' languages like C.

Re:Oh come on

[kisrael]

I don't get this "Java was meant to be easy".

Visual Basic was meant to be easy, for the masses.

Java...it was meant to be secure, and multiplatform. Historically, I never saw "easy" entering into it, for the masses... (Heh...especially now with J2EE and that whole EJB mess.)

Processing on the other hand...that is meant to be easy and fun, and feels like Java meets great old school BASIC, back when we'd make little toys on our Atari 8bits and C=64s...

Re:Oh come on

[cabazorro]

Perhaps a good analogy is Microsoft Word spelling auto-correct feature. Which writer is cooler, the one using good-ol pen and notebook or the one in his 2K laptop using MS Word On-line-auto-correct Tools? Which writer requires to adopt a more disciplined/critical disposition towards the art of writing?

Still even the best writer has other people proofing their work by others. Even after using MS tools which won't catch mistakes such as:
"He deplaned from the train" a-ha!

Personally I think Java is un-cool because is a language created and championed by a for-profit Company(SUN). And as we all know, the primary objective of any for-profit company is not to create better technology but to make money and crush the competition. I must admit this is some sort of reactionary/anarhcist view..which some think is cool too ;).

Re:Oh come on

[imbaczek]

Look at Python. It's a clean, easy, portable language that protects you from your own mistakes and it somehow manages to be cool. Java is too verbose and doesn't fit my brain; that's why I don't consider it cool.

Re:Oh come on

[gnuLNX]

I would also like to add that the people we brag about getting code to run in sync with memeory rotation, or who inline SSE assembly instuctions, or what ever other truely geeky thing are the programmers that are truely doing it for the love of it and these are also the ones who will still have jobs after the outsourcing thingy reaches it's peak. Fact is there are great programmers, good programmers, ok programmers and shitty programmers. Great programmers will succeed. They will always require that extra control that a language like C will afford them. Perhaps languages will be divided into professional langauges (think NFL) and learning langauges (thing college).. who knows. I will never slight a Java programmer, because he may be ten times smarter than me or he may write certain apps faster than me. But when speed is king ( I develop comutational chemistry apps) I will always use C++ as I can get the security through the STL and I can optimize to my hearts content. Yes I have written several routines of inline assemble that take advantage of the SSE2 registers. No a compiler will never write assembly as good as I do....ok never is a really long time, but currently gcc doesn't even come close, nor does intel.

Now I have a question...because I honestly do not know. Is it possible to inline assemble with Java? I guess you would probably loose a lot of your cross platform stuff with it huh?

oh well just my two cents worth.

Re:Oh come on

[FriedTurkey]

Now I have a question...because I honestly do not know. Is it possible to inline assemble with Java? I guess you would probably loose a lot of your cross platform stuff with it huh?

Yes, you can just call a C/C++ library which has inline assembly. Never needed to do that. In fact that would get me fired because nobody would be able to maintain it. To make up the costs of coding/maintaing something for the applications I write versus the hardware costs of needing a more powerful computer to run it would never come close.

Re:Oh come on

[ClosedSource]

The development of programming languages has always been about increasing productivity not about being cool. C was created so system programming could be performed without resorting to the more difficult assembly. In the preface to K&R's "The C programming language" C is described "easy to learn".

Perhaps we should check the "real hackers'" Harley for training wheels.

Re:Oh come on

[a_n_d_e_r_s]

Well, the same can be said about both C and C++ they where also created by a for profit company.

Are they also uncool ?

Re:Oh come on

[cabazorro]

Maybe I should re-phrase instead of "created"..I should say "distributed/maintained/controlled". Java Standards are controlled by a for-profit company. C and C++ standards are controlled by ANSI.

ANSI doesn't care of who get's to do what.
SUN does.
Go write your own (non-standard) c compiler and be kewl by adding new bells and whistles.
Very cool.
Go write your own Java compiler with added features and watch the army of SUN lawyers knocking at your door.
Not very cool.

Re:Oh come on

[gnuLNX]

Interesting. Just goes to show you my knowledge of Java.

"In fact that would get me fired because nobody would be able to maintain it"

Not suprised....for the vast majority of applications this would be a big time no no. However I am lucky enough (ok so the geek inside is lucky enough) to have apps that demand the extra speed. Makes it hard for others to maintain...but then that also provides a degree of job security...if there is even such a thing as that any more.

-Cheers.

Type System

[BarryNorton]

Says the article:

Java is a strongly typed language therefore you have to tell the compiler exactly what you intend to use. And if you make a mistake in the way you use it, the compiler has the guts to tell you that you were wrong. Too much chaperoning?

The problem with most Java code is that there was (for nearly a decade, despite this being a well-established feature of type systems) no parametric polymorphism, therefore using the containers collection meant throwing away the typing information and casting... and, no, the compiler doesn't tell you when you're wrong, not even the static type checker does, the dynamic type checking fails at run time! That's not cool!

I think the guy needs to learn something about modern programming languages before sitting down to write...

Re:Type System

[CountBrass]

That was a deliberate decision in order to avoid the monster mistake Bjarne made with C++ templates.

Java 1.5 introduces generics: the ability to define type-able collections and does them in a much, much more elegant way than C++'s abomination.

Re:Type System

[BarryNorton]

That was a deliberate decision in order to avoid the monster mistake Bjarne made with C++ templates. Java 1.5 introduces generics[...]

I'm quite aware of the new features (hence "nearly a decade") but, believe it or not, C++ was not the origin of parametric polymorphism... in fact, the real lesson to learn from C++ is that this should be a core part of the type system, and dealt with as first class by the compiler and linker, from the inception of a language, not grafted on later!

Re:Type System

[CountBrass]

Like Java is doing- and C++ has still to do you mean?

I'm confused in that case, what was your problem with Java?

Re:Type System

[BarryNorton]

Like Java is doing- and C++ has still to do you mean?

Sun have a time machine?!?

I'm confused in that case, what was your problem with Java?

That all our experience with it so far (because that's what the article's about), and legacy code for years to come, is based on type casts everywhere and reliance on dynamic type checking.

(What's more there will be lots of programmers whose CVs prove they 'know' Java who won't use features grafted on after the fact.)

Ha!

[Fizzl]

For once I can say "Java sucks!" and be on-topic.

For all you moderators: "Neener! Neener!"

If *Java* is uncool....

[revscat]

... where does that put C#? In the basement with the red Swingline?

Re:If *Java* is uncool....

[npsimons]

... where does that put C#? In the basement with the red Swingline?

If you mean that C# will probably burn down your company's building someday, then you are probably right.

Re:If *Java* is uncool....

[javaxman]

C# just wishes Java would let it *borrow* the red Swingline...

I-Robot and Java

[auburnate]

The company I-Robot uses Java to interface a Linux box running Red Hat to all the sensors, cameras, and motors on their research line of robots. I spent four months trying to get the darn thing to work, CLASSPATHS and all to no avail. What a friggin nightmare. My master's thesis was going to be on that robot and now Auburn University is just building a robot from the ground up. Life's like that ...

command-line arguments

[benasselstine]

From Sun's Java TM tutorial: "Purity Tip: Programs that use command-line arguments are not 100% Pure Java because some systems, like the Mac OS, don't normally have a command line or command-line arguments."

Command-line arguments are cool damnit! Any language that doesn't encourage them is uncool.

Classloading, not VM startup is slow

[Anonymous Coward]

VM startup is quite fast these days (tenths of a second on reasonable desktop hardware):

user% cat hello.java
public class hello {
public static void main(String[] args) {
System.out.println("hello, world!");
}
}
user% javac hello.java
user% time java -cp . hello
hello, world!
0.140u 0.020s 0:00.29 55.1% 0+0k 0+8io 0pf+0w

Classloading is slow as all get-out, and even moreso when you're suffering through the startup of a Swing application, since Sun saw fit to make every Swing class reference every other Swing class.

Why Java is popular

[Scarblac]

Java is used a lot these days. There are three main reasons, in my view, why it became so popular:

• In the beginning, there was an amazing amount of marketing and hype.
• After that phase, it continued to be popular because by that time there was a large amount of libraries, both free and commercial.
• As a language, it's not that hard to learn, and it gives some protections that C++ doesn't have.

So if you look at it purely as a language, it's just not that cool. You don't see amazing Java hacks. It's not great, it's just not bad. Add to that a few really irritating things (that are being addressed) like constant casting and having to check every exception all the time... Why would it be considered "cool"?

Enterprise-grade Java?

[adb]

What mythical implementation is that? A common online chess applet can crash most of the JVMs I've tried it with. When I see "jsp" in a URL, I twitch uncontrollably. "Slow" and "flaky" are good words, but they don't nearly convey the necessary intensity.

I write software in decent high-level languages like Ruby and Perl all the time. It's not bug-free, but it never crashes the goddamn interpreter and if it's slow it's because I wrote it wrong.

Re:lame

[Cocoronixx]

Java GUI is slower than native alternatives

Not really. Tried it recently? eclipse is a good example (eclipse.org) of fast java program.

Apparently, one of you two is smoking crack. Take a guess on which one.

Swing

[raffe]

Swing is a brilliant, although hard to learn, API.
Can someone please tell me the brilliant part about Swing. Honsestlly. I want to know! This is not a flameware. Please tell me what I am not seeing here. I code in java almost every day and i like it a lot but the Swing part i dont get.

Re:Swing

[freality]

I wrote a desktop (email, browser, chat, etc.) in about 1500 LOC in Swing. I think Swing is cool.

http://freality.org/~pablo/code/index.jsp?packag e= jos.desktop

OBVIOUS NOTE: It's not Windows XP. Hackers only.

Re:Swing

[popeyethesailor]

IANAJP, but I guess its the MVC, Smalltalk-ish, cross-platformish nature of it. True that the default look sucks, the rendering is slow as molasses, but its designed well, IMHO.
It looks pretty on Macs, supposedly.

Re:Swing

[Malc]

I'd also like to know why it's considered hard to learn. When I tried writing some Java stuff (a few years ago) I found Swing extremely straight-forward and obvious. Perhaps that's because I had previous experience with GUI toolkits in Smalltalk, C++ (including MFC!!! ;)) and Modula-2. Perhaps it's not easy to learn if you're a newbie to programming, but then any large class library is going to be challenging.

Re:Swing

[TheRaven64]

It looks pretty on Macs, supposedly.

Not really. The OS X look and `feel' for Swing looks a lot like 10.1, so doesn't really fit in a modern OS X system. Added to that, most people seem to aim for a Windows feel in their Swing apps, which makes them feel very wrong on a Mac. On the other hand, the Cocoa bindings for Java make it very easy to create a native OS X GUI for a Java app.

Re:Swing

[blackwater]

It's not brilliant (IMO) but it's at least fairly consistent and reasonably OO. Coming from an MFC (and previously C/Windows) background I found it quite pleasant.

Re:Maybe because it's slow ?

[deadlinegrunt]

"...The first time it's going to be very slow, every time after (until the vm is killed)..."

And things like the garbage collector kick in etc.

Java is an excelent platform. It just is not the be all end all platform.

70mbit/sec, 100% Java

[revscat]

To all you "Java is slow" parrots, I would just like to offer a counterexample. Where I work we serve up 70mbits a second, and the site is 100% Java/J2EE. The DBs are AS/400s and SQL Servers, but all the application code is in Java, and it performs quite well, thank you very much.

Re:70mbit/sec, 100% Java

[NeoSkandranon]

Anything runs fast if you put it on a fast enough computer.

Re:70mbit/sec, 100% Java

[pcraven]

No, go back to your big 'O' notation. Throwing big computers at a problem doesn't always get it to run fast.

Anyway, Java apps usually run similar to C depending on what you are doing. Like any benchmark though, you can make Java run faster than C or slower, depending on your goal.

Re:70mbit/sec, 100% Java

[The Unabageler]

so what? I've done the same using php/perl and postgres on cheap x86 hardware.

Re:70mbit/sec, 100% Java

[nickos]

Is Google written in Java using J2EE? No? Why's that? How many J2EE sites have been slashdotted, while Slashdot, written in Perl, is fine? Hmm...

Re:70mbit/sec, 100% Java

[ScytheBlade1]

It's a porn site, isn't it?

There's no denying it now! No site gets 70mbit/sec unless A) /. B) It's a porn site.

Re:70mbit/sec, 100% Java

[julesh]

1. Not every site is google or slashdot -- these are two sites that carry an exceptionally high amount of traffic.

2. Once you get up to the sort of traffic slashdot receives, the extra overhead of a Java implementation is low compared to the amount of work you're doing that really has to be done.

3. PERL couldn't cope with Slashdot's load by itself. Slashdot uses a content cacheing scheme where most requests aren't actually handled by the main CGI scripts. It's the only way of handling such a high load.

4. I've seen sites slashdotted that were using a whole variety of scripting technologies. Some of them are just static HTML. Slashdotting has more to do with the speed of the server's Internet connection than it does the software running on it.

hrmm...

[sl8763]

I think Java is super cool. Then again, I used to work in COBOL.

Huh? Java?

[Dark Lord Seth]

I don't see why it should be considered "uncool". It's nicely documented, easy to work with, resembles other decent programming languages and it's a scripting language. Yes, native apps are going to be faster, but we live in a 3+ghz era. The minor impact from script-compilation is negligable these days.

Cool?

[squiggleslash]

I don't think it has anything to do with coolness.

Java the language is actually fine. I don't know many people with major issues with it (at least, not compared to other mainstream programming languages - I'm not talking scripting languages here, so Python and Ruby zealots need not reply.) It's a little verbose, and it's imperfect, but it's an average language. It can certainly be improved, but I'd prefer it to C++ or even Objective C, if natively compiled and linked with a decent library.

Java the library, on the other hand, is a poorly organized and overly large confusing mess. It's hard to find the exact classes you need without having an intimate knowledge of the entire library, something hard to do because it's just so large.

Java the run time environment is slow, it uses memory poorly and programs generally take an age to load on all VMs, and vary in speed depending on the quality of the VM.

Java the portable environment is clumsy and eschews industry standards. Portable, standardized, solutions exist for many applications that Java deliberately ignores, from the POSIX APIs (Java doesn't even give you access to environment variables any more) to OpenGL (which Java deliberately ignores in favour of Sun's "higher" level wrappers.)

Java the system forces you to write portable applications, so Java is unusable for many small, one off, tasks. As a basic example, you can't write a one-off CGI in Java (the load time and lack of POSIX features makes that impossible), the "proper" way to use Java in this instance is to use a full blown application server like Tomcat. But if you're writing something small, that's simply overkill. Note: please don't respond saying "You're just using the wrong language", I know that, that's precisely the point, because of a few dumb design decisions, Java isn't suited to this, and those design decisions appear, for the most part, to be arbitrary and not in any way complementary to the system.

Java the web plug-in has, in the past, been unreliable and prone to crashing the container browser. While these issues have arguably been fixed in more recent environments, they've still left a sore taste in the mouth of anyone using them. Certain features, such as simple website authentication, generally become PITAs with Java applets because those applets rarely interface with the browser well enough, forcing the user to repeatedly re-enter usernames and passwords, or the developer to work around the issue with complex alternative authentication systems.

Java isn't cool or uncool. Java just has a bad reputation, a reputation justified by various design issues that all serve to reduce the number of applications for which you'd want to use it. It's fairly good at the "giant web services application" area, it seems to suck for the most part elsewhere.

Totally mis-informed

[brunes69]

The number of mis-informed posts on this subject is staggaring. An attempt to debunk some of them:

Java is slow - This is a myth. A long-running Java app running under HotSpot will over time grow to be faster than nearly any simmilar C or C++ app. Why? Because the Vm can over time learn how the codepath actually is executing and optimize it at the assembly level. The only way you could consistantly achive performance as good would be to hand-code the whole app in assembly, and thati s assuming you already know in advance exactly how the program will be used so you know what paths to optimize. This is highly unlikely.

Java UIs are slow - Java UIs are only as slow as your toolkit. Yes, Swing blows ass. But there are Java bindings for Gtk, Qt, and wxWindows, all of which are pretty cross-platform. And there is also the SWT toolkit from IBM which uses native widgets when possible, and when not falls back on its own widgets.

Java needs a VM so you can't run it everywhere - THis has to be the dumbest one of all. Since when can you write any resonably complex C or C++ application for multiple platforms without some effort? Any C/C++ app targetting anything more than basic POSIX will be littered with #ifdefs everywhere. With Java at least you can complile it just once, then ship multiple VMs , rather than having to adust your code and re-compile for every target platform.

Re:Totally mis-informed

[kisrael]

Anecdotally, I'd say: the Java editors/IDEs I've seen that were written in Java were all dog-slow (Jbuilder, I'm looking at you...and Forte, you haven't been forgotten.) And that's the biggest most complex app a lot of programmers interact with ALOT... so I'm not surprised programmers think Java is slow...

Re:Totally mis-informed

[Anonymous Coward]

In theory, all of hte above is correct.

But I am a JAVA developer using Borland JBuilder X (one of the leading JAVA IDEs, implemented in JAVA) on a 3Ghz machine. The UI is the slowest, most unresponsive thing on my system. If the maker of one of the leading JAVA IDEs can't package their system (w JDK of their choice, toolkit of their choice, etc) so that its responsive on a modern machine using XP Pro, then I think it's fair to say that JAVA is slow for GUIs. (Yes, XP pro sucks, but every other app on my machine, most of which are written in C/C++, work fine.) Try eclipse - even using SWT, my experience is that its about as unresponsive, compared to Microsoft's C++-coded IDE, and even compared to Emacs, which is largely written in bytecoded LISP (and not even a very fast LISP) and has been known as a hog for decades.

Also, while hotspot VMs in principle can grow to faster cpu performance than native compilation, the major cause of JAVA's slowness is space cost, not time, plus startup time (of the JVM, classloader, etc). I've never heard of any JVM which is reasonable in space terms. Most need a 10M resident set for hello world, and go up very fast with increasing complexity of app.

Starting BEA (_the_ leading JAVA app server) on my system takes 30 seconds. This is absurd. (And it's not even precompiling the JSPs needed, because as soon as I hit a page, it chokes again for multiple seconds.)

Plus, htere are things that native compilers are better at than hotspots, as they can make lower-level decisions than a bytecode compiler while they can still see the source tree. I don't think either type of compiler is clearly better than the other, but I don't think its fair to say that JIT is always faster. Try using a few JAVA apps, then using a few C++ apps, and see which one works better.

That said, JAVA has a huge security advantage over C/C++. Even experts screw up sometimes using those languages (look at the occasional security hole in carefully coded bits of core unices). _Any_ garbage collected, bounds-checked language has much of what JAVA has (excluding secure classloaders, sandbox, bytecode verification) for security, in fact. Some, such as OCaml and Common LISP, can potentially be far faster than JAVA, especially at compute-intensive tasks. If speed is no object, use Python or Perl (and I know, sometimes they're just as fast).

Tool choice depends on the task. And sometimes the task is "interface to these twelve hoary enterprise systems using the same language the standards committee decided the other twelve hundred programmers will use." Don't laugh. I think the analogy from JAVA to COBOL has some truth to it...and just think how much better of a COBOL JAVA is, in most ways. But that doesn't mean that Paul Graham should like JAVA. He made his career by seeking out the kind of problem that is NOT subject to the above constraints, but very different ones. (Did anyone actually _read_ his article? Or his other 30?)

Re:Totally mis-informed

[Xpilot]

With Java at least you can complile it just once, then ship multiple VMs , rather than having to adust your code and re-compile for every target platform.

Problem : You can't ship a VM if it does not exist for your particular arch + OS combination. There's no VM for Linux-Sparc, if I'm not mistaken.

Re:Totally mis-informed

[mschaef]

"A long-running Java app running under HotSpot will over time grow to be faster than nearly any simmilar C or C++ app. Why? Because the Vm can over time learn how the codepath actually is executing and optimize it at the assembly level. "

You know, profile guided optimization is available for statically compiled languages too. It also has the benefit of working well on apps with short run times where the cost of JIT'ing can't be amortized over long run times. The only real benefit to doing this at run time is to be able to adapt your binary to different CPU architectures on the fly, which simply isn't that common for applications where CPU performance is that critical. For other kinds of hardware specific optimization (disk usage, memory, etc.) HotSpot's level of optimization isn't as important as designing your application right in the first place, when you pick data structures and algorithms, etc.

and that is assuming you already know in advance exactly how the program will be used so you know what paths to optimize. This is highly unlikely.

For a truly performance intensive application, a good programmer will use a profiler and a decent suite of test data. If you really don't know what paths to optimize, then you're way too far gone to be saved by HotSpot optimizations at run time.

Java needs a VM so you can't run it everywhere - THis has to be the dumbest one of all.

But not solely for the reason you state. There are some ways to compile Java to native code that are good enough to run Eclipse.

Re:Totally mis-informed

[Milo77]

Just an FYI, MSVC 7.0 allows you to do some of the optimizations you mention. First, it allows "whole program" optimization - that is, the code is optimized not just a compilation unit at a time, but the entire project is examined and optimized based on interactions between compilation units. Second, it allows you to build a special, tooled version of your app that you run against your use cases (unit tests, regression suites, etc). This process spits out all kinds of heuristics to a log file that can then be passed to a secondary compile where more optimizations can be done. I believe they call this "profile guided optimizations". Of course a JIT can still choose the best assembly for the currently running processor.

Re: Totally mis-informed

[er_col]

Maybe it is a myth, it's one backed by reality. I mean, if after surfing the web my system slows down quite a bit,

killall java

always brings it back to normal. Actually I should use past tense, because I disabled Java globally a few weeks ago, and plan to keep it that way.

Re:Totally mis-informed

[iGN97]

The HotSpot will in time be faster than C++ is an interesting argument, and while it's not illogical or directly wrong, it's unlikely.

The typical argumentation goes along the lines of "in Java, we can monitor the program at runtime to do specialized optimization".

Well, guess what, you can do the same thing in C++. You simply profile the code with live production data and recompile using the profiling reports.

It might not be functionally equivalent, but you have the benefit of knowing exactly what binaries you are deploying and you need not worry that time will be spent optimizing at runtime things that can be perfectly well optimized ahead of time.

I've actually only ever seen one program that outperformed a C/C++-implementation, which was a highly recursive fibonacci-calculator; implementation extremely naive and favoured Java. Implementing the same thing in "real C++" allowed the program to solve the same thing in constant time (at compiletime using template metaprogramming), and even then the compiletime was more than 10 times faster than the Java execution.

I am, however, as always interested in pointers to other pieces of code that isolates a situation where Java outperforms C++, immediately or over time.

Re:Totally mis-informed

[bigberk]

Java is slow - This is a myth. A long-running Java app running under HotSpot will over time grow to be faster than nearly any simmilar C or C++ app.

I certainly believe what you are saying here, but my problem with Java is that for servers, we typically use small units of software that execute, do their jobs, and terminate. Java programs are just unsuitable for that model; the initial overhead is high (loading or configuring VM) and the programs don't run long enough to make it worthwile. Sure, you could convert every program to a 'daemon' style but this truly is unnecessary and flies in the face of simplicity most of the time.

Re:Totally mis-informed

[MORB]

Java is slow - This is a myth. A long-running Java app running under HotSpot will over time grow to be faster than nearly any simmilar C or C++ app. Why? Because the Vm can over time learn how the codepath actually is executing and optimize it at the assembly level. The only way you could consistantly achive performance as good would be to hand-code the whole app in assembly, and thati s assuming you already know in advance exactly how the program will be used so you know what paths to optimize. This is highly unlikely.

While there might be some optimisation opportunities for a JIT virtual machine that aren't available to compilers, I don't see how this would work (although I Am Not A Virtual Machine Coder).
Let's say the JVM translates a block of code in native assembler. The first time, it doesn't have any information from the program execution to guide the optimisations.
Then, once it's translated in native code, how does it obtain these informations about which function is most called, which conditional branches are taken, etc. ? Does it have to instrument the code the first time it's translated ? But if so, isn't there some execution overhead that you don't have with precompiled native code ?

Anyway, I think another reason why it's slower than C++ is the garbage collector, and various things in the language that aren't designed with runtime efficiency in mind.

In C++, for instance, you don't have to use a garbage collector. And for a lots of apps, smart pointers with reference counter are perfectly enough for the job. There's lots of applications where you want the object destruction to be deterministic, and not to occur sometime when the garbage collector feels like it.

I believe that's also why C++ is often prefered over java: it's a compromise between having modern programming paradigms and still be able to know exactly what happens at runtime, which makes it easier to optimize. Lots of people aren't willing to throw out all control and understanding of what occurs under the hood for the sake of having a nice programming model.

I think it all come down to Java being too strict in enforcing what its creators think are good programming practise, at the expense of performances, instead of trying, like C++, to be a compromise that can have some benefit for about everyone.

That said, I think Java can be pretty cool too, just for different usages than C++.
For instance, I think that a lot of applications would be best done in java, using the eclipse platform, rather than in C++, because it's easier and faster to do (especially when also using eclipse as ide) and much easier to maintain and to update.

Re:Totally mis-informed

[csnydermvpsoft]

but my problem with Java is that for servers, we typically use small units of software that execute, do their jobs, and terminate

Java isn't the Holy Grail[tm]. For that sort of thing, you're better off using Perl, or maybe even C/C++. No one said that you had to use the same tool for every application.

Re:Totally mis-informed

[Paulrothrock]

A long-running Java app running under HotSpot will over time grow to be faster than nearly any simmilar C or C++ app.

But what if I want an app to run quickly for a short period of time? Say, a quick game of pong. I'd have to wait for Java to load the VM every time. This is why people think it's slow. Most people aren't running enterprise apps on Unix systems that run for ages and "optimize themselves." People run apps for 10-15 minutes at a time. I don't want to wait 5 minutes to type a letter, I want it now. Now now now now.

Re: Totally mis-informed

[mlk]

Applets are very ofton baddly written, the language can not protect you (the end user) from very bad developers.

Re:Totally mis-informed

[Big Boss]

We do the same thing here. I wrote a simple app server that spawns off the required apps on a thread to save the JVM overhead. I don't have any performance problems under this setup.

Re: Totally mis-informed

[er_col]

Applets are very ofton baddly written, the language can not protect you (the end user) from very bad developers.

That would've been a good excuse if you could say "some applets are badly written". Bad news is, in reality nearly all applets are resource hogs, and I only say "nearly" in case there are exceptions, of which I know of none. Same goes for non-applet Java programs. Do you still want to blame it all on bad developers? And I won't even get started on the GUI...

Re:Totally mis-informed

[Anonymous Brave Guy]

A long-running Java app running under HotSpot will over time grow to be faster than nearly any simmilar C or C++ app. Why? Because the Vm can over time learn how the codepath actually is executing and optimize it at the assembly level. The only way you could consistantly achive performance as good would be to hand-code the whole app in assembly, and thati s assuming you already know in advance exactly how the program will be used so you know what paths to optimize.

I've already debunked this particular fallacy elsewhere in this thread. I don't know when the popular spin on Java's JIT technology went from "it could theoretically catch up with C++" (true, to a reasonable degree) to "it should theoretically go faster than C++" (not true, to a reasonable degree) but I wish those claiming the latter would go back and think about it for a minute. You can fairly easily see the flaws in the latter, even without knowing exactly how HotSpot works (and therefore that a lot of the claims made about its effects by enthusiasts in this thread are simply wrong, even in theory).

string handling

[Spazmania]

I can't speak for anyone else, but the thing I don't like about Java is that the string handling sucks ass. There are how many different types of strings that you have to convert back and forth between in order to do something simple like accepting text from a network socket, altering it, and presenting it on the screen? At least three major type conversions that come to mind as the minimum-path.

Re:string handling

[rmjiv]

The reason that Java IO is complex, is because IO in general is complex, especially character IO. You're trying to read text from a network socket: What character set is that text in? UTF-8? ISO-8859-1? How about something more unusual like ISO-8859-5 (Cyrillic) or EBCDIC?

My point is that Java doesn't assume that your IO needs will fit neatly into ASCII. Java can best be thought of as a language who's motto is "Safety First."

Re:string handling

[Spazmania]

You say, "Java doesn't assume that your IO needs will fit neatly into ASCII." I say, "Java does a clumsy job of handling IO needs which do fit neatly into ASCII."

It wouldn't be so bad if I only had to convert text to a string type once, but Java has multiple types for handling text strings depending on what operation you want to perform on the text and Java's strong typing means that each string type is incompatible with the others.

No offense to the authors, but you guys need to figure out how to do a string and then deprecate all the rest. The whole eclectic thing Perl has going on only works with a loosely typed language.

MOD Parent funny

[Fr05t]

It's a joke - laugh :P

Strongly typed...

[Yrd]

...Java's strong typing isn't a problem because it's strong typing. C++ does strong typing rather nicely. Haskell does it even better. Java's libraries, because they don't have anything like templates (at least until Java 5), require huge amounts of casting and instanceof checks to pull anything out of a container. That's when static typing gets in the way instead of being helpful.

I'm quite a fan of static typing, really (honestly), but not the way it works in Java. Of course, I hate lots of other things about Java too, but it's not because it's 'un-cool', it's because it's crap. Even if nobody used it, it still wouldn't be cool (I'd have a party though).

And although it pains me to say it of a Microsoft product, I hope C# takes over from Java, because although it's not perfect (no language is, or can be), it's for the most part what you might call 'Java done right'.

Can I ask a question?

[Rik Sweeney]

Why do you think Java is slow? What was the version that was slow?

Maybe it's because...

[blackmonday]

Maybe it's because a whole lot of us are too busy working on multi-million dollar financial projects to stop and tell you how cool it is? Java is all about the server side, so if we're not coding desktop apps, its because there's more appropriate software out there for that. That doesn't make Java uncool - there's a lot to be said about enterprise Java. Whether it's cool or not, it works.

By the way, I frequently use a very cool Java desktop app - It's an Amp/Effect editor from Line 6 that controls their Guitar and Bass Amps - It's all Java, looks and runs fantastic. Check it out if you have a Podxt.

Re:Maybe it's because...

[kisrael]

- there's a lot to be said about enterprise Java. Whether it's cool or not, it works.

Not when your "enterprise Java" is EJBs. IMHO. YMMV.

Re:Maybe it's because...

[SillyCON]

I disagree. PHP and ASP for instance are also server-side, and there is nothing Java can do PHP and ASP doesnt, faster and lighter. I used to code financial statistics routines in java that carve deeply into our database for a multi-million internation enterprise . Even with precalculated tables we have to stop public access to let the dual-procesor multi-gigabyte Sun big-iron not die of exhaustion. Today I code in php and run like such painstaking routines over a 2Ghz/512Mb Debian PC and the only care is for disabling the 30-second timeout.

Re:Maybe it's because...

[eddison_carter]

Only multi-million dollar projects? Bah :)
Look to C, Assembly, and (but deceasingly) Ada for the multi-billion dollar projects ....

Re:Maybe it's because...

[Beryllium Sphere(tm)]

>(but deceasingly) Ada

Best. Typo. Ever.

Re:who cares what he says?

[vbweenie]

Um...you've heard of Viaweb, have you?

Re:who cares what he says?

[SparafucileMan]

That's bullshit. Didn't Graham start and run his own software company? Didn't he write production-grade code that handled thousands (or hundreds, at least) of users simultaneously? Didn't he make millions doing it? And what language did he use?

That's right, he used LISP.

Strongly typed - Good or Bad?

[lachlan76]

Is having strict typing always what you want? I don't know Java very well, but is there a template-like functionality in it? In C++ for instance, if I want to make a linked list, I have three choices:

• Use a single data type for EVERY list (int, char*, struct DATA*, etc.)
• Use templates to choose the list type for every list created
• Pass a void* as data

Restricting programmers to choosing all variable types during coding is restrictive, and takes away some of the advantages of a heavily object-oriented language, like doing this (Maybe Java can do this, but I haven't learnt how yet)

class A
{
virtual void dostuff() { printf("A::dostuff()\n"); }
}

class B : public A
{
virtual void dostuff() { printf("B::dostuff()\n"); }
}

int main()
{
A* a = new B;
B* b = new B;
void* c = (void*)new B;

a.dostuff();
b.dostuff();
(B*)c.dostuff();

return 0;
}

And still call the same function every time.

Now I haven't been using Java long (started about 2 days ago) and haven't come across pointers yet. Are they in the language?

Re:Strongly typed - Good or Bad?

[SillyCON]

No, they arent. Java is designed to avoid you making mistakes out of mispointing and misreferencing. There is no void type. Every variable or instance has its type, and even simplest, best-studied silly method is a painstaking type casting forth-and-go.

Re:Strongly typed - Good or Bad?

[brunes69]

Disregarding the about 35 syntax errors in your example, if it is doing what I think it is doing ( and because of the errors I cannot be exactly sure what you mean), this is no different from using the Object superclass in Java.

Object inJava is like void* in C/C++. Every class inherits from Object so you can cast to and from it when you need to pass around generic pointers.

The Java version of what i think you meant:

public class A
{
public void doStuff()
{
System.out.println("A::doStuff()");
}
}

public class B extends A
{
public void doStuff()
{
System.out.println("B::doStuff()");
}
}

public static void main( String[] args )
{
A a = new A();
B b = new B();
Object c = (Object)new B();

a.doStuff();
b.doStuff();
((B)c).doStuff();
}

Re:Strongly typed - Good or Bad?

[lachlan76]

#include <stdio.h>

class A
{
public:
virtual void dostuff() { printf("A::dostuff()\n"); }
};

class B : public A
{
public:
virtual void dostuff() { printf("B::dostuff()\n"); }
};

int main()
{
A* a = new B;
B* b = new B;
void* c = (void*)new B;

a->dostuff();
b->dostuff();
((B*)c)->dos tu ff();

return 0;
}

Was what I meant, and the output should be

B::dostuff()
B::dostuff()
B::dostuff()

But yeah, what you thought I meant was what I meant.

After reading it myself, and counting the errors, I have decided what I should do with my life:
It's time to get some sleep.

Re:Strongly typed - Good or Bad?

[Prior Restraint]

Object c = (Object)new B();

Just so you know, this cast isn't strictly necessary, since B "is-a" Object already.

Java is the only language I know of that can

[sir lox elroy]

bring a system to it's knees just by invoking the interpretor.

First Impressions, then second

[Ozwald]

First impressions for java weren't all that good. Back in the early days it wasn't just slow, it was painful. We'd ask "why does VB have a user interface that's so much quicker?" I still don't know. We also asked why every interface looked different. Java never did successful wrap the APIs provided by the OS and there's no reason not to.

By the time of the second impressions, Sun and Java zealots started to become annoying, promising silly things like it was faster than native code. Maybe in some cases it is, but certainly not where it counts: the GUI.

Oz

Re:Maybe because it's slow ?

[bwt]

Compared to what?

Java is faster than perl, python, ruby, and PHP. If you want speed, use C or C++. Enjoy debugging the pointers and memory leaks (that is the "slow" part I care about more).

Java *is* un-cool

[glenmarshall]

One reason Java is un-cool is that it is just another proprietary technology, owned by Sun. If Sun goes away, as it very well may, the Java code-base is at risk. And that would be very un-cool. Linux and Open Source development are cool. Geeks tend to like consensus-based technology that doesn't have a heavy intellectual property burden. Ultimately, Java is un-cool for the same reason that Windows is un-cool.

Go write me an OS in Java

[NitsujTPU]

...and then I'll tell you it can join the club of "cool" languages.

Re:Go write me an OS in Java

[LnxAddct]

Here. I guess java is a cool language after all. BTW, the OS I just linked to is pure java with a little assembly stub that loads just enough to get a JVM running, from that paoint on its pure java. I love java, I also like C++, but I have yet to find a language that is comparable to java. If for nothing else, it is indispensable because of its amazing APIs, ease of use, amazing IDEs, speed (with the 1.5 VM from Sun, you can only achieve similar performance hand coding the app in assembly - look into hotspot, its on the fly optimizations at the lowest level), portability, and deployability (google for WebStart). Any real programmer understands the value of Java, we are just too busy being productive to convince the /. groupthink otherwise.
Regards,
Steve

Re:Go write me an OS in Java

[IamTheRealMike]

An OS written in Java is the coolest thing, mostly because being safe you can do away with things like processes and IPC - huge swathes of infrastructure can be removed because there's no way a Java class can randomly puke over memory used by another app. Therefore, all you need are threads: the performance cost of switching address spaces, communicating using IPC and so on all just disappears.

It gets cooler. You can have very flexible and fine grained security - the Java type system has been mathematically proven sound, meaning that there's no way to subvert it (short of waiting for cosmic rays to flip bits, hah). That means you can limit the relationships between classes very easily: sorta like SELinux except more fine grained.

Basically an OS written entirely in a safe, managed language would be an awesome thing, the only problem being that it'll never happen as the huge quantities of code needed to make a good OS is all written in C! You could port it, but that'd be a lot of effort that isn't worth the gain.

That doesn't make the concept uncool though. A pure Java OS done right would be very cool indeed.

Re:Go write me an OS in Java

[nsayer]

Very interesting.

This is going to descend into off-topic-ancy a bit, but I would think that deep in the guts of a Java OS there would have to be some JNI as well to handle things like DMA for devices. I mean, the average USB device driver can be pure Java, but the driver for the USB host controller probably is going to need to at least be able to wire down a DMA buffer, get its address, stuff that into a device register, and wait for an interrupt. The drivers themselves can be written to use abstractions of concepts like DMA buffers or interrupt scheduling, but the abstractions will probably need to touch the hardware...

Re:Go write me an OS in Java

[MobyTurbo]

That doesn't sound as impossible as one would think. People made OSs out of LISP for LISP machines, after all; and made large parts of OSs out of Smalltalk at PARC.

Java's problem is Sun's mismanagement

[Master Of Ninja]

The problem with Java is that Sun really has managed it properly. We all thought it was cool when it came out, but the promises really weren't true. Write Once Run Anywhere mostly managed to work on different platforms, but the GUI is so god awful slow nobody really wants to bother. Its just easier to code native. I'm not exagerating here that even Visual Basic programmers could have come up with something better.

Sun has let the technology stagnate while Microsoft has caught up (and IMHO surpassed) Java with their .Net products. Hate MS all you want but .Net actually is really easy to use.

Plus I don't know what's going on at Sun marketing, but they've descended Java into acronym hell. Plus the naming conventions don't really make sense now. The new version of Java is J2SE5 (I'm not even sure that it is this now).

I'm taking this from the perspective of desktop developers (rather than the server side as they seem to use Java fine). Java really does blow, and there are now better technologies to use. Sun has even ignored integrating other, better technologies (*cough* SWT) due to NIH syndrome.

If Sun went and fixed their mistakes rapidly (a bit late IMHO) then Java could still be cool. But everyone on the desktop who's used it considers it a steaming POS.

Re:Java's problem is Sun's mismanagement

[RadioheadKid]

Definitely mismanaged. Sun should have let Java grow from the ground up in the late 90s instead of over-marketing it. Judging by the comments here, server side implementations written in Java seem to work well. In the late 90s Sun would have had you believe that every microprocessor from your microwave to your cable box to your car was going to run Java. At the time the only user experience with Java was on their Pentium 233Mhz processor and a slow internet connection. That makes a bad impression. Furthermore, who the hell decided to name JavaScript, JavaScript. That just confused matters more.

Re:Java's problem is Sun's mismanagement

[wilder_card]

Another big example of mismanagement is that the Sun implementation is so godawful. Java the language isn't too bad (until you compare it to Python). But the Sun compilers are buggy and slow, and the virtual machine uses so many resources it can bring a good server to its knees.

I've seen it stated that adding new features to Java has been given a higher priority than fixing existing bugs. The result is a huge collection of libraries, none of which can be relied on to do what the documentation says they will.

Re:Java's problem is Sun's mismanagement

[Warpedcow]

But everyone on the desktop who's used it considers it a steaming POS.

I respectfully disagree. I've used Java on the desktop and developed Java apps on the desktop, and I think Java quite remarkable. Written properly, it's just as fast as C++/.Net and I personally don't think that it's ugly in any way either. Also, cross-platform capability is a Godsend, and it DOES work if you're not an idiot about it.

Just my 2 cents.

Re:Java's problem is Sun's mismanagement

[Master Of Ninja]

Point taken that there may be some good uses for desktop Java, but there's this "lagginess" that just doesn't feel right. And this is not just for 'big' applications, but for small (trivial) ones as well. I don't even think I could name 10 (IMHO) "good" java desktop applications (including the SWT ones).

The cross platform stuff really is a great plus for Java, but with Mono out even I'm off to hedge my bets. I take your point about writing Java GUI apps properly, but this could be the other problem. Is Swing "broken", or is working with Swing inherently too complicated for most programmers? Either way GUI apps seem to be not quite right on Java. Sun should either fix Swing or make it easier to program. I've seen other people commenting that Java was to be VB but better. VB was good for making GUI apps (whatever sort of kludge it was though). Java is nowhere near as good, and this is a fundamental problem that Sun needs to solve ASAP.

Re:Java's problem is Sun's mismanagement

[kaffiene]

I've been coding in C# for about 6 months and I can assure you it's not a patch on Java for ease of development. There are a lot of issues, but the biggest is the APIs. Java's best feature is that a hell of a lot of work has been done in creating broad, powerful, well tested and portable APIs. .NET is a shadow by comparison.

Re:Java's problem is Sun's mismanagement

[anomalous cohort]

but the GUI is so god awful slow nobody really wants to bother

What GUI are you talking about?

Hate MS all you want but .Net actually is really easy to use.

I'm not sure what you mean by ".Net is easy to use." Are you saying that it is easier for algorithms to be expressed using C# and VB.Net than they are when using Java? There are, IMHO, marginal language improvements (such as properties and operator overloading) but hardly enough to say .Net is easier.

I don't know why everyone thinks SWT is cool. I don't find it to be all that good myself.

Too much OO

[Anonymous Coward]

I wouldnt say that any of those reasons is why I dont like Java. My reason is the enforced OO that has a tendancy to drive me up the wall. The fact that everything must be an object and used properly. Is irritating if you are trying to do a smaller program that doesnt need the OO.

Re:Too much OO

[JavaLord]

I wouldnt say that any of those reasons is why I dont like Java. My reason is the enforced OO that has a tendancy to drive me up the wall. The fact that everything must be an object and used properly. Is irritating if you are trying to do a smaller program that doesnt need the OO.

Java is an OO language. I think that is one of the reasons it's seen as "uncool" by the script kiddie crowd, it's too complicated for them so they stick to their procedural roots. It's easier to say "OMG WTF HARAR JAVA IZ SLOW" then to actually learn to code a differnet way.

Writing small programs in Java where you don't need much OO isn't hard, I just wrote a program the other day that read in a comma delimited flat file, manipulated the data and then pushed the data into oracle. I didn't need to abstract anything or go into any heavy OOP to do that, or even write any new classes. People just have these myths based on 1995 Java about what Java can and can't do in 2004.

Re:Too much OO

[fazzumar]

Too much OO? What kind of drugs are you on? There is no such thing.
Check out Squeak if you think OO or lack of it counts for geek points in a programming language.
OO isn't about what you need or not, it's just a different way of thinking.
Most clean procedural code I've seen looked incredibly similar to OO code.
But, then again, the things I don't like about Java (strong, statically bound types, statics, primitive types...) are probably things that procedural developers like about the language

resentment

[SuperBanana]

I know one reason I considered Java uncool was because people who claimed to know it were earning twice as much as me- a "lowly" sysadmin.

They never got calls after midnight, never once had to deal with "this needs to be done in the next 5 minutes", and it was the exception, not the rule, for them to do anything other than get told what to work on- and rarely more than one thing at a time.

Furthermore, while I actually had to demonstrate proven skills to be hired- they had to show up for the interview and have a pulse. Without naming names, let's say that 99% of them were on visas. They had atrocious English skills and/or horrible accents, so understanding them enough to support them was a pain. Rudimentary computer skills (for a programmer, there's little excuse) so they required lots of support. Lastly, they also tended to form their own clique and resisted multiple attempts by other staff to get friendly etc- pretty much ignoring the two or three programmers who were not from their country.

I once caught one of the new hires printing out a 600 page "learning Java" PDF well after closing hour- he didn't expect (foolish man) someone from IT to be around at 7pm. I hand-delivered it to his desk and told him that he had come within a millimeter of his boss finding out he was printing rudimentary books he shouldn't need. I was completely disgusted.

Wasn't as bad as the consultants who were paid $120 an hour for specialized development- and didn't know how to use Sun's desktop environment. Every time I walked into their room I found them playing solitaire, checking their stock portfolios- in one case, a guy was playing Quake (he was summarily fired within days).

Re:resentment

[JavaPriest]

I surely believe what you are telling, but in what way is Java responsible for that? Your companies uncool recruiters are to blame here.

Re:promise

[noselasd]

That's not the real problem. Java is portable, and backwards compatible.
The real issue with portability is you need.. a virtual machine for
your platform. Sun ships it for windows,linux and solaris. I'm sure
even most C programs written for *nix are far more portable than that

Why is Java considered un-cool?

[hype7]

Maybe because you need to post to /. to find out?

-- james

Java simply falls behind on startup

[Kainaw]

In my experience with Java, it simply falls behind on startup. It takes far too long to load the interpreter, load the byte code, and get going. What Java needs to compete is a true compiler. I need to be able to take a program, compile it for the OS that I choose, and make a lean and mean native executable.

The Java zealots panic. That would destroy the cross-platform ability of Java. Wrong. It would destroy the cross-platform ability of that one executable - simply meaning that I can give the slower byte code to all the other platforms that I don't want to compile an executable for.

Others will quickly point out that there are programs that compile Java to native executables. That is true, but I said I wanted a lean and mean native executable. Because of Sun's licensing, it is not legal to make a native executable that only contains the parts of the Java that are needed to get the program running. You must include EVERYTHING in the native executable - meaning it is required by law to bloated and slow.

So, after all of that, I realize what the problem is. Sun needs to fire a few lawyers so we can legally compile our slow and bloated byte code into lean and mean native executables.

Re:Java simply falls behind on startup

[Kainaw]

I normally make it a rule to never, ever, reply to an Anonymous Coward, but this just makes the reason for that rule so obvious...

The following is a quote from my post:
Others will quickly point out that there are programs that compile Java to native executables. That is true, but I said I wanted a lean and mean native executable. Because of Sun's licensing, it is not legal to make a native executable that only contains the parts of the Java that are needed to get the program running. You must include EVERYTHING in the native executable - meaning it is required by law to bloated and slow.

Then, the Anonymous Coward responds with:
Hey, just in case you haven't noticed they have native compilers for Java. Ooooooh, for more than 3 or 4 years.

Getting out a fresh post-it... 'Never Ever Reply To An Anonymous Coward'

don't hate me because I'm beautiful....

[kpharmer]

yuck, the reasons given in the article are all just back-handed compliments. Like being asked by a job interviewer what's your biggest weakness, and saying that you work too hard and care too much!

How about something like - programmers want a language, not a lifestyle: and java's ambition to do *everything* is more than just about anyone wants.

How about the 'not invented here' syndrome? EJBs? Container-Managed Persistence? Ever try to get some other application to talk to a database where they used container-managed persistence? You're out of luck. And before you say go through the Java app - you need to understand running *major* analytics on a large database will do to java - like imaging marshalling 500 million objects...

At a java systems integrated during the dot-bomb I performed some productivity analysis, and discovered that it look us just as long to create a webpage using java in 2001 as it did to create a stateless page using cics on mainframes in 1989. Of course, this is partially due to the fact that we had one person creating the entire page in cics, but required separate html, jsp, & ejb people with java due to its specialization.

"cool" isn't the point... bug free code is.

[Baldrson]

The reason serious programmers -- the kind who have programmed in Java for enterprise critical mission projects -- hate Java isn't because it isn't "cool".

They hate it because to produce bug-free code in it requires far more time and money. The reason is pretty simple actually:

Lines of code, or more accurately, the size of the bz2 file of the source code stripped of comments.

A serious programmer tries to minimize the amount of junk in their program for the same reason a serious scientist tries to minimize the amount of junk in his theories: The more you junk you have hanging around the more difficult it is to analyze it and really get it right.

Java is just a bad language for that.

Re:"cool" isn't the point... bug free code is.

[smack.addict]

They hate it because to produce bug-free code in it requires far more time and money.

Than what?

I have been programming for quite some time in many different languages. Next to Python, Java produces the most bug free code. In general, if it compiles in Java, you are much closer to bug free code than you are in other compiled languages. Once it has generics, it will be even closer (about 80%-85% of my runtime bugs are ClassCastExceptions from collections).

Re:"cool" isn't the point... bug free code is.

[michaelggreer]

Could you be more specific? Your argument is very vague. "Lines of code" surely does not directly translate into "number of bugs." That's just silly.

Re:"cool" isn't the point... bug free code is.

[michaelggreer]

Well, inside a single language that may be true. Between languages, I think it is a meaningless measure. Languages have different densities. Java, for instance, is intended to be sparse for legibility. And legibility does lead to fewer bugs.

I do stupid things all of the time in Java, but usually they are pretty easy to find because it is highly readable. So, in the case of Java, the inverse of your measure could be true.

Re:"cool" isn't the point... bug free code is.

[Baldrson]

Take the code that is specific to your app, strip the comments and compress it with bzip2 to factor out the sparseness.

What you will find is that, "denseness" aside, the sheer complexity of your Java app will be 5 times that of a comparable dynamically typed language app such as Perl, Python or even Javascript.

Java creates what Ockham called "multiplying entities beyond necessity" and what everyone trying to make things comprehensible avoids.

Re:"cool" isn't the point... bug free code is.

[michaelggreer]

Well, but you are still not making your point: what is your proof that it is more complex? There are actually tools for testing code complexity, and they would give the answer. You may be right, but lines of code (or size of bzipped file) is not proof. You are just stating over and over it must be true. Code density is not easily compressed out. Perl, for instance, can be very dense, but quite obscure. Java forces explicit coding practices (sometimes quite annoyingly) like catching all exceptions. Its not just whitespaces.

It's "Occam", by the way.

Not close enough to the machine

[MarkPNeyer]

I don't know about anyone else here, but I find that I have to think about what the machine is doing while I program. With Java it seems all neat and tidy and squared away and abstracted. I learned C++ first, and so I like to think about what's going on in the memory locations while I'm programming. With java, that seems to disspear. It's almost like programming with pseudo-code.

Oh double negative, why do you haunt me!!!

[pottymouth]

"And of all the great programmers I can think of who don't work for Sun, on Java, I know of zero"

Why do I get the feeling I wouldn't want to debug this guys code??

Re:Oh double negative, why do you haunt me!!!

[SwankDude]

sure, but I'll bet his code would be COOL!

Re:Oh double negative, why do you haunt me!!!

[SilentStrike]

"Why do I get the feeling I wouldn't want to debug this guys code??"

Beacuse it's written in lisp.

-1 flamebait ;)

Re:lame

[elchuppa]

o Java GUI is slower than native alternatives

Have you tried IDEA? You might be surprised by how well a JAVA GUI app can perform.

o Java is not supported by all platforms, and is not supported by WinXP by default.

Aye? Java is supported by just about every platform I can think of. As to WinXP, the fact that it doesn't come with a JRE is hardly a knock IMO. WinXP doesn't come with a lot of things.

o All the Java "binaries" I've tried relies on me having installed a local interpreter.

Yes, they're not actual binaries, it's called byte code. The whole portability thing...

o It's object oriented

well you are entitled to your opinion. But you should be weary of being nostalgic for less effective technology. I honestly can't imagine writing enterprise software procedurally. OO is way cool man. I've been kind of surprised by all the negative opinion of Java here. I was a C++ programmer up until a year or so ago at which point I got a job in the Java world. I was honestly not excited about it when I started but as time has passed I have become more and more impressed with the language. I suspect that most of the nay sayers probably just don't have that much experience with it. Also Java is more than just a language. The massive framework of open source code around it makes it an incredibly rich environment. From a software engineers point of view, I would venture that Java is probably the most interesting and capable language/community out there (I'm thinking of things like Ant, Maven, Junit, ORM techs like Hibernate and OJB, J2EE, etc) Of course I have just about no experience with .NET so I can't really speak authoratively on the matter.

Maybe because it's true

[0123456]

Every Java program I've run sucks up tons of memory and runs dog-slow. Now, I'm sure there are plenty of programs where people spend most of the time interacting with the user interface so raw performance doesn't matter and ease of programming is more important, but for general use, Java is a poor choice of language.

Re:Maybe because it's true

[EmperorKagato]

I used to say the same thing whenever I ran Azureus: A Java bittorrent client. Now, I am amazed by the new release. Azureus takes up less processing time and no longer memory leaks. Like all other languages Java has the potential to be optimized.

Re:Maybe because it's true

[StillNeedMoreCoffee]

I would think you are using an old version of Java. The newer versions 1.4 and above have much improved runtime performance. It is possible that the style you use creates and destroys a lot of objects and this is always a slow process. Just like in C++ is you are doing a lot of object creation and distruction. The fact that you are sucking up a lot of memory might suggest that as well. I have a lot of applictions that smoke.

You can use strategies like object caching and re-use of objects and singletons where appropriate to improve performance. Like any language once you undestand the costs of various operations you can program better. I remember when floating point mulitplies and divides were so expensive and done mostly in software and we had to program around that and compilers made optimizations for that face replacing floating point operations with interger operations behind the scenes. It is a continuous battle to find the proper path in any forrest.

Re:Maybe because it's true

[packrat0x]

Have you tried BitComet ?

Re:Maybe because it's true

[EmperorKagato]

I feel very comfortable with Azureus. Seeing how the main window looks in BitComet. It seems to be a bit too much in one interface for me. One day I will give it a try.

Re:Maybe because it's slow ?

[CurMo]

Java really isn't -that- slow. That's a common misconception.

Everyone thinks "Java is slow" because the only time they experience Java is in a Swing app. Swing is VERY bloated and therefore very slow. The only other "slow" processes in Java are Garbage Collection, which is pretty minimal if the app is written correctly, and the initial startup of the VM.

Look, for example, at Eclipse IDE. Eclipse is a Java app, and its extremely powerful and not very slow. Why? They use their own widgets that have less overhead, they are not using Swing widgets.

Also, a correctly written OpenGL java app has been proven to perform at 85% the speed of its C counterpart (yes C, not C++). A couple of guys (I can't find the link) ported QuakeII to java to get this statistic. Not bad considering the relative youth of OpenGL bindings in Java.

I once had a "Java Sucks" attitude myself (I've been a hardcore C++ programmer for over 9 years), but I must say, after using the language for quite some time (~2 years), I've become very fond of it, and have written several large & FAST Java apps -- in about 70% of the time it would have taken to write in C++.

This is mostly babble.

[theonomist]

First, I've read Graham's essay, and his definition of "Great Hacker" is on the vague side, and consists largely of platform advocacy. It turns out that his "great hackers" are all people he knows. Fair enough: He can't really judge anybody else. But that leaves him with such a small and selective set of data that his conclusions are meaningless. For example: He claims that all "great hackers" refuse to work on Windows. He works at companies developing software for UN*X. Not surprisingly, most of the programmers he knows are UN*X people, who don't work on Windows. So what? This proves nothing at all. He has merely suggested (however plausibly) that Windows developers tend not to develop for UN*X and vice versa, which is tautological. Dennis M. Ritchie has a Windows box on his desk these days, but Graham doesn't know Ritchie personally, so Ritchie's not considered. Graham's working from a thin set of anecdotes.

Secondly (and this has been said before), Graham's "great hackers" are prima donnas who refuse to deal with practical problems outside some very limited set of problems that they enjoy. I remember a story about Richard Feynman helping paint the walls at Thinking Machines when he worked there; I guess Feynman wasn't a "great hacker".

Finally, I often hear from Java advocates that the memory-lebensraum problem and the speed problem are due to programmers not understanding the internals well enough to work around their flaws. This is not said to be true of any other programming language on Earth, as far as I know.

It all sounds like a crock to me. Knowing the tools better will always help, but if only an expert can write usable code -- not great, but merely usable -- the language is junk, or at best the implementation is junk.

Re:This is mostly babble.

[sdcharle]

Finally, I often hear from Java advocates that the memory-lebensraum problem and the speed problem are due to programmers not understanding the internals well enough to work around their flaws. This is not said to be true of any other programming language on Earth, as far as I know.

True, and in the article a similar excuse is used for Swing's Lameitude:

Swing disasters continue to give Java a bad name. Swing is a brilliant, although hard to learn, API. But the vast majority of Swing applications are so bad that they give Swing and therefore Java a bad name.

So...it's a language for the 'average programmer' (also from the article), but 'average programmers' are making it look bad? Er, OK.

In conclusion, the article is worse than Graham's, but took less time to read anyway.

Re:This is mostly babble.

[buzzcutbuddha]

You say you did RTFA, but your recollection seems a bit spotty. The majority of his article did not revolve around advocating *nix over Windows, but instead talking about the qualities that attract good hackers as opposed to those that deter them.

So he discussed the atmosphere and furniture of the office, the attitudes of management, the tools they would use (including the OS), and centrally the programming languages used by great hackers.

He never said that they don't want to deal with practical problems. He said that they don't deal well when not challenged. And let's be honest here, is it a good thing to take someone who's a wizard at development and ask them to maintain code? That seems like a horrible waste of productivity. At many companies though, you see it happen that someone codes something approaching brilliance, and then his managers want to farm him out and have him spend time fixing bugs, maintaining the code, writing documentation. That's not challenging enough.

Graham even made the point that one company he worked at had MIT trained hacker Robert Morris as their network admin. To point to Feynman and imply what Paul Graham's opinion of him would be is a strawman argument. Let's keep the logical fallicies to ourselves, and keep our gloves above the belt.

I think you need to go back and RTF Paul Graham A again before you continue to malign it here.

Re:This is mostly babble.

[bugbear]

if only an expert can write usable code -- not great, but merely usable -- the language is junk

Is that really true? In many fields there are tools that only experts can use properly. Why should it be different in programming? I think Michael Vanier makes a good point about LFSPs.

Re:This is mostly babble.

[AaronStJ]

Err, off tpic, but whats the memory-lebensraum problem?

Re:Maybe because it's slow ?

[stevey]

This is part of the problem of discussing Java.

Which Java?

Java the language? Jave the runtime? Jave the virtual machine? Jave the class libraries?

It seems like Sun haven't made this any easier for us to understand, in much the same way that Microsoft is rebranding everything as 'dotNet' a couple of years ago.

Java the language I like, although I think it's only become something I'd like to use in the most recent releases.

Java the runtime class libraries are very very very comprehensive, and usable in a verbose manner - but the write-once-run-anywhere? I'm less and less convinced of this as time goes on.

Re:Maybe because it's slow ?

[molarmass192]

People seem to be able to install Flash without too much trouble. Just send the use to a java applet that does something kindergarten-ish like write "Congratulations, you've just installed Java!" and it becomes the same auto-download and install process as getting Flash done.

Re:promise

[proj_2501]

Java is completely unrelated to JavaScript, JScript, and ECMAScript. JBoss is not a separate language; it's an application environment written in Java.

Re:who cares what he says?

[alex_tibbles]

never built a real world system?

Re:who cares what he says?

[originalsyn]

Unfortunately, your assumption is completely false. Paul Graham has been wildly successful in the corporate arena. For just one example, he's responsible for the software behind yahoo shopping's dynamic web stores (which was written in Lisp). While I don't agree with the man on a lot of things, his track record lends him quite a bit of credibility.

Re:Maybe because it's slow ?

[Xugumad]

Actually, it's not that comparable. Method calling time is much much lower, which is where the stats claiming it's as fast/faster than C++ came from, but that's about it. For example, by the Fibonacci benchmark that was used. for which their results claimed similar times in C++ and Java - I managed to get an approx. 3000 time speed increase for the C++ version be making it non-recursive.

Having said that, for enterprise applications, better/faster hardware is frequently an option. For in-house applications, better hardware may even be drastically cheaper, compared to developer time. This is certainly the case for Java applications I work on - my time is expensive, and a $1500 server doesn't ever noticably slow down while running our application.

Re:Maybe because it's slow ?

[deadlinegrunt]

"...use C or C++. Enjoy debugging the pointers and memory leaks (that is the "slow" part I care about more)"

In the hands of a skilled C++, as well a C, developer these things are actually not the issue you made them out to be.

The better advantage here is the Java platforms ability to be dynamic at runtime without jumping through hoops as you need to with the more static nature of C or C++*.

* In relation to Java has a uniform platform to support this since it is its own platform. C and C++ have to implement them on their own based on the Arch/OS being used.

Perhaps hackers like hacking?

[mwvdlee]

And hacking requires low-level access to the system which Java simply does not offer.
Yes you can add low-level functionality to Java, but you're not programming THAT in Java now are you.
I am a full-time Java developer and for all the goodness it brings there is also the lack of a decent referencing system to allow ingenious algorithms, good GUI mechanisms (Eclipse does a decent job to proof a Java GUI can work but is still no match for a native application) and, for instance, a standard and well-performing OpenGL API. There are many other things missing but most of it just boils down to the fact that it cannot access OS-specifics when needed.

Re:Maybe because it's slow ?

[nkh]

Java is not more secure than Ruby or Python. They all check the access to arrays, are object oriented, have exceptions support and a cool standard library. The only advantage for Java is that its standard library is bigger than the other languages.

Debunked? I think not.

[Masker]

How is this even considered an article? This looks more like a laundry list of complaints that some Java programmer (I use the term loosely) has heard over the years with some non sequiturs thrown in. He doesn't do any in-depth analysis of the few points that he does bring up, and doesn't mention any real criticisms of the Java language (e.g. much promised but little delivered garbage collection).

Let's look a few of the points he chose to include in his "analysis":

Java is popular. Anything popular isn't "cool".: What? First, prove that Java is popular. Second, how do you explain the iPod's coolness despite being wildly popular?

Java has a vast library that is available to all Java developers: (he means that you shouldn't re-invent the wheel, which makes it "less cool") Well, for most programmers comfortable with OO programming (including Linux kernel hackers; remember that the VM and VFS subsystems are OO design implemented in C), having a large toolset is a god-send, not something that's "uncool". In fact, most C++ programmers that I know think generic programming, which is pretty well enabled by the implementation of the STL, is pretty damned cool, in that it gives you a lot of high-performance power and reusable code for little-to-no work.

Java is an application programming platform (and therefore you can't do device drivers, etc.) Actually, who says that application programming isn't cool? Forms programming isn't very cool, but saying "applications programming" covers such a broad range of tasks that it's almost impossible to say it's any one thing with a straight face. I've done some incredibly cool applications programming in Objective C, and some really tedious applications programming in C. The language didn't change anything about the "excitement" of the task; it was all about the problem we were solving.

I don't like Java because I think it's a broken implementation of a decent idea. I prefer ObjC's object model and dynamism, C++'s operator overloading & template features and C's simplicity for the large majority of the programming tasks I perform, and Perl (a necessary evil) for anything that is small & quick enough that I need to do it on the command line. Java is a heavy duty programming language that's missing features like operator overloading and broken or brain-dead features like its garbage collection (how can you enforce memory reclaimation? Oh, you can't in Java. Hrm. Take a look at Cocoa's reference counting memory allocation/reclaimation system, or C++'s ctor/dtor paradigm for an example of how to do this correctly).

That's why it's not "cool", IMO: because it is inferior.

Re:Maybe because it's slow ?

[Florian Weimer]

A program made in Java without an eye to security is going to be more secure than a program made in C without an eye to security.

I wouldn't count on that. The classes of vulnerabilities that affect typical C and Java programs are just different. Of course, buffer overflows aren't a problem for typical Java programs. On the other hand, lack of synchronization is not such a big problem in the C world.

For example, if you write a web application in C, it's quite unlikely that it exposes data from a different session if you hit the browser's back button. With Java, such problems do occur (because the same servlet object is used in different sessions and some programmers use it to store session-specific data).

Re:Maybe because it's slow ?

[Anonymous Coward]

This is absolutely true, there is no perfect platform/language/OS/tool/etc. for everything. Java makes developing large applications very easy and small applications more difficult. It makes creating portable code easy, it makes creating incredibly efficient code more difficult. When you're in a large network and need (for example) a web-based accounting system where you might have 30 different types of computers on multiple operating systems and hundreds of people working with the system at a time, Java is wonderful. When you're tasked with creating a (again, for example) inter-office messaging system where every computer needs a client, and some of these computers are desperatly in need of upgrades, you might look at Java but should probably use something else. If you need to make something quick to do a one-time task, you'd be insane to be thinking about using Java.

Re:promise

[tolan-b]

-1 ignorant

You have no idea do you?

Java - Yes, this is Java

ECMA Script - This has nothing to do with Java. It's a scripting language, it doesn't even have the same syntax.

Javascript - a name for ECMA Script

Jscript - Microsofts implementation of ECMA Script

Jboss - An application container...

I'm running FreeMind (a Java mind mapping tool) on Windows and Linux, with the same binaries. My colleague is running it on OSX, the same binaries... How is it not portable?

So can you make xcalc run on your HP calculator?

Idiot.

Re:Maybe because it's slow ?

[banzai51]

You may not like to hear it, but it is still TRUE. It's a problem that has to be addressed. You can't take the Microsoft tact and hope hardware speeds up enough so the difference is too small to matter. Full programs written in Java simply suck. They're slow, don't follow any native UI guidelines, and are a thorough pain in the ass to use.

If a company brings their product in and it is written in Java, they are demoted and booted if any of their competitors have a remotely close app. I hope SUN sits up and takes notice of that last bit. People using your little system are losing money.

Re:lame :)

[forgotten_my_nick]

Your refering to SWT making JNI calls to the native GUI API calls. SWT framework also allows it to be portable.

However eclipse itself is built on java and isn't slow.

Only slowness I have seen in java is in applets in browsers or coded to the MS JVM.

Java Started with 1.4

[DeckerEgo]

Versions of Java prior to 1.2 were more sluggish than steering a dump truck. And yes, GUIs prior to the native look-and-feel implementation in 1.4 could be icky. But we're in a post Java 1.4 world, and it's looking much better.

First, an initial startup of a JVM does take up a larger memory footprint. But subsequent calls to the JVM do not... it's that initial runtime environment that needs resources. So if you're running several Java apps at a time (such as NetBeans, ConsultComm, Resin and other fun stuff memory and resource allocation is still much more conservative than apps that would exist outside of a runtime environment.

The original abstract windowing toolkit was kludgy, but the advent of the Swing API and the native look-and-feel within Java make things run and look like native apps. And with NetBeans GUI editor I can build windows and forms faster than a VB app in Visual Studio. Plus things are nicely skinnable by using GTK themes, QT themes or a combination of the two.

Plus let's not forget JDBC, something that I just can't live without anymore. Take a single file, drop it into your classpath, and you have instant access to whatever database you want. Want to change your database? No prob. Just drop in a different JAR file as your JDBC driver and tweak your SQL as needed. No connection recoding necessary. Much, much, much better than installing new ODBC drivers.

And system independence isn't to be taken for granted, either. I like being able to just create one package and have it run on my Linux box, then hand it to a WinXP user without recompilation. Keeps my apps easily cross-platform.

I am the great one.

[JavaLord]

Of all the great programmers I can think of, I know of only one who would voluntarily program in Java.

That would be me!

Re:I am the great one.

[JavaPriest]

That's because you don't know me =:-)

Re:I am the great one.

[JavaLord]

That's because you don't know me =:-)

I am the lord, you are the priest. I believe you should be worshipping me. Oh, and lay off the little Java boys Mr Priest..I am watching you. k thx. ;)

Re:I am the great one.

[JavaPriest]

I believe you should be worshipping me.

You believe? A real Lord would know! What kind of Lord are you anyway... ;-)

Move beyond language to what is done with it?

[juanfe]

I do have some level of admiration for someone who can code assembly in her sleep, but I'd rather focus on what the software does, and how it does it, than what it is written with.

In the wireless space, I've seen a lot of really excellent software--things that link position sensors and GPS and cameras and remote controls and other people. I've also seen a lot of crap. It didn't matter if it was written in J2ME or BREW or flavor-of-.NET or C++ ; what mattered was what the coder could do with the tools.

It's like any other field where talent matters. I'm sure Norm Abrams could build a set of Adirondack deck chairs using only a Dremel and a butter knife if he had to...

I Love Java, But...

[Joel Carr]

I love programming in Java. It is simple to program in, simple to understand, and I find it just feels 'clean' compared to say C++. The available API tends to be sufficient for most of my needs, and I find the documentation satisfactory and quick and easy to browse.

If I needed to write a quick, run a few times then throw away, command line application, I would code it in Java every time. For everything else I would unfortunately use something else.

On my aging 4 year old computer, graphical java applications feel slow and clunky to use. Even when the GUI has been coded correctly. Java apps with a poorly coded GUI are just unbearable. Also, the resources the Java VM uses isn't exactly small. Another thing is all graphical Java apps just feel out of place. They always look slightly wrong and feel slightly wrong. This tends to put the user off side from the start, and makes them feel that the application is somewhat substandard.

So basically, I feel that as it currently stands Java isn't suited to serious end user applications. As computer performance increases, and some of Java's future graphical enhancements are available, things may change.

However, while programmers are familiar, comfortable and satisfied with other languages, toolkits and tools, I see little incentive for them to start coding in Java.

---

Re:promise

[Florian Weimer]

Also their marketing department is high on crack. Java 1.2 = java2? Next up, Java5 ?! WTF!!!

And "Sun Java Server" is actually the next release of Solaris. 8-)

Who Gives A Shit?

[jjohnson]

Anyone still concerned with whether or not their favoured language is cool or not is a 1) hack, 2) student, or 3) self-described 'geek' who's not nearly as good as he thinks he is.

Java works well in some environments and for some tasks, and poorly in others, and a lot of that depends on the programmer, not the platform.

Besides, success is its own argument. If you can't understand why Java is so big these days, maybe that's your fault, and not the world's.

Re:Who Gives A Shit?

[forgotten_my_nick]

If your a real talented programmer then the language is probably not going to matter, except in what tool you need to complete your job.

There are armies of mediocre programmers in any language. You have them for a reason.

Do you want your real talented programmer working on the same thing over and over or have them code in such a way that a mediocre programmers can maintain it?

Re:Maybe because it's slow ?

[danheskett]

Except that Flash 6 is like ~500kb and a decent JRE is like 30MB.

Flash 6 can install on accident even on a dial-up modem. You won't be accidentally downloading a huge runtime to get Java installed.

Does this mean FORTRAN is uncool too?

[cspring007]

Crap, now when i go to the big computer programmer prom no one will dance with me. i like java because i can make applications on my computer that my boss ( who only uses a Mac ) can run on his. This is good. Also, its easy. cspring

Re:Does this mean FORTRAN is uncool too?

[gnuLNX]

Yes FORTRAN is un-cool. It has been un-cool for 10-15 years now.

Re:Maybe because it's slow ?

[dajak]

I notice everytime I use JAVA, it simply eats processing time, even though I am not currently running anything.

That problem is solved if everything runs in Java, and Java is part of the kernel.

Heck, playing devil's advocate here, as I think JAVA as such has a very nice API.

I agree. Of the languages I am allowed to code in nowadays, it is also the most elegant one. One of the problems of Java is that there are gigabytes of example code on the internet of how not to program. Crappy memory and resource management and bad string manipulation are the worst problems. I rarely have performance problems, as long as I don't have to write a GUI or use an application server or XML related library.

Re:promise

[southpolesammy]

Why the hell is this modded up? Java has nothing to do with javascript, jscript, ecmascript, or jboss. That faulty premise is so old and tired that it surprises me that people still are confused by it.

And as far as Java 1.2 vs. Java 2 goes -- ever heard of versions? You really think that everything in the original specifications were rock solid and that nothing needs to change? That's ignorant.

-1, Troll

Re:Maybe because it's slow ?

[molarmass192]

I have news for you, you WERE right, it is because of "programmers who weren't leveraging Java correctly". The same crap goes for bad C programmers. The problem is that the VAST majority of Java programmers who haven't worked in C rely ENTIRELY on automatic garbage collection and produce excruciatingly fat code. To summarize, in C:

many mallocs - zero frees == bloated crapware

while in Java:

many news - zero "= null"s == bloated crapware

... the big difference is the first one is also a leak.

Re:Maybe because it's slow ?

[micromoog]

Why, are we just supposed to look the other way and ignore Java's enormous overhead now? You're not suggesting it's actually gone, are you?

Re:Maybe because it's slow ?

[dtfinch]

Maybe Java is fast but what people see is that Java gui's are typically slower than hoped.

I've tried the 1.5 beta and it seems to go a long way toward addressing this problem. It feels as fast as native, and easily beats gcj in my own unprofessional benchmarks. But massive Java applications like Eclipse and NetBeans still perform horrendously slow for me, even with the server vm, and I doubt it can be blamed on any gui toolkit.

Re:Maybe because it's slow ?

[mwood]

It's the startup time.

I have no complaint about the speed of a Java application once it is up and running. The only problem I have is that the runtime takes so long to heave its vast bulk into memory and fiddle with stuff before the app. gets control.

Notice that as the size of the app. grows, and the time you spend in it begins to dominate the time you spend getting there, this becomes less and less a problem. But it's still noticeable. The time-to-first-interaction is painful here on a box that opens non-Java, non-Gnome app.s in what my human nervous system perceives as zero time.

There's no reason writ in stone for code compiled to an abstract architecture, running on a suitable interpreter, to be slower than native code. It could be *faster*, if the architecture is well-designed and the interpreter well-written. I have no doubt that someone could trot out an app. which runs faster in Java than in native machine code made from well-crafted C.

Server slashdotted

[TheEvilOverlord]

Paul Graham's Great Hackers essay has really touched a lot of people's nerves. The wires are choked with people giving their point of view.

Yet again, though, I have had to stop and think - what is it about Java that makes people brand it as the most un-cool language on earth? I have had friends look at me like I was a poor sod for "having to" develop in Java. So, let me list all the reasons I can think why people consider Java un-cool.

Java has considerably fewer surprises and prefers not to add complexity to the language for rarely used features thereby resulting in a language where you cannot really make your friends go ga-ga at amazingly brief programming constructs. You need to write something substantial [like Gosling's Huckster] for them be to impressed with your programming abilities and not your language knowledge. This is probably the biggest reason Java is un-cool. It's too easy (although programming or software development remains as tough as ever). Java was always touted as the language that the "average" IT programmer can use. It's such a language-for-the-masses that yet again, it fails the "geek" test. And if you use Java, so do you.

Java has been considered slow for ages. The earlier allegations (1995) were true. However, with the recent advancements in the JVMs from Sun and IBM, Java runs pretty close to C/C++. Check this benchmark. Contrary to this, there are other benchmarks that prove that Java is slower. All considered, it would be fair to say that Java cannot be considered "slow" anymore, yet its stuck with the label.
How cool is to be the jock with the second fastest race-car in the block?

Swing disasters continue to give Java a bad name. Swing is a brilliant, although hard to learn, API. But the vast majority of Swing applications are so bad that they give Swing and therefore Java a bad name.

Java is a strongly typed language therefore you have to tell the compiler exactly what you intend to use. And if you make a mistake in the way you use it, the compiler has the guts to tell you that you were wrong. Too much chaperoning?

Java has a vast library that is available to all Java developers without any ambiguity. Thus, if you wrote yet another Map you would not be considered a data structures guru by Java programmers but a guy who hasn't heard of java.util.*.

Java did not have a good IDE that compared with MS Visual Studio. I think this one was true. I am not so sure it is any more with IntelliJ. The absence of good tools probably pushed away a lot of good programmers.

Java is popular. Anything that is popular has lost its elite status and therefore is not cool.

Java is an application programming platform. You cannot do cool things like device drivers and games, etc (until recently - but Java gaming is coming in a big way).

Re:Server slashdotted

[TheLink]

php is popular and at least a fair number seem to think it's cool (I don't, but I'm not the majority - I think the PHP devs have a bad habit of adding features/functions/methods as standards without thinking about the long term consequences).

If Swing is brilliant but hard for most people to do correctly, it isn't so brilliant is it? That's a lame excuse. It's almost like saying Perl programs are easy to read as long as the programmer takes the trouble to make them easy to read. What's the percentage of good Swing apps? What's the percentage of readable Perl programs?

"Java has considerably fewer surprises and prefers not to add complexity to the language for rarely used features "

I was pretty darn surprised when there was an easy way to find the number of columns returned by an SQL query, but there wasn't an easy way to find the number of rows. Maybe it's only me but I think trying to find the number of rows of an SQL query is more common than trying to find the number of columns.

I also was pretty surprised some years back when the default java classes for doing http clients don't appear to support cookies. EVEN till today it appears to still be true. Check this or this out. Whereas with perl LWP, it just takes a few lines of code to login to a site, rip data out, etc etc.

Basically Java gave me the impression that the people who write the default classes (and other stuff) don't use them in practice, they're just told to write a bunch of methods as part of their job to fit a spec given by The Project Leader/Committee. So many things appear to be only be useful for PHB/BS compliance (look at the recent Java version numbering scheme for an example of Java Culture - J2SE 5..).

Whereas looking at the other languages, the default libraries etc are written by programmers who actually use the stuff on an almost daily basis, so if you need to do something common, it usually is there.

For Java you often have to go write it yourself. While that's also true for languages like LISP, with LISP you don't have to type as much.

And what's with the blooming XML for almost everything? Worse is the _almost_ part. I was trying to configure something using an XML config file, and followed the existing style to try to configure a parameter. After wrestling with it for some time, it turned out there's no way to do it via XML, you have to do it in the command line (till maybe in a future version).

The real great thing about Java is: projects done in Java can be outsourced to many average and cheap programmers (in fact java makes it almost compulsory for large projects to have many programmers). You just need an elite programmer (or two) who programs in English (or whatever human programming language of choice), and then you send it (the spec) to India for "compilation" to Java for the next 3-6 months.

Then the expensive elite programmer can go do something else.

Whereas with many of those "cool" languages, even though you only need one Elite Programmer who can do everything in 1 month, only the expensive elite programmer can continue to handle the project (maintenance, feature additions/changes etc). So what happens if the Elite Programmer gets bored and wants to do something else? You're screwed, that's what.

That, is the big advantage of using Java. Though it takes 3-6 times longer, who cares? How many times can you ask an Elite Lisp programmer to do Yet Another Customized Accounting/Business Application before he resigns? I suppose if you get the Elite programmer to write the modules and then get the grunts to use the modules it may work. But how many grunts know Lisp? How many know perl? How many know Java?

Re:who cares what he says?

[silentbozo]

LISP?!? Someone please tell me that there's a full-featured IDE for LISP. I remember by bad-old days as an undergrad, stiching together CARs and CDRS in a rat's nest of parentheses, trying to figure out which left paren matched the right paren that was causing an error message...

For those who haven't look at Java lately

[Coppertone]

I posted this in another thread before, but I suppose no on mark it up so no one noticed...........

The current list of cool Java Programs that I use quite often:

Eclipse IDE - www.eclipse.org
Azureus - http://sourceforge.net/projects/azureus/
IBM Community Tools - http://community.ngi.ibm.com/

and of course you need a GREAT JVM to run them:
www.ibm.com/java

Overheard in a recent Sun board meeting...

[Junior J. Junior III]

Exec1: Bill, we have to do something about Java.

Bill Joy: What's wrong with it?

Exec1: No one's using it.

BJ: The hell they aren't. Java's everywhere.

Exec2: Well, maybe, but no one wants to use it.

BJ: Why?

Exec3: Maybe because the performance sucks compared to programs written in C++?

BJ: That can't be it. Sun hardware doesn't perform very well either, and people use our servers all the time! By the way, you're fired.

*uncomfortable silence*

BJ: Well, why else can it be unpopular?

Exec1: Sir, I think geeks won't want to use it because it's not cool enough for them.

BJ: Not cool enough for geeks? How the fuck does that even make sense? Someone get marketing on the phone and tell them we need an X-TREME mascot for Java, right away. That'll make it "cool" enough for these geeks.

Secretary: Yes, sir. Right away sir.

BJ: Alright, now then, what else is on the radar?

Re:Overheard in a recent Sun board meeting...

[togginho]

overheard in a recent board meeting (industry to be neglected): CEO: we need to get this mission-critical system up and running - any suggestions exec1: yeah, we can get a bunch of really cool geeks to code it up for us - it'll be the coolest massive system on earth - probably a clump of C++ includes and binaries that we can never migrate to a more modern architecture or OS. Alternatively, we can do it in just 2 or 3 lines of Perl. nobody will ever be able to maintain it, but heck - how cool are we gonna be? exec2: or we might use an industry standard and use EJB's to hook in all our legacy systems and deploy them as web services - it'll be scalable, maintainable and complies to said standard - but it's no cool at all CEO: if you wanna be cool, go buy yourself a surfboard. do it in java...

does any language offer both?

[dheltzel]

Enterprise-grade apps and "coolness" may be inapproriate bedfellows. Besides, does any language offer both?"

Yes, pig latin.

Re:who cares what he says?

[kisrael]

Oh right...he was that Lisp dude...I forgot about that.

I only encountered Lisp in college for a while, and it NEVER seemed like a good "real world" tool. Its mix of data and code and love of recursion seemed excellent for certain cherry picked tasks...

Eh, I dunno. maybe I was just using too limited an environment. I have no idea what a "Visual Lisp" would be like.

The real reason it's uncool

[ndogg]

Want to know the real reason it's uncool? It's because all those geeks use it. Us real programmers beat them up and take their lunch money...

Err, wait, that's just too weird too think about.

Re:The real reason it's uncool

[sadcox]

I have to disagree...

the.real.reason.its.uncool.is.that.it.takes.too. lo ng.to.getToYour(methods);

Re:The real reason it's uncool

[sadcox]

if.you.have.that.many.dots.use.fucking.import.you. fucking.wanker.how.the.fuck.did.you.get.a.job()?

Simple--ended my statements with semi-colons instead of question marks without having to rely on the compiler to catch my error for me. :P

Re:Go write me a distributed n-tier web site in c

[NitsujTPU]

You're going to benchmark the value of a programming language by its ability to render a web site?

Doesn't that seem like judging the value of a television set by how well your DVD player shows videos on it?

You're defining the entire value of a programming language, by relation to other programming languages, by its ability to perform a distinct subset of tasks that could be performed with equal ease with a set of libraries for many other languages given that interest were great enough for such libraries to exist.

Re:promise

[sporty]

j2ee includes a larger api base. j2me is a smaller one. j2ee is more of a spec that gets implemented than anything else. j2me, I won't speak for as i only do the other 2 javas. And btw, the j2ee vm is the same exact one as the j2se vm. The only difference is the apis you use, due to the availability of the implemented j2ee standard. To make a j2se installation j2ee, just include the j2ee jars ;P

Oh, and java is quite portable. I develop a java app using j2ee via resin on my mac laptop, work on it at work using j2ee via jboss on a windows machine and depoy it to a unix box in the end. And if you wanna bother talk about swing applicaitons, anyone can write one. It takes someone smart to do it well. It takes an idiot to whine about it all day and find out that it's not hard to write one that works well. Not as fast as say, mvc, but works just like gtk "works".

java is a language, javascript is a language with a licensed trade mark which are different. I'm surprised you haven't learned this by now. Jscript and ecma script have nothign to do with anything. jboss is a j2ee server, just like apache is an httpd server and wsftpd is an ftp server.

Not always. Everything doesn't work "easily" off of c. Some use some form of assembler. Only reason you see more c support for simpler devices like calculators, is because c is easy to implement. a jvm isn't as easy.

Re:promise

[Atzanteol]

Also their marketing department is high on crack. Java 1.2 = java2? Next up, Java5 ?! WTF!!!

Best point you've made. Seriously, Sun's marketing depertment should be drawn and quartered. Java2, Java5, J2EE? J2SE? J2ME? Solaris versions vs. SunOS versions, putting the word 'java' on *everything*, etc.

It's the VM

[qray]

The cool part is the VM, not the language. I've used Java, C#, C++, and many others. Java and C# offer modest improvements over C++ while taking away a number of useful tools. Hopefully at some point someone will get it right and come out with a language that is truly an improvement. Though I really would love more improvements in the development environments. Today's environments are 20 years old and not capable of managing the software we're creating today. Think about it, nothing much has changed since Borland's Turbo Pascal.

Re:Maybe because it's slow ?

[dan_sylveste]

Bound checking and buffer overflow takes very little extra time on modern processors, typically less than 10%. So you have to find another reason.

Re:lame

[cecille]

I'd hardly say that Java is a training language for children. If I was training my child I'd go for a non-object oriented language to start. Besides that, to say a language is "for children" just becuase it is easy to use is kind of contradictory. I'd say that if a language was excessively hard to use THAT would be a flaw because you would end up with more bugs. Essentially, you're saying here that Java was too well designed and too safe for real programmers to use.

adversity of change

[man_ls]

The quote in my signature ("'Java is the Packard Bell of programming languages' - John Slattery") is an example of the adversity of change.

The man I attribute that quote to, was one of the developers of post-relational theory and worked on database design projects in the 1980s.

He is a big-time C/C++ guru, and very, very skilled at SQL (he writes all the queries for annual reports generation by hand, some of which as I have seen, can be over two pages long.)

He absolutely hates Java, because "it's too clean." He can't get access to memory locations, pointers, etc. This makes him feel powerless. He can't adjust to the fact that there are defined methods for doing things such as binary trees, linked lists, etc. whereas he used to roll his own every chance he got.

The language isn't the problem, the problem is that he's so set in his ways, he won't adapt to using a new language because of his preconcieved notions of it's capability and usefulness.

I think that is a bigger problem than the author of the article admits.

Ego

[Shadowin]

Every Java developer I've ever met has been on an ego trip, thinking they are the god of programming.

I want to know what it is that causes this mentality.

Re:Ego

[easter1916]

I've been developing in JAVA since 1998, and other languages for 15 years before that. While I think I'm competent, I don't think I'm a God of programming.

Re:Ego

[mlk]

Strange, I've always found C/C++ programmers to think that.

Strong typed != inflexible

[hsoft]

That is called typecasting no? I guess that Java has it. Even if a language is strong typed, it doesn't mean that you can't typecast.

I consider Delphi as a strong typed (and *cool* :) ) language, and you can easily do what you wrote.

Re:Strong typed != inflexible

[lachlan76]

void pointers can be nice to have sometimes, though.

Lack of Flexibility (Why *I* don't like java)

[dspeyer]

Java has no function pointers. If you want to include callbacks in your data structures, you need to do hideous things with interfaces and virtual functions. You probably need to waste lots of space instatiating them, too, because you can't put a class in a data structure. Granted, you could auto-generate this code (I would if I had to), but using code generation for something which is trivial in a lower level language like C is a very bad sign.

If this is too abstract for you, consider the following C code for a simple command-line interface:

struct command_t{

void (*)callback(char *data);
char *name;
char *help;

};
struct command_t commands[]={

{exit, "exit", "exit this program"},
{help_callback,"help","get help on a given command"},
{save_callback,"save","save you work to a file"},
(NULL,NULL,NULL}

};

void run_command(char *comm){

int i;
char *c;
c=strchr(comm," ");
*c=0;
for(i=0;commands[i].callback;i++){

if (!strcmp(comm,commands[i].name)){ commands[i].callback(c+1);
return;

}

}
printf("Unknown command: %s\n",comm); }
Implementing help is left as an excercise for the reader. So is handling bogus input. The point is that this way I can add a command without touching the command parser -- just write the callback and insert it into the list. If there's some more sophisticate processing needed on some commands, I just add a flag to the structure and do the work once in the parser. Short of code generation, how would I do this in Java? A switch statement is not acceptable, because it means that everwhere I deal with commands, the data will be duplicated (embedded in the code).

That's just getting started, of course. Then there's the type system, which uses hideous wrapper classes around the most useful types (this can and should be done transparently without involving the user -- lisp, python and ruby do it fine). There's the complete lack of introspection. There's the absolute need to put every helper function into a class whether it logically belongs there or not, bloating classes beyond the problem-space items they represent. There's the misdesigned basic library so complex I need documentation every time I read from a pipe....

It just takes far too much work to make Java do anything I want.

Re:Lack of Flexibility (Why *I* don't like java)

[Anonymous Coward]

What's the matter with the following code? (broken up into appropriate files, of course). I wouldn't call this "hideous", and as far as I can tell, it implements what you're trying to do just fine.

public interface Command {
public void execute(String data);
public void getName();
public void getHelp();
}

public abstract class CommandImpl implements Command {
protected String name;
protected String help;
public String getName() { return name; }
public String getHelp() { return help; }
}

public class exitCommand extends CommandImpl {
{
name = "exit";
help = "exit this app";
}
public void execute(String data) {
// do what you want here
}
}

public class someClassThatDealsWithCommnads {
Map commandMap = new HashMap();
public void addCommand(Command command) {
commandMap.put(command.getName(), command);
}
public void executeCommand(String name) {
Command command = (Command) commandMap.get(name);
if (command != null) {
command.execute();
} else {
// deal with bad input.
}
}
}

Slashdot's lameness filter bites my ass, so I have to put some more text here to give this post an appropriate ratio of "good" characters to "junk" characters.

Careful design can get around the need for hacks like function pointers (I know that I'm going to get flamed for that comment...). You don't necessarily design things quite the same way in Java as you would C, but that doesn't make it bad. It might mean that C programmers aren't automatically good Java programmers.

Relating to your last comment (about needing documentation to do things): don't confuse your lack of experience with Java with lameness. Sorry, but once you use it enough, you'll only be needing references to do things that you haven't done before. I guess that the alternative is to have slim class libraries that don't give you too much to remember, and as a result require you to code everything from the ground up. No thanks - I'd rather not re-implement the wheel every time I have a project to code.

Now the lameness filter is really starting to piss me off. How much do I have to type here? blah blah blah. Talk about lame.

Introspection: how about java.lang.reflect? Not used very much because you can use good design to do just about anything that you'd want to use reflection for, but it's there for those circumstances where you need it.

Really, what's the deal with the lameness filter? How much actual junk (as opposed to what it's calling junk) am I going to have to include here in order to get this thing posted? It took me less time to write the above code than it has taken for me to defeat the lameness filter! Lalalalalalalala.

Re:Lack of Flexibility (Why *I* don't like java)

[toriver]

ava has no function pointers. If you want to include callbacks in your data structures, you need to do hideous things with interfaces and virtual functions.

No, you use the Command or Strategy patterns to solve the problem the function pointer "hack" is used for in C/C++.

Java doesn't have function pointers because it's not C. I am sorry if anything non-C frightens you, but it's time to move on. If language A doesn't have feature B of language C, it means you need to learn something new instead of just apply the knowledge of C to everything.

C is just assembly that has put on finer clothes, trying to look like a higher-level programming language.

Re:Lack of Flexibility (Why *I* don't like java)

[Big Boss]

You obviously haven't used some of Java's more powerfull APIs. Take a look at java.lang.reflect.* sometime. You CAN put classes into data structures (other classes with the Class class), you can call arbitrary methods on objects (Class.getMethod()).

So you could do something like this:

public Class CommandHandlers
{
public command_Help()
{
// show the help here...
}
public command_Save()
{
// save here...
}

public void command_Exit()
{
System.exit();
}

public void doCommand(String command)
{
getClass().getMethod("command_" + command).invoke(this, null);
}
}

This is really basic, but you get the idea. Some of your other complaints are annoying, but not as big a deal as you seem to think. I have wanted autoboxing about twice, I don't use things like Integer much. I just use the primitives. I have wanted generics for quite some time, avoiding the need to typecast (and to get compile-time checking) when using collections, but that's a minor thing, and is coming in the next version (along with autoboxing/unboxing).

Helper functions have to be part of a class. So what? Make a Utilities.java if you want and call them from there. You have to put them all in a .c file anyway, so it's not THAT big of a difference. You don't even have to instantiate the object if you declare the methods static.

I don't find the class library nearly so complex as you seem to. I think it's eaiser to work with than standard C++ or MFC. Sure, clib is a simpler, but it's also less capable.

Most of the complaints I see about Java boil down to "but it's DIFFERENT". So what? Every language is different. They all have strong and weak points. If I could have Java's code with C's memory usage, I'd be so very happy. ;)

Re:Lack of Flexibility (Why *I* don't like java)

[dspeyer]

So then do you write things like this?

someClassThatDealsWithCommnads commandHandler=new someClassThatDealsWithCommnads();
commandHandler.addCommand(new exitCommand());

I guess that'll work, though the requirement to give each command its own file whether it warrents it or not is annoying. It will also be a pain if I want to change the behavior of a command at runtime (I suppose I could remove the command and insert one with the same name -- awkward). It strains the Single Point of Truth Principle because defining commands and inserting them into the used list are seperate. Finally, it's almost twice as long as the C implementation, and C is a verbose language. Using a high level language should shorten code without harming readability. Remember that bugs are proportional to physical lines of code.

As for the Reader classes thing, I stand by my statement. I've been coding Java for three years. If the classes were intelligently designed, I'd have them memorized. The seperation of Readers, FileReaders, BufferedReaders, and all the rest of the relevent classes is a mess. I guess they're trying to imitate the Unix file-descriptor/file-handle distinction, but it's horribly clumsy and since they don't relate to the thread model that way, there's no need for it.

And don't even get me started on Java threads....

Re:Lack of Flexibility (Why *I* don't like java)

[Pentagram]

Short of code generation, how would I do this in Java? A switch statement is not acceptable, because it means that everwhere I deal with commands, the data will be duplicated (embedded in the code).

Polymorphism. It has the advantage of being far more readable than your code.


Then there's the type system, which uses hideous wrapper classes around the most useful types


Autoboxing.


There's the complete lack of introspection.


Reflection.


There's the absolute need to put every helper function into a class whether it logically belongs there or not


Every function logically belongs /somewhere/.


There's the misdesigned basic library so complex I need documentation every time I read from a pipe....


I'll concede that point. Streams are a bit of a mess. But at least the documentation is good :)

Re:Lack of Flexibility (Why *I* don't like java)

[mattgreen]

It is ridiculous that you MUST use interfaces to implement callbacks. It is this asinine, "there-is-only-one-way-to-do-something-and-it-is-i nherently-elegant" attitude that Java has about it that I dislike. When you point things out like this, then inevitably someone comes along and chastises you for wanting another feature in the language, pointing you toward some GoF design pattern as if it were holy writ. News flash: GoF patterns are nice but language support for them is nicer, witness .NET's built-in event handling.

Also, I don't see how function pointers are a "hack," but this is usually leveled at anything that isn't the One Java Way. So have fun making factories that consist of switch statements inside instead of just plopping the switch statement at the point where you need it.

Re:Lack of Flexibility (Why *I* don't like java)

[nojomofo]

If you really don't like interfaces, then use reflection. Nobody said that you have to use interfaces. Most java programmers would consider interfaces as much more elegant, but you can implement this sort of thing in other ways.

Re:Lack of Flexibility (Why *I* don't like java)

[Anonymous Brave Guy]

Polymorphism. It has the advantage of being far more readable than your code.

I think that's missing the point slightly. The C code to do this is horrible. Something like Perl would do it with a hash and function references in a much more concise form. Obviously functional programming languages offer considerably more powerful features than simple function pointers. The fact that Java's equivalent would be more readable than the C is not something to be proud of -- and looking at the AC's suggestion a bit further down this thread, I'm not sure I even agree with that!

Re:Lack of Flexibility (Why *I* don't like java)

[IncohereD]

It is ridiculous that you MUST use interfaces to implement callbacks. It is this asinine, "there-is-only-one-way-to-do-something-and-it-is-i nherently-elegant" attitude that Java has about it that I dislike.

It is ridiculous that you think you only need one screwdriver in your toolbox. *gasp* Different languages are good for different things. There are interfaces between different languages. Deal.

Re:Maybe because it's slow ?

[animaal]

Synchronization is not a problem for C because the average C programmer writes single-threaded code, and it tends not to be server-side (and if it is, it tends to be CGI, which doesn't scale well. It's possible to run Java in from a CGI script too). Of course it is possible to write multithreaded apps in C, but then synchronization becomes a big issue too.

Server-side scalability means pooling, caches, lots of things that imply resource sharing. This means some form of synchronisation, whatever the implementation language.

Re:who cares what he says?

[jbester1]

Erm, he did a start up in the 90's and literally crushed his competitors. The company was eventually sold to Yahoo! for approx $25 million. How much more in touch with the business environment can you get?

His trick was rapid development and the ability to debug and add features while he was still on the phone with customers. All of this using CLISP (byte-code compiler for lisp) in the mid-90's.

He generally rags on Java the most not because it's interpreted or slow or anything of that nature. It's because it's slow to write, has no REPL, and lacks good abstractions/is too verbose.

Re:Maybe because it's slow ?

[LnxAddct]

Thats a programmer error. A bad programmer can make anything happen.

Are your apps constantly restarting?

[FatSean]

Mine aren't. They run for weeks and months at a time. Startup time is irrelevant in the enterprise.

Re:Are your apps constantly restarting?

[Switchback]

You're correct, but I think we're comparing apples and oranges here.

On the server side, startup time isn't an issue and neither is the memory consumption or vast GUI issues that Java has. It is, however, a completely different story on the client side.

There are several problems with Java that more or less make it unsuitable for client side applications.

• While non-GUI Java is sufficiently fast, Java GUIs (particularly SWING) are horrendously slow. They also don't quite have the proper look and feel of a native application. Java GUIs also tend to be quite buggy. Both SWING and SWT have many problems.
• Java takes up too much memory. Client machines dont' have the memory resources that servers do. Java apps take huge amounts of memory to run and cause many machines to start swapping...especially if you are running 2 or more Java apps. This kills the client performance more than anything.
• Startup time is horrible. Again, this is not an issue with server side, but I don't want to wait a minute (which is perceptively a very long time) for an application to start up.

I could go on from a programming side as well, but that's off-topic on this thread.

Re:Are your apps constantly restarting?

[afd8856]

I use a somewhat regular desktop system with an Athlon 2000 processor and 256MB Ram. I run a lot of Java desktop apps (Sancho, Azureus, Freemind, G2Gui, etc) and never had issues concerning speed or memory bloat. Neither startup speeds. Honestly.

Re:Are your apps constantly restarting?

[dasmegabyte]

I've mentioned this before, but the primary difference between a C/UNIX programmer and a C#/Java/Windows programmer is the perception of what constitutes a program.

In UNIX, a program is usually a tiny little thing which passes its output to other tiny little things, creating a network of programs controlled by a lightweight master program. Because of this, programs HAVE to have a small footprint and have to start up and close down quickly. A good UNIX program does only what it's supposed to, and then it quits.

In a Java/C#/Windows program, you generally start the program once per day/week/year. The program, once started, calls objects with functions that operate the same as individual programs in the UNIX paradigm. Because the program is doing all of the work and all of the flow control, it doesn't matter if the thing starts or stops quickly, doesn't matter if it uses a lot of memory, because you're not going to be using that memory for a whole lot else. A good Java program does so much, it's almost like its own windowing or operating system.

The essence of "I don't understand OOP, it's full of bloat" is the perception of what a program is and does. If you think a program should do one small thing and then pass its output or control to another program, you're essentially in the OOP mentality already...substituting processes for objects and programs for functions. On the other hand, if you believe as I do that programs should sit open and ready to use on a whim, even the fast startup time of the average UNIX utility is too much. You need the memory allocated, the commands loaded and ready to handle whatever you've got to do -- which is why OOP makes sense. You don't start your notebook every time you need to jot a note (I don't anyway)...you just pick it up and write.

Anyway, to get on topic: I always thought Java *WAS* cool. All the under-40 programmers I know LOVE Java, even if they don't use it. It's almost a spiritual thing (I plainly remember wearing a "Java is the Way" back when I was a Java coder) and it's even more mysterious because the older generation of C coders didn't like it. Not disposing of objects and relying on GC is the programmatic equivalent of not cleaning your room. And a good UML diagram reads like a map of a futuristic city.

Re:Are your apps constantly restarting?

[kill -9 $$]

I (like many others) have been saying for years that its a matter of right tool for the right job. Also, I'm very competent in Java, C/C++ and Perl. I also, typically develop exclusively for UNIX and stick to the UNIX philosophy of building small, highly configurable/reusable programs wherever I can.

The truth is though, not all applications can be distilled down into simple pipe/filter utility-type solutions. In these cases I typically like objects. If you understand OO programming, and I have found few who can both claim they understand and actually do (its about a 1:5 ratio from my experience) you can build very complex/robust systems very quickly. The tradeoff, memory. In this case I usually use java. Yes, its restrictive, and you can't do everything you can in a different language like Smalltalk or C++, but for most things it is capable. Its also cross-platform, if you know what you're doing, and there are hundreds of "standardized" API's for doing lots of stuff. Not to mention, because of those API's, you can actually get cross-platform database connectivity, web applications, and in theory but not really yet, enterprise services.

If it comes to writing simple utilities, throw away code, anything that I feel falls into less than 100-200 lines of Perl code, I'll use Perl typically. My experience with Perl is that it doesn't scale, from a software management perspective, as nicely to large complex systems. Its usefulness though, is that you can do some pretty powerful stuff, without having to get bogged down in datatypes, complex exception handling, complex string manipulation and other language-isms that you have to deal with when you use a more strict language like C, C++, or Java. I also like the fact that anything I can write in C I can typically write just as easy in Perl, so for some of that systems programming type stuff that Java doesn't do so well, its nice to use Perl and not have to get into the guts of a C program

As for C/C++, I avoid them whenever I can :). Only when doing embedded programming do I get into C and C++ is typically on a supporting existing code type basis.

Again though, it comes down to right tool for the job. I've had this argument time and time again with PHP, Perl, and Python programmers and it always seems to come down to size/scope of the problems they are trying to solve. Most people who love these tools have written what I view as smaller applications. They have never had to write an e-commerce system that ties together multiple enterprise datasources, call into SOAP/CORBA etc services on another box, etc. Or the other thing I experience is that if they have, they end up reinventing some API/technology/feature that was already present in Java or that had they implemented their solution in Java would have made their life much easier.

Anyway, this has been my experience, and this is the toolset I use to solve the problems that arise in my world. Everybody is different, use the right tool.

Re:Are your apps constantly restarting?

[Switchback]

The bloat honestly depends on one very big factor: If the application provides its own JRE or not. A lot of commercial apps deliver their own JRE with the application. This causes you to launch a new JVM each time.

If, on the other hand, you are able to run the apps against your system JRE, then you won't see nearly as much bloat. But like I said, almost every commerical app that I use provides its own JRE, which does not help.

Re:Are your apps constantly restarting?

[jrexilius]

An earlier poster makes a point of comparing a JVM to a whole OS and further (relatively) new methodologies to java, like spaces, RMI, web services, are just new implementations of OS level IPC methodologies. Where the Java thing starts to break down and things start to look more ugly is when you are not trying to abstract away the platform. Device and peripheral interfacing, integration with platform services (quota's, /etc stuff, blah blah, mail services, etc), and IPC with non-java apps. Once you start to build apps that are not so self-contained and you want to leverage the platform, you have to start working very hard in java.

Anyhoo, I am still not convinced that java really should be compared to languages like C, perl, python, etc. as they each have very different views of the world. The difference is that POSIX systems programming and languages have had about 30 years to mature and develop where as the Java approach has had little more then 10.

Re:Are your apps constantly restarting?

[FatherOfONe]

What the heck are you talking about. Currently every new java program will start a new JVM. So if I want to launch two versions of Jdevelper, it will load "the vendors supplied jvm" two times. However for a lot of programs the ~5-16MB of RAM needed for the JVM isn't that big of a deal.

As to the parent. SWING is not slow. You don't know what you are talking about. Your statement was accurate 5 years ago, but not today.

Re:Are your apps constantly restarting?

[darkarena]

Being in the "OO Mentality" and observing OO Design are two different things. The real features of OO Design depend heavily on Polymorphism and Inheritance - something which modules or procedures do not. This is not to say that the modules themselves to not use objects, but don't mistake the consuming of libraries and functions in a C Program for OO programming.

The difference between the systems in not so clear cut. It is true that JAVA programs (generally) have a larger startup time. The reason for this is NOT because of the Java language nor the byte code it generates, rather the extra startup time is because Java needs to run on Intel based machines using a Virtual Machine. This is both an advantage AND disadvantage to JAVA, one that a company (or programmer) would need to evaluate before choosing the language and Platform.

Do NOT, however, mix this up with C# and Windows Programs. Like Linux, Windows is an Operating System. Debates aside, the usage of .NET and COM programs is a lot closer to what you would find in the Linux environments then what you would find in the Java Virtual Machine. Running Java on a NATIVE Java Machine, however, and you'll notice all of those startup delays disappear.

The real truth here is scale. Bigger programs take longer to start up then smaller programs. In large implementations, the JVM start time becomes negligible. If start time is a consideration, then by all means writing code NATIVE to the machine will always have an advantage. JAVA, however, offers a WIDE variety of advantages over its older counterparts which, in my opinion, makes it a very strong competitor to other platforms.

As far as calling Java Programs LARGE is not a fair assessment. Many of them are simply because Java makes it easier to implement large system then it's native counterparts. Furthermore, one of JAVA's biggest advantages - it's cross-platform compatibility - is typically needed most in large applications. Your analogy of starting up your laptop is a valid (albeit a bit exaggerated) assessment of JAVA, but it greatly oversimplifies your assessment of the language in general. Good OOPs do ONLY what they need to in a class and then return. Similar concepts exist in C++ and C#. Perhaps the Windows libraries are not as LEAN as they should be, but again the concept behind their ten millions dlls is the same as in Linux, to provide small tools that a master program can piece together.

Re:Maybe because it's slow ?

[mikael]

Garbage collection. Some well-written Java applications allocate all the memory they will ever need at the start, and reuse these objects. Others rapidly create and discard temporary objects. Since garbage collection only occurs periodically, the system can end up with large blocks of unused memory.

I could never understand why Java couldn't allow the programmer to choose how often or when to perform garbage collection (end of function calls).

Hackers? Cool?

[myside]

Since when do "Hackers'" opinions of "cool" make a shit's worth of difference? Please.

It should be cool because it's so bad

[Flyboy Connor]

In my experience, things are considered cool (by geeks) when they are difficult to use. If that is the case, Java should be cool. Perhaps it is not as cryptic as Perl, but it comes pretty close.

I have learned and programmed in about 15 different programming languages (professionally in 5 of them), and designed a couple of special-purpose languages myself (also professionally).

My experience with Java is that it is tremendously difficult to learn. True, it is fairly easy to read and understand a Java program by someone else. It is also fairly easy to kludge something together. But if you try to program elegantly in Java, you are suddenly confronted with a huge number of standard classes which seem to have been designed by dozens of people who did not communicate with each other. Learning Java is like learning several different languages at once.

Java is the only language I know that makes a distinction between 'int' and 'Integer'. It is the only language I know that requires you to be fairly fluent in a completely different language (Perl) to use some of its default methods. It is the only language I know that has two different standard classes for the same functionality (Vector and LinkedList).

The idea behind Java was OK. The execution was terrible.

The only reason I can see why Java is not cool despite the fact that it is difficult to use, is the fact that it isn't elegant. Probably that was in the article, but slashdotting prevented me from reading it.

Re:It should be cool because it's so bad

[UfoZ]

It is the only language I know that has two different standard classes for the same functionality (Vector and LinkedList).

Huh? Sorry, but there's a huge difference between a vector and a linked list. Just like there's a difference between an airplane and a balloon - they both fly so they must be the same thing right?

Vectors use a contiguous memory area to hold data, so they have immediate random access to all the elements, but the tradeoff is that inserting elements in the middle of the vector means data is going to have to be moved around. Linked lists, on the other hand use -- surprise! -- a linked list to store data items, so they have fast iteration and random insertion, but random access is slow because it requires an iteration through the list.

The difference between int and Integer is indeed annoying and I would also consider it a shortcoming of the language and has bitten me in the ass many times.

It is the only language I know that requires you to be fairly fluent in a completely different language (Perl) to use some of its default methods.

Please give an example, because I couldn't program in Perl to save my life, yet I've managed to use Java when I needed to, and I assume that involved using these "default methods", whatever they might be. Hell, I still prefer Java to do TCP sockets because they're so damn simple to get working.

Re:It should be cool because it's so bad

[Flyboy Connor]

Vectors use a contiguous memory area to hold data, so they have immediate random access to all the elements, but the tradeoff is that inserting elements in the middle of the vector means data is going to have to be moved around. Linked lists, on the other hand

That's my point: it's a technical difference, not a functional one. In a language such as C, which is low-level, I understand that such differences must be taken into account. Java, however, pretends to be a high-level language. So I would expect one of two things: Either there is one class, and a parameter controls the storage method, or there are two classes, which have exactly the same interface (easier, and therefore probably preferable). Vector and LinkedList, however, use completely different method names for their interface. Which is stupid, because their functionality is the same. That is what I mean by bad design.

Please give an example, because I couldn't program in Perl to save my life

I forget the exact method name (I think ReplaceStr, but don't pin me down on it), but in the String class there is a method to replace substrings with other substrings -- check it out.

Customers must have JVM installed

[truz24]

The main reason why I do not use java to build applications is because I cannot require users to install the java VM just to use my applications. In my opinion the only way Java will become a serious competitor is if it is implemented into the Operating system.

Re:Customers must have JVM installed

[togginho]

that may be the reason web-based applications don't really kick off - it requires customers to have a browser installed...

Debunking Pro-Java Myths

[Frankie70]

Pete Becker of Dinkumware has debunked a lot of FUD spread by Java Programmers. Pete worked on the Java Library & the C++ Library for Dinkumware (& earlier for Borland) so he knows quite a bit about the subject.

Here are his usenet posts on the subject.

Re:Debunking Pro-Java Myths

[brunes69]

Some of his posts are grossly incorrect. Examples:

But the semantics for many programs would not be correct, since Java requires array bounds checking. Disabling it means that you're not compiling Java.

True, if youe xceed the bounds of an array in a Java app you will get an array out of bounds exception - but that is the worst that can happen, a nasty error message. However, this is a totally different can of worms in C/C++. If you don't check the bounds of every single array, you could be exposing buffer overlows in your application, which is a huge security hole. +1 for Java.

You've posted three examples of code that you claimed was as fast or faster in Java than in C++, and every one of them, when compiled properly, turned out to be faster in C++ than in Java.

Faster when run how many iterations under hotspot? 1? 10? 100?

In Java you have to write nine copies of the basic sort function: one for arrays of chars, one for arrays of doubles, one for arrays of Objects, etc.

For one, most people use the Collection or List interfaces for utility classes so that you can pass in any type of object, be it an ArrayList or a linked list, so in the Real World(tm) this is rarely an issue. Additionally, Java 1.5 has templates so it is a moot point.

I could go on and debunk more of his debunking, but I can tell from his posts that ihe is quite biased and is not being resonable. Just for reference, I am *not* a Java developer. I write a lot of C++ code and a lot of java code, both are ideal for certain situations. For example, desktop apps with need for a fast startup time will always be best written in C++ until Java Vms are built into the OS. But for long-running business applications, where startup time is not a huge requirement and ease of development, debugging, and security are a higher priority, Java wins hands down.

Re:Debunking Pro-Java Myths

[iGN97]

If you don't check the bounds of every single array, you could be exposing buffer overlows in your application, which is a huge security hole. +1 for Java.

You don't need to check the bounds of every single array all the time. This is why STL puts some trust in you. It's easy as hell to make STL-code that compiles and crashes and burns, but it's obviously for a reason. Constantly re-checking data that should be validated elsewhere, relying on exceptions to communicate an error message is extremely inefficient. That's why it's not done in C++. Writing operator[] with bounds-checking has got to be one of the simplest things in the world in C++.

Faster when run how many iterations under hotspot? 1? 10? 100?

There it is again, the cluthing-at-straws "somewhere down the line it will be faster" that is so typical from a member of the Java community. What does it take to actually produce some code and a supporting environment that actually outperforms some C++-code and is not just a castle in the clouds?

For one, most people use the Collection or List interfaces for utility classes so that you can pass in any type of object, be it an ArrayList or a linked list, so in the Real World(tm) this is rarely an issue. Additionally, Java 1.5 has templates so it is a moot point.

Java 1.5 doesn't have templates, it has generics. Generics in Java are not much more than autocasting and autoboxing; basically two constructs that introduce even more runtime overhead. It also has a number of other shortcomings, like the inability to tell the difference between a List<JavaCoders> and a List<Donkeys>, and frankly so have I.

C# 2.0 at least makes a decent attempt to get this right, but falls a little short if you're used to C++ templates. In C++/CLI you can have both and should be a happy camper.

The point the original poster was trying to make, however, is that C++ templates are better than Java generics because they lend themselves to implementing generic algorithms. Being how you're a C++ coder, you should understand this.

Re:Debunking Pro-Java Myths

[julesh]

For example, desktop apps with need for a fast startup time will always be best written in C++ until Java Vms are built into the OS.

The original ancestor post we're replying to suggested one of the two things that can be done to remove this problem: don't use AWT/SWING, they're very slow and resource hungry. The alternatives result in programs that start up much more quickly.

For instance, with Java 1.4.1 and my own toolkit, I get typical application start times of 3 seconds, including loading initialisation files and resources.

Also, there are several compilers available now which can compile Java code to a native executable. One is even included with GCC. Using this technology, I get that time down to less than a second.

Thus is the 'java slow startup time' myth debunked: it entirely depends on the libraries your application uses, what your application does, and the implementation of Java that you're using.

Re:Debunking Pro-Java Myths

[master_p]

I don't know how you ended up modded 5-insightful, but you are the one to be hugely wrong.

If you don't check the bounds of every single array, you could be exposing buffer overlows in your application, which is a huge security hole. +1 for Java

Why should I have the burden of array bounds checking forced on my neck? In C++ I can skip it wherever the array access is trivial, and that's a lot of cases. What happened to freedom of choice?

Faster when run how many iterations under hotspot? 1? 10? 100?

First of all, no benchmark runs 1 time only. Secondly, the hotspot compiler does not re-optimize an already optimized block of code.

For one, most people use the Collection or List interfaces for utility classes so that you can pass in any type of object

This has several drawbacks: a) it forces you to go back to where the collection is created to see want kind of key is being used b) it allows for any type of object to be inserted in the collection, which is undesirable.

Additionally, Java 1.5 has templates so it is a moot point.

Java templates are nothing more than autoboxing. The Java 1.5 generics still use Object-derived instances internally, with many disadvantages: a) losts of unecessary dynamic casts that slow down the program, b) lots of unecessary small object allocations like integers.

Just for reference, I am *not* a Java developer.

It is obvious.

both are ideal for certain situations

C++ is much better as a language specification than Java (with many minor problems), but the language environment has serious flaws. Imagine a C++ running with garbage collection and the same toolset as Java, and you can easily see what language is the best.

until Java Vms are built into the OS

BS. You don't need that built into the OS. VMs are frequently updated.

where startup time is not a huge requirement and ease of development, debugging, and security are a higher priority, Java wins hands down

You got that one right, mate.

Re:Debunking Pro-Java Myths

[pommiekiwifruit]

For those of us who use make, it is nice to have programs start up in a fraction of a second (as my c++ ones do) when they are being called a hundred times in a row from a simple makefile. I guess that's why ant was invented.

When a large IDE like visual studio 6 takes less than a second to load, but "hello world" in java takes longer, it doesn't give a good impression.

Re:lame

[black mariah]

Assembler? You pussy. I write in raw machine code, DIRECTLY TO MY HARD DRIVE, using a magnetized nail. Fuckin' know-it-all youngster.

Because its starting up too slowly

[markus_baertschi]

All other languages looked at are scripting languages with great interactivity. Just press/type 'run' after the bug is fixed and you get your instant gratification in milliseconds. Compiled languages like Java need e compile cycle. Java is the worst due to the long startup time of the JVM. I have never seen, even on multimillon-$ hardware, a snappy Java app. Even 'Hello World' has visible responsetime !

I prefer the Java language over perl, python, php, etc. The structure helps me to rapidly stitch a reliable program together. But I use the others more due to the snappy development cycle. I want milliseconds, not seconds !

Markus

cheapest that still gets the job done...

[dpilot]

I'm not sure I see anything wrong with that, though I guess really you have to examine "cheapest" very carefully. I'm sure that the Slashdot crowd is even less likely to program in Ada than in Java, and gripe even harder about the higher "overhead" in Ada than even Java has, and how it gets in the way of their coding.

Yet you have to look at the initial assumption of Ada as a programming language *for embedded systems.* For the Ada target market, they had studies indicating that 90% of the programming "cost" was spent in maintenance. From this perspective, initial coding is a nit. Even debug was rated as more expensive than initial coding.

So you have to look at the meaning of the word, "cheapest." (If they mean cheapest tools, regardless of suitability to the job, I have to agree with your attitude, though.)

Re:cheapest that still gets the job done...

[kbielefe]

I couldn't agree with you more. I am an embedded software engineer. I have only done maintenance for about the last year (no new code), and wouldn't want to maintain a large project in any other language than Ada. Most everyone I work with will agree. Let me give you just two reasons why.

In Ada, if programs fail during runtime, they are much more likely to fail at the point where the coding error actually occurred, instead of at some side-effect point later in the execution.

The constraints of the Ada language make most errors occur at compile time. I recently had to increase the size of one element of a frequently used data structure. It was a pain to get it to compile again, but every single bug caused by the size increase was fixed before I even ran it once. As a frequent C programmer, I know that I would have missed a large number of those until runtime, and at least one bug would probably have gone unnoticed until the most inopportune time (like a customer demo).

I'd even argue about the initial coding taking longer in a language like Ada. Sure, it can sometimes take a little more effort to bang out your first compilable version, but it is a lot more likely to work the first time. And usually it is only the declaration section that is significantly different from a C implementation.

Re:cheapest that still gets the job done...

[PythonCodr]

The analogy to ADA is a good one. When I was at CMU we had a prof who told us one of the promises of ADA is that it would make programs easier to write/read/maintain because ADA enforced "Good software engineering practices" as a part of the language. Java does similar things by trying to encourage you to write your code a specific way.

I worked with Java for a while, before I learned Python. In fact, I kind of liked working in Java. But Python (IMO) takes a different spin on things. It's designed to be understandable, and I've found it just fits in my mind better than a lot of languages. Perl is a seductive language as well (I've coded in it), but Python's a lot easier to read and evolve into a working program (it's all out there for you to see, there is no default/hidden magic going on "under the covers".)

Yeah, you can write bad Python ... you can write any program poorly in any language. But Python doesn't try to force you into a particular design style for OO code. Java does, and that IMO is it's weakness. Or Python's strength, depending on your point of view.

Ada died a slow death under the weight of it's bloat. I wouldn't be surprised if Java ultimately met the same fate. And unlike Java, Python doesn't get in your way when writing code, though it has a richer object model. And that's why I like it, and I suspect a lot of other folks feel the same way (unless I really am alone in the universe ... as my /. profile seems to indicate. ;-))

Re:cheapest that still gets the job done...

[dpilot]

I do quite a bit of Python. Actually, any programming for me is a sideline, since I'm primarily in chip design. So programming languages have to pass the "2 week test" for me. I seldom/never do any programming for more than about 2 weeks in a row, then some other firedrill comes along.

I NEED something I can get somewhere with within that two weeks. I NEED to have readable code, so when I get back to it, I can figure out what the heck I was doing several weeks ago, and continue. Obscure syntax doesn't hack it. Clarity does.

I used to use Pacal and Modula2, with various extensions, but Wirth is so far out of favor these days that it's hard to find. (Oberon (and /2) followers have an IMHO self-limiting attitude, too.) I've dabbled a bit with Ada, but to be honest, it goes too far the other way. It fails the "2 week test" with more "clarity" than I can readily learn how to use.

For the moment, Python and bash get most of my programming part-time.

Re:cheapest that still gets the job done...

[dpilot]

For more, see my other response on this tree. In short, I've played with Ada, and it fails my "2 week test" because there's a lot there to learn. Other tasks distract me before I've learned enough to be useful. Programming is not my job, it's what I sometimes use to do my job.

As I said elsewhere, I usually use Python. For the types of jobs I do, the performance of an interpreted language is entirely adequate. The ability to drop the code for weeks at a time, then return to it for a few days is critical, for me. If I ever get over the hump on Ada, it would fill my bill, though it's not as readily available.

Re:Maybe because it's slow ?

[mwood]

Running on a 1gHz Pentium 4 256MB box here, and JRE startup still takes forever. It's really not much slower on the Pentium MMX 166 64MB box I have at home.

Java lacks a good IDE??

[LWATCDR]

"Java did not have a good IDE that compared with MS Visual Studio. I think this one was true. I am not so sure it is any more with IntelliJ. The absence of good tools probably pushed away a lot of good programmers."
What about Eclipse? What about NetBeans? I have found NetBeans to be a very good IDE and I know that many people Love Eclipse. This is just wrong.

Resistence is futile?

[Kell_pt]

Well, probably like lots of other folks here, I develop projects and program for a living. Although I've programmed in Java and recognize the tremendous ease with which one develops some complex stuff, I can't help feeling some resistence in applying it to new projects. A few considerations and reflection about it is probably in order.

The argument that it's portable fails to meet the fact that many of the times you do NOT want to care about installing the latest JRE on the destination computers. I'd be happier with compilation to native format. I know GJC and the likes, but they don't work 100%, although they're progressing a lot.

On clients, I find some resistence to Java due to the way it's marketed. "Isn't that for cellphones" - they ask. Stupid? Not really... that's the message the media hands out for Java nowadays (at least around here). We've had clients that knew where PHP, C and even Delphi fit in in their solutions, but failed to recognize Java. Maybe this is just something local to this country though. :)

At times, the verbosity of Java really gets on my nerves. I'm a lot more productive using a combination of VI and Screen than in most IDEs, so regardless of auto-completion, I resent having to type stuff like:

X509CertificateSimpleChainVerifier x = new X509CertificateSimpleChainVerifier();

I mean, wouldn't it be possible to ommit the type again from the new operator? I'm sure the parser could infer the default type from the variable it's being assigned to. :p
Please, this is just an example. When you develop for a long time in something like Perl, PHP or Python you end up resenting writing too much. Sure those are typeless or just have yupe hints but still... I'm sure others will have different complains. What I sometimes feel is that compared to a pet language like D http://www.digitalmars.com/d/ it feels a tad old!

*ducks at the flames*

Re:Resistence is futile?

[flibuste]

I resent having to type stuff like:
X509CertificateSimpleChainVerifier x = new X509CertificateSimpleChainVerifier();

It took me 2 seconds copying/pasting this. What's wrong with copy/paste if you do not like typing?

Also, interestingly enough, without any other code, I can read that you are dealing with X509 certificates, and you are about to write something to verify one.

Verbose comes with the benefit of understandability! It's great!

Re:Resistence is futile?

[FriedTurkey]

so regardless of auto-completion, I resent having to type stuff like:

X509CertificateSimpleChainVerifier x = new X509CertificateSimpleChainVerifier();

I mean, wouldn't it be possible to ommit the type again from the new operator? I'm sure the parser could infer the default type from the variable it's being assigned to. :p

Somebody doesn't understand object oriented programming. That "type again" is called a constructor. You sometimes need to provide parameters to a constructor or even use a constructor from an inherited class.

Re:Resistence is futile?

[Kell_pt]

Sorry, but either I didn't explain myself right or you're missing the point. What would be wrong with:

X509CertificateSimpleChainVerifier x = new();

It's not as if the compiler can't tell it should create a X509CertificateSimpleChainVerifier object. I can't stress this enough, but this is just an example of how verbosity could sometimes be avoided. Check that link for the D language and you'll see what I mean (I could mention how miss associative arrays, as another example). But then, this is slashdot! :)

Re:Resistence is futile?

[Kell_pt]

This was never about understanding. OOP isn't new with Java either and has little to do with syntax (althouth the dot notation is king). So your itsy bit of sarcasm is lost and could have been better applied elsewhere.

This is about an example of how Java forces the programmer to type stuff that it is able to perceive. Seeing as the constructor is always the name of the object you're creating and you already specified it on the leftside, it could very well be optional after the new operator. It's syntactic sugar. It's an example.

Re:Resistence is futile?

[FriedTurkey]

Seeing as the constructor is always the name of the object you're creating

No that was one of my points, it doesn't have to be the name of the object.

Re:Resistence is futile?

[nojomofo]

So you're suggesting that sometimes you specify what class you want and sometimes you don't? For example:

Map myMap = new HashMap();

Sometimes you want to use the constructor for a different class. I just don't understand why people think that conciseness is so much more important than readability. It's nice and clear if you have to specify which constructor you want to run. I guess that some people consider it a badge of honor to produce the most confusing code possible, but some of us live in the real world where our reputation at work depends on producing code that other people can work with (rather than producing code that other people can't figure out).

Re:Resistence is futile?

[Kell_pt]

I can understand that. But maybe readability varies from person to person. I suppose that even if the constructor was optional many would still use it as a matter of programming style.
Maybe this was a bad example - let's try associative arrays for instance. Most modern languages have some means for specifying an associative array with minimum fuss. How does Java make it any clear by making you use a series of function calls to build an associative array?

Re:Resistence is futile?

[Kell_pt]

The constructor IS always the name of the object class you're creating - that's how you declare constructors. It's the variable you're assigning to that might be of a different class.

Re:Resistence is futile?

[Anonymous Brave Guy]

Somebody doesn't understand object oriented programming.

No, somebody doesn't. In most cases, there is no need to specify the type twice to identify the desired behaviour, and indeed in most OO languages you can instantiate type T without doing so. The only time it's necessary to specify two types is when you need a base class reference to identify an object of a derived type, which isn't a very common thing to do.

Maybe

[anpe]

BecauseJavaIsSoDamnVerbose.QuestionMark()

Re:Maybe

[flibuste]

Funny that your username is the name of the French unemployement agency.
With such junior-programmer-like comments like yours, no wonder why...
Every senior programmer will tell you there is nothing like a lengthy variable name, or class name, or whatever has a name and is used to program.
If you really fancy it, Java does not prevent you from writing a class called "A" with a method called b(). However, I am not sure about how much your teammates will like you after that.
Also note that it is actually what obfuscators do...

Java is a dead language, like Latin

[xyote]

It's fairly tightly defined, so you really can't experiment with it the way you can with C. I work with lock-free programming involving alternative forms of GC beside Boehm GC. It's not even something you can think of doing in Java. I keep mentioning JSR-166. That's not something somebody did in Java and then said "hey, let's put this into a native library". Those techniques came from outside Java.

Re: Cheap Shot

[freality]

Actually, programs are abstractions of electrical systems that, though I have programmed a simple CPU in an FPGA and wired up breadboards, etc. etc., I still don't understand. And Physicists don't even understand Physics! And thanks to Gödel, it's clear we don't understand Math! Argh. Who can save us?!

It's an indictment of Aristotle, Kant, the Enlightenment and the Scientific Method that all of our attempts at formalizing the universe blow up in our faces.

Until we approach every program as the algebraic systematic proof of a string-theoretic electrical circuit model, we will be burdened by the inexorable piles of poo that is the vast majority of the software written today.

Parent iInsightful? WTF?

[Anonymous Coward]

Since when is an unsubstantiated flame with absolutely no substance considered "Insightful"? I guess it was moderated by overly sensitive Java developers.

By the way, don't take Paul Graham's comments out of context. His main argument wasn't about what language is better but about what tools are available that hackers like using. He also points out that with Java being touted as the language everything must be written in by PHBs because it's the trendy thing to do (rather than the right language to use) means everyone and their brother wants to learn to be a Java "developer" in order to get hired and make a decent salary. He points out that this makes it more likely to get someone not so good at coding if searching for Java programmers. By contrast, if you put in an ad for Java AND Python programmers (for example) you're more likely to get a good hacker in that position. Not necessarily due to Python being a better language but because someone knowing the language probably wanted to learn it for themselves, not because it was a trendy "I can make lots of money" sort of thing to do.

I equate it to the same problem we have with a mass of "point and click" admins (you know, folks that go through and get their MCSE's to admin Windows networks that don't actually know squat about networks, couldn't write a shell script to save their lives and generally don't know more than the basics and are unable to figure much out on their own apart from what they were trained to do). The problem here isn't that Unix/Linux/BSD is in itself better, but that you don't just have a bunch of geek-wannabes sitting down and thinking, "Damn, I need to learn FreeBSD or get Linux certified because it'll be easy and I can make loads of money and find a job easy!". Does this mean that all Windows admins are idiots? Of course not, it just means that if you advertise a position for a Windows admin and another for a Unix admin, your going to (percentage wise) get more capable folks
applying for the Unix admin position. You may get a few good folks for the Windows admin position but mixed in there will be a horde of point-and-click admins to go through and the problem is, those HR folks probably won't know the difference.

Geeks don't give a damn about coolness.

[SpaghettiPattern]

Geeks don't give a damn about coolness.

Have you ever seen a cool geek?

I rest my case.

Re:Geeks don't give a damn about coolness.

[mandrake*rpgdx]

I'm a geek and I'm cool. Just because you stick yourself into some saved by the bell retarded steroe type doesn't mean the rest of the world has too.

Re:who cares what he says?

[Anonymous Coward]

There are. Several big commercial Common Lisp packages (eg.), and for Scheme (a Lisp variant), a nice little free download from Rice University. I've been playing with the latter since reading Graham's latest, and it's sweet...auto-indenting, highlighting to show matching parens, source-level step-by-step debugging, unit-testing support....then there's Emacs support of lisp code editing (again with the parens matching), and the Bigloo package for well-optimized code that compiles to native or JVM (with full access to Java libraries)...google and you'll find plenty.

Sounds like Bill Gates

[ClosedSource]

"Of all the great programmers I can think of, I know of only one who would voluntarily program in Java. And of all the great programmers I can think of who don't work for Sun, on Java, I know of zero."

Paul Graham sounds a lot like Bill gates in "Programmers at Work" as he talks about great programmers. Gates definition of a great programmer happened to coincide with his own skills and in Graham's case, great programmers hold the same views on Java that he does (and by inference Graham must be a great programmer too, right?)

In both cases, this is self-serving crap. We can debate the value of Java, but let's drop the question begging and the self promotion.

Is C# A Good Alternative?

[GoatChunks]

I know I'm going to regret posting this, because I know you folks like to take every opportunity you can to bash Microsoft, but I'll ask anyway...

I've been a Java developer for a number of years now, and generally like it, though I agree with a lot that has been said here. It's slow, and what I'd call "clunky".

The APIs are great, and for most things my code will run about the same on Linux, Windows, Solaris, or, in some cases, OSX. Given the project I'm on, this is a good thing. We are able to get cross-platform development done quicker and cheaper. Anything that we need good performance on (such as terrain databases and 3D display) we'll use C/C++ for. So there's this mixing of technologies that brings us the best of both worlds. Portability, ease of use, and speed.

Now it seems that .NET is getting some legs. Delphi has all but given up the ghost, and has pretty much decided that the only way it can survive is to be .NET compliant. My limited knowledge of .NET says that the reason .NET is gaining popularity is that it's easy to mix and match languages. So developers can do portions of this big mammoth project in C++, C#, J#, VisualBasic, or Delphi, and these parts can play together seamlessly.

So, I'm wondering, is C# a good alternative to Java? It gives some of the safety nets of Java while coming closer to C/C++ in terms of speed. You all would know better, but I seem to remember hearing that there's a .NET Framework being developed to work on Linux. If/when this becomes a reality, would that change your perspective on the validity of .NET?

Any thoughts are appreciated, but let's try to keep the Microsoft bashing to a minimum, shall we?

Re:Is C# A Good Alternative?

[DevolvingSpud]

C# is a good alternative to Java, in that it is basically Java with the ability to put things like pointers in an "unsafe" block. That's where the "speed gain" comes from. But given the massive improvements in the JIT compilers for Java, the speed difference is negligible or even negative.

Just to make the point that Microsoft's strategy is basically to create a Java clone wrapped in Microsoft marketing, here's an excerpt from a MS presentation at the upcoming Borland Conference:

Converging Roads: .NET, Longhorn, and C++

In this session, the lead Microsoft architect of C++/CLI talks about the importance and viability of environments based on virtual machines and garbage collection, even for performance-driven applications, and demonstrates how C++ operates seamlessly in that environment with a tour of the C++/CLI language design and major features.

http://info.borland.com/conf2004/tracks/speaker/su tterherbmicrosoft.html

Sounds suspiciously like Java to me.

Re:Is C# A Good Alternative?

[The boojum]

I've been studying C# for kicks lately and it's starting to grow on me. When I first saw it, I dismissed it as being so similiar to Java that the old Perlis quote ("A language that doesn't affect the way you think about programming, is not worth knowing.") came to mind and I might as well stick to Java which I'm already proficient at.

But recently I'd wanted to write some Windows GUI programs with native GUI and Delphi's not really viable anymore. So I decided to give C# a second chance and it's growing on me. My opinion now is that it's probably what I'd use if I had to write a GUI program for windows and didn't mind it being non-portable.

Some things that intrigue me are: almost braindead easy interop with native C/C++ DLL's (no scary JNI stuff necessary), native GUI with GUI builder in VS, delegates and an event model, a comprehensive library, fast startup time (the JIT compiler caches data between runs), and it looks like a normal EXE (and can contain resources so it shows an app icon in Explorer, etc.)

So yes, I like that I can write a program which from my perspective is written in a clean, modern, high-level garbage collected language. Users see a program that looks and feels like a plain old fashion Windows app like they're used to. If that's your goal it's a good tool for the toolbox. I'm more of a "right tool for the right job" kinda guy and to me, C# fits the bill for some niches.

For true portability or raw speed, I'd look elsewhere of course. I don't think I'll be porting my renderer from C++ to C# anytime soon. Likewise, I'll be sticking with Java for big enterprise WebApps.

Re:Is C# A Good Alternative?

[kenlars99]

Right, I mean most of the things you mention are possible with Java, but you have to kind of put together your own set of tools. SWT if you want native GUIs, tools to create an EXE, tools to help you with JNI, etc. But the problem is if what you want is a windows app, and you want it right away, as a Java developer I'm sorry to say that C# makes that easier. But that has been where Microsoft has traditionally shined: giving you a complete set of nicely integrated tools and technologies. Now, for larger projects, the overhead of putting together these tools becomes not as important, and the cross-platform capabilities and nice selection of quality open source libraries (Hibernate, etc) led us to choose Java over .Net. But I do wish that Sun would really address these things and make them less painful. Or maybe realistically I should hope for nice Eclipse plugins to make it easier.

Re:Maybe because it's slow ?

[LnxAddct]

Java is not slow. Have you used it in the past 3 years? With the JIT compiler alone, you achieve C++ performance, in come cases better (believe me, I've had to run these benchmarks a million times), and with HotSpot, some java apps run so fast that similar speed can only be achieved by hand coding the app in assembly. HotSpot does on the fly optimizations at the lowest level. It pretty much learns what paths the program takes most often and optimizes for them, its a truly amazing and indispensable thing. The notion of java being slow came from the Swing gui. Swing is a little slow to react everynow and then, but its mainly due to its robustness. Regardless, even Swing isn't really an issue anymore. One of the greatest java apps I've seen recently that was coded really well and shows some of java's potential is Azureus. Java is a great tool in a toolbox of many great tools (i.e. python), and thats how it should be treated. Also, deploying an application with Java's WebStart makes deploying applications fun again:)
Regards,
Steve

Re:Maybe because it's slow ?

[Smallpond]

I have to agree with you that one is more productive writing in Java than C++. However, saying Java is fast as long as you don't use Swing is like saying Phelps isn't much of an athlete except for the swimming. One of the main reasons for the existence of Java is platform-independent graphics.

Personally I have found Perl to be just as fast as Java, and easier to implement graphics applications. I can prototype in perl and code in C+OpenGL if I want speed. As for your statistic, a correctly written OpenGL app spends most of its time in the OpenGL library, which is all written in C.

Site is creeping slow...

[RAMMS EIN]

Since /. is evidently causing a lot of sites trouble, why don't we add a wrapper that will automagically cache linked pages? That way, the site owners will be happy (lower bills) and /.ers will be happy (lower latency).

Re:Site is creeping slow...

[PrimeNumber]

why don't we add a wrapper that will automagically cache linked pages
Just dont write it in java...
Sorry, given the current topic I couldn't pass this one up :)

Re:Maybe because it's slow ?

[contagious_d]

I'm proud to say that my language of choice is Java.
I agree. During my first two years of school we programmed almost exclusively in Java. We were the first incoming freshmen to take the introductory classes after they made the change from teaching in C++, and I noticed that a lot of the people who spent their time complaining about the use of Java were the same ones that failed the classes and changed from CS or IS majors to IT, Meteorology, or Living in the Basement majors. At the time, I was doing most of my schoolwork on an old eMachine with a Cyrix processor, and, although the POS pretty much screeched to a halt when I launched them, it handled Java apps fairly well once they got up and running. Uh, anyway, Yay Java!

One word.

[Atzanteol]

CLASSPATH. This thing sucks. Worst design decision ever, I swear. Spend forever setting the frigging thing up, and hope to $DIETY things don't change. Oh, and make it so you need to reference individual .jar files too! What a great idea? What to add a library to your project? Be prepared to do battle with classpaths.

Anybody know why they decided to make it so you can't just put all .jar's in a *direcotry* referenced by CLASSPATH? I'd love my CLASSPATH to just be "/usr/local/java/lib:${HOME}/java/lib" or something rather than specifying a million .jar files...

Re:One word.

[dajak]

CLASSPATH. This thing sucks. Worst design decision ever, I swear. [..] I'd love my CLASSPATH to just be "/usr/local/java/lib:${HOME}/java/lib" or something rather than specifying a million .jar files...

You want to dump all your libraries in one directory? Now that's a good design decision. Don't forget to check whether Micro$oft patented that practice.

Re:One word.

[anomalous cohort]

Would you rather have to depend on the system registry?

Ultimately, the CLASSPATH is good for you. I don't really understand what the problem is with adding another jar file to this environment variable. If you insist on being lazy, then rejar everything into one big jar. Ant can help you do that.

Re:One word.

[graveyhead]

A bit of shell script ususally solves this:

CLASSPATH=""

for x in `find /usr/local/java/lib -name '*.jar'`; do
CLASSPATH="$CLASSPATH:$x";
done

for x in `find $HOME/java/lib -name '*.jar'`; do
CLASSPATH="$CLASSPATH:$x";
done

You could put the first for x in... statement in the global /etc/bash.bashrc, and put the second $HOME for loop in ~/.bashrc so that it's run on user login.

At least this way you don't have to maintain it, but if you add .jars to one of the directories, you'll have to re-login to bash before starting the runtime.

Hope that helps!

Re:One word.

[Atzanteol]

Oh, god no! I just want it to behave more like 'libraries' under Linux/Unix. Let me edit /etc/java.conf to set which directories hold "libraries" (jar files). Java wants too much on the command line. One needs to be a good shell script writer (and/or batch script writer) as well as a Java developer as it is. Ever seen the weblogic startup scripts? *huge* shell script infrastructure just to setup all the correct params to java.

Re:One word.

[mlk]

CLASSPATH to just be "/usr/local/java/lib:${HOME}/java/lib" or something rather than specifying a million .jar fil

Err, mine is.

Also, for deployment, use Webstart, and not touch the CLASSPATH.

Re:One word.

[That's Unpossible!]

Anybody know why they decided to make it so you can't just put all .jar's in a *direcotry* referenced by CLASSPATH?

This issue was solved a long time ago.

You put your .jar files in the jre/lib/ext directory of your Java Runtime Environment. They are magically found when you use the JRE as your runtime environment. I haven't had to set a classpath environment variable in a long time.

Re:One word.

[Just Some Guy]

Yes, but relying on the backtick operator limits your CLASSPATH to only about 64K characters, so you'll probably need to split that into 5 or 6 chunks.

Re:One word.

[graveyhead]

Yes, but relying on the backtick operator limits your CLASSPATH to only about 64K characters, so you'll probably need to split that into 5 or 6 chunks.

Do you have any clue how much text 64,000 characters is?! I did say "usually" takes care of the problem. I've never seen such a big classpath. You're blowing smoke.

Re:One word.

[adiposity]

Because, the JAR itself represents an entire directory (or more) of class files. It is not one lib, it is many, packaged in a convenient format that saves space and makes them easier to move around. There is no reason they couldn't have implemented it how you want, but keep in mind that every jar in that directory would have to be unzipped every time something wanted to use that classpath. Your idea could be extended to saying "there should be a way to include a dir and every subdir for the c++ library path", and that would be essentially the same concept, except that the c++ dirs wouldn't be nicely packaged. In spite of these points, I actually agree with you; the way jars are used in practice means it's a PITA to set up a classpath with all the jars you end up needing. Being able to include several jars simultaneously with one dir would be welcome. -Dan

Re:One word.

[Just Some Guy]

Yeah, but it was a lot funnier than what you said.

Re:One word.

[miniver]

That's why you use while, not for, as follows:

CLASSPATH=""

find /usr/local/java/lib -name '*.jar' | while read x ; do
CLASSPATH="$CLASSPATH:$x";
done

find $HOME/java/lib -name '*.jar' | while read x ; do
CLASSPATH="$CLASSPATH:$x";
done

Re:One word.

[eison]

Portability warning: Find does not sort; you tend to get things listed in a date-based ordering. If you don't run this through something like 'sort' you can get different / unpredictable classpath orderings, particularly on different systems, which will lead to disaster when two different JARs have two different versions of the same file (and you will - EJB.jar is a fine example of old/different versions of lots of files.)

Re:One word.

[graveyhead]

I assume you meant to reply to my post, since this response has nothing at all to do with Ant. Although the parent brings up a good point - Apache's Ant / Maven solve a lot of the problems we're talking about.

Your question centered around defining 'hot' java directories on a unix-like system. And you're complaining about having to write (7 line!) shell scripts to do it! Um, I may be speaking out of turn here, but perhaps you should consider a different language or environment for your project, especially if it needs more setup than my snippet can provide.

If installation on multiple (including non-unix) platforms is your goal, I'd suggest looking at something like InstallAnywhere or something that takes care of these details for you. If installation is only on a single unix-like platform (say for a www application deployment) that 7 lines of code will take you a long way!

I just don't get it. People must like to complain. :/

Re:One word.

[graveyhead]

Sweet! Didn't know while could take stdin.

You learn something new every day, huh? :)

Thanks,

--g

Re:One word.

[sr180]

And what happens when you use the Java Update to update your JRE... Do all of these extension in the ext get copied across to the new JRE installation?

Re:Maybe because it's slow ?

[kdz13]

quite frankly i don't understand how this would be possible. Given generic compile of c/c++ code this would be true, but when the code is compiled for the arch it will run on, (and assuming the c code is as well done as the java code) i just cannot see it. So, anybody care to explain *how* this could be?

Re:who cares what he says?

[nessus42]

Of course there are full-featured IDE's for Lisp. In fact, the very first IDE's were made for Smalltalk and Lisp.

The fact that you can't understand Lisp speaks more to your intelligence than to the merits of Lisp. As Paul Graham says, he is talking about the tools preferred by the best and the brightest programmers, not by average programmers.

|>oug

In response to your points:

[tonywestonuk]

>> Java GUI is slower than native alternatives

That may be true, however, it's still pritty snappy. on my Pentium 1.5 Ghz, I can still open 20 or so windows (JFRames), with a few fields/buttons/dropdowns in under a second. This is quick enough,

>> Java is not supported by all platforms, and is not supported by WinXP by default.

Java is supported by a good many more platforms (Windows/Macintosh/Linux/IBM iSeries/ Zseries/ to name a few) than Win32 apps, that are supported by , well Windows. It's not Java, or Suns fault that Microsoft have refused to install a JVM as default... Are you saying you do not like Java, because Microsoft does not like Java?

>> All the Java "binaries" I've tried relies on me having installed a local interpreter.

All the Win32 apps I've tried relies on me having installed a local copy of Windows, which Requires *86 compatable chip. At least Java allows you to decide which hardware you wish to run your app.

>> It's object oriented.

There's nothing stopping you writing a huge Java class, using nothing but public static methods (and end up with a procedural pile of shite)..

LISP IDE

[flink]

Here you go.

Re:LISP IDE

[Fujisawa Sensei]

Even better

Re:LISP IDE

[flink]

:-P

Re:LISP IDE

[roju]

grin, not to get into an religious argument here - but do keep in mind that emacs is written in (e)lisp, and has been optimized for writing itself. *shivers*

I don't want cool

[JavaPriest]

Who cares if a language is cool?

My customers (and me) want an application that works, is maintanable and runs on platforms on which they haven't decided yet.

I use Java to program those applications. And they live up to their expectations.

I once attended a .Net convention. There Java was considered "uncool" because you had to think before writing a program. That did put some things in perspective...

penil angst

[mandrake*rpgdx]

He really doesn't get it. Java is not uncool for any of those reasons. Grahm states in his essay why Java is now uncool. Because it was overhyped. Because we are told it's cool. It doesn't have street cred. And a lot of people believed the hype when it came out, used it, saw it was too slow and got burned by the Hype. But in contrast, I see the same thing happening to Python. It's over hyped (although for the moment it has street cred), and it's slow. If I was a Java Dev'r, I wouldn't take the words of a man who still thinks Lisp is god's gift to programming language, that C++ is inferior to C, and that hacker cred is worth a pile of shit in a compost heap.

You've all got it wrong...

[Anonymous Coward]

Brainfuck is by far the best language ever concieved :)

Because it is a limiting language

[An Elephant]

Java is considered uncool among good programmers because good programmers seek abstractions, and factoring out commonalities. Java limits painfully the set of abstractions you can express.

The one most painful issue for me (when I wrote Java) was function objects. Java makes using functions as arguments, variables, etc. very painful (not to mention Lisp or Python's ideas of constructing functions on the fly). C# delegates cover a whole lot of that ground. I read the articles on java.sun.com explaining why there will never be delegates in Java; they are nothing but hubris and NIH syndrome.

Then you have the issues with collections (to be fixed, we're told, in 1.5) -- the omnipresent downcasts. Now, go read Stroustroup about downcasts. In C++, there are exactly two situations where you really need downcasts:
1) you're interfacing with non-C++ code, sending pointers back and forth
2) A design error
This is because C++ supports proper type abstractions.
Then look at Python, Perl, JavaScript, or any other dynamic language: downcasts are not needed and make no sense.

So -- the most common operation (modulu assignment and method call) in Java is one that is not needed in dynamic languages, and indicative of a design error in proper static-typed languages.

Java forces one to repeat oneself, because it excludes important classes of abstractions. This is why it sucks, and why it is uncool.

Re:Because it is a limiting language

[graveyhead]

Man you are so full of shit I can't believe this post is modded +5 and no-one has responded.

First you say:

Java makes using functions as arguments, variables, etc. very painful

Yeah, and your point is? In case you didn't notice, passing functions as arguments does not make the worlds most legible / maintainable code. On the other hand, an explicit interface is both legible and maintainable, plus you have an explicit place for documenting the interface (Javadoc in the interface definition).

Then you go on to say:

Then you have the issues with collections (to be fixed, we're told, in 1.5) -- the omnipresent downcasts.

This is an implicit downcast:

class foo { ; }

class bar extends foo { ; }

foo f = new bar();

It compiles perfectly and works as expected.

The last line of this:

ArrayList l = new ArrayList();
l.append("A String");
String s = (String)l.item(0);

Is an upcast. and I dare you to find a list implementation in any type-strong language that doesn't require an upcast in this situation. You need it to be able to store objects of an anonymous type on a list.

How such misinformed tripe ends up at +5, I'll never know...

Re:Because it is a limiting language

[Aragorn379]

Quote:

The last line of this:

ArrayList l = new ArrayList();
l.append("A String");
String s = (String)l.item(0);

Is an upcast. and I dare you to find a list implementation in any type-strong language that doesn't require an upcast in this situation. You need it to be able to store objects of an anonymous type on a list.

Whenever I want a container of objects, I always want them to be of the same type or have the same base type. Otherwise, it usually doesn't make any sense to put them in the same container. At least 95% of the time, they will all have the same type.

C++ allows me to express this:

std::vector l;
l.push_back("A String");
std::string s = l[0];

No upcast required because I can tell the compiler that I'm only going to store strings in my vector rather than always having to store an Object. This also makes Java harder to read because when looking at a container, it is impossible to tell from the variable declaration what type of object will be stored in the container.

Re:Because it is a limiting language

[dvdeug]

In case you didn't notice, passing functions as arguments does not make the worlds most legible / maintainable code

I think a lot of people didn't notice. Given an IntegrateRtoR(foo) function, what type do you expect foo to have? What's wrong with a function Apply (function, list), that applies a function to every element of the list and returns the resulting list? If you want to change list to be a tree or an array, you just have to add a function Apply (function, tree) instead of changing every place in the code where you would use Apply.

Re:Because it is a limiting language

[graveyhead]

OK I was wrong about upcast / downcast. I looked it up and the other posters are correct. That meaning is strange to me, because I envision the class hierarchy upside-down apparently :/

As far as templates are concerned - gimme a break everyone. They are simply syntactic sugar - a macro language that is preprocessed before compiling to binary. So even though you didn't have to deal with the cast, it still exists. Sorry if it was too much for your mind to handle before templates came along.

Re: the specific case of STL that has been mentioned here - the no-casting is a *side effect* of the template implentation of STL, not the goal. The goal is to allow differently sized structures as data on the list instead of e.g. requiring that only pointers are put there. The templating system plops the explicit type names into the generated code.

Templates may sheild you from writing casts, but that doesn't mean they aren't there!

Re:Because it is a limiting language

[graveyhead]

Wrapping the function into an interface is laughable and not desired, interfaces are always public.

And I'm an idiot?! :)

Here's a non-public interface (or the functional equivelant):

public class SomeOuterClass {
class NonPublicInterface {
public abstract void myMethod();
}
class NonPublicImplementation extends NonPublicInterface {
public void myMethod() {
System.out.println("My Method!");
}
}
}

Because of inner-classes, you can define them right inline with your invoking class, if you so desire.

That you cannot use dynamic functions.

WTF do you mean 'dynamic functions'? If you implement the above interface 5 different ways, it's functionally equivelant to writing 5 functions and passing them. Plus, it's much more explicit and like I said before, gives you a place to write documentation.

Re:Because it is a limiting language

[Sax Maniac]

Templates may sheild you from writing casts, but that doesn't mean they aren't there!

No, if you have collection class that stores objects (not pointers) each generated copy of the class is totally type-safe. No casts at all. Value semantics are done by operator= and copy construction. If you try to generate a class that doesn't fit with what the template is doing, you'll get a compile error. A C-style cast would just blithely get it wrong.

The partial-specialization trick of having a single underlying pointer-based implementation that's cast to is a possible optimization for pointer-based collections. That's far from being to only thing templates can do.

But, in C++, you can have a collection of objects, which is not a collection of pointers to objects. So, for a 10,000 object collection, all 10,000 do not need to be indivdually be on the heap in their own blocks. That kind of aggregation is a huge optimization boon for real code.

Re:Because it is a limiting language

[kenlars99]

function objects? Ever heard of classes or interfaces? Ok, I'll admit, for button click handlers and the like, delegates reduce the amount of code nicely, but for almost everything else, using interfaces and classes is far more elegant.

Re:Because it is a limiting language

[wirelessbuzzers]

The last line of this:

ArrayList l = new ArrayList();
l.append("A String");
String s = (String)l.item(0);

Is an upcast. and I dare you to find a list implementation in any type-strong language that doesn't require an upcast in this situation. You need it to be able to store objects of an anonymous type on a list.

Yes, but typestrong languages don't like lists of objects of anonymous types.

For example, in OCaml:

# let l = []
let l = "A string" :: l
let s = List.hd l
;;
val l : string list = ["A String"]
val s : string = "A String"

Note that I didn't specify any types there (I could have, but I chose not to), and the compiler figured it out. Of course, I didn't use an ArrayList, or even any real objects. Let's try that again with objects, supposing I have a class ['a] arrayList.

# let l = new arrayList
let _ = l#append "A String"
let s = l#item 0
;;
val l : string testlist = <obj>
val s : string = "A String"

What if I'd goofed and tried to use it as an integer?

# let l = new arrayList
let _ = l#append "A String"
let s = 5 + l#item 0
;;
This expression has type string but is used here with type int

(And it underlines the 5+l#item 0 in the console.)

Re:Because it is a limiting language

[wirelessbuzzers]

What is this supposed to prove? Java is strongly typed, but not dynamically typed. The only reason your code does not require a cast is because you are using dynamic typing and "figuring out" the type at runtime. Big deal.

No. OCaml is strongly, statically typed and its type-safety is figured out at compile time. Of course, if you're running in the interpreter, compile time is directly before runtime, but if I had tried to compile the code (either to bytecode or to machine code) instead of run it in the interpreter, it would have given me the same error (with a line number).

Re:Because it is a limiting language

[An Elephant]

Let me rephrase your parent post: Wrapping the function in an interface (anonymous class) or an inner class makes for cumbersome, cluttered code. Instead of code you can look at and see what it's doing, you get a place for documentation that can go miles out of sync with the code.

Dynamic functions, my dear totally uninformed friend, are functions built on the fly by the program, in myriad ways -- basically, composing functions, applying higher-order functions to functions (look it up), and many other interesting things. C++ supports these notions in its standard library, in a header called <functional>, because they are elements of the functional programming paradigm. Java thinks functional is not useful, because it aims at a very low common denominator of programmers -- hence its uncoolness.

What you said earlier about passing functions around amounts to "I am not familiar with the abstractions you like, therefore they are bad". This fits in with the head-in-the-wall object-oriented approach of Java, but is not good for you. If you want to evolve as a programmer, you'll always look for new ways to abstract things.

You were wrong about the directions of casts, you were wrong about the meaning of templates. You should at least consider the possibility that your all-Java education (yes, it shows) has led you to miss a few other useful notions.

BTW: the templates In Java 1.5 are indeed only syntactic sugar, because the JVM doesn't support templates and is itself cast in stone. The CLR -- which I generally don't think too highly of -- does make room for templates, and their implementation in C#2.0 will be closer in spirit to C++'s). And even though Java's generics are only syntactic sugar, they are a great improvement.

Re:Because it is a limiting language

[An Elephant]

The specific case where I cursed the most about not having delegates in Java was a little parser which had to modify a "result object" according to "events" detected in the input string. Nothing to do with UI. There was one state object, with many methods to effect the changes, and the most natural thing would have been to install those methods as callbacks in the more general parser object. Which I ended up doing, but I had to use reflection to do it, so I passed method names (strings) instead of method objects.

Yuck.

Re:Because it is a limiting language

[kenlars99]

Maybe I'm not completely understanding what you are doing, but I'm not convinced that simply using the observer design pattern, with say, an interface "ParserObserver".

Re:Because it is a limiting language

[Anonymous Brave Guy]

function objects? Ever heard of classes or interfaces?

Do you know what a function object is?

[...] for almost everything else, using interfaces and classes is far more elegant.

No, it really isn't. Take a look at a language that supports closures some time, or just at something like Perl's sort function or C++'s STL algorithms. Function objects live in that world, and while they are not the most powerful concept it has to offer, in comparison the elementary support for interfaces and classes in Java falls a long way short.

Re:Because it is a limiting language

[kenlars99]

I respectfully disagree. I've used C++ for many years before I switched to Java, and C++ itself generally removed the need for function pointers. Thats one of the thing any object oriented language does, because an object basically has a set of function pointers. The only time I ever really needed function pointers in C++ was to call some API function that required one.

STL is generally unnecessary in Java because of the Collections API. Things like sorting - hey, an interface like IComparer or IComparable works very nicely as a replacement for function pointers.

In every case you use a function pointer, you can declare an interface with that signature. It is completely equivalent in terms of functionality, but in my opinion it makes it clearer what is going on. A function object is simply equivalent to an object with a single method, no?

Now, a delegate or a function pointer is less code, I concede, but I would argue that this is not really a burden except when adding lots of button click handlers by hand. In the case of GUIs, usually a GUI builder will relieve you of this tedious task. In the case of a parser, I'm still having trouble imagining that the better design would really use function pointers over interfaces.

One of the guidelines taught to people moving from C to C++ is that any time you write a switch statement - stop and think, could you do this in an object-oriented way, with polymorphism? Now, not all cases are better handled using polymorphism, but a large proportion are. I'll venture to assert the same thing about function pointers. Again, not all cases, but most of them.

Re:Because it is a limiting language

[Anonymous Brave Guy]

A function object is simply equivalent to an object with a single method, no?

In a sense, but it's usually used to mean an object that can be treated like a function, right up to calling it with function notation. It thus becomes a "function with a memory", which can be customised at run-time, in the same sense that closures allow this. It's a step towards the power of full first-order functions, without requiring all the other aspects of functional programming and still fitting in neatly with a principally OO language.

The technique you describe using interfaces is fairly isomorphic to using function pointers, I agree, albeit with a rather more cumbersome syntax IMHO. In that respect, interfaces (or pointers to base classes in C++) do indeed replace many uses of a function pointer in C. That's still some way short of replacing function objects, however, which was all I was saying.

Re:Java is slow, bulky, and mostly useless...

[smack.addict]

Applets (Java in your browser) make up a tiny minority of Java applications. I would be willing to bet less than 1%. Java is mostly used on the server where it is undoubtedly the best language for building applications (as long as you avoid EJBs).

This annoys me!

[Anonymous Coward]

Background:
Currently I program about 30% of the time in Java, 30% of the time in WebMacro (similar to PHP), 20% in C and the rest in Perl/bash.

1. "Java is uncool"
All languages have their purpose. Java is THE multipurpose development platform for Big Business (use google and do some research). So, yeah, it is uncool.

2. "Java is not write once run anywhere"
All of my software has been write once, run anywhere. Currently I develop and test on a Win32 machine and deploy on a Linux box.

In previous professions I have deployed software on Solaris and also deployed on IBM JVM's with code written and tested on Sun JVM's.

3. Why Java over c and the like:
I have outsourced work to India, and, irregardless of the standard of code returned, I have always been able to immediately takeover/finalize projects. The Java language makes things a lot easier to manage at a higher level. All of the magic associated to c/perl hacking is negated by javas rich libraries (definitely catching up to CPAN) and enforced syntax and of course javadoc. Maybe you guys are afraid of losing your superiority over the stupid managers etc?

In the past, when I have outsourced c code to India, I have spent many, MANY days fixing the mess or even rewriting things from scratch (I am fairly busy and I outsource prototype development - it is still cheaper than hiring a westerner).

4. Java runs slower:
This is the biggest crock of dog turd that anyone can use as an excuse against Java.

Of course it runs slower, IDIOTS!!! It has to run the jvm first and load up associated libraries. If this is too slow for you, then, look into native java compilers (jcc or whatever it is called).

The real slow startup time for java (takes less than a second on current machines) is not usually due to the jvm loading, but, due to poor programming of the target application.

5. Java is not open source.
So? Idiot.

To conclude:
* The geek community should stop being stupid about Java.
* Java systems will ALWAYS need C++/C/Perl/Bash interfaces, and there are many niche markets for people to work with integrating java software.
* What Java offers is what the big Corporates want, this is proven by the similarities of c#, and the latest Perl and PHP versions.

Stop blinding bagging Java and instead make money integrating with it!

Also, if you think that javascript and java are related, then, go back to your trailer park!

Re:who cares what he says?

[kfg]

I think by "business enviroment" he means "prairie dog colony."

In that respect he's probably right, Paul would likely not fit in as a code monkey. Like he'd consider that a bad thing.

KFG

Re:lame

[Halo-]

>>Java GUI is slower than native alternatives >Not really. Tried it recently? eclipse is a good example (eclipse.org) of fast java program. SWT == Native widget bindings. This is why you get to chose if you want to download the "Motif" or "GTK" version of Eclipse for Unix systems... That being said, GUI's in Java tend to be slow (IMHO) mainly because the developers writing them don't properly use the EventQueue and helper threads correctly. Writing a GUI which doesn't block in Java is somehow conceptually harder than in C/C++ even though the tools/methods are part of the SDK. Dunno why that is... >>Java is not supported by all platforms >You can get a JVM for most if not all platforms. It also works on XP (don't confuse MS JVM as being a workable JVM, its years old). This is sorta non-argument. Every platform has it's own JVM (just like every platform has its own C compiler). The problem is that JVM's are large, and often liscensed differently. (For example, HP has a funky license) With a compiled language like C, you have to track down compiliers for every platform you support, but you only have to ship the resulting binary. For Java, you have to ship the JVM which you have a lot less control over. Now, other interpreted languages, like Perl, have the same need to provide the "VM" but there are fewer providers. (Unlike Java which has a ton of different implementors all working towards the same "spec")

Re:Maybe because it's slow ?

[Florian Weimer]

Thats a programmer error. A bad programmer can make anything happen.

Of course it is. It's a bit shortsighted to assume that Java magically makes bad programmers less risky.

Same reason as everything else

[Kohath]

Java is uncool because people are snobs. You can't think you're better than everyone else without thinking that the popular choices are beneath you.

Let me summarize the attitude:

I'm better than you. I'm one of the good ones, not one of the masses. Java? You still use that? I used to use that, but now I only program in the new super-trendy "Rubytalk" It's a Ruby-smalltalk hybrid, but I tweaked the compiler so none of the keywords are longer than 3 letters.

I have to go now. I have reservations at the new "Chittii" restaurant. I had to make them 3 months ago. All the food is vegan. You Java programmers probably eat at McDonald's and shop Walmart with the rest of the proles.

Bye. Oh, and tomorrow I'm taking the day off. PBS is running a six-part biography series on British showtunes composers. It's the only channel I watch.

Re:Same reason as everything else

[narsiman]

yeah that is because we are red amygdala and you are blue.
oh wait that was on a different subject. . .

Re:Java is unpractical!!!

[gwynevans]

And how much of the 3GB did you actually allocate to the JVM on startup? From memory, the default settings just allocate 64MB's memory...

Sounds like an ID:10-T error to me...

Re:Why, Perl, of course.

[black mariah]

If you can't develop fast in Python, you're a fucking moron. Even my idiot ass has made usable programs in Python.

Re:Maybe because it's slow ?

[timbloid]

Have you tried JRE 1.5?

There has been a massive speed-up in the load time...

Re:Why, Perl, of course.

[sean23007]

HAHAHAHAHAHAHAHAHAHA.

Okay. Got that off my chest. But I should just point out that Python programmers can write the code as fast as anyone else. (It was kind of a main talking point for Paul Graham: great hackers like it because it communicates what they want to get done very quickly and with few lines.)

Re:lame (now with formatting! sorry...)

[Halo-]

>>Java GUI is slower than native alternatives

>Not really. Tried it recently? eclipse is a good example (eclipse.org) of fast java program.

SWT == Native widget bindings. This is why you get to chose if you want to download the "Motif" or "GTK" version of Eclipse for Unix systems... That being said, GUI's in Java tend to be slow (IMHO) mainly because the developers writing them don't properly use the EventQueue and helper threads correctly. Writing a GUI which doesn't block in Java is somehow conceptually harder than in C/C++ even though the tools/methods are part of the SDK. Dunno why that is...

>>Java is not supported by all platforms

>You can get a JVM for most if not all platforms. It also works on XP (don't confuse MS JVM as being a workable JVM, its years old).

This is sorta non-argument. Every platform has it's own JVM (just like every platform has its own C compiler). The problem is that JVM's are large, and often liscensed differently. (For example, HP has a funky license)

With a compiled language like C, you have to track down compiliers for every platform you support, but you only have to ship the resulting binary. For Java, you have to ship the JVM which you have a lot less control over. Now, other interpreted languages, like Perl, have the same need to provide the "VM" but there are fewer providers. (Unlike Java which has a ton of different implementors all working towards the same "spec")

Gee... I guess preview would have been good above... sorry...

Clarification

[someguyintoronto]

Actually Java was not "designed" to be used in web-based apps. Its initial design goal was to be platform independent. AWT was thought to be the killer app of Java (ok, true applets are sort-of web-based).

It only became web-based after AWT failed due to horrible performance (early VM) requiring higher client-side system requirements. It moved to the server because at that time servers had the juice to power the VM and Sun needed something to keep it alive. In fact the "web-based design" are really just extension APIs. The servlet spec only made it to the standard distro in 1.4 (maybe a version earlier I forget this).

Not to knock Java, cause it pays my bills too. It is important if we insist on getting into these stupid bickering sessions to know what the original intention of the language was and how it evolved to what it is today.

Re:who cares what he says?

[toomuchPerl]

i can't believe you got modded insightful. paul graham built a successful ecommerce site using LISP, FreeBSD, and no relational database systems. he and his co-developer robert morris sold it to yahoo for 50 million.

think about that before you go to insult him again, and say that he's detached from the real world.
-toomuchPerl

2 sides of the story

[mrjb]

> Java was designed to be easily learned, and to especially be used in web-based apps.

Exactly, and the web was designed specifically for graceful degradation. Most of the time, it isn't trivial to gracefully degrade a java applet. In many cases, Java is overkill.

Many business applications rely on form entry and report generation, which can perfectly (if not better) be done by server-generated HTML. As a bonus, the apps will also work using lynx in an SSH terminal. For a long time I have avoided writing Java apps for two reasons: First of all, I didn't need it because http+php+JavaScript already do all I want, and secondly, (perhaps nowadays misplaced feeling that) it is slow.

However, I recently started using Java in an area where I feel it does have its uses though: Desktop database applications. It gives users the feeling that they are working with a program instead of browsing the web, and the back button of the browser no longer gets in the way. I too, used to have the impression that Java was slow; however I also heard that nowadays its performance compares with C++, for which I found it hard to develop truely cross platform. In any case, in database/business applications, the bottleneck is hardly ever the user interface, but rather the database. I enjoy working with NetBeans, it's a very mature IDE. I haven't (yet) gotten to the point where Java breaks its write-once-run-anywhere promise, I guess it also depends on how you write your code. If you insist on calling the Windows API, your code won't run on a Mac or in Linux, but it's not fair to blame the language. Of course, my Java desktop database apps are still not going to present users with a windowed user interface on text terminals, unlike lynx.

Re:2 sides of the story

[Pfhreakaz0id]

Now you start to see why VB was so popular. So much of business programming was client-server desktop db applications. And VB was simply unmatched in that area for cranking them out. Belive me, if you think netbeans and java is a nice environment, it's primitive compared to Visual Studio and Vb. Of course, not cross-platform, but for 99.5% of the business world, that doesn't matter.

Re:Maybe because it's slow ?

[WindBourne]

To summarize, in C: many mallocs - zero frees == bloated crapware while in Java: many news - zero "= null"s == bloated crapware

look. If you have to make a call to free the memory, then you have no difference. It will still be a missed call. Besides, I do not think that it is GC that is the real problem. The real problem is that Java encourages lessor coders to do the work. These coders will take shortcuts and not think once about memory. They will use algo that involve creation of many times the # of objects needed and then will blame either Java or GC.

I do not believe for a second that a well written java app is going to perform nearly as well as a well-written C/C++ app. But, it will be more than adequate for the enterprise

Graham blew it in his GH essay

[Baldrson]

Graham's Succinctness is Power essay is right on, however the word "succinct" doesn't occur in Graham's Great Hackers essay. Nor does the word "terse".

It's clear Graham got the cart before the horse in his Great Hackers essay.

He should have led that essay with this quote from "Succinctness is Power":

"The quantity of meaning compressed into a small space by algebraic signs, is another circumstance that facilitates the reasonings we are accustomed to carry on by their aid."

- Charles Babbage, quoted in Iverson's Turing Award Lecture

He should have reiterated that point again in the middle of the GH essay and he should have ended with it.

Re:Graham blew it in his GH essay

[good-n-nappy]

OK, I just read that essay "Succinctness is Power." I think his starting hypothesis is totally bogus. He claims that the reason we use high level languages instead of assembly is to make programs shorter. That's a huge generalization. Yes, assembly is usually going to be longer but that's not it's main problem. Just taking the second link from a Google search suggests that the main advantage of high-level languages over low-level languages is that they are easier to read, write, and maintain. High level languages also often have the advantage of being platform independent and abstracting the details of hardware operations.

I would also like to point out that "power" is not that meaningful. The thing we should be talking about is efficiency. I think you have to take into account the amount of mental effort you have to put into the language to get out the power. Not just the first time you look at the code but every time.

To give an extreme example from my own practice - I usually don't even use "i++" to increment a variable. I find that understanding these statements takes me a few extra seconds (over "i=i+1") to convince myself of what's going on. Maybe "i++" has more power since it takes two less characters and can be combined with other actions such as "j=i++", but the efficiency is much lower for me because I have to spend extra time every time I look at that piece of code.

Kids these days. Sheesh.

[rs79]

Oh, look at Mr. fancy pants, he has a HARD DRIVE and a NAIL. When I was a kid we DREAMED of having a hard drive and nails hadn't been invented. We had a pointy stick and a deck of Univac 90 column punch cards.

Re:Kids these days. Sheesh.

[black mariah]

PUNCH CARDS? I WISH I had punch cards when I was your age, fuckin' whippersnapper. When I was YOUR age I had to count on ANTS. That's right. ANTS. I lined those fuckers up in binary. Red ants for 1, black ants for 0. I INVENTED distributed computing when I got the red ones to attack the black ones. I was doing crowd simulations before those Weta fuckers stole my idea. You don't even want to know what I used when I was a KID. FINGERS. That's right. I programmed my first OS using nothing but my fingers. I had 10 BITS of memory. You think your idiot ass could program an ENTIRE operating system in TEN BITS? I think not. Damn kids.

What's wrong with Java

[Pedrito]

To me, Java as a language is an excellent language. I think where it fails isn't the language itself so much as the user interface libraries. Most of them looks terrible and the ones that look decent are slow. At least this has been my experience. I have yet to use a Java user interface that made me "comfortable" as a user.

From a programming point of view, it's an excellent language. It has great features for producing code quickly as well as many features to minimize buggy code. But these things are only technically good. They don't necessarily produce programs that users want to use. To me this is the biggest failing of Java.

But like I said, it's not so much a failing of Java, but the UI libraries available for it.

You make good points, here's my back-patting:

[jm007]

Disclaimer: I've only done a smattering of Java here and there.

I can appreciate its potential and comprehensive libaries. I have even contemplated using it for personal projects for which I could choose anything. However, before I can even begin the first line of code, "It requires too much crap to be installed" is my sentiment exactly. By the time I set up the environment for Java (from scratch), I could have set up a db and begun a rudimentary, functional UI to start data I/O using other technologies (MS and/or OSS). More time can then be spent on biz logic and optimization -- even the UI!

Any yes, "Extreme object-orientedness..." does seem to involve buttloads of explicitly-called instances, each of which has several other similar classes that might do the job better but unless I have years of experience to know which is best, I just go with what seems to work.

The GUI, oh... *sigh* the GUI. Quite possibly the worst part of Java development. Improvements to this area are seen as just sucking less than the previous incarnation.

I know, I know... there are (good?) reasons and explanations to rebut all mine and the parent's comments but at the end of the day, I just need to get the job done; obstacles that can be avoided, at any level of development, will be given strong consideration.

The Pragmatic Program Inverse Theory

[kvnmcsc]

During the last 20 years that I've been a professional programmer I've developed a theory that says, the more practical an application will be to the larger masses, the less cool it is to programmers. A corollary being that the tools to create uncool applications will also be uncool.

Consider the coolest programming jobs: game developer, theoretical research and embedded missile guidance systems, etc...

Now consider: accounting applications, banking applications and word processors - arguably the most used, most common, most practical of applications - and low down on the programming pole.

And then there are the tools used to build those applications: at the top of the pole assembly, C, Perl; at the bottom: Java, Basic, C#. Again the uncool languages are associated with building uncool apps.

It's a simple as that.

Finally, the exception that proves the rule is operating systems. Linux being a perfect example of a cool thing to work on and eminently practical. I would argue however, that the OS is unseen by the masses. The translucent background against which applications are run, thereby exempting them from the theory.

Re:Maybe because it's slow ?

[molarmass192]

Solid post but I wouldn't say bounds checking is the primary reason why Java is "considered" slow. I think the blame rests squarely on Swing, not AWT, Swing. I primarily write console and server side code in Java and it's plenty fast (Java's console line buffer I/O is NOT cool ... but that's a whole other story). Swing has gotten better as of 1.4 with the switch to Java 2D, but it's still not responsive enough for some. With the renewed emphasis on desktop apps, hopefully the gap between Swing + Java 2D and native widgets will close even more. That aside, getting bad Java programmers to stop writting bad code is a whole aspect ... maybe a "Programming 101" enabled optimizer? :D

Virtual-Machine is a nonsense resource-eater

[SillyCON]

... for executing local applications. It consumes large chunks of processor time and memory (and the garbage collector never worked very fine), and is loaded and executed (so, add the loading time) for EVERY concurrent instance. Four or five simultaneous programs (think a simply web shop or corporative portal) can collapse your system, and its suposed to be designed for enterprise environments!The only thing Java does great is distribute the workload... Among the coders, I mean.

Re:Virtual-Machine is a nonsense resource-eater

[togginho]

i don't get it - reading all these comments about "java is too slow, java uses too much memory" - one must thing everyone's got a real-time airline cargo logistics system running on their box. or, their box is too old and too slow... embrace change and step through the gigahertz barrier, people ;-)

You haven't used Eclipse

[revscat]

I'm a Java developer, and I completely agree with what you said. JBuilder is a waste, and Forte/NetBeans is absolutely atrocious: everything but the kitchen sink is thrown into the default install, and it makes it gargantuan and inelegant.

Having said that, however, you should be aware that 80% of Java developers these days use Eclipse. This is IBM's donation to the world of IDEs, and IBM has recently announced that all (!) future applications written by them will use the Eclipse framework. It is fast, uses SWT instead of Swing (meaning you have access to the native windowing subsystem, instead of having to deal with a new [Swing] one), and incredibly flexible. I come from a MS background, and I have to say that I *vastly* prefer Eclipse to VS.NET; it's leaner, meaner, and far and away more intuitive.

Re:You haven't used Eclipse

[kisrael]

Cool, I gotta check it out...

but looks like I gotta upgrade my JVM/SDK first :-)

Re:Maybe because it's slow ?

[slartibart]

I managed to get an approx. 3000 time speed increase for the C++ version be making it non-recursive.

Did you try making the Java version non-recursive?

Why I don't do Java

[vbweenie]

1. Primitive type system (compared to Haskell or O'Caml). One of the reasons for Java's verbosity is the lack of type inference. Another is the absence (until very recently) of type parameterisation (now provided, kinda, by generics). You're stuck with a cumbersome, inflexible type system that forces you into cumbersome, bloat-inducing "design patterns" every time you want to glue two different kinds of thing together. No wonder everyone's defecting to Python.
2. No first-class functions. Java's "object-oriented", you say? So's Smalltalk, in the truest sense of the expression (everything's an object), and Smalltalk has blocks which are true closures and can be passed around and composed together to your heart's content.
3. The most tiresome exception-handling mechanism of any mainstream language ever.
4. J2EE. Yes, I know you don't have to use it. Yes, I know you can use some of it without having to use all of it. Yes, I'm sure there are cases where you really do need the things J2EE endeavours to provide. None of that makes J2EE anything other than a stinking morass of terrible design, responsible for hours upon hours of pointless busywork for coders and an entire industry of consultants whose sole contribution to the field of human knowledge is finding ways to make-believe the J2EE is anything other than a total, hopeless, hideous loss. Why's this a reason for not using Java? Because it tells you how Java people - I mean specifically the Sun suits responsible for Java-the-product - think. It tells you how much they value the time and intelligence of Java programmers. And, most importantly, it tells you that there's a sucker born every minute. And that sucker is telling the developers on his team that they've got to use Java, so he can replace them cheaply when they finally collapse of boredom, self-loathing and the frustration of working on yet another never-ending J2EE behemoth that could have been implemented in a quarter of the time with a few well-crafted Perl scripts.

Re:Maybe because it's slow ?

[mwood]

I think that some of the attitude is not against Java so much as it is against the Java zealots. There are few things as off-putting as somebody else's religion, if it's thrust in your face. The whole OO scene has too many zealots and not enough skilful apologists.

I had an "ewww, Java" attitude and I got over it. It's a good tool and I'm glad I added it to my toolbox. I use it when it's appropriate, and select something else when it isn't. It's great, for example, when I want to develop on Linux, then just hand a .jar over to those folk who use MS Windows or MacOS.

(If the truth be known, I'm actually quite vain about the number of different tools I use. I feel good about being able to use C, Java, Tcl, Perl, bash, and even (shudder) VBscript, sometimes two or three in one project. If I still had access to COBOL and DCL I'd be using those too, where appropriate.)

Re:PHP...PHP offers both....

[smack.addict]

I know I know PHP and Java are not actually in the same category.

No, JSP and PHP are in the same category. PHP is great... if you like security holes and unmaintainable code.

However, the problem with Java is its damn slow,

That's an absolute load of shit. I wrote a content management system in Java and JSP (Simplicis) and it performs spectacularly.

its not nearly as cross platform compatible as it would have you believe,

Another line of nonsense. Two areas have minor cross-platform issues: complex file management and complex UI programming. Of all the applications I have written in Java (and I have been building Java apps since 1996), I have never encountered a cross-platform issue that took more than a few moments to address. And I have deployed my apps on systems as diverse as Mac OS X, Mac OS 9, Windows, AS/400, Linux, Solaris, AIX, and HP/UX.

its libs are a f***ing mess to say the least.

Some libraries are a mess; others are brilliant. That's about what I would expect from a language this mature. You end up with API's like JAAS that are a steaming pile of shit, API's like the date/calendaring API that are brilliant but too complex for common needs, and API's like JDBC that are dead on what an API should be.

Would kill for a Java job

[Anonymous Meoward]

For what it's worth, I'm a C++ guru with lots of experience in embedded systems. I would love to use Java on a regular basis.

It's part of my personal desire to get back into the applications arena. And it's because I like steady paychecks. And because I'd love to get more exposure to databases and Web services. (If you have tips on this, by all means share.)

I personally don't care very much if Java is a bit slower, more verbose, etc. Fact is, the language is cleaner than what I'm used to working with.

(To be fair, part of the prejudice results from debugging C++ code written by EEs and hardware geeks who have no clue about software construction. I would never have to work again if I had $1 for every time somebody created a data structure, saved it to NVRAM, and said, "Oooh, looky at my new database!" Uh huh. In your under-qualified dreams, my friend.)

In short, it would be nice to work with an OO language that doesn't have the more nefarious 1970s-era baggage of legacy C, and that (gasp!) supports threading and introspection cleanly. And one that employers are demanding...

Paul Graham

[The AtomicPunk]

He's always struck me as something of an ass.

When slashdot ran his piece bragging about how his Lisp software ran the most stores on the Internet at 14,000 - I sent him an email pointing out that Vstore ran over 500,000 on a Java system.

He said that "didn't count because it's different."

That's some serious ego.

Re:Paul Graham

[Tiny Elvis]

Well is Vstore really different or not? If it is different then you are the ass, not he.

Re:Paul Graham

[The AtomicPunk]

Maybe he's not the ass, but you certainly are the retard.

Actually he never even explained why it was 'different' he just blew off the comparison.

Re:Maybe because it's slow ?

[Cyberax]

JRE is about 7Mb.

Java Basher vs. Java Apologist

[RAMMS EIN]

I think the author could have done a much better job at debunking those myths. I, for one, am not convinced. Some snippets:

``you cannot really make your friends go ga-ga at amazingly brief programming constructs.''

Right. When you have to write BufferedReader in = new BufferedReader(new InputStreamReader(System.in)), that indeed doesn't give a strong sense of brevity. Nor does public static void main(String argv[]).

``Java has been considered slow for ages.''

And it's still slow. Each time a new release comes out, people get into the debate of Java is slow vs. you moron did you actually test that? Well, after 1.4 I have given up on testing. It's slower than unoptimized C for all programs I have tested with. Probably this is because I use the wrong kind of tests (ranging from simple loops and calculations to simple chat servers and clients), but just the fact that there are such wrong programs tells something, IMO. And startup time and memory usage continue to amaze me.

``Swing is a brilliant, although hard to learn, API.''

If it's hard to learn, what makes it brilliant? Certainly not its good performance or integration with the host environment. Themability and portability are good, but other toolkits have these, too.

``Java is a strongly typed language therefore you have to tell the compiler exactly what you intend to use.''

That's a fallacy. ML is also strongly typed, yet you don't have to tell the compiler the type you want to use.

``Java is popular. Anything that is popular has lost its elite status and therefore is not cool.''

You mean like Linux, Apache, Perl, PHP, gcc, etc. etc. etc. etc.?

Actually, now that I have read the full article, I don't think the author was trying to debunk any myths at all. More just summing up the points, so that those who want to defend/attack Java know where the battle is.

Re:Java Basher vs. Java Apologist

[Sigma 7]

And it's still slow. Each time a new release comes out, people get into the debate of Java is slow vs. you moron did you actually test that? Well, after 1.4 I have given up on testing. It's slower than unoptimized C for all programs I have tested with. Probably this is because I use the wrong kind of tests (ranging from simple loops and calculations to simple chat servers and clients), but just the fact that there are such wrong programs tells something, IMO. And startup time and memory usage continue to amaze me.

The "wrong" programs aren't wrong - they are simply very small loops. If you couny count the time spent in the program from the start of the main function to the end of the main function, the JIT optimizations performed by the Java interpreter will cause the Java's speed efficieny to approach C's speed efficiency. The same applies if Java is compiled to native machine language rather than Java byte-code.

Also, Java implements two features that will slow down the program - bounds checking and garbage collection. If you remove these two features from Java (or add them to C), the speed differences would be fairly marginal.

If anything, I'd prefer the small speed loss of Java over what could happen in C. For example, one of the projects I was working on had a memory leak - an entire division on a binary tree. While this was caused by a malformed method on creating the tree to begin with, the memory leak will eventually cause the application to crash as it is unable to allocate any more memory.

Re:Java Basher vs. Java Apologist

[aled]

BufferedReader in = new BufferedReader(new InputStreamReader(System.in))
Verbose yes, but flexible and clear. You can make your own filter stream class easily and chain in the same way. I did for encription.

Probably this is because I use the wrong kind
Then keep to C. The best tool...

public static void main(String argv[])
is worst than int main(int argc, char *argv[])? I don't think so.

Certainly not its good performance or integration
I have seen the first but not able to produce. Advanced Swing hacking is still difficult. And for the second, Swing wasn't made for that, it was made for portability.

Anything that is popular
Read popular in enterprise. Hackers just hate that.

Re:Java Basher vs. Java Apologist

[Anonymous Brave Guy]

Layout managers! A UI that looks good regardless of users resizing the window, different-sized widgets (themes[*]), different fonts/sizes (accessibility), different lengths of words (i18n).

Cocoa can't do this. MFC can't do this. Qt and Gtk don't, do they?

Actually, I wrote a typical MFC dialog-based tool at work recently, and having decided I wanted resizing on the Window, it took me about five minutes to find, install and integrate a free-as-in-you-can-have-it resizing class from one of the usual MFC web sites.

I've also worked with plenty of cross-platform and internationalised apps, and I'm still waiting for someone to tell me how any of Java's standard layout managers helps with getting a Windows-like interface on Windows, a Mac-like interface on OS X, and a KDE-style interface on Linux; there is a lot more to the styles of each OS than the alignment of dialog buttons!

Layout managers go some way to helping with these problems, and just about every major GUI library either has one itself or has several a download away. What else does Swing have to offer?

Re:who cares what he says?

[bheer]

And if you really can't tolerate the parentheses, look at Haskell. It's about as easy to learn as Python and more productive (and there are JVM/NET bridges available too).

> not by average programmers

Gosling once noted that Java *was* a blue-collar language designed to get the job done, contrasting with the `purity' of Smalltalk. While I agree, there's a place for Java, I can only hope one day Sun/MS/IBM will see the light and offer a non-procedural language as a first-class offering.

VB?

[hsoft]

Visual Basic was meant to be easy, for the masses.

Are you saying that VB is cool? I would consider this language as one of the most un-cool language ever.

Re:VB?

[kisrael]

Are you saying that VB is cool? I would consider this language as one of the most un-cool language ever.

Well, my experience is different than most folks...I started using VB3 back in the day, just for kicks...in fact, I made up and taught a class at Tufts in it, in 1995 or so, in their "Experimental College" (Prolly the first MS language taught at Tufts). And you know what? It WAS fun, and maybe even cool...at least not the un-coolest language ever. I could make a cheap and cheerful paint/sketch program in 2 lines of code...literally. I could put little graphics on the form and move 'em around, and in general do some nifty event-driven-model stuff. So there are at least some forms of VB that I think qualify as reasonably cool.

Re:VB?

[hsoft]

Of course, cool for making little 2 lines feats that wows the guys around. Anyway, the cheerful paint program is the first thing they learn you to produce with VB. But try to make a big project then. Your 2 cute lines of code turn into an ugly mess. Before VB.NET (which is a clone of C# with a different syntax from what I heard), you couldn't even make your own classes IIRC.

I guess that it is possible to create good code with VB. The only thing is that as soon as a programmer's skills become decent, the first thing that programmer does is to drop VB, hence the poor VB code quality...

Re:VB?

[Xentor]

I think I'll sneak into one of the longer branches of this thread, to avoid being flamed to bits.

VB added class support in version 5, I believe, but it was a pathetic imitation of true OOP, since though it handled encapsulation, it didn't support inheritance (Except through codeless interface implementation) or polymorphism.

VB.NET has fixed pretty much everything, and though you don't get quite as much raw power or low-level access as C++, you can make large, well-structured and well-designed program.

Yes, I'm a VB programmer. I learned Atari Basic at the age of 4, and I've moved up the line since then. I've done my share of C, C++, Java, Delphi, Perl, PHP, TCL, ML (Functional, like LISP), and hell, even Flash, but I usually gravitate back to VB (Currently VB.NET) unless I need something that would work better elsewhere.

Why?

For simple tasks, I can churn out a VB.NET program in a tiny fraction of the time I would normally spend reinventing the wheel in C. For generic algorithms, would you prefer to write your own quicksort implementation, or just call Array.Sort()? Even for custom objects, you can plug a comparer function into that method to still take advantage of the runtime's built-in algorithm (Which, incidentally, is quicksort).

For large-scale apps, VB.NET really shines. It's completely-standard OOP, so you can keep everything nice and organized just as well as a C++ app. The design IDE lets you build all of those annoying data-entry forms quickly, and some support classes and interfaces even let you automate parts of it, to eliminate the tedium.

For low-level calculation routines, mathematical modeling, huge array sorting, 3D rendering, or memory manipulation... Well, that's when you fall back to a "cool" language and build a function library.

Ok... I'll get the asbestos suit, because I know, even though I can churn out C apps in my sleep, I'm going to get flamed to high hell for supporting anything with a garbage collector.

Java:

[Mongoose Disciple]

It all sounds like a crock to me. Knowing the tools better will always help, but if only an expert can write usable code -- not great, but merely usable -- the language is junk, or at best the implementation is junk.

That seems a little harsh to me. Every language has its shortcomings.

For example, developers working in C++ who aren't experts will, on a project of any reasonable size, tend to write code that leaks memory like a sieve. In many environments, that's at least as crippling of a deficiency as Java's speed issues. I wouldn't say that's an indication that C++ is junk, however.

There's the old axiom in software development: Good, fast, cheap; pick two. It's pretty much the same thing in choosing or designing a programming language. Java's got its strengths over other languages, and it's got its deficiencies. Whether the strengths outweigh the deficiencies depends on the project.

Re:Java:

[TheLink]

What's with all these buffer/heap overflows? Those are definitely a crippling deficiency. Nowadays they can even be worse than speed. They seem too common a problem in C++ programs, not sure why.

Heck, I'm starting to look for an SSH server written in a language that isn't prone to "attacker can execute arbitrary code of the attacker's choice" problems. It's not like I need stupendous performance for SSH.

Mauve Was Cool In Its Day

[handy_vandal]

The reason Java is perceived as uncool is because they've got this horrible grey/violet default color scheme. Since when has violet been the color of cool? Exactly never.

In its day, mauve was all the rage:

In 1856, while trying to synthesize artificial quinine, 18-year-old chemistry student William Perkin instead produced a murky residue. Fifty years later, he described the event: he "was about to throw a certain residue away when I thought it might be interesting. The solution of it resulted in a strangely beautiful color." Perkin had stumbled across the world's first aniline dye, a color that became known as mauve.

"So what?" you might say. "A teenager invented a new color." As Simon Garfield admirably points out in Mauve, the color really did change the world. Before Perkin's discovery all the dyes and paints were colored by roots, leaves, insects, or, in the case of purple, mollusks. As a result, colors were inconsistent and unpredictably strong, often fading or washing out. Perkin found a dye that would always produce a uniform shade--and he pointed the way to other synthetic colors, thus revolutionizing the world of both dyemaking and fashion. Mauve became all the rage. Queen Victoria wore it to her daughter's wedding in 1858, and the highly influential Empress Eugénie decided the color matched her eyes. Soon, the streets of London erupted in what one wag called the "mauve measles."

Mauve had a much wider impact as well. By finding a commercial use for his discovery--much to the dismay of his teacher, the great August Hofmann, who believed there needed to be a separation between "pure" and "applied" science--Perkin inspired others to follow in his footsteps: "Ten years after Perkin's discovery of mauve, organic chemistry was perceived as being exciting, profitable, and of great practical use." The influx of bright young men all hoping to earn their fortunes through industrial applications of chemistry later brought significant advances in the fields of medicine, perfume, photography, and even explosives. Through it all, Garfield tells his story in clever, witty prose, turning this odd little tale into a very entertaining read.
--Sunny Delaney

Link

-kgj

Re:Java is unpractical!!!

[squiggleslash]

I keep forgetting that another of Java's faults is the completely arbitrary requirement for users to configure its memory requirements, despite the fact most users will have no idea how to do this, what legitimate requirements a program might have, and even that they're supposed to do this at all.

I think it's ironic you accuse the grandparent of being an "ID:10-T". I'd say that moniker is properly deserved of the person who thought users should be doing this.

Re:Maybe because it's slow ?

[nat5an]

I tend to agree with you. It seems intuitive that each interpreted virtual machine instruction would map to several instructions on the native processor (at the very least, since the virtual machine has to decode instructions in software, whereas the native processor can decode the instructions in hardware). Due to this increase in the number of instructions, the code would usually run slower. However, I do agree with the grandparent post that there is no theoretical proof which requires interpreted languages to use more instructions (hence more time) than natively compiled languages. It just seems logical and tends to hold most of the time.

There are lots of good reasons to use interpreted languages; they're easier to debug, they often have very powerful runtime environments, they're great for educational and research purposes. At the risk of short-circuiting the inevitable flamewar, certain languages are good for certain applications and there is no global measure of language "goodness."

Re:Serious question - OSS, "Great Hackers," &

[beerits]

But if you're writing for one of the BSDs [e.g. FreeBSD], what compiler [& libraries] do you use? Obviously you can't touch the GCC with a ten foot pole.

You use GCC. Just because you use a GPL compiler doesn't make your code GPL.

Re:Maybe because it's slow ?

[Wateshay]

The reason Eclipse's GUI toolkit is fast is because it uses the native (non-java) GUI toolkit of the PLATform it's running on. Java has its place, and Eclipse has done a good job finding it, but they've also realized that there are some things for which it's not (yet) appropriate. Same thing with the OpenGL bindings.

Anger/distrust of liars, Sun-dependence, OS pain.

[dwheeler]

Some other reasons don't seem to get mentioned.

First, there's still anger and distrust of Sun. When Java first came out, Sun promised to help make Java a standard not solely controlled by any one vendor, and Sun started working with ECMA and ISO to make it so. IBM invested over $1billion with that understanding. Then Sun suddenly decided to take Java out of the standards process, and take complete control over Java. Yes, there's a "Java Community Process", but look at the process: if Sun doesn't like it, it's dead. Period. That's not an independence, it's a dictator model. And it's not necessarily benevolent; in an open source software project, you could fork the project if things went really badly (e.g., XFree86), but there's no mechanism for a true 'vote of no confidence' in the current process.

Fundamentally, developing in Java still primarily involves kneeling to Sun. We have lots of C and C++ compilers, with vendor-independent standards for them. Many other languages have standards, too. There's no need to return to a language totally controlled by any single vendor, that's a model from decades ago. Yes, there are other Java implementations, but not many; few others support the GUIs, and none support the massive library that's the primary point of using a language like Java. gcj does great stuff, but try compiling a normal Java program with Swing and other key libraries. C# is heavily controlled by Microsoft, and there are reasons to distrust that too, but at least Microsoft managed to release the language fundamentals to a more neutral party; why can't Sun exceed those low expectations?

And on most systems, implementing a Java system is a pain. It doesn't come with Microsoft, who's actively trying to kill it. It doesn't come with any purely open source software OS (Fedora, Debian, etc.), because it's not open source. This isn't a killing problem, but it does make development of Java applets essentially hopeless -- because it's quite likely that users will NOT have the necessary plug-in. You can do Java application development, and install the necessary libraries -- on servers that's not a big deal, but it's a little more painful on clients for client applications. But at that point Java enters a crowded field: there are LOTS of languages that can be used this way.

There's a lot to like about Java. But Sun has managed, through a series of missteps, to make a lot of people unhappy and avoid Java, even if Java would be a fine fit technically.

Re:Maybe because it's slow ?

[bruce_the_moose]

One word: Eclipse

IBM took a different tack than Microsoft, yes. They wrote an app that didn't suck and made it open source to boot.

Depends ...

[gstoddart]

In particular, Graham claims that terser languages are more powerful , because studies have shown that coders churn out a pretty constant number of lines per day, regardless of the programming language. Java is anything but terse.

In my experience (which isn't huge with Java, but I've used it for commercial work), one of the things I liked most about Java was that it actually tended to save me lines of code.

Oh, sure it's got an explicit full-on syntax, but I'm comfortable with that. What I was most impressed with was there was a vast amount of standard data types and APIs available to accomplish a very huge amount of stuff. Looking at C++ and the like, the APIs are anything but cross-platform. (Any helpful links to a good C++ API (not GUI toolkits) which is both POSIX and Windows might make me use that some more.)

For the type of code I was writing at the time (oddly enough, server side stuff behind a web front-end, no GUI) I found I could always find a standard routine to do what in the past I've had to implement from scratch.

I also specifically loved the good type checking and the like. I want that from my languages.

I'm actually planning on using it for some projects I want to work on for myself.

Would I say it's the perfect language? Nope. Would I claim it has all of the shiniest language features? Nope. Do I, as an old-school C-coder, think it's a straight-forward API rich language that I can get stuff done in? Damned straight!

Since I don't grok functional-programming and I despise languages with really wierd syntax and the like, for me, Java is like the Toyota Camry of languages. For the way I use it, it's fine.

Words from a programmer rather than a end user

[wolenczak]

This is why I really hate Java - Object casting and marshaling - Obnoxious try and catch structures for *EVERYTHING* - Int's can't evaluate to boolean - Native versus object typed numbers - Error, not warnings, on loss of precision - Lack of unsigned bytes - StackTrace mumbo jumbo - Compiler output is sometimes inacurate - CLASSPATH - Many others but these came top of my head

Re:Words from a programmer rather than a end user

[networkBoy]

I've never programmed in anything but PERL and C (really I don't count logo) and never had the itch to learn Java.
"Int's can't evaluate to boolean"
Now I know that I never, ever, will [have the itch].

Re:Words from a programmer rather than a end user

[pomakis]

This is why I really hate Java - [...]

Some of the things in your list are valid gripes, but there are a few that I don't agree with. For example:

• "Int's can't evaluate to boolean" - So what? (a==0), (a!=0), is that so hard? I think good programmers generally do the expicit test like this anyways, even in languages like C.
• "StackTrace mumbo jumbo" - It's not mumbo jumbo. It tells you where the program fails and how it got there. Stack backtraces are a very powerful source of information for debugging. For programming languages like C you generally need external programs like gdb to provide this information. It comes for free with Java.
• "Compiler output is sometimes inacurate" - Is this really a problem with the language, or with bugs in the version of the compiler you're referring to?

Re:Words from a programmer rather than a end user

[BigGerman]

God bless you all.
I am glad that these are the only things the guy who truly hates Java can come up with ;-)

Eveything you listed is your friend, not enemy. Once you program for a while (and I mean 5,6,10 years), it will start coming to you.

Object casting
Often, downright ugly, this "feature" ensures that every object is what you think it is. You delegate all the checking to the compiler so you program, when it is incorrect, fails early, in fact, fails before it runs. Failing early is the sign of great code.

try and catch
Exception handling is a marvelous feature once you realize that from every situation there may be more than one (or two, ..) ways out. Using exceptions allows much cleaner separation of the "normal" logic and the "error" logic. Now, whether all the exceptions must be checked, or if C# model is better - is a different question.

int and boolean
Well, they are two completely different things, representing completely different animals in the real world. Why would you expect to be able to compare,assign, etc. apples to oranges?

native and object types
Tend to agree with you there.

Precision
Because IT IS an error when precesion is lost?

bytes
bytes are bytes and numbers are numbers.

stacktrace allows to pinpoint your runtime problems

classpath can be messy but it is precise: only stuff from classpath will be loaded by your program, nothing less, nothing more.

etc., got to go, do some uncool programming.

Re:Words from a programmer rather than a end user

[SenseiLeNoir]

# native and object types Tend to agree with you there.

In JAVA 1.5, autoboxing is (finally) inplemented.... even erasing that little problem

Re:Words from a programmer rather than a end user

[bani]

bytes are bytes and numbers are numbers.

this kind of philosophy is what causes programmers to avoid Java.

Re:Words from a programmer rather than a end user

[semios]

Sure they can. They just don't have an implicit rule for evaluating an integer as a boolean. Like Larry Wall says, there is no general way to convert a scalar to an array. Java designers would say, there is no general way to convert an integer to a boolean. So if you like C's implicit rule for integer to boolean conversion (i != 0), then use it but be explicit about it.

Re:Words from a programmer rather than a end user

[jeremyp]

I hate that actually, it doesn't feel right when I say it in my head.

OTOH since I ban myself from doing assignments where an expression is expected, and have done for 15 years, whenever I even see

while (foo = bar)

alarm bells always ring inside my head straight away.

Re:Words from a programmer rather than a end user

[rolling_bits]

"Often, downright ugly, this "feature" ensures that every object is what you think it is. You delegate all the checking to the compiler so you program, when it is incorrect, fails early, in fact, fails before it runs. Failing early is the sign of great code."

Not when the type is checked at runtime. I dare to say that many of the popular libraries do have the chance of blowing up at runtime. Ever heard of the abuse of RTTI and bytecodes? :-)

"Exception handling is a marvelous feature once you realize that from every situation there may be more than one (or two, ..) ways out. Using exceptions allows much cleaner separation of the "normal" logic and the "error" logic. Now, whether all the exceptions must be checked, or if C# model is better - is a different question."

Care to share with us your 10kloc of code that do the right think and handle the exceptions carefully and perfectly?

"Because IT IS an error when precesion is lost?"

You mean you can represent infinite numbers without losing precision?

"stacktrace allows to pinpoint your runtime problems"

Nice feature, indeed, shared by many programming languages.

"classpath can be messy but it is precise: only stuff from classpath will be loaded by your program, nothing less, nothing more."

Cool, you mean that stuff in jre/lib and alike directories isn't loaded by default?

Anyway, Java is good enough. Just like the web is good enough. etc. :-)

Re:Words from a programmer rather than a end user

[lisp-hacker]

[Object casting...]
The Problem is, if I use just general containers
in Java, I have to use casting to muffle the
compiler. But I have no safety at all,
the containers (Vector, Map, ...) contain
Objects, whatever they are.

So with the static typing as in Java you win
nothing:
You have to write lots of casts to work
with the Compiler, but you are very likely to
trap ClassCastExceptions.

If running untyped, you write half of the
code, and you will get errors,
when the Object, handed over to some method,
can not be handled there.
Which is not as often as you get ClassCasts in
arbitrary places in Java.

Martin

Re:lame :)

[Cocoronixx]

I have tried eclipse on several different occasions, and while it is an impressive IDE and feature rich, it is slow to me. Slow enough that it aways made me feel like i was being held back.

Why am I still hearing this?

[kahei]

Java is slow - This is a myth.

I honestly don't understand why people are still repeating this. It _is_ slower than either native C++ or .NET (MS implementation, don't know about Mono) for the vast majority of serious tasks (I am not including GUI stuff). It's all very well talking about how in theory HotSpot will optimize code beyond what a static C++ compiler can do, but the memory requirement of the Java program is typically so much greater that processing speed barely matters -- and it cannot be optimized, without a scary custom VM, because the app programmer has no direct control of it. I'm not just saying that for my health -- _look_ at Java memory footprints, _look_ at your options for reducing them (ie adjust the GC. Great.)

Java bytecode is not easy to optimize, having been originally intended for interpretation (my, how silly that seems now!). This is usually a minor issue compared to memory. I also suspect that, using the standard Java libs, IO is bound to be slower than a more direct approach unless the JVM takes some shortcuts and makes some methods into special cases. But actually, from the point of view of my actual work it doesn't matter what the reason is -- performance critical serious number crunching is done in C++, and that's pretty much a universal, because everyone relevant has made the same simple observations I have. This C++ can then be wrapped with a Java interface for the benefit of other systems that depend on Java and for people who only care about whether the system is Java or not (and so that it works with WebSphere now that the company is locked into WebSphere, heh heh).

So, _whyyyyyyy_ am I _stilllll_ told by posters on /. and people just out of university that "Java on Hotspot is theoretically faster than any compiled code!" I mean just stop it. Please. You are free to use Java. Java has many good points. Go use it and enjoy those good points and HUSH UP ABOUT HOTSPOT.

Re:Why am I still hearing this?

[Decaff]

Java bytecode is not easy to optimize, having been originally intended for interpretation

Hotspot does not optimize the java bytecode. It optimises the Java source (with techniques such as inlining and variable re-arrangement) and produces high-performance native code.

_look_ at Java memory footprints, _look_ at your options for reducing them (ie adjust the GC. Great.)

Java memory footprints can be very small - which is why it is favoured for use in many embedded systems. There are many options for reducing footprints, including run-time GC, stack and heap options and re-coding as a results of profiling, just as with any other language.

because everyone relevant has made the same simple observations I have.

Not true - there is a lot of work being put into Java numerics.

So, _whyyyyyyy_ am I _stilllll_ told by posters on /. and people just out of university that "Java on Hotspot is theoretically faster than any compiled code!" I mean just stop it.

Because in the experience of many of us, Java on Hotspot is not just theoretically faster, its actually faster, and we have benchmarked this with real examples. (IBMs VMs are particularly high performance).

Remember when C++ was 'slow'? I do. Almost anything written in it was declared to be memory hungry and sluggish. I remember the big fuss when major companies moved from assembler to C/C++ in the 80s. It was often stated that C++ could never be fast because of object orientation and because it could not be 'fine tuned' like assembler.

Seeing all the same old arguments with Java is just like Deja Vu all over again.

Re:Why am I still hearing this?

[sploxx]

Thanks alot!
Over all, it seems that most /.ers are now just these terrible java zealots.
I've written a very similar comment above. First of all we should stop saying JVM==Java.

Re:Why am I still hearing this?

[Svennig]

I'll debate one point - the memory footprint of java apps isnt that large, and can be well optimised.

This is why it is used in small devices like mobile phones etc.

Re:Why am I still hearing this?

[kahei]

Perhaps I misunderstood the job of hotspot -- if it compiles Java source, across all classes, to a native code image which it then runs, I agree it should be able to go as fast as C++ (assuming it can avoid boxing/unboxing all the time and so on, which it can if it is effectively constructing its own native executable). Presumably it also has to compile the standard java libs?

I agree that there are some options such as GC tweaking etc that can affect memory footprint in Java, but this is nothing -- and I don't mean 'not enough', I actually mean 'nothing' -- compared to having actual control of memory use. When I need to allocate 1.5 million new 'deal' objects in C++, I do it in a block that I prepared earlier, and I free them before the next 1.5 million could potentially arrive. When I allocate 1.5 million 'deal' objects in Java... well, it's upgrade time again. Java sells Sun hardware -- that's part of its job.

To me this is by far the biggest issue. The C++ analogy you make is not really correct, because in C++ you can control all the same factors you can control in asm -- whereas Jave prevents you from controlling an important factor, memory management. It does not just insert an extra layer between the programmer and the machine, it prevents the application from having any control over a huge chunk of its actual activity. .NET is much better in this respect (a bit like using inline asm in C++, but well implemented in a way), but as it only (in real life) runs on Windows the scope for using it is limited.

Until the above issue is fixed (and I don't see any reason for anyone to do so, really, nor any activity in that direction) announcing that Java on Hotspot is as fast as C++ remains a pointless activity, but I bet it will also remain an inexplicably popular activity.

Re:Why am I still hearing this?

[vmaxxxed]

Maybe because we dont cut to the point, and we keep arguing.

I think you are 100% percent right, but....

Whether JAVA can be optimized, whether Hot Spot can out perform C++ code......

Thats all nonsense, the real point is simple:

In what language do people think are all those fancy JVMs were written....????

Sure JAVA under hotspot is the fastest language around!!!.... mmmhhh, wait, was HotSpot written in java then ....????

Hellooooo....

Re:Why am I still hearing this?

[_xeno_]

Sure, Java Micro Edition can be small. Java Standard Edition has a base memory footprint of 4MB. No matter what you do, you have 4MB of crap that's only the base of the system. This does not include any of your code.

Not to mention that Java will always start with a base heap size of 2MB. Combined with the 4MB to store the base of the system, starting Java means that you will always lose 6MB of system memory allocated away to Java, not matter what the program does.

If the heap size ever grows, it will never be shrunk again. (In other words, if your app takes 64MB at some point, but then shrinks back to 4MB, the Java VM will still have 64MB allocated to it that it will never release back to the system.)

But don't take my word. Try it out for yourself. Compile that program and run it, and watch your memory usage.

Re:Why am I still hearing this?

[_xeno_]

I think most Java people object to the idea that Java is far slower than C or C++ code. It isn't.

It is, of course, slower - but it's like only 90% as fast as C code, as opposed to 50% as fast that some people seem to believe.

And anyone telling you that HotSpot will magically make Java faster than C is, of course, wrong. Thanks to Java's need for allocating many things, repeatedly, doing the same thing in Java as you do in C often requires many little memory allocations, and those still require extra processing time. The simple overhead of the language itself slows it down, no matter how wonderful HotSpot is.

Unless, of course, you have many instances when you need to count from 1 to 10000. Java with HotSpot can do for (i=0;i<10000;i++) { } on par with C.

Re:Why am I still hearing this?

[Decaff]

Presumably it also has to compile the standard java libs?

Ah. Looks like I have misunderstood aspects of how Hotspot works. I was wrong. Hotspot does work on class files and byte codes.

I think I understand what you are saying about C++ and memory, but I can't see the relevance to real memory application requirements and performance. Firstly in, Java you can easily free up memory blocks for re-use: just set them to null and let the highly tuned garbage collection system deal with them. Secondly, memory use is highly architecture-dependent. I have had years of tedious experience of attempting to use profilers and sizeof() calls to monitor and control C++ memory management. When I switched to Java I abandoned all that with a sigh of relief. I strongly believe that software engineering should be primarily about algorithms and not resources. There may be some hacker kudos in manually allocating and managing each byte of your application's memory, but in terms of almost all practical coding jobs its surely an outdated practice - I would no more want to handle memory management for my applications that I would want to handle hardware interrupts.

Re:Why am I still hearing this?

[Decaff]

So give us some LINKS to these benchmarks instead of just endlessly asserting..

Well, I don't think one comment in a post qualifies as 'endlessly'. But as you asked for links:

http://www.idiom.com/~zilla/Computer/javaCbenchm ar k.html

I particularly like the quote:
"Programmers, despite their professed appreciation of logical thought, are not immune to a kind of mythology," (such as "Java is slow")

Re:Why am I still hearing this?

[kaffiene]

I've been programming for 20 years and I can tell you (because I have benchmarked it) that in some cases Java with hotspot running can get faster than compiled C code. Your assumption that if someone says something positive about Java they must be "just out of university" shows a hell of a lot about your languages biases.

Re:Why am I still hearing this?

[angel'o'sphere]

Java is slow - This is a myth.

I honestly don't understand why people are still repeating this. It _is_ slower than either native C++ or .NET (MS implementation, don't know about Mono) for the vast majority of serious tasks (I am not including GUI stuff). It's all very well talking about how in theory HotSpot will optimize code beyond what a static C++ compiler can do,

It can and it does ... global code optimizatins perfomr better than local compile unit based ones since ... 30 years?

but the memory requirement of the Java program is typically so much greater
In what real life application?
You really think eBay.com or amazone.com or google.com would be better written in C/C++ because of memory consumtion? You really think that matters?
that processing speed barely matters -- and it cannot be optimized, without a scary custom VM, because the app programmer has no direct control of it. I'm not just saying that for my health -- _look_ at Java memory footprints, _look_ at your options for reducing them (ie adjust the GC. Great.)

Come on that is bullshit. A big application is used by .... how many concurrent users? 100, 1000, 100000?
So you really think it is easyer to write a multithreaded, concurrent, distributed, web and database centric application more easy in C++. Oops, no you only where considering performance. So gain: bla bla bla, you think such an application is FASTER in C++?
Dream on.

Java bytecode is not easy to optimize,
Bullshit. Stack based interpreters are aroound +40 years. Its a very well known topic how to optimize byte code.

having been originally intended for interpretation (my, how silly that seems now!). What do you mean with that? Isnt your nice compiled C++ code inerpreted by the processor?
This is usually a minor issue compared to memory. I also suspect that, using the standard Java libs, IO is bound to be slower than a more direct approach unless the JVM takes some shortcuts and makes some methods into special cases.

Ah, you suspect ... and? Curious to investigate and find some proof?
But actually, from the point of view of my actual work it doesn't matter what the reason is -- performance critical serious number crunching is done in C++
Because you *know* that C++ performs better in number crunshing than, erm Fortran? You obviously don't know that "number crunshing"in Java is very fast?
, and that's pretty much a universal, because everyone relevant has made the same simple observations I have.
Sorry, just remove all my arguments above. I forgot that it is universal and that every one knows .... how silly from me :-/

[...]

So, _whyyyyyyy_ am I _stilllll_ told by posters on /. and people just out of university that "Java on Hotspot is theoretically faster than any compiled code!"
Probably because its true and you are wrong?


I mean just stop it. Please. You are free to use Java. Java has many good points. Go use it and enjoy those good points and HUSH UP ABOUT HOTSPOT.

In 15 years, there won't be any native code anymore.
Do you think Intel really likes to compete with AMD etc. about how to make the best processor in executing 80x86 code? There will be a standard VM. A standard byte code. Likely ISO standardized. And prozessors and OSes will compete in executing/optimzing that standard VM byte code.

Currently a lot of companies are spreading everywhere compiling ancient machine codes to JBC. Interpreting ancient machien codes in emulators on JVMs. In parallel compilers of ancient languages like Fortran are crafted which compile directly to JBC.

Transmeta has a CPU which does on the fly JIT compiling of 80x86 code to Transmeta micro or nano code. Those processors run faster than native processors with similar MHz.
What do you think is the difference of JIT compiling java byte code to 80x86, SPARC or PowerPC versus JIT compiling of 80x86 to an internal VLIW RISC code?

Conclusion: you live in your little tower and have no clue.

angel'o'sphere

Re:Why am I still hearing this?

[Trinition]

performance critical serious number crunching is done in C++

OK, I'll bite. Give us an example, even the C++ source if you wish. I'll do my best to do it in Java and see what I can come up with. I'll even share it with the community to see if I've missed anything.

Re:Why am I still hearing this?

[angel'o'sphere]

No not really.

The processors will still be executing their own native code, as you are right, people wont be able to agree on an optimal set of instructions etc.

But you will be either hotspot/jit or ahead of time compile the "standard byte code" to the native code, or the prozessor itself will have a transformation stage and a kind of cash for transformed instructions like transmeta does it.

Its of course thinkable that several, about 3, de facto standards will compete. Parrot e.g. uses an regiser based approach for its byte code while other VMs use stack oriented byte codes.

I believe that the distribution format of software, and by that its "first after load" execution format will be bytecode. And I believe furhter that those bytecodes will merge to one or a few standards.

angel'o'sphere

Scheme and Python in Java

[swagr]

Look. Some people who were obviously "smart" enought to do it, and "hacker-ish" enought to want to, have implemented Python and Scheme in Java. (see Jython, SISC, Jscheme).

Anyone can use all 3 languages at the same time, running in the same VM talking to each other.

Life is so easy when you Google for 2 seconds instead of bashing different groups of developers and trying to figure out why they can't all get along and write nice code they way they want.

Oh, I enjoy it!

[Mold]

For a decent C/C++ programmer, memory leaks really aren't a big deal.

For a non-decent Java programmer, memory leaks ARE a big deal. They probably just don't know that.

Java's garbage collector helps with that, but if the programmer doesn't even know that it's possible to get memory leaks in Java, it's going to get them. I assume good Java programmers do, and know how to handle them. Same with C/C++ programmers.

If the programmer knows what they're doing in the language they're using, it's not an issue.

Re:Maybe because it's slow ?

[mschaef]

"Java is slower because it's safer: automatic bounds checking on arrays, which helps to prevent buffer overflow attacks, etc. A program made in Java without an eye to security is going to be more secure than a program made in C without an eye to security. "

The not so funny thing about this is that, as early as 20 years ago, this was true:

Lisp is slower because it's safer: automatic bounds checking on arrays, which helps to prevent buffer overflow attacks, etc. A program made in Lisp without an eye to security is going to be more secure than a program made in C without an eye to security.

One of the major differences is that Lisp allows easy early compilation to optimized native code, whereas Java relies on run time compilation.

It's still possible to write insecure Java

[feronti]

Java may protect you from the common mistakes like buffer overflowas and whatnot, but that doesn't mean that Java code is automatically secure code.

As an example, a company I used to work for contracted out a single-signon module for our website. Basically the user would authenticate to us, and then be passed off to a third-party site. Well, the programmer who wrote the single-signon (in Java) never checked to make sure that someone calling his servlet had a valid session on our system, so by simply caching the page with the link, anyone could get a hold of a user's login to the third party site. Granted, the flaw would be pretty difficult to exploit, since the page was transmitted over SSL, but it was by no means impossible.

So it still requires a security-conscious programmer when writing security-related code, even in Java. The security consciousness is just at a higher level than in C/C++. Java will not force an idiot to write secure code.

Re:It's still possible to write insecure Java

[StillNeedMoreCoffee]

The contention that Java is more secure is true. The problem you mention is an architecture issue that spans over the language (more a design pattern thing) and C or C++ or .net programs written for the same application would have the same issue. But the C and C++ would in addtion to your stated problem have buffer overflow and and whatnot problems. There is not automatically secure envrionment but the Java language has stopped up many of the hole that exist in other languages including those things that kill the app like array out of bounds and memory leak problems.

Java like Smalltalk soft fails typically with user catchable errors whereas C and C++ hard fail most of the time with errors that are not catchable without much programming in many places. Thats a good trade off for my money

Re:It's still possible to write insecure Java

[feronti]

I definitely agree that it's easier to write secure Java. And yes, the problem I mentioned was independent of language. But that was the exact point I was trying to make. Just because a language protects you from the simple mistakes (that may be hard to find) doesn't mean that the programmer doesn't still have to be conscious of security.

It could even be argued that Java could, by claiming to be a "secure" language, encourage programmers to be sloppy in regards to security. However, I'm not entirely convinced of that argument myself. The vendor in my example had a long history of obliviousness to security--we only caught this problem because I disassembled the servlet to reengineer other parts of the system that I didn't have access to the source code for. I'm pretty sure that they would have given us an insecure product regardless of the language.

Re:Maybe because it's slow ?

[LehiNephi]

Ah, but there is a way to force garbage collection:

System.gc();

because your boss likes it.

[number6x]

Java is quickly becoming a de facto standard among management.

Some of the managers are technically savvy enough to realise that there is not much difference in choosing one language implementation over another. They choose Java because there are many programmers being taught Java at school. They are betting that should keep the labor pool large and the labor cost down in the long run.

These tech savvy managers know that python or curl is easier to write and maintain. They also know that other OO languages perform better, but they are adding the cost of staffing and outside support into their equations. They are projecting Java to become the next COBOL or C. None of them were 'perfect' coding languages, but they each dominated all other languages. What is technically 'best' is not always the 'winner' in the marketplace.It only needs to be good enough.

That said, most of the rest of the management (about the other 90%) likes the cool Java swag they got at the last convention. They think it makes them superior to wear it in first class while sipping cocktails and talking loudly on their cell phones about 'their' latest Java project implementation, and its overall downward effect on the cost ratios of delivering customer facing services, thus maximizing the returns for each level without jeopardizing the long term blah blah blah blah blah...

Re:Maybe because it's slow ?

[kdz13]

Indeed, I agree with you. All I'm trying to get at is this: There is *no* way that a interpreted or JIT compiled language can be *faster* than native code. It will always be second best. That being said, I agree with the advantages. I just don't understand why we have these huge flame wars... "Java is fast" "no it's not" "yes it is". Can't we just all agree that it's second-best in speed and better in debugging/hand holding? -kz

Re:Maybe because it's slow ?

[bwt]

In the hands of a skilled C++, as well a C, developer these things are actually not the issue you made them out to be.

That's a tautology.

The real issue is that a developer has to spend some time developing this skill, and it is essentially waste for solving most problems. The same developer could have learned something else with his time that makes him more productive.

Bad article

[photon317]

Just like the last article slashdot linked from this source. For one, it's a straw-man argument. He gets to set up the 10 greivances that he'll knock down. How about he ask Paul for a list of 10 greivances to knock down? Secondly, the greivances he picks and his arguments against them clearly show that he's incapable of thinking in the way that people who despise java think, which makes him a poor arbiter of such things. Would a great hacker really say "Java sucks because it doesn't have a cool IDE like MS Visual Studio?"

Re:Maybe because it's slow ?

[Sj0]

Wouldn't a Java interpeter in Java require another Java interpeter, culminating in an endless cycle of programmers who really want to be directors?

rubbish

[animaal]

How can a language be un-cool? Could you call a hammer or a screwdriver "uncool"? And who'd listen to a guy wearing a beard, sandals, and white socks, getting red-in-the-face discussing the subtleties of static versus strongly-typed languages, deciding what's cool or uncool?

Programming languages exist to solve problems. Java happens to be among the best languages for mobile-phone apps (not the fastest, but very compatible), and scalable server-side apps. How can it be either cool or uncool? Personally, I wouldn't use Visual Basic to write production code, but I wouldn't call it uncool. It has its own niches.

Re:As a programmer, I'll tell you why

[Anonymous Cow4rd]

This is coming from a former experienced (actually had a full time job for many years) C programmer that switched to Java programming (for many more years of full time employment) and would never go back to C (unless, of course, I had to to feed my family).

Similar to me. I've been programming in C for nearly 20 years and Java for nearly 10 (back when it was in beta). I've done huge projects in both languages.

What good is a program that can manage 1000 transactions a second when you only need to manage 10 a second. And besides, current archs require clustering of applications (for robustness) which also provides load balancing which in turn increases the throughput further. Java is more than fast enough.

It's that kind of thinking that creates the bloatware crap we have today. Stuff that performs worse than older software despite the fact that the hardware is 10 times faster.

This is EXACTLY what Java tries to be. The benefits of compiled languages (type checking, link checking) with the ease of use of a scripting language.

Hmm, some people would say "The disadvantages of compiled languages and not nearly as useful as a real scripting language".

Sun has been an inept manager of Java, but that shouldn't taint the language itself. If you don't like Sun's JVM, use IBM's. You have a choice

Nope. Didn't work; won't work. Java is dead because of what they did.

Who said "Extremism in the cause of object-orientedness is no vice"? Just kidding. Actually Java is not on the extreme end of "object-orientedness". More so the C++ (this is a good thing) but less so than Smalltalk. As a matter of fact, the C-ness of Java makes it quite easy to understand.

Any time I have to instantiate a "Point" class just to put in X/Y coordinates, that's going too far. Java is tedious like a low-level language but you don't get any of the power (no pointers, etc).

Java is better on the server but not just because of the available API's (no question those are nice too). A program that follows the Java naming conventions and good OO design philosophy is just easier to maintain.

The same could be said of any language. The disadvantages of Java take it out of the picture as a viable option.

Huh? Java was nothing if not new. Try explaining the benefits of garbage collections to a C programmer. He probably won't say "we were doing that with C in '83"

We were. And at least in C/C++ I have a choice. Plus I have more control. If you want complete ease of use, use a scripting language, if you want speed/power use a low level language. Java is the worst of both.

Re: Java Myths

[bobv-pillars-net]

Java is Cross-Platform - I remember attending a seminar where Sun introduced Java as the Holy Grail of programming: the first truly write-once, run-everywhere language. And it sounds really cool, except that I now work for an ISP and I don't go through a single day without finding yet another "portable" java app that runs everywhere... as long as you've got the right JVM and OS version.

Java, as it is typically used on the client side, is about as cross-platform as Visual Basic.

Re:Maybe because it's slow ?

[Theatetus]

Java is not more secure than Ruby or Python. They all check the access to arrays, are object oriented, have exceptions support

Interesting points but I'm not sure what that has to do with your assertion.

• Checking access to arrays: this is good for preventing a programmer from shellcoding himself, but very few user / remote exploits are based on overwriting a statically-allocated array (those attacks are relics from older C libraries).
• Object-orientation: You only think Java is OO because you've never tried CLOS. Once you've used multiple-dispatch you never look back. At any rate, object-orientation just means that data structures contain or point to their own algorithms, and has little if anything to do with program security.
• Exceptions. I'm trying to think of a modern language without exceptions. Hell, even C and Forth have exceptions.

At any rate, I think you're missing the main security concern: yes, VM languages like Java have some security features, but the security concerns should not be about the application but about the vm itself. I probaby cannot corrupt the virtual heap or stack of a java application since the code is managed, but I can corrupt the heap or stack of the VM itself, and in fact that's what the java exploits I've seen do.

Re:Maybe because it's slow ?

[the quick brown fox]

There are optimizations that a runtime-managed environment like Java can make that a non-managed environment cannot. For one example, the runtime could tell if a virtual method is not actually overridden in any class that is currently loaded, and so can be treated as a nonvirtual method (inlined into call sites, for example). I'm sure there are many other examples, but I'm not an expert.

Another possible reason is because C/C++ has to free up memory as it goes; in Java, that cost is paid only during garbage collection (which might never happen during the lifetime of the process), and even when it does, in some cases it could be a lower total cost than the equivalent time spent cleaning up in C/C++. (Not taking into account libraries that add automatic memory management to C/C++.)

Re:Maybe because it's slow ?

[Tassach]

The only advantage for Java is that its standard library is bigger than the other languages

I wouldn't say that's it's ONLY advantage. There is a HUGE amount of industry support for Java, particuarly for server-side enterprise applications (Websphere, Tomcat, etc). The desktop is not the sum total of the computing universe. Java scales well at the enterprise level and Java code is a lot more maintainable than C++, or even perl.

Look at some help wanted ads and see how many companies are hiring J2EE/EJB programmers compared to Python or perl programmers, and how much those positions pay. I don't care how "cool" a language is, I care that someone is going to pay me to use it. I'd develop in COBOL (shudder!) if that's where the jobs were.

Er.. because Java is best hot?

[saikou]

Who would want to drink cold Java anyways? :)

security

[Bob 4knee]

The security features of Java are somewhat like "daytime running lights" on GM vehicles. We are admitting to ourselves that there is a class of people who are too stupid to figure out when to turn on their lights, but we want them to be able to drive "safely". Java has a lot of bounds checking and type checking built in, so it's "safer" for the coder who doesn't bother with these things. Is it better to educate the programmers about security, or have the lights come on automagikally? (Hint--they may, someday, have to code in another language and all security properties are NOT type properties).

Sometimes the safest thing to do is to idle a car w/ the lights out, or to visibly flash your lights at an oncoming vehicle, but folks with daytime running lights don't have that option. Sometimes you might want to speed up some code by ignoring typing, writing past the end of an array, or directly manipulating a pointer.

Re:security

[Sj0]

The problem with your argument is that some people refuse to be educated. Hell, the biggest software company in the world is putting tons of money into educating their programmers, and after a couple years, there haven't been any appreciable gains(actually, since hackers have had that much more time to study, there have been extraordinary losses in the security department)!

Re:security

[tzanger]

Sometimes the safest thing to do is to idle a car w/ the lights out, or to visibly flash your lights at an oncoming vehicle, but folks with daytime running lights don't have that option.

I can still flash my high beams at night, and (at least on my '94 Grand Cherokee Ltd and my '99 Transport) there is a visible difference between "daytime running lights", "headlights" and "high beams" -- you can still flash your lights, even with DRL-equipped vehicles.

Sometimes you might want to speed up some code by ignoring typing, writing past the end of an array, or directly manipulating a pointer.

I agree with the type ignorance and directly manipulating pointers, but can you give me one example of where writing past an array is a good idea, even for speeding up code?

Re:security

[Bob 4knee]

I can still flash my high beams at night...

I meant (and should have specified) during daylight.

can you give me one example of where writing past an array is a good idea

No.

I was thinking more along the lines of the compiler not needing to check that I was within bounds (so should not have said "writing past the end.."). For example, a subroutine does not need to check (or even to know) the bounds of the original array (declared elsewhere). If the subroutine knows where A[0] lives, and the programmer wants to mess w/ A[99], C wouldn't check, and wouldn't need to know how big A is. I guess that really falls under "directly manipulating pointers", since A[99] is the same as *(A + 99)

Re:security

[Fooby]

An optimizing compiler can in many cases figure out the static cases where bound-checking is unnecessary and omit them. If a programmer is intelligent enough to write secure code in C, s/he should be intelligent enough to write fast code in Java. I'm not saying that Java is a perfect hacker language, but I am saying that C is not a modern language and not the best choice for most large applications. There's no reason in this day and age that an applications programmer should have to be constantly piddling over things like memory management in their code when garbage collection can be done by the compiler.

Re:security

[Cruciform]

Sometimes the safest thing to do is to idle a car w/ the lights out.

Yup, imagine how many stalkers get beaten up every year because of those damn daytime running lights. :P

Re:security

[tzanger]

I can still flash my high beams at night...
I meant (and should have specified) during daylight.

I meant during daylight, too -- I went on to say that DRL (at least on my two vehicles) is diferent than full-on headlights.

Re:security

[tomhudson]

can you give me one example of where writing past an array is a good idea

No.

Easy enough - strings in c are arrays of type char. So, given 2 char arrays in memory one after the other - concatenating them is quickest by writing to the null byte at the end of the first - inplace modifying the last part would require writing to the end of the original char. array.

Example:

This is string 1.0x00This is string2.
<br>
This is string 1, this is string 2.

just by replacing the period with a comma, the null with 0x20, and lowercasing the T.

A lot quicker than creating a new char array, copying/modifying the strings, and freeing the original strings.

That was just a thoughtless statement

[flibuste]

One has to admit that a statement such as
Of all the great programmers I can think of, I know of only one who would voluntarily program in Java. And of all the great programmers I can think of who don't work for Sun, on Java, I know of zero.
can only come from someone who doesn't really have a global picture and is a bit narrow minded. Otherwise, he'd think more, open his eyes and will find some happy Java developers around. Obviously, this argument is flawed on purpose and all he wanted to do is revive a closed debate that has been around since Java is out, which is a bit pointless IMHO.
I think Paul Graham should have been modded "flamebait" or "troll" at best.

Java still playing catch up with Smalltalk

[sideshow Pablo]

I know, I know, not another TOTL(The One True Language(tm)) comment.. but...

I'm amazed that how all of the current "state of the art" Languages/Frameworks still haven't caught up to Smalltalk yet.

Smalltalk is a Language/Library/ and integrated development environment all in one.

It's had for over twenty years:

1. multiple hardware support via Virtual machines,
2. garbage collection,
3. robust library,
4. Edit and continue debugging (the stack unwinds to the spot of the edit and it continues from there, once a coder experiences this, going back to pause, figure out problem, stop program fix, recompile and restart from the beginning sucks 'big time'),
5. Pure object based (everything including 'primates' is an object, at least how it appears to the programmer that is ;)and it makes it hard to write procederal code unlike Java/C++/C#, where it take coder discipline not to )
6. A good GUI framework (heck, it was used to invent Gui's),
7. Clean elegant language: 5 reserved words
8. Encouraged an iterative programming style( XP ).
9. And More...

Java/C#/.Net wish they had all of this "20 year old" tech. They are good Languages/tools that are slowly evolving into Smalltalk. Why don't you just save time and go to the top of the food chain?

It's amazing how one research lab, Xerox Parc, could have been SO far ahead of its time. Its like software has stood still for twenty years.

You can explore it via the open source squeak project. Understand it is written for coders by coders so it takes a little work to come up to speed on it, but in my option, well worth the effort. And Morphic just rocks. http://minnow.cc.gatech.edu/squeak/1

Re:Maybe because it's slow ?

[Glock27]

It's the startup time.

I have no complaint about the speed of a Java application once it is up and running. The only problem I have is that the runtime takes so long to heave its vast bulk into memory and fiddle with stuff before the app. gets control.

You should try using Java apps compiled with gcj or one of the commercial traditional Java compilers. There's nothing set in stone that requires Java to be interpreted.

JRE 1.5 should help quite a bit also.

screw coolness

[orabidoo]

I'm currently doing a big project in, of all things, visual basic .NET. Not my choice, I'd probably have picked wxPython, but There Were Good Reasons(TM). It's got nearly all the uncool bits of Java (static typing, cumbersome VM, and an overwrought class library with three bazillion classes where a more dynamic design could have done with a tenth of those), plus some of its own (a butt-ugly verbose syntax, and MS lock-in).

You know what, at the end of the day, it's code. If you're a good programmer, it's readable, maintainable code. If you're not, no matter the language, it's going to be a mess.

Re:Serious question - OSS, "Great Hackers," &

[finkployd]

Are you under some weird impression that if you use GCC your code must be licensed under the GPL?

Were the moderators under that same clearly mistaken impression?

What gives?

Finkployd

Great Programmers?

[Fujisawa Sensei]

Martin Fowler of Refactoring does Java.

Erich Gamma of Design Patterns is a major player on the Eclipse project.

Besides why should people consider a language cool at all? Shouldn't it be, "What I can do with a language" is considered cool?

Re:Great Programmers?

[the quick brown fox]

Guy Steele of Common Lisp: The Language and C: A Reference Manual and one of the creators of Scheme helped design Java.

(Although I think Martin Fowler's language of choice these days may be Ruby.)

Device drivers don't hit the Java "soft spot"

[argent]

About the only thing slower starting up than a Java app is a Java/Cocoa app. A Java device driver is initialised at boot time so you don't pay for the virtual machine creation every time you open it.

True ....

[gstoddart]

From my employer's point of view, it makes me more productive than (most) other languages would, since I spend less time worrying about crap like header files, pointers, memory leaks, and so on.

That's what I like about the language. A co-worker recently got transferred to a C++ project, and he spent a lot of time grumbling about the need to suddenly handle all of that after a stint in Java.

"Cool" stopped being important when I turned 18.

Laugh. I wasn't cool then either so what do I care? =)

java echo and echopoint

[codepunk]

We always thought it sucked for web developement also until we found echo and echopoint, now we build
everything with it.

sponsored links..

[Suppafly]

Is it just me, or are there more sponsored links on that page than there is information.

I'm ok with people using ads to substidize content, but there are like 30 sponsored links surrounding the article.

Because Java does not work on the fun platforms

[eddison_carter]

It's simple, if you're a programmer, and you really are that good, you can do more with less memory and cpu cycles. I can write a program that runs on a $5 chip with 256 bytes of ram, and 16k flash, and have it controlling a robot. Go do that in java :)

What MMO?

[LabRat007]

I have notice a few Java clients for MUDs out there, but other then that I havn't seen anything else. Of, what java based MMO do you speak?

Re:Java is unpractical!!!

[Glock27]

I keep forgetting that another of Java's faults is the completely arbitrary requirement for users to configure its memory requirements, despite the fact most users will have no idea how to do this, what legitimate requirements a program might have, and even that they're supposed to do this at all.

This can, of course, be handled by the installation process but it is a pain in some ways.

IIRC this is also addressed in the release of Java formerly known as "1.5".

Java is the COBOL of the modern age.

[stuffduff]

COBOL was written by accountants for accountants you have to account for every friggin' byte! Java is just as bad in that respect. I like a language that can take care of data management itself. If I had to manage the data storage in that manner I'd rather skip the middleman and go right to assembler.

I also like to do just what I need to do right where I need to do it. Why load a bunch of class libraries when you're only using a small portion of them? I can do the same thing without extra function calls then I save a bunch of cpu time and stack space. And don't even get me started on VM's...

Re:Maybe because it's slow ?

[bwt]

Java is not more secure than Ruby or Python.

Java is faster than both ruby and python, so what is your point?

Amen

[dido]

I'm reminded of an article written by C.A.R. Hoare once (you may remember him as the guy who invented Quicksort), where he quotes the late Christopher Strachey:

It has long been my personal view that the separation of practical and theoretical work is artificial and injurious. Much of the practical work done in computing, both in software and in hardware design, is unsound and clumsy because the people who do it do not have any clear understanding of the fundamental principles underlying their work. Most of the abstract mathematical and theoretical work is sterile because it has no point of contact with real computing...

(the essay I refer to by the way is C.A.R. Hoare's "Programming as an Engineering Profession"). The grandparent poster shows exactly the kind of attitude Strachey so derides in the quote. If anything, this kind of fundamental disconnect seems to have gotten worse today than it was when Hoare wrote his essays on programming as an engineering profession and programming as applied mathematics.

Re:Maybe because it's slow ?

[flibuste]

You missed the entire point while happily going in the usual pitfall of blaming the garbage collector.
There ARE badly Java programs too, which can make things pretty slow, and various JVM implementations which exposes various GC behaviours.
Think twice, your brain has two hemispheres. Use them.

Re:Maybe because it's slow ?

[fitten]

In the hands of a skilled C++, as well a C, developer these things are actually not the issue you made them out to be.

That's a tautology.

The real issue is that a developer has to spend some time developing this skill, and it is essentially waste for solving most problems. The same developer could have learned something else with his time that makes him more productive.

I'd count "paying attention to details" a valuable skill and one that increases productivity.

SWT

[SlipJig]

All you people complaining about Java GUIs need to check out SWT. It's the GUI framework used for Eclipse. It's pretty fast, cross-platform, easy to program for*, and takes advantage of native widgets so your apps look like native ones. I also recommend this book on it if you're new to SWT as I am.

*You still need to use layout managers as in the other frameworks, but this is a given for cross-platform apps.

Re:SWT

[spike2131]

As far as I can tell, Java running SWT is still pretty poor on the desktop. I use Eclipse, and there are many things I like about it, but performance is not one of them. In addition to general slowness, it still feels the need to hang for 15 seconds every 10 minutes or so, I think to take care of garbage collection or something. Thats the kind of thing that should no longer be acceptable in a modern GUI.

Re:SWT

[metamatic]

...and you people advocating SWT need to write some decent searchable online documentation for it.

Re:SWT

[SlipJig]

That's why I recommended the book ;-)

Re:SWT

[metamatic]

Yeah, but I hate doorstop books, and I can't program without decent searchable documentation.

(I have the O'Reilly Java reference HTML CD, for example, because Sun's documentation is often inadequate. Though at least it exists, which is more than you can say for the SWT documentation...)

Re:promise

[DevolvingSpud]

> Straight C with makefiles is more portable now than java. We can program hp calcs with c right? Where's java?

Um, on about a few million mobile phones? And handhelds? And desktops? And toasters? Well, maybe on the toasters (yet).

Re:lame

[mwood]

As far as needing to install the JVM before you can use it, I'll say that I was pleasantly surprised to find that Sun's packaging people grok the Microsoft Installer better than most third parties. I had little trouble pushing their JRE kit out to a couple hundred MS Windows workstations via an Application Management Group Policy. (I always have *some* trouble because I always want *something* weird, but Sun's people had already explained how to get the effect I wanted, and all I had to do was make a tiny transform to set it up.)

For individual installs, "go to www.java.com; click on Get It Now" is really not very hard, is it?

Re:Try Motif

[vingilot]

The java language is not verbose, in fact it is quite the oposite. I like Java over other languages because it has great documentation, a powerfull core library and small syntax. Swing sucks but I don't try to build GUI's so no problem.

Re:Maybe because it's slow ?

[Tassach]

In the hands of a skilled C++, as well a C, developer these things are actually not the issue you made them out to be.

Bullshit. IME, there are maybe 1000 (tops) C/C++ programers in the world that can consistantly write non-trivial code without memory leaks, buffer overflows, and the whole gamut of classical C/C++ bugs, and even these top programmers still make the occasional mistake. If the hacker gods can't get it right, what chance do mere mortals have?

I've worked with some really brilliant C++ hackers, who tested the crap out of their code, and they were still constantly finding the same old classic bugs. The fact remains that it is insanely difficult to write good C++ code. Java lowers the bar somewhat, so that you don't require superhuman ability to write decent software.

Java's no longer got the advantage library-wise

[Dan Ost]

The only advantage for Java is that its standard library is bigger than the other languages.

And with Jython, Python programmers can program in Python and access all the
Java libraries. But that's becoming less of an issue as the Python library
offerings mature.

Whenever I work with Java, I always feel like I'm fighting it every step of
the way. Python, on the other hand, just lets me create working code without
ever getting in my way.

Python is what Java should have been.

Java doesn't play nice with other children

[argent]

Let's see, here I am at a command line, I want to run a Java application. Any other compiled language compiles to a native executable that you run by typing its name. Java is just this random archive full of "stuff", and you have to use a "run" command like we were back in 1968 before Bell Labs invented the executable bit.

Here I am running a Java application. I type the command line to start it, and wait. And wait. And wait. And wait.

Here I am with some code written in Java, and I want to call it from Tcl. Write a quick C wrapper, link the .o in, and package require... no...? How do I do that, then?

Here I am with a library written in C, or Fortran, and I want to call it from Java... well, how badly do I want it?

Java is like Mac OS used to be, its own little world and the only way to play is to leave everything else you've ever worked on behind.

Re:Java doesn't play nice with other children

[hikerhat]

Let's see, here I am at a command line, I want to run a Java application. Any other compiled language compiles to a native executable that you run by typing its name. ...
Compile in kernel support for misc binaries on linux. Read Documentation/binfmt_misc.txt to learn how to use it. Read Documentation/java.txt to learn how to use it with java. On any recent version of windows it works to just type the name of the jar file.

Here I am with some code written in Java, and I want to call it from Tcl. Write a quick C wrapper, link the .o in, and package require... no...? How do I do that, then?
The first google hit - http://www.javaworld.com/javaworld/jw-05-2001/jw-0 511-legacy.html

Here I am with a library written in C, or Fortran, and I want to call it from Java... well, how badly do I want it?
http://java.sun.com/docs/books/tutorial/native1.1/ It is really easy.

Re:Java doesn't play nice with other children

[forgotten_my_nick]

>Any other compiled language compiles to a native executable that you run by typing its name.

Never heard of a self-executing jar files I take it. They have been around for ages. Just type the name of the jar file and it executes.

>I type the command line to start it, and wait. And wait. And wait. And wait.

Depends a lot on what your application is doing. I am guessing you are talking about GUI based applications.

>Here I am with a library written in C, or Fortran, and I want to call it from Java

JNI

Re:Java doesn't play nice with other children

[Mybrid]

Compile in kernel support for misc binaries on linux.

The point is that Java doesn't play well with others. By having to special case how to build per use implies it doesn't play well.

To futher illustrate take a Makefile for building java. Java sucks with traditional Makefile invocations. The javac JVM will get invoked repeatedly unless all the java files are on the same command line. So, the language that doesn't play well needs to re-invent the wheel and call it Ant. The main bonus to ant is that Java files are compiled in place. The overwhelming minus to Ant is that it can't build anything but Java. Again, Java doesn't play well with others. But the point is that Java didn't play well with Make. Implicit rules in Make failed because Java files have to be batched in-line. Java Developers claim that "tabs" and other oddities in Make lead them to write Ant but in my opinion, and it is just my opinion, the real reason was because performance with the javac compilier using make really sucked. Java doesn't play well with others.

Perl, on other hand, doesn't need any special compilation, run-time Jar files are whatever. There is nothing to build. In fact, the Java designers were stupid for compiling an interpreted language. The JVM is not a virtual machine, it is an interpreter that ultimately makes system calls into the OS, end of story. A real virtual machine emits hardware instructions that get translated from one machine to another via a *hardware* vm layer. Everything else is interpreting for the OS. It's stupid to force programmers to compile interpreted code.

C++ and C programs chain together nicely at the command line without having to be repackaged or recompiled or yeah even knowledge by the person programming that progam will be used a pipe.

Re:Java doesn't play nice with other children

[argent]

Depends a lot on what your application is doing. I am guessing you are talking about GUI based applications.

What part of "command line" is hard to understand?

There's a significant irreducible per-execution overhead as you, well, boot the java runtime.

Re:Java doesn't play nice with other children

[iGN97]

http://java.sun.com/docs/books/tutorial/native1. 1/ It is really easy.

Are you f-ing kidding me?

This is easy: (C#, P/Invoke, supported by .NET/Mono, etc)

public sealed class MyNativeFunctions {
[DllImport("MySharedLibrary")]
public static void MyNativeFunction(int myParameter);
}

Then you call it with

MyNativeFunctions.MyNativeFunction(42);

Java might be good at a lot of things, but native interop is not one of them. This is one (of the many) features .NET should be applauded for.

Re:Java doesn't play nice with other children

[argent]

Compile in kernel support for misc binaries on linux.

I'm not using Linux.

Also, neither of those links show me how I can actually link the Java into my application. The only options seem to be dynamically loading a Java class into the interpreter, or dynamically loading a separately linked shared library from a Java application.

I realise that for a large proportion of the "classical" Java applications neither of these are significant hurdles, but they do make it pretty much impossible to build a statically linked standalone executable.

Re:Java doesn't play nice with other children

[hikerhat]

There are always boundry cases where things won't work. The case where you have a system that is running Java code you later find you need to access from a C app and the system doesn't support dynamic linking must be pretty rare. It would be difficult to make any interpreted language mix with C on that platform.

I've never used gcc's Java compiler, but it does compile Java to native code, so there's probably a solution there. I assume you can compile the Java code to a native library you can statically link to.

If you're on a system so obscure it doesn't even support gcc linking C with Java is really the least of your problems.

Re:Java doesn't play nice with other children

[argent]

The case where you have a system that is running Java code you later find you need to access from a C app and the system doesn't support dynamic linking must be pretty rare.

There are many other cases where I would want to use a statically linked executable for security, reliability, or administrative reasons than that rather contrived example.

Java is the first compiled language I have used (whether compiled to p-code or native code), where you have to go to such extremes.

If you're on a system so obscure it doesn't even support gcc linking C with Java is really the least of your problems.

I used a variety of interpreted languages that linked cleanly with native code (whether C, Fortran, assembly, PL/I, or other "obscure" systems languages) for almost a decade before there were such things as Java or GCC. "Oh yes, just build a shared library and dynamically load it..." or "Well, if you use this compiler that gets pretty horrible performance on the platform you're using, you'll be OK"... it seems to me that when the way to avoid startup penalties is "use Linux", and the way to use other languages is "dynamically load only", that's a pretty tight boundary.

Re:Maybe because it's slow ?

[StillNeedMoreCoffee]

Well Java as I understand moves much of the optimization process down into the JVM whereas a compiled language like C++ does that optimization during compile time. Comparing the time I have spent waiting for C++ during the code, compile, run, code, compile run, I find I have wasted much more of my time. With the Caching of classes and dynamic inlining of code the JVM tunes up as you you go along.

You are correct that this model has a start up delay which can be seen as a problem if you do a lot of startups, but like many applicatons say a web server that starts a JVM and keeps it running while the server is up it is a one time charge. I find that given the saftey of the language especially around automatic garbage collection compared with C++ my envirionment is rock stable and the online Web apps we have only come down with the hardware needs maintenance.

The folks compainign about MS Java have a good complaint as that was an old buggy version of Java that has not been in general use for years by people using Java from the Sun source. The new versions of Java 1.4 ... current and 1.5 (Tiger) coming in a few months are light years ahead of that old MS version and should be looked at seriously.

I write my code on NT and W2k platforms (java 1.4.2) and field the same code on WNT W2k Sun Solaris with out modification and no changes for envirionments. With C++ or C# and the java clone this is impossible at this time. I have in the past had to field C++ code on different platforms and that was not a very nice time.

How do you want to spend your time. Collecting your own Garbage, writting very very carefully so you can use your code in different environments, or do you want to just get the job done right and once and get on with it?

Re:Maybe because it's slow ?

[Xugumad]

Drat, knew someone would ask that. No, never got around to it. Will try to remember to later tonight, and will post the results...

Optimise for legibility

[DG]

The trick to writing maintainable perl code is to optimise for legibility - and rigourously enforce it.

That means cutting back a little bit of some of the idiomatic perl shortcuts, especially the use or implied use of $!. It also means solid commenting.

I used to assume that every single perl program I wrote would be handed off to somebody else to maintain, and that this person would be relatively unfamilliar with perl - a skilled coder to be sure, but not necessarily a perl guru.

Accordingly, whenever I used some particularly elegant perl trick - but something that might not be immediately obvious - I commented the hell out of it, explained how the trick worked, and would even give references to the perl manuals where further reading could be had.

The end result - programs that not only did their function, but acted as perl tutorials for the poor bastards who had to maintain my code.

The side effect was that it made MY maintainence much easier too. If a bug was found in something I hadn't touched in years, optimising for legibility meant I could pick up where I left off without too much trouble.

I found that perl's expressibility made it EASIER to do this than "bondage and discipline" languages like Java. When there's more than one way to do it, you can choose the manner that accomplishes the task in the most human-understandable way, rather than being forced to think like the compiler.

I've noticed over the years that the best perl programmers (and in many cases, the best programmers period) are good writers, or have some sort of literary background. I think this is no accident; perl is a language for conversing with both the computer and with other coders.

That's it's strength, and its weakness. Like any expressive language, phrases write one can that difficult to parse are. But you can also write Shakespere.....

Perl is like English, where Java is like Esperanto.

DG

Re:Optimise for legibility

[michaelggreer]

As a programmer who also has an MFA in writing, I have to agree :)

#1 reason java is uncool....

[Kjella]

...is that if you don't program in Java, you've probably tried it. I know I've dabbled in everything from assembler, basic, visual basic, c, c++, java and various libraries/toolkits.

Java, by an order of magnitude, has the worst first impression of them all. Try writing "Hello world!" in a Swing window as your #1 tutorial. The start-up time, memory use and whatnot makes it seem like a dog.

Yes, I KNOW Java scales well to a large app, where it's not that relevant. That doesn't change the fact that if you dabbled in Java, and decided on something else as your language, your impression of it will be far less than stellar.

And you know how it is with every programmer telling you that "[MyLanguage] is the best", you'll think "Riiiiiiight. I tried it, not so buddy."

Kjella

Re:#1 reason java is uncool....

[toriver]

Java, by an order of magnitude, has the worst first impression of them all. Try writing "Hello world!" in a Swing window as your #1 tutorial. The start-up time, memory use and whatnot makes it seem like a dog.

How do you write a graphical "Hello world" in, say, C++? I mean without using a GUI builder. And, that's right, C++ doesn't have a standard GUI library, so you need to pick one first.

Re:Maybe because it's slow ?

[Sj0]

Some people weren't in class when the concept of an interpeter was explained, I think. ;)

Re:Maybe because it's slow ?

[Euphonious Coward]

It's not just because it's slow, but the reason it's slow (and Python, nominally 100x slower, isn't) is because of cache footprint. Java's garbage collector scatters storage all over as much address space as it can, so you get no effective locality. If your system ever swaps, it scatters its data all over the disk, too. That's why fake benchmarks always show it as "comparable to C++" (i.e. less than 3x slower) but experience shows you just sit and wait for a Java program.

But the reason it is uncool is because, outside of stuff written just for Java monkeys, there is no Free software to speak of written in it. Free software is written in C (65%), C++ (25%), and Python and Perl (all but the last 1%). Free Software coders have avoided Java for lots of reasons, including its not-really-portability, its bad performance, its hasty and stupid language and library design, its corporate 0wnedness, and their own resistance to hype and idiotic jargon.

Java killed Freenet in the crib.

Obligatory Simpsons Quote (Sort of)

[sirGullible]

"But my mom says Java is cool!"

Whoops!

[DG]

Curse Slashdot's no-edit functionality!

especially the use or implied use of $!.

That should read "especially the use or implied use of $_"

My bad.

DG

Re:Maybe because it's slow ?

[AndrewCox]

And you would've missed that question on the Java Cert exam. System.gc() is only a suggestion. You can never force garbage collection.

Re:Java is unpractical!!!

[Anonymous Coward]

Not only do they do have to do this, but usually it's achieved by setting a custom "Java runtime parameters" string, it's not even as if you can type it into a little text box. Worse still, it's only centralised and "easy to find" (ha!) for the Java Plug-In: if you want to set options for .jars, it becomes a PITA.

And the "developer that creates scripts of executable that start the application" is essentially implementing a hack to get around this problem, not solving it. Java is supposed to be cross platform remember? You're supposed to be able to run a ".jar" bundle without setting custom options, remember?

Re: Java Myths

[gnuLNX]

Could not agree with you more there. Java just is not the write once run any language that SUN marketed it to be. It is close, but it ain't there.

Re:What is a 'real progamer'?

[Anonymous Coward]

Do they have any other choice? ;)

Paul Graham...

[JustNiz]

So he's never heard of good programmers outside of Sun?

Well he can't have much real experience then so why should I care what he thinks?

Re:Maybe because it's slow ?

[markbthomas]

It can, in theory, be faster. Sometimes you discover data that turns out to be constant in the end, but you don't know this until your program is running. A JITter can use this additional information to compile to machine code that is a lot simpler and therefore faster. If you then execute this piece of code lots of times, you can earn back the time spent compiling and then start to profit from it. I remember some work being done into some research which did this in C: it generated some C based on a template, fork()-exec()ed gcc to compile it to a shared library, dlopen()ed the shared library and then ran the code. Of course, you had to do this explicitly, but I think since the chances of actually having an algorithm that benefits from this is pretty rare, that's not going to be a problem.

That being said, Java has no way of hinting to the compiler "this is going to be constant for a long while now", or "I'm going to run this loop a couple of million times in a bit, you might want to JIT it real good". Without those, the compiler doesn't really have a hope.

Also, it's not a case of interpreted languages not being cool. Perl, Python and a myriad of other languages are all interpreted (or run as some kind of byte-code), and no-one complains. Then again, I've seen Java out-paced by many of these languages (most of which compile the program to byte-code at start-up faster than Java loads), which suggests to me that Java is just a poor interpreted language. If you've seen how JVMs work internally, I think you'll agree with me.

I know! Enterprise and Cool!

[DingoBueno]

Enterprise-grade apps and "coolness" may be inapproriate bedfellows. Besides, does any language offer both?

It's VB, right!?

Re:Maybe because it's slow ?

[Paulrothrock]

The only Java app I used very much was Limewire, and that was slow as hell for four versions of Mac OS X. Even heavily optimized Java that I wrote myself ran slow. And don't get me started about the load times or the ugly window elements.

Re:Maybe because it's slow ?

[SkyWalk423]

System.gc() suggests running garbage collection, doesn't force.

http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ System.html#gc()

I'm happy doing Java.

[cubicleman]

I've been using Java since '96 off-and-on. I've been on a J2EE project for the last 2 years. It's not a perfect language, but I definitely prefer it to C++ and Objective-C which I did in the early to mid '90s, and hopefully I'll never touch a Perl script again (I used to do some Perl--a most painful and ugly language).

Re:Maybe because it's slow ?

[danheskett]

What OS are you dealing with, and what JRE? I have Sun's offical XP friendly JRE here, and it's 28,501,412 bytes - pretty close to 30MB.

Re:Maybe because it's slow ?

[ArbitraryConstant]

It might be slow but it's not slower than Python. Not even close. Yet, Python is cool. It's because Python is fun. Partisans of other languages will likely feel the same about their language, and they're probably correct, but I don't know many people that way about Java.

Sir, I wish I could mod you +6

[Mister G]

Best. comment. ever.

Re:Maybe because it's slow ?

[smarttowers]

You may want to think about why software isn't written in java. One when you write software you want to make it available to as large a group as possible. Most computers don't have the JRE installed on them. This causes the issue now the person who wants to use the software needs to download the JRE also. As for it not-really-portability this is just nuts, I was part of a research grant that wrote a application in java. It was written on Solaris, run on Windows, Linux and we purchased a powerbook to check the platform independence and low and behold it ran on that also.

Why food is considered uncool debunked.

[atani]

After recent coverage on slashdot about breathing it had to happen. Hiro Antagonist has rebutted all claims against food and explains why eating really is cool.

So for all you fashion victims out there: white is the new black, Moto is the new Sony, C is the new B, my sig can beat up your sig.

<fx: retch>

Masses? hat Masses?

[reallocate]

>>"Visual Basic was meant to be easy, for the masses"

First, there's nothing wrong with a language being easy to learn and easy to use. Power and ease of use are not mutally exclusive.

Second, what's with this stuff about languages "for the masses"? VB programmers are programmers. No one's running down to the local curb store for a loaf a bread and a $400 box of VB.net. MS hasn't included Basic, Visual or otherwise, with its operating systems since,I dunno, DOS 3.3?

Re:Depends ...

[Saucepan]

Any helpful links to a good C++ API (not GUI toolkits) which is both POSIX and Windows might make me use that some more.

C++ has been around so long that by now there are jillions (possibly even hojillions) of C++ libraries/frameworks/APIs. Since you say you don't need a GUI kit, and assuming you are doing server programming, you might find ACE helpful.

I used ACE for a previous multithreaded server and the project was very successful. We developed on Linux and FreeBSD but had no difficulty porting to Solaris, and could have ported to Windows with a couple of days of effort (we had use the occasional POSIX-specific idiom, but this was our own fault, not the toolkit).

The author, Douglas Schmidt, is a well-known standards wonk and performance freak -- an interesting combination that results in a kit that provides full cross-platform support while running hard with C++'s approach of "you don't pay for it if you don't use it." The kit included a full CORBA ORB that supported realtime operation (ie, bounded maximum delay).

Probably the best compliment I ever heard about ACE was a from a very senior coworker who commented that ACE was "not bad, for C++." Trust me -- from him, that was high, high praise.

Having said all that, when I have to share the tree with other developers, Java is my favorite mainstream language.

Re:Maybe because it's slow ?

[toriver]

some programmers use it to store session-specific data

Then they are only pretending to be Java programmers. Session state is kept in the session object - what the hack do they think it's for? Servlets shall be stateless, possibly unless declared single-threaded, but noone is that stupid.

Nope.

[Prior Restraint]

You cannot force garbage collection. From the API:

Calling the gc method suggests that the Java Virtual Machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse.

[Emphasis added.]

Re:Maybe because it's slow ?

[Dan Ost]

Java is faster than perl, python, ruby, and PHP

As JIT technology matures for these languages (like psycho has
for Python), statements like the above become less and less true.

If you want speed, use C or C++. Enjoy debugging the pointers and memory leaks

What are you doing with pointers that you have to spend any time at all
debugging them?

Re:Maybe because it's slow ?

[johnnyb]

I agree with all of your points except the one about exceptions. You said:

"Exceptions. I'm trying to think of a modern language without exceptions. Hell, even C and Forth have exceptions."

I think he was talking about useful exceptions. Java has a real nice way of handling exceptions, and since it is GC'd you don't have the same hideous problems that you do in C/C++ with memory allocation.

Personally, the reason I think that Java sucks is the same reason I think most languages suck:

* No macro system
* No closures (you _can_ do closures w/ objects, but it's REALLY UGLY)
* No continuations
* No tuple-returning functions (this increases code size by about 50%)

Of those, the lack of tuple-returning functions is probably the biggest practical issue on a daily basis. For example, with Perl, I can grab a row from a database query like this

($firstname, $lastname, $zipcode) = $sth->fetchrow_array();

In Java (it's been a long time, so this isn't exact) it goes something like this:

row = statement.getrow()
firstname = (String) row.element_of_row(0);
lastname = (String) row.element_of_row(1);
zipcode = (String) row.element_of_row(2);

And that is just a waste of life and breath.

Macro systems (true macro systems, like Scheme's, not crap like C/C++ macros) are nice, because they allow you to emulate just about any feature of any other language. Scheme doesn't have exceptions, but you can combine continuations and Scheme's macro system and make exceptions. Scheme doesn't have dynamic variables, but again you can build them w/ macros. Scheme doesn't have tuple-returning functions, but you get the picture (hopefully).

Continuations are _really_ nice in complex code, but they aren't that necessary on a daily basis. They are more useful in behind-the-scenes functions.

Closures are pretty darn useful, but you can usually code around them pretty well if you don't have real ones.

If you haven't noticed, I like Scheme because it has a few really powerful features, and the macro system can be used to stitch these features together into just about any other feature of any other programming language.

Re:Maybe because it's slow ?

[seti32]

Eclipse itself was written in Java. From the Eclipse website:

The Eclipse Platform is written in the Java language...

A data point.

[Baldrson]

I'm involved with a project using a dynamically typed language that is implementing a major W3C standard. The code is pretty far along, probably 70% to 80% complete. Comparing it to the only open source java implementation by:

1. Stripping comments.
2. bz2 compressing.

The dynamically typed language is less than 10% the size of the java implementation.

When complete it is going to be, at worse, 20% the size of the java implementation.

PS: The symbol names used in the dynamic language implementation aren't terse.

Re:Maybe because it's slow ?

[freedom_india]

Are you serious? or have you never worked in an enterprise scenario?

Java is used in MANY thousands of enterprise applications at Server-side. Why do you think WebLogic, WAS 4.0 and even OC4J sell so much?

Java is manna for banking industry.

Re:Java is unpractical!!!

[fitten]

Different architectures will use different amounts of memory for stuff. If the developers have to worry and deal with all this stuff, it isn't much different from doing the same sort of things in C or C++ (worrying about 32-bit vs. 64-bit integers and the like).

From my experiences, Java being cross platform is one of the major myths about Java.

Re:That's why ...

[Sj0]

Don't mistake popularity for technological superiority.

After all, Windows has a 90% market share.

Re:PHP...PHP offers both....

[Ralman]

No, JSP and PHP are in the same category. PHP is great... if you like security holes and unmaintainable code.

Being able to recognize and prevent security holes are the mark of a decent and seasoned programmer. Javas hides this from the novice programmer.

As for unmaintainable code, this can happen with *ANY* language. Again, preventing this is the mark of an experienced programmer.

Both Java and PHP have cross platform issues no matter how you slice it. Again, the familiarity with the language keeps these down. You are not the only one who has written cross platform applications and had them run on a variety of platforms. I have built PHP apps that run well anywhere you put them. I have also seen Java apps that won't run anywhere but on the platform they were developed on. This is really a stupid point all around!

As for the library issues, PHP suffers from the same, so does Perl. CPAN has some crappy and nearly useless libs in there. Again, a stupid point.

In the end it comes down to programmer preference. I like PHP, you like Java, in the end, does it really F**ing matter what you use, as long as it gets the job done?

Re:Maybe because it's slow ?

[toriver]

Look, for example, at Eclipse IDE. Eclipse is a Java app, and its extremely powerful and not very slow. Why? They use their own widgets that have less overhead, they are not using Swing widgets.

And then you use Borland's JBuilder, which is a Swing app, and see it's not slow either. It's not the library that's the problem, it's how you use it.

a bit naive

[dollargonzo]

frankly, this is a somewhat naive point of view. java can leak memory just like any other language. sure, you wan't forget to free something, but java might if you leave it lying around in some persistent collection. sure, you might not have header files, instead you have interfaces which allow different classes to depend on each other. java does alleviate the problem of pointers, but it has plenty of other problems it introduces. the stuff you mention isn't "crap," it's just that java masquerades most of those things to make it easier for simple projects. as the size of the project grows, java has as many problems as other programming languages.

JRE size?

[Watts]

I just went to java.com and went to the manual download page (since the automatic page detected I have a JVM installed) and the "offline" installer I downloaded was 15,633,128 bytes (14.9MB, if you just want to toss numbers around). The net installer package was about 1.5MB. Where are you getting this 27MB number?

Re:JRE size?

[Doctor Faustus]

27 meg sounds about like the size of the JDK.

Re:Maybe because it's slow ?

[An ominous Cow art]

True. An example of this would be FoxPro (grr, I mean Microsoft Visual FoxPro), which compiles to bytecode. It's extremely fast, but Windows-only. I'm sure the design tradeoffs made in it were different then those made for Java.

I've programmed extensively in both and like them both for different reasons. Whenever I need to access a data source in Java (which is right this very second if I weren't posting on Slashdot :-)) I envy VFP's built-in database manipulation commands.

Why I Dislike Java

[Prien715]

My dislike of Java has nothing to do with slowness. It has to do with control and succinctness. Trivial example:

// Must be stored in a file called "hello.java"
public class hello {
static public void main(String[] argv) {
System.out.println("Hello world!");
}
}

Since everyone likes readability, I'd like to ask what part of "static public void" helps you to understand the program. Let's compare this to, oh say Perl.

print "Hello World\n";

Which, as Perl's reputation precedes it, is obviously harder to understand.

Javs relies on vast ammounts of knowledge drilled into the heads of students. If the OO paradigm wasn't so popular, Java would be entirely obtuse. Anything not memorized must be looked up. You wanted to add that integer to the float? Too bad. Go look it up type converting. Additionally I'd like to conjecture that the human mind is better at remembering small things than large ones. Therefore, system.out.println() is more difficult to remember than print. I'd rather remember something like "-e" (Perl) to test for file existance, than the Java equivalent, which I have looked up and since forgotten (though I've used each the same number of times).

While C may be verbose, it allows you to have near complete control of the physical operations of the hardware (e.g. when you delete memory or use a pointer, this has a physical analogue).

Java is both verbose (lots of commands to do simple stuff), clunky (really long commands), and forces you to use the OO paradigm whether or not the problem demands it. It's these reasons why I dislike it.

Re:Why I Dislike Java

[Capt_Troy]

Your sample just goes to prove that java and perl may not be suited for the same tasks (which everyone already knows). Comparing languages is pointless, it's like comparing a fork and a spoon. Forks are good for steak, spoons are good for soup.

I use Perl when I have a task suited for Perl, Java when it better suits a task.

I do agree that it's difficult to do some simple things in Java... I personally feel that it's benifits outweigh it's detractions in most cases though.

Re:Why I Dislike Java

[DpakoH]

$ bsh 'println("Hello, world!");'

Re:Why I Dislike Java

[MemoryDragon]

My dear friend, this is easy to answer. The reason why your hello world is as verbose at it is, is that java in the core is OO (not really pure thanks to the hack... core datatypes and operators, but pure enough, that the example is justified as it is)

Perl on the other hand is in its core procedural, like C++ has a procedural core.

Perl is not harder to understand, but the main problem of the language simply is, that it has so many shortcuts to problems that you easily end in a mess of shortcuts, ditto for C++

Java basically sacrifices some of those shortcuts for the sake of readability. What in the end comes out, is probably 10-15% more locs but much more readability and less bugs.

Well if you go for the fast hack this approach might not be the best, but if you have to design huge software systems, are more readable approach which some security nets builtin is heavens sent.

Now if we go to Python, python developers always claim less code, but I did a few things with Python, and the less code approach is more or less not justified, the class libs of this language arent too far off the ones java and C# use, and the only code reduction i could see was to use inlining instead of brackets for block signing (which is a matter of taste but saves a few lines per class, not very much) and the non declarative character which removes you of the responsibility of having to declare a variabe.

The non declarative approach maybe in the long term saves around 1-2% of code, but causes lots if trouble regarding typos in variable names, idiotic assignments and so on, which have to be covered by unit tests, which add another 15% to the code, to reach the same stability.

So non talkativity in large systems is a question on how fast you can achieve an elegant decent result, and often non talkative languages with shortcuts, prove to be worse solutions for middle sized and large systems, than ones which look on the first sight not that elegant.

Re:Why I Dislike Java

[retinaburn]

Others have said it, but I guess you missed it. Java is a tool, for a specific type of problem. If you need to do funtional programming then don't use this tool. If you need to print out a statement to stdout, then don't use Java its overkill.

Re:Why I Dislike Java

[smart.id]

Or, your could combine the spoon and fork and get a SPORK!

Re:Why I Dislike Java

[Capt_Troy]

very true, very true...

But then you have a utensil that is not good at being a spoon or a fork! It's only useful quality is as a conversation starter:)

Re:Why I Dislike Java

[Prien715]

OO does not mean not elegant. Ruby is pure OO and also elegant. So OO isn't necessarily the answer or the problem. Hello world in ruby is as follows:

print "Hello, world!\\n"

Which is every bit as elegant as Perl. Readability is a two-way street. Sure, you can write term papers using vocabulary words a 2 year old would understand. That's Java. Succinct syntax is harder for you to read initially, but after looking it up just once, you'll remember it. Think of it like the abbreviation "TCP/IP". Yes we know what it means, but would writing it out each time really increase readability? I've not worked on "large" systems, but I'd imagine the most important thing is the existance of functional contracts between component parts (i.e. black box descriptions of functions/objects) and testing to make sure the IO is what its contract stipulates rather than necessarily reading everyone's code (which, I'd rather have be fewer overall characters, but that's a personal preference from literature that's carried over).

(As a parenthetical expression, but responding to some of the people not you, it bugs me when people talk about the $ and % in Perl as making it less readable. Once you figure out what they mean (which takes approximately 1 minute), I find that they substantially increase readability as you can now tell variable names and types from anything else. Like how all nouns in German are capitalized (no one complains capitalizing nouns makes it harder!))

Re:Why I Dislike Java

[Warpedcow]

Anything not memorized must be looked up.

But that's the beauty of Java. It's very easy to look things up. The Sun Javadocs are vastly helpful, plus you can generate your own javadoc for your own code very easily. Does perl do that?

Therefore, system.out.println() is more difficult to remember than print.

You don't have to remember system.out.println(), you only have to remember how to navigate to sun.com's javadocs. Actually, with any decent java development environment (such as Eclipse or JBuilder), you just have to remember the beginning of the word system, and up pops a box to auto-complete with the full name plus a snippet from the javadoc explaining what it does etc... this is much more intuitive than Perl.

The point is, with Perl, you have to memorize "print". With java you don't have to memorize ANYTHING because it's all so easy to look up.

Just my 2 cents from my own programming experiences.

Re:Why I Dislike Java

[MemoryDragon]

You totally missed my point, you just showed another shortcut to a very special problem, hello world. But also in ruby, you end up pretty much with the same amount of lines as in java C# and other languages once you have a larger system. The problem lies within the mentality as soon as you have too many shortcuts to fundamental problems a larger system is hard to write and maintain. A simple hello world is a bad example for the quality of a language, by this definition it is very easy to write totally stable rock solid systems in C++ in a short period of time, which it isnt. And it is totally easy to maintain a foreign perl system which is badly documented.

Re:Why I Dislike Java

[BestNicksRTaken]

Well, said OO is totally overrated.

I've seen job applications that *require* OO Perl and OO PHP - WTF, have those people actually tried doing OO PHP and seen how cludgey it is?

OOP, just like Java is a bloody buzzword for PHB's.

Python is beautiful though - and not because it's OO, but because it's got rid of all the crap like "{}", ";", "public static void", "system.writeln"

Python: print "Hello World!\n"

Re:Why I Dislike Java

[Cyno]

$ echo "Hello, world!"

Absolute simplicity, proof that Shell is the supreme programming language!

"There can be only one." - Santa Clause in South Park

Re:Why I Dislike Java

[AnyoneEB]

As a logical continuatation of keeping "Hello World!" short, we can see that Microsoft's QBASIC is obviously the best programing language:

? "Hello World!";

(For those of you who do not know QBASIC: "?" is a shortcut for "print" and a semicolon after a print string instead of a comma makes a newline after the string.)

Seriously, Java is obviously not the best tool for the job of printing a string to the screen (not even counting the verbosity, the start-up time and memory usage would be too much). On the other hand, in larger projects, the verbosity means the code is easy to read. Also, as mentioned by other posters, Java IDEs have autocomplete with Javadoc preview, so actually opening up the docs is rarely needed once one is used to the class libary. Of course, if you believe that Java is not the right tool for the job, don't use it.

Re:Why I Dislike Java

[the_greywolf]

I use Perl when I have a task suited for Perl, Java when it better suits a task.

as i see it, the problem is exactly here. some people are so insanely zealous for their language of choice that they can't see beyond one simple fact: their language of choice may not be the choice language for their task.

Re:Why I Dislike Java

[Anonymous Brave Guy]

The Sun Javadocs are vastly helpful, plus you can generate your own javadoc for your own code very easily. Does perl do that?

Without wishing to fuel a pointless language flamewar, you did know about perldoc and POD, right?

You don't have to remember system.out.println(), you only have to remember how to navigate to sun.com's javadocs.

Sorry, but that's taking a reasonable argument (it suffices to know the simple things off by heart and know where to find the rest) to an absurd extreme (it's not important to know anything as long as you can remember where the reference docs are). It doesn't matter how easy to use the reference materials are, if I have to go on-line several times for each line of code I write, I'm not going to be terribly productive.

And it's just as easy to look up print in Perl, BTW.

Re:Why I Dislike Java

[Warpedcow]

The point I was making was that for me, Java is much easier than any other language I've touched because of the Javadocs (and many other reasons as well). I've not done much perl and no I've not heard of perldoc and POD. If I ever do Perl, I'm sure they will be helpful :)

Also, the system.out.println() vs print argument is silly. I've never used that call in any of my 2 years of professional java coding to my knowledge (I do mostly gui stuff). I think there are thousand of other properties of a language that determine it's usefullness than that.

Just my two cents...

Re:Why I Dislike Java

[Anonymous Brave Guy]

I've not done much perl and no I've not heard of perldoc and POD. If I ever do Perl, I'm sure they will be helpful :)

They certainly will; they're more-or-less directly equivalent to the Java tools you mentioned. :-)

Also, the system.out.println() vs print argument is silly.

As an isolated case, a specific example, yes, I agree with you. My point was more the general approach I read into your previous post: that having good documentation was an adequate substitute for knowing even the basics of your language's standard library. If you're working with console apps, the print example is directly relevant; if you're a GUI kind of guy, I guess not knowing the basic classes of your windows/dialogs framework of choice would be equivalent.

Re:Maybe because it's slow ?

[Kombat]

It's a bit shortsighted to assume that Java magically makes bad programmers less risky.

Uhm... but it does. It doesn't make them good coders, of course, but it does substantially limit the damage they can do, compared with C.

I'm reminded of a humourous quote by Bjarne Stroustrup, which was something to the effect of, "C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, you'll take your whole leg off."

Re:Maybe because it's slow ?

[Viol8]

"Another possible reason is because C/C++ has to free up memory as it goes"

It doesn't have to. You could have a global list of pointers you've used and free them all up at the end or every given time period a la java.

Re:Maybe because it's slow ?

[deadlinegrunt]

"Bullshit. IME..."

Oddly enough I was pointing out that comparing Java's platform to a language specification that is implemented differently for each platform it runs is a better cost-benefit analysis than simply saying, "Good luck pointer jockey"

At no point did I elude to the fact that C or C++ hackers who know what they are doing don't have problems. Am I to infer that Java developers do not have problems? No - you qualified it by "Java lowers the bar somewhat" BUT my original meaning seems to be lost.

Bullshit indeed.

Ugh

[That's Unpossible!]

You mean you own a TV?

Re:Masses? hat Masses?

[kisrael]

First, there's nothing wrong with a language being easy to learn and easy to use. Power and ease of use are not mutally exclusive.

True. But sometimes "ease of use" runs into "quick and dirty", and all the difficulty in maintaining and extending that that implies. VB and Perl lend themselves to quick and dirty and require more self-discipline to stay well-engineered. Java usually pushes you to more forethought, and while crap code is certainly possible, it's somewhat less likely.

Second, what's with this stuff about languages "for the masses"? VB programmers are programmers. No one's running down to the local curb store for a loaf a bread and a $400 box of VB.net. MS hasn't included Basic, Visual or otherwise, with its operating systems since,I dunno, DOS 3.3?

Yes, currently VB is just another language.

But I grew up with built-in BASICS, and when I got introduced to it, VB3 seemed to be positioned in a similar role. I got a student edition for cheap and had a lot of fun.

As for the "for the masses", that could also be "for the non-techie, business-knowledge people in your company". I don't know if VB (especially the Office-centric versions) still do that well or not.

I do think that we who grew up with computers that booted into BASIC have an edge over people who get the start button. Making goofy, kiddie programs had a much lower barrier to entry back then...now it's almost certain you'll have to install something, or go nuts with the Javascript.

Ahh I see...

[FatSean]

I agree that Java is not the best on the client for the reasons you list. There is a time and place for it, but honestly deploying Java apps to the desktop should be verboten! Leave it on the server and let your users use their familiar web browser to get work done.

the real reason

[pchan-]

here is the REAL reason hackers don't like java, and most of them don't even realize it.

the job of an organization developing a software product (whether it's a company, an open source team, whatever), is to get a product out. nobody outside the project cares about languages or anything else, as long as it all works in the end. but to get a product out, the manager eventually has to pick a strategy. they usually fall somewhere in between the two extremes:
A) use a few brilliant (possibly well paid) hackers and let them do the work. they're smart, and good enough to rely on to just do it. managing them is like herding cats, but why would you need to?
B) use an army of keyboard monkeys and manage the hell out of them. these guys can pound out mediocre code, but with enough software engineering from the top down, well defined specs, and massive testing and integration, their work is sieved into a release-quality product.

real hackers hate being marginalized, having their creativity stifled (yes, for those of us who actually write code, not just implement specs, creativity is involved), having to do the dumb solution just because everyone else is too weak to do their part of the smart solution.

java is not a bad language. i think many would agree that is it at least decent (i think it's pretty good, actually). but java is the language of the B coders. it is made to be easy and idiot proof, like visual basic. you cannot do "neat hacks" in java, because if you could, the B coders would screw it up and produce worse code. java is a great language for the B coders. but the choice of java for a project is often a leaning toward strategy B. it's the "we can get any code monkey off the street to do this". it's the grunt work software that real hackers don't want to do, and what B coders are hired for.

perl, a RAD (and rad) programming language, does not suffer this stigma. perl is accepted by hackers, precisely because it is not idiot proof. it's easy to confuse the B coders (and yourself) with some maliciously written ascii barf. you can do some crazy tricks in perl. it does not lend itself well to software engineering and the micromanagement of the B coders. perl is a hacker's language.

many real hackers i've seen instinctively feel resentment towards java and the like, because they see marginalization of the software industry. java is for the blue collar coders, part of the greater plan of "software factories", where reproducability, meeting deadlines and specs, and easy replacement of people is way more important than doing cool shit. those of us who wish to stay at the top of the game, to do the cool shit, to write the programs that interest us the right way are often drawn to the languages that keep out the idiots, that have a higher barrier of entry, and let us do the cool hacks.

i don't dislike java, and i don't dislike you B coders out there (you know who you are). i just don't want to be one of you.

thanks for reading my long-ass post,
p.

Re:the real reason

[U96]

Mod parent up! This is right on.

Re:the real reason

[fakeplasticusername]

I understand your point, but i would have to disagree. Partially.

I am a java coder. I consider C/C++ a knowledge based coding language. If you take your time to learn all the tricks of the trade in C, you will probably be a better coder than I am. Java isn't as tricky of a language, most everything you need is in the javadocs.

I can gaurantee you that the C++ master would write cleaner code than the casual java coder, and probably even better than the java master, the difference being the java coder doesn't have to know every nook and cranny of the coding language to write a good program. I would never presume to call the C++ programmer more intelligent than the java programmer, merely more knowledgable and likely more passionate.

I personally don't use java with the desire to become a java guru or a programming master, i just want to write software that works, and i don't want to spend a great deal of time doing it. I don't program for the joy of programming, i program for the joy of solving a problem. The amazing thing about java is that it gives the ability to write software to just about anyone. Yes there are B coders in java, but many of them are A engineers who see coding as a means to an end, not the end itself. Whether they can write good software or not is a function of their intelligence, in my opinion, not of their language choice.

Re:the real reason

[BigLinuxGuy]

The saddest statement is that great code [in whatever language] still ends up being crap if it's based on bad (or missing) requirements and a lousy design. Unfortunately, most coders are not good are requirements or design because they want to focus on the code for the instant gratification. It's even more poignant when application developers suddenly think that they are enterprise application developers by virtue of using a toolkit or spec that has the word "enterprise" in it. Far too often the desktop application programmer mentality becomes apparent when so-called enterprise applications require the resources of an entire server for a single application (and frequently a cluster of those servers).

I've sort of given up on common sense coming to bear because of the "just buy more/larger servers" or "drop in more RAM" mentality that is far too common in the industry these days. So let's hope that Moore's Law doesn't slow down any time soon because all of these "advanced" enterprise applications will need all the help they can get.

Re:the real reason

[BigLinuxGuy]

Interesting post. My observation is similar, in that management has been trying to do away with the need for developers for at least the last 20 years or at least commoditize them (see tools like PowerBuilder or Visual Basic). Is this a bad thing? Well, as you note, it allows less-skilled workers to be successful (to a degree). However, you often get what you pay for (see another "rant" on my part in this chain).

Realistically, hackers like to think of themselves as outsiders to a degree because that's how they measure their "coolness", i.e., by their code kung fu. Well-established languages with visual paradigms, such as VB and now Java, become increasingly looked upon as children's toys.

To balance things, Java is a very clean language that builds on the footsteps of its predecessors. However, the frequency of change and the size of the required virtual machine (and its resource demands) may make it less desirable for some projects.

For most of the things I do, Perl, Python, PHP, and occasionally Tcl/Tk are more than adequate. I'll go to C or C++ if I need more speed and FORTRAN 77 if I need all the speed I can get. But I guess being multi-lingual is too much of a strain for what you characterize as "B" coders. ;-)

Re:the real reason

[delete]

You sound rather bitter. Is it perhaps because you have found that real companies actually like to meet deadlines and produce reliable software in a structured manner, rather than letting "A coders" (based on whatever ad-hoc criteria you use) like you waste time doing some "cool hacks"?

I would certainly argue that the ability to understand complex problems and implement novel solutions is what separates good coders from those who might be more suited to other jobs. However, surely "doing cool shit" does not depend on your choice of language, but on the individual. If you're unable to do that in Java, is it really the language's fault? Do you believe that no developer is capable of originality or creativity merely because they use Java as their primary language?

The level of language bigotry in this thread is amazing. Ironically it was Paul Graham, the champion of oft-rediculed language, who started this discussion.

Re:the real reason

[Austerity Empowers]

Drop the elitist crap, it makes you sound like a teenager. I almost don't even want to read your post because it's so wrong.

You had a valid point in there somewhere, I think it is that Java does not have a niche application where it actually makes development faster.

Java's one "best" is portability. Neither Perl or C natively move from platform to platform with the same ease Java allows.

However, the vast majority of programming out there is custom stuff that is particular to an environment. Either embedded stuff that goes directly on some random processor, or custom application layer stuff that takes one big hunk of software that someone else wrote and makes it work with another big hunk of software, with a lot of your own in between. That in itself is almost always specific to an environment.

The only niche i see for Java is the graphical front end for "Office" applications, "EDA/CAD" tools, etc. However in terms of people working, these represent a smaller chunk of development. Most of those that use Java to date, tend to use it only for the graphical front end.

Re:the real reason

[TheLastUser]

Typical anti-Java bunk. You forgot the "Java is slow" comment by the way.

The truth is that there are B coders that write C and perl too. It really doesn't matter what tool you give a B coder, you still don't end up with A material.

In our shop, we code in both C++ and Java. Nobody upstairs tells us what to use, we even use a bit of perl now and then. Most of our stuff gets written in Java. Simply because its vastly easier than to do it in C. Java has a really fantastic set of libraries that allows very complex applications to be written easily. This lets us concentrate on producing a kick-ass product, instead of fiddling with memory allocation, etc.

For web applications, C and Perl are less than useless. Java app servers are so far beyond apache/modperl that the comparison is a joke.

As a C bigot and part time anti-Java stooge, I am sure that your inane construct of the A and B coders serves you well. It must be very satisfying to produce a bunch of C that does next to nothing, in between seg faults, and say to yourself, "This is a masterpiece and I am a god".

What we do in a month, you couldn't do in a year, and that, my friend, is why your shitty language of choice is headed the way of Ada.

Re:the real reason

[durdur]

IMO the main reason to program in a "safe" language is not to cut the coding cycle but to cut the debugging and maintainence costs. You can't leak memory in Java or stomp on pointers (well, you can, but it's hard ..). So you don't spend time finding the leaks and overruns, and you don't get angry customers who find them for you. Do you really want to do more bug fixing?

I also dispute that Java coders are generally less skilled. You get the same spectrum of skill in Java you have in other languages. I know guys who are Java wizards and are maybe 15x more productive in the language than your average coder. Plus they know all the latest features: generics, NIO, enums, annotations, etc.

Re:the real reason

[Anonymous Coward]

It is good that you don't want to work for hte big software shops, as it would never happen. Let me give you a manager's persepctive on why "cool hackers" are not desireable as hires; you just listed all the reasons why I would never, ever hire you in a million years to work on my major financial system.

1. You think you are too smart to work from a spec. Implementing a spec does not leave no room for creative solutions to problems. It just guarantees that you won't be a typical "midnight cowboy" loner who programs an 31337 solution that does not actually meet the requirements of the users. I will take someone who can solidly do the work I need done over a genius who gives me a creative app that fails to implement the spec any day of the week. And I will have more confindence in the B coder who I know is not a prima donna.
2. You look down on the concepts of testing and integration. Imagine 40% of financial derivative deals in the world financial market suddenly unable to be valued and executed for a day, a week, a month - that is what happens if my system goes down. If an appliation outage means potential damage to the company and a noticeable impact to the world financial market, testing is not just a good idea. It is everything. Hell, yeah, I manage the hell out of my team. I don't sit at their desks and micromanage them, though, and you seem to think that the former implies the latter. I just make damned sure that everything we do is extremely well-tested, lest we cost the bank millions of dollars with a simple error.
3. You actually think "cool" matters. There are places where this is true, such as perhaps game companies. But my own time in the candyland of the late 90s boom showed me that coolness is not nearly as important as delivery and reliability. You may deliver good, cool code, but as a manager I am not at all sure I can rely on you unless I coddle you and keep you happy.
4.You have disdain for your potential teammates. I will never hire an "A" programmer if that means getting someone with your attitude. Instead I will hire what you call "B" programmers (many of them extremely bright people at the top of their field). I will treat them with respect and empower them to make their own decisions as much as possible. And day to day I will worry much less about them than you because you come off as an arrogant ass who thinks highly of himself and cannot work with others.

Enjoy your work on the "big" apps with the other A programmers. Those of us who build software that keeps the world running have other things to do.

Re:the real reason

[atlacatl]

I read your post and it reads like a flame bait, so I'll bite...

I see that you class yourself to be a programmer only. Your knowledge of language dictates the cool stuff you write as a self proclaimed hacker. In your case, perhaps Perl and PHP. I don't think all hackers see themselves in that light. Wether Java is cool or uncool is a childish argument and it shouldn't really be discussed - Or if Windows is better than Linux - In thruth, who cares. There are things that each tool does very well.

Now, when it comes to writing/designing cool stuff, what really should drive the design and the implementation is the problem itself - NOT the "cool" programming language. I've written code in most languages liked by real hackers and the most unmantainable code I've seen has been written in Perl.

The point of Software Engineering is not to identify the "real hacker" in the group - Most projects based on that mentality fail, anyway. Software Engineering is about building Software System that are mantainable through the productive life of the system. Java is a tool that lends itself to implement true OO Engineering. Wether some Joe Shmo guy consider it cool, is irrelevant to my ability to architect "cool" system - Cool is a subjective term here. For mere programmers, scripting tools are fine, for Software Engineers, the product/business problem drives the implementation. And we are talking about business application that need to be upgradable, maintainable, and accessable most times of the days, Java seems to be tool of choice - At least for some years to come (10 or more). I trully doubt a multi-million dollar system would be awarded to Perl shop with 10 real hackers, if a Java shop with 2 or 3 top architects with good software engineers to implement the system is competing for the same project. Like the saying goes, to hammer, everything looks like a nail.

BTW, I'm not saying that Java is the only tool that can be used to architect and implement big systems, I'm just saying that CTO are investing in the technology and leaving scripting language for minor tasks...

Everyone is motivated by different things, so if writing lonely code that will be used once to do ONE cool thing is the real hacker way, then I am not a hacker - Giving value is my motto, not unmantainable obfuscated lines of code...The code is but a small part of anything - If one cannot see this, then one should stay a programmer for life...

Re:the real reason

[I_Love_Pocky!]

No one has responded to the real problem with this post. You seem to come at this like programming is some kind of difficult feat. I don't care what programming language you use, you are not special because you can program.

The only real interesting problems in software are in the design. A programming language is just a means to an end. I don't care what you program in, all programming is grunt work. It can be fun at times, but it isn't an intellectual challenge.

So, to put it plainly: Get over yourself. If it makes you feel better to produce all your apps in something with a high barrier to entry like assembly, feel free. It doesn't guarantee that they will be better though. If you pick the wrong algorithms/data structures/architecture, even the most bloated high level language could out perform your low level code.

The bottom line is that Java is an excellent language for certain applications. If you are so intelligent that it bruises your pride to use Java, then what the hell are you doing as a grunt programmer anyway?

Re:the real reason

[Frizzle Fry]

it is made to be easy and idiot proof, like visual basic. you cannot do "neat hacks" in java, because if you could, the B coders would screw it up and produce worse code.

The only people who would rely on "neat hacks" in a production system are your "B coders": kids straight out of college who haven't yet learned who to write clear, maintainable, solid code. Regardless of language, your "A Coders"-- people who know how to write professional quality code-- are going to be good enough to write correct code that doesn't rely on being clever and tricky, and don't think that clever and tricky code is cool or macho.

Re:the real reason

[Anonymous Coward]

Java servers are either leaky or un-safe (according to Sun's definition of safety), and this is easily proven. To be safe, you must ensure that the type Foo I load now was the same as the type Foo I loaded yesterday. The only way to ensure that is to keep the Type Information Block (TIB) describing Foo around, even after all instances are gargabe collected. Wait, memory that is kept around after it is not used? That's a leak! The reason it exists is that Java provides the class.forName() capability (if it was just new's to worry about, you could keep safety and not leak).

Now, how serious is this leak? Not too bad in most cases, but it can be serious if using application frameworks that dynamically generate classes and load them (like Java Server Pages). And so, you have to reload your server every once in a while. Of course, you could just allow it to be unsafe and reclaim those TIB's, since nobody in their right mind would actually reload one of those old classes anyway.

I just thought I would bring it up since so many Java coders get their panties in a bunch when someone disses their language. Me? I program in Java, but I agree that it is a terrible lanugage. Unfortunately, I can't afford Franz Lisp (and only use CLISP for non-gui stuff), I don't really like Qt (sorry C++, I liked you the most), I hate PHP, don't like the fact that ObjectiveC isn't useful off of the Mac, ... crap, work time

Re:the real reason

[StillNeedMoreCoffee]

"java is not a bad language. i think many would agree that is it at least decent (i think it's pretty good, actually). but java is the language of the B coders. it is made to be easy and idiot proof, like visual basic. you cannot do "neat hacks" in java, because if you could, the B coders would screw it up and produce worse code. java is a great language for the B coders. but the choice of java for a project is often a leaning toward strategy B. it's the "we can get any code monkey off the street to do this". it's the grunt work software that real hackers don't want to do, and what B coders are hired for."

But then if you think about it historically, say Databases for instance which when they were first introduced were expensive, slow, combersome to use and support, but yet there use took over the industry in a short time. Why? Not because there were difficult to use, or expensive or slow but because they solved a fundemental problem, that of the seperation of the logical view of data from the physical view of data. That one fact alone saved everyone man centuries of work. The IT industry was at a standstill with all the time maintaining systems and no time or manpower left for building new systems. Some of the features of Java like Garbage collection and array bounds checking solve another fundemental problem software developers have (not to mention the device independence and the comprehensive language libraries).

I guess it gets down to where you want to spend your time. Writing applications that work, or collecting the garbage yet again. If your contention is that people who like to collect their own garbage over and over are "A" programmers then I think we are really talking about "D" programmers for Dinasaur's.

Some people write poems some novels some advertisements some love letters some editorials. Who are you to say which medium of expression is more valuable?

Re:the real reason

[pzarecta]

As to whether Java is ultimately un-cool: of course it's uncool. It's a programming language, for cryin out loud. But if you /.ers think hacking out one-liner code in C or Perl is cool you are sadly mistaken. if (geek.isProgrammer()) { cool = false ; } Speaking from personal experience, I've even gotten laid more since I've started programming in Java, so C/C++ (and perhaps Perl, etc.) are at least as un-cool as Java if not more.

Re:the real reason

[Sirius25]

Wow, thanks for posting that long ass thing.
Although i don't really agree with some of the specific points you made, you go the gist of it enough to get me thinking.

I'm definately no elitist.. not even an "A" coder, but i really hate Java.
I think, for me at least, Java is just a symbol of the 'new' computer industry. The college kid's & corporate suit's computer industry.

Not sure if Java simply had bad timing, or is just generally stood up for by the wrong kind of people (college kids & suits).
I don't like the language itself, but i might have used it, if it wasn't such a strong symbol of the curruption of our industry.

Our jobs have gone corporate & our networks have gone public. The geeks have to lash out at something.. and Java seems to be attatched (though not necessarily by function) to the root of it.

Re:the real reason

[Edie O'Teditor]

The college kid's & corporate suit's computer industry

It could be worse - imagine if there was more than one of each.

Re:the real reason

[Sirius25]

Or even worse than that, imagine if they were so superficial they lost all ability to infer meaning..

Re:the real reason

[lee7guy]

I have never really used FORTRAN and was quite intrigued by your comment. A google search for example code brought me some examples of which I found this one the most interresting:

SUMMA = 0.0
ADAM : DO I = 1, 10
X = TAB(I)
EVA : DO J = 1, 20
IF (X > TAB(J)) CYCLE ADAM
X = X + TAB(J)
END DO EVA
SUMMA = SUMMA + X
IF (SUMMA >= 17.0) EXIT ADAM
END DO ADAM

The question is, are all FORTRAN coders that obsessed with various forms of sexual acts?

Re:Go write me a distributed n-tier web site in c

[togginho]

you just stepped on your arguments from the original posting... thanks for that ;-)

Re:Maybe because it's slow ?

[sploxx]

First of all, Java!=JVM. Please make this distinction. I won't discuss the pros and cons of Java as a language here, just the JVM. You can use gcj to GNU-compile Java and you'll get very close to the performance of GNU-compiled C++ which is what one would expect. Note that I said GNU-compiled because there still commercial compilers which produce better code, in terms of execution speed. [Of course, I hope GCC will overtake them, but that's an unrelated issue :)]

Mod me troll flamebait, whatever - but the JVM is slow, not only on start up.

The empirical argument
IMHO, todays average real world JVM app *is* slower than the average real world compiled app. And, no, I do not talk about the startup time only. GUI code is slow. Network/File I/O is slow. Show me a JVM app (app, not test case!) with a native compiled equivalent which is slower. You won't find any.

MAYBE there is the *theoretical possibility* of JIT being faster than compiled/hand optimized assembly code. But this is purely theoretical. I have yet to see real world apps and not some made-up testcases with matching peephole optimizations for a particular architecture where this is the case. There are still uneccessary virtual method calls, wasted stack space etc. in JIT code.

The theoretical argument, mixed with personal opinion :)
Doing JIT with JVM code involves steps very similar to decompilation [JVM->IntermediateCode->Target] because in JVM code, no information about higher-level structure is preserved. This reconstruction is computationally very expensive (google: decompilation problems) so only approximative algorithms are used, leading to non-optimal code. There are reasons why e.g. the ANDF format preserves much more information than JVM code.

A possible solution
I think LLVM is a nice project that could bring all the VM hype of Java to C/C++/CommonLisp/Perl/Python/BiglooScheme etc. And Java!
Sure LLVM still lacks many things, the VM code isn't much more descriptive than JVM code etc. But it is independent, and it is growing. An LLVM applet plugin for Mozilla would be nice :)

This is also a partly political thing. Why do FLOSS Java developers accept the fact that Java and JVM are so tightly coupled? Maybe this helps Sun's goals (to spread the platform Java) but technically, it is clearly an inferiour solution.

Re:Maybe because it's slow ?

[Euphonious Coward]

Most computers don't have the JRE installed on them. ... As for it[s] not-really-portability this is just nuts.

The first sentence above contradicts the one that follows. Java code can hardly be portable if it won't run at all on most potential users' machines.

On machines that are already burdened with JREs, how can your program pick from among them all which one to use?

Re: Java Myths

[mlk]

Right... So cos a DEVELOPER did not know how to use the language/platform, the language is shit...

Mmmm.....

They can always use the VM interface...

[FatSean]

...and many still do if they are more efficient with it.

Boring old language wars?

[Fallen Andy]

Sigh. Being the oldster I am I thought the nonsense of mine is bigger than yours had died down.

This is the followup to a piece of hero worship (very much in the spirit of U.S centric culture) of the "Great Hacker". Oh where is this mythical beast? I see him not, yet I have longed to meet this wise and omnipotent entity.

Foo. Here in Europe we don't believe in such junk.
I've met some fine artisans, and some really unpleasantly egotistical f**ks as well. Sometimes they seem to be one and the same entity. But like
male cats you can't exist in the same arena without risking some nasty matter anti-matter collision...

Twenty plus years of avoiding cobol (deliberate lower case) and other crocks and I'm still reminded of that line in Blade Runner:

"I want more life f**ker"

Here in Greece, you could end up homeless for two years or worse just *trying* to be a hacker. Believe me. I've spent more time feeding the doves and educating the locals here in athens about dove culture than programming...

Hope nobody remembers this post...

Re:I guess that you didn't read Paul Graham

[Phaid]

The specific languages that Graham and Hejip compare to Java are irrelevant; I was citing a reason for Java's perceived un-coolness and used C as an example of a language without Java's perceived shortcomings in that regard. I'd also recommend that you read the Graham article more carefully, as he does indeed mention C, right here:

If Microsoft used this approach, their software wouldn't be so full of security holes, because the less smart people writing the actual applications wouldn't be doing low-level stuff like allocating memory. Instead of writing Word directly in C, they'd be plugging together big Lego blocks of Word-language.

To put that passage in context, he's talking about a bottom up approach, and how the "great hackers" should be used as tool makers, building the Duplo blocks that the less talented people can use to assemble applications.

Have fun with your Lego.

Thanks for the link ...

[gstoddart]

Since you say you don't need a GUI kit, and assuming you are doing server programming, you might find ACE helpful.

I'll look into it. It's bugged me about C++ that I would need to write different OS-specific libraries for a bunch of stuff.

Cheers

Re:Depends ...

[Anonymous Coward]

In my experience (which isn't huge with Java, but I've used it for commercial work), one of the things I liked most about Java was that it actually tended to save me lines of code.

Oh, sure it's got an explicit full-on syntax, but I'm comfortable with that. What I was most impressed with was there was a vast amount of standard data types and APIs available to accomplish a very huge amount of stuff. Looking at C++ and the like, the APIs are anything but cross-platform. (Any helpful links to a good C++ API (not GUI toolkits) which is both POSIX and Windows might make me use that some more.)

Ding ding ding! We have a winner! Congratulations, you realized that a terse language is not necessarily a productive one. If that were true, C would be more productive than Java, and APL would be the most productive language on the face of the earth. Neither of those statements is true because the terse languages have primitive standard libraries and therefore usually require more code to accomplish the same thing.

Re:Depends ...

[Haeleth]

If you want all the nice Java libraries, strong static type-checking, and compilation to JVM bytecode, why not try Nice or Scala? Both provide everything Java has, including the ability just to use arbitrary Java classes and APIs completely transparently - and they add many of the best features of functional programming, and have terser syntaxes than Java too.

Worth considering, anyway.

Take a look at Python

[Dan Ost]

There are Python libraries that have platform specific behaviors, but at the
app level, something written in Python will behave the same on any platform
it's run on.

Site error

[Ifni]

From the article link in question:

Server Error
The server encountered an internal error and was unable to complete your request.
Could not connect to JRun Server.

Obviously, the Slashdot effect has brought pretty much every language to its knees and depends more on the hardware than the language the app is written on, but when the server hosting a page defending a language is itself run on that language and generating errors, it makes me laugh.

In all seriousness, on problem I have with Java as an end user is that many Java apps seem to be coded to a specific version of the JVM such that even subreleases from the same major (or even minor) version of the JVM will cause the app to not run. Ciscoworks is one of these. It drives me nuts havibg to have 2 or 3 versions of the JVM on every computer I use simply because one Java app or another is REALLY finicky. I don't know if this is a problem of Java attracting/creating bad programmers (as posited in the article this story is responding to) or if the JVM developers have no interest in backwards compatibility.

Other than that issue, I, as an end user, think Java is great. But then again, I program mostly in PHP or (*gasp*) Visual Basic (including VBA and VBScript), so I'm not really qualified to discuss what languages are a "real man's" language.

Uncool! I must not have gotten that memo.

[rben]

I guess I'll never make anyones list of greatest programmers, but I think Java is plenty cool, especially with some of the recent changes. Java has gone from being a trivial scripting language that was primarily useful for animating pictures on the web to a very powerful language that can occasionally outperform C++, especially on web appliations.

Java is far easier to learn than C++. While Java does not provide all the flexibility of C++, most of the time I don't need to be able to write code that interacts directly with the hardware.

The days of managing memory by hand should have become a distant memory for all but a handful of programmers long ago. Memory management bugs are among the most common and difficult bugs to fix.

When I first started programming Assembler programmers made all the same comments about us "sissy" C programmers that the C++ programmers make about programmers in Java and other memory managed languages. There aren't so many assembly language programmers around these days...

Re:Uncool! I must not have gotten that memo.

[Austin Milbarge]

> can occasionally outperform C++, especially on web appliations.

There are no C++ web applications. The only ones may be HTML embedded ActiveX controls and I highly doubt they are slower than java applets, unless the programmer is really sloppy.

> Java is far easier to learn than C++.

Yes, and Visual Basic is easier than Java. Ease of use is in the eye of the beholder. Outside of memory management, Java is on the same level of difficulty as C++. Besides, Java forces the OOP paradigm, C++ doesn't. You can learn OOP through C++ at your own pace. Also, the syntax among these two languages is practically identical.

> Memory management bugs are among the most common and difficult bugs to fix.

Yes, but what if the bug is inside the virtual machine? Want to talk about difficult to find and fix! It's happened plenty of times before.

Bottom line. Nothing is for free.

Who is choosing the right tool for the job

[Skapare]

I'm all for choosing the right tool for the job. But there are still a couple problems with this. First, there are plenty of valid choices to make for modern applications, which are so often web based these days. Second, the choices being made are done by business managers without consulting the technical staff, often before they've even hired any. Java seems to be the most common choice among the business people, with Perl and PHP coming in a distant second and third. The reason I believe so much Java is being chosen is not because of any technical value (which it does have), but because it is being sold to managers by sales people from companies like Sun and IBM. In other words, the decisions are being made "behind the backs of real programmers", despite the fact that in most cases Java would be a fine choice (as would a few others), anyway. It seems to me that there is some resentment against having non-technical people forcing a technical decision, made for non-technical reasons, on technical people.

Java is slow - so what?

[kelleher]

People are slower and more expensive. Hardware gets faster and cheaper every year.

Anyone who has worked with budgets in large corporations can tell you Developer/Tester hours are generally the majority of the budget. Hardware is a drop in the bucket (and you can even capitalize it). On many projects I've worked on, Java has driven the people cost down resultig in a net savings even though we may have had to throw a crap load (official Business terminology) of CPU/memory at the application.

Re:Java is slow - so what?

[Austin Milbarge]

> Hardware gets faster and cheaper every year.

Yes, for servers. But ask your IT manager to buy all new DELL Pentium 4GHZ workstations for the entire company because you need to code in Java and see what he says.

Re:Java is slow - so what?

[kelleher]

Yes, for servers. But ask your IT manager to buy all new DELL Pentium 4GHZ workstations for the entire company because you need to code in Java and see what he says.

Why would I do that? It'd be a silly waste of money. (Rule #4: Every $100,000 is a head and the head you save may be your own.)

Right now all Prod applications run in a shared server environment - so our Dev, QA, & ITE regions are shared too. For example, I'm in the middle of consolidating all our Weblogic development (4 groups / 30ish developers) onto a Sun E2900 (8CPUs / 16 cores) from an aging E6500 and an E450. This allows us to share not only the hardware resources but the software licensing as well. Of course, this is just for Dev - the other regions are scaled horizontally according to capacity and availability requirements with like applications being grouped together.

BTW, I'm not a developer. I work in A&E making sure the infrastructure meets business and technical requirements while driving down run-rate.

And fail it will...

[Baldrson]

Oh, it will fail alright -- but not before you've gotten your promotion and left the company. Who cares that the company will itself be left with the unanalyzable miazma produced by having 5 to 10 times the code in Java that you would have had if you'd simply had decent code-reviews and used mature Perl programmers. Well, the stock holders care but who is going to call them about your references for your next job?

Re:And fail it will...

[WhiplashII]

Well, that would be great, except that as CIO I'm not really getting promoted anymore, and I am a shareholder in any company I get involved in. (I like working with smaller companies, where you can actually do something).

Also, I tend to stay with companies for a while. I've been with my current company for 8 years (that has to be some kind of record for CIOs). It probably has a lot to do with the fact that they don't mind "sharing" me with other companies for a piece of the action. I'm currently working 3 jobs, and still get home for dinner each day!

Re:Depends ...

[stormcoder]

Open source cross platform C++ libraries include Boost, ACE, STLSoft, and Loki to name a few.

You should give Python a try as well.

Re:Because end users hate the applications

[afd8856]

I've recently completed a Python-based office app. It used Excel for data gathering, through COM, and it wrote reports in Word.

Advantages? It's free, you get to use the same documentation as for Vbasic (the Office help files) and the language is cool and easy to learn.

Done.

[mccalli]

Anybody know why they decided to make it so you can't just put all .jar's in a *direcotry* referenced by CLASSPATH?

-Djava.ext.dirs=/your/dir/here

Done.

Cheers,
Ian

Because it's FATware.

[Spy der Mann]

All with the servlets, enterprise javabeans, setting up the whole mess, and the fact that the free available java environments are _NOT_ the ones you're using at your job. They're just used for "training" (well that was one or two years ago - but I got a php job and i love it).

To get a good handle in this J2EE not-quite-multitier mess, you need HEAVY training ($$$), and of course, the ones who really get money are Sun.

Where I live, there are thousands of vacancies asking for people with two years experience in J2EE. PHP? No, thanks. "Eew... hackable, for newbies".

Still, I can setup Apache, PHP and mySQL in a couple of hours (INCLUDING downloading), and start testing with source code right away. Try that with Java.

The real reason why J2EE is "cool" is because Sun gives FREE Java support to those who purchase their computers. It's just like Microsoft, but without the monopoly (yet).

If the time that one invests in java training would be used for PHP / MySQL (including multitier programming), things would be quite different.

MOD PARENT UP

[rudeboy1]

Nice post. +5 insightful if I had the points to give. I fully agree that Java is a great language if you don't want to put your higher thought processes to work. You can get away with looking at a spec sheet and punching out a "plug in the code to meet the specs" scenario. There is no, "let's Make A and B work, and in doing so, supercede the need to put in C" and make it better, with less code, better reliability, and less common errors.

Java vs. what?

[Fallen Andy]

I don't know why everyone wants to slag off a language which was designed to be a minimalist approach to getting software portably on set top boxen...

Yes, I prefer C# (aesthetically) , assembler (for control), C (for a reasonable trade off), Wirth languages (for attempts to make braindead cattle capable of programming), (write the rest, because I don't have enough space in the margin...).

Why the need to make this an interminably boring and dull debate? Next you'll post that CowboyNeal needs a spell checker or Michael has the repeats repeats repeats or that puke yellow isn't your favo(u)rite colo(u)r on slashdot...

Oh. Sorry. It's August isn't it. We have to watch the olympics (R)

(worth the mod down?)
Stop eatin the beans mike?

What's in a Name?

[cybin]

Maybe Java is considered so un-cool because it has a crappy name. Of course, we all like our coffee, but "Java" as a name is rather lame. It doesn't have the same ring to it as "C", or "perl".

Seems to me that all the "cool" languages have either really mysterious names, or "shiny" ones. Try this out:

"I'm a C programmer" (add ++, even cooler)

"I'm a perl programmer"

"I do Ruby."

"Python is my language of choice"

then, in a squeaky voice...

"Java is the coolest!"

doesn't work for me, man. :)

Re:What's in a Name?

[cybin]

Could be wrong. :)

it might be cooler if the java community started calling themselves something cool and exclusive, like maybe "The Javanese Gamelan". :)

Because Java Programms are lousy C++ Programmers

[deischi]

This is not really about Javas coolness or not (could not even read the article).

To my experience when Java programmers switch to C++ they tend to produce code that is full of memory leaks (new in Java and C++ are VERY different) and have a tendency to write overdesigned and unnecessary complex code.

What you will always see from a person done Java in the past and now doing C++ is things like:

DoSomething() {
C * c = new C();
if( ! C->doSomething() )
return;
C->doMore();
delete c;
}

Harald

Re:Maybe because it's slow ?

[Theatetus]

I think he was talking about useful exceptions. Java has a real nice way of handling exceptions, and since it is GC'd you don't have the same hideous problems that you do in C/C++ with memory allocation.

OK, that's a fair point. I never used C's exception capability; I've always kludged up signals for that sort of thing.

* No macro system
* No closures (you _can_ do closures w/ objects, but it's REALLY UGLY)
* No continuations
* No tuple-returning functions (this increases code size by about 50%)

Let me just say a thousand times "Amen", especially about closures. I honestly have no idea how people get by without them. Closures and tuple returns are why I do all my work in either Lisp or Forth depending on how much I need to control memory allocation and how little I need to manipulate character strings.

You're exactly right about multiple return values and code size: single-return-only languages require you to either design a structure or class (increasing program size) or pass an alterable reference (increasing program fragility) any time a function has a more interesting answer than a single primitive type.

Personally, what I can't seem to program well without are:

• Closures
• Either manifest typing or absolutely no type-checking (ie, a value should either be exactly "what it is" or only be what I say it is, nothing in between -- this is why I can't stand ML or Haskell despite my love for functional languages in theory)
• First class functions and anonymous functions
• Multiple dispatch for methods if I'm using OO (sorry guys, but Smalltalk and therefore java simply got it wrong by dispatching only on the implicit "this" argument)

I'm not sure whether that speaks more to the kind of work I do or my particular weaknesses as a programmer...

Java cool/uncool is irrelevant

[upsidedown_duck]

when considering how few people can design a good database schema! Sadly, the same college newbies hired for the Java skills get stuck looking like deer in the headlights when dealing with storing their darn data. Remember, kids, when you see fields like email1 and email2 in your design, sit back and think about the pain you will cause when someone needs email3 (i.e., you need a different solution entirely).

ummm..

[natas802]

ummm because java sucks and no matter how of them mhz you got, its always going to be slow as s**t!!!

Re:Maybe because it's slow ?

[barawn]

There is *no* way that a interpreted or JIT compiled language can be *faster* than native code.

Nope.

There are actually quite a few ways that an interpreted language can be faster than native code.

If you were right, then VLIW processors would've taken over long, long ago.

It's important to realize that the instruction set that any processor uses is not its native instruction set, for a long time now. Ever since the Pentium days, there's a "instruction decode" step in the pipeline, and even PPCs use it to pare down the (comparatively simpler) PPC instruction set to something more RISC-like.

So what does this have to do with programming languages, you might ask?

The point is that the analogy is exactly the same: VLIW processors rely on the instruction stream being very parallel, and well tuned to the architecture so that they can be very simple and very fast. There's only one problem - compilers can't be that smart. You don't have all the information until the program runs - this is very similar to the Halting problem. Until the program runs, you don't know how it will behave.

So what you're saying is "I don't see how an interpreted language can be faster than native code", likely because of the overhead. The answer to your "how" is that the interpreter - like any modern x86 computer - has more information available to it while its running than the compiler had when the program was compiled. Therefore the possibility exists that an interpreted language can outperform native code, because it can optimize for cases that the native code cannot. If that optimization is enough of an improvement over the overhead, you win.

It is for this reason that modern x86 computers perform so well compared to VLIW architectures - it's very difficult to extract parallelism from the code itself, before it's executed. It's actually more efficient to extract the parallelism while the code is actually running.

This is the exact same reason why Java can beat C++, in certain cases. And for benchmarks, http://cpp.student.utwente.nl/benchmark/. Note that this is in fact someone improving upon a C++ vs Java benchmark that showed Java won, so this is C++ striving as hard as it can.

Here you can see that for certain cases, Java can win. The most notable one is the nested-loop benchmark, where the Intel C++ compiler ran in 1.8 seconds, and the Java example ran at 1.05 seconds.

Your next statement might be that "yes, but in assembly..." and I will then say that yes, I highly doubt that you can find a Java program that will beat a hand-assembled piece of code. But it still is *possible*, because the interpreter may be able to perform some optimization during runtime that the person doing the coding can't because it's not strictly correct - this is akin to a branch predictor in hardware. It's allowed to cheat so long as it's later proved that it was right, but then pay a penalty when it's wrong.

Java programmers cool, Java sucks…

[Naum]

... Java is a tool, and in the hands of any gifted programmer, it can be used to craft quality software.

Java, the language, sucks, but yet has made huge inroads into commercial realms, supplanting COBOL and other languages as the language of choice for business applications. And it's a shame, as there are loads of shortcomings, that offset the advantages of Java and the JVM deal:

• Sun's dictatorial control of standards as has been previously detailed. I believe it's the Win/Unix client/server setups that influences decision to develop in Java, both for business software units and third party software vendors selling wares to such customers. In *nix-less shops, .net or whatever the Micro$oft platform dujour is called these days, and Java may not flourish there.
  
  
• Too resource intensive. Running a mini-OS VM on top of another OS is never going to be a performance maven. Java applications on both client and server suck in this regard. Huge memory footprint, excessive startup/load times, and measurable delays in graphic intensive applications plague this beast bad.
  
  
• Serious issues with threading prevent it from serving for any serious server workhorse. No doubt, talented engineers are still trying to crack this nut, but threaded Java applications pushing large chunks of data about are very susceptable to insidious behavoir, depending on the machine architecture and other system software instances mix.
  
  
• The natural handicaps built into the language, that can make for inelegant and unflexible solutions. Say what can be said about Perl, Python, C, Lisp, etc., but those tools are remarkably more expandable and resilient when it comes to possible solution spaces. Also, forcing one to treat everything as an object, as has been written by others, is a limitation, not a benefit.

But the programmer != the tool. It might make it more difficult, or more lines of code, or more kluginess, but a talented codesmith can work with primitive tools too.

Re:Java programmers cool, Java sucks…

[Mybrid]

And don't forget...
Java doesn't play well with others.

Java sucks because trying to chain Java to a shell script or any other program really really sucks.

Larry Wall has the right notion of software engineering and languages. This is taken from the Social Engineering chapter 6 of the Camel book.

Languages have different personalities. You can classify computer languages by how introverted or extroverted they are; for instance Icon and Lisp [EDITOR's note: and Java] are stay-at-home languages, while Tcl and the various shells are party animals. Self-sufficient languages prefer to compete with other languages, which social languages prefer to coordinate with other languages. As usual, Perl tries to do both.

Java sucks because in the Unix environment it is impossible to easily invoke Java. What if you want to chain using pipes at the command line like this:

java_program1 | shell_script1 | java_program2

Most likely the JVM will start up and stop with each invocation rather than using an already running JVM. That really sucks. Java doesn't play well with others with regards to the JNDI interface either.

Java sucks.

Re:Java programmers cool, Java sucks…

[tsotha]

Serious issues with threading prevent it from serving for any serious server workhorse. No doubt, talented engineers are still trying to crack this nut, but threaded Java applications pushing large chunks of data about are very susceptable to insidious behavoir, depending on the machine architecture and other system software instances mix.

I'm not sure what you mean by this. I've been writing multi-mulithreaded Java server-side apps for five years now and the threads have always behaved the way I expect.

#1 reason:

[jafac]

(not kidding here)
#1 reason why Java is UnCool: JavaScript.
JavaScript has nothing to do with Java. But Java was victimized, bent over, and abused with a pointy stick in order for some marketing jackasses (company not named) to make a quick buck trying to confuse people.

Not slower than .NET C#

[Baki]

It is not slower than C#! (for non GUI stuff). How did you get this idea? Can you provide some hard benchmarks? I have seen some and did a number of benchmarks for myself, comparing .NET 1.1 C# to JDK 1.4, and in most cases Java was faster.

It is very irritating to see repeats of such blatant lies trying to engrave these myths in peoples minds.

Re:Anger/distrust of liars, Sun-dependence, OS pai

[toriver]

if Sun doesn't like it, it's dead.

Sorry, but that's untrue; there has been at least one feature added to Java that Sun was against. All Sun has is a permanent seat on the JCP Executive Comittee, and the same veto any other member (like IBM) has.

vendor-independent standards ... that are vague because of the politicking in the comittees. "Left to the implementation", anyone? "Left for further study"? That's not a spec, that's a suggestion. And I won't even mention SQL, which is almost actively ignored as a standard.

it's not open source

Nor are AT&T's C or C++ implementations. Does that mean they cannot include GCC? The major difference is that C++ isn't trademarked, so you can call anything C++ and get away with it. My, how "standard".

Why must Sun's implementation be open-sourced? Isn't that just the OSS community saying "woe is us, we can't write a good implementation of the FREELY AVAILABLE SPECIFICATIONS, plz help us"?

a little more painful on clients for client applications

No, it's just as easy to make installers for Java apps as for "native" apps; Vise, InstallShield and InstallAnywhere all have flavours for making Java installers if you don't want to use Java WebStart.

Re:Masses? hat Masses?

[Sigma 7]

MS hasn't included Basic, Visual or otherwise, with its operating systems since,I dunno, DOS 3.3?

Windows 95, actually. The copy that came with my computer had a folder in an "OldDos" directory that contained the latest verison of QBasic. The only reason I use it is if I'm trying to do something a bit more dirty than Perl. Perl gets used when I have to do mass processing of stuff, such as regular expressions or other means of searching.

Also, the programming languages that shipped with old computers were generally considered "essential" to use the operating system - there has been a shift away from that by having users switch over to a CLI or GUI rather than have them understand how programs work.

Nowadays, those programming languages are no longer necessairy - and perhaps that's a good thing. Although it was impressive that I could type 'Load "*",8,1' at the age of 2-3, it's something that could have been a bit simpler and faster with a GUI (assuming the had the processing power to support one.)

Re:Maybe because it's slow ?

[fredrik70]

bound checking is removed dynamically by JIT if it finds there's no need for it. So having a'debug' version isn't really necessary.

First Post

[drsquare]

I posted this on my java web browser!

Re:Maybe because it's slow ?

[SillyNickName4me]

You are aware that there exist garbage collectors for c/c++?

Also, in the example you give, you can know that a virtual method is never going to be overridden before runtime, you do need to link your .o files tho, so it is after compile time. THere is however no theoretical reason why you cannot decide at that time to recompile a bit of code to get the exact same optimizing as you could with java.

There are other cases where you can't tell things untill you are actually running the code, and java can indeed have a performance advantage there that is only possible in c/c++ when you do extensive profiling and debugging (to see what is really happening) and direct the compiler properly by correct hinting.

That hinting is something you cannot do in java, so well.. it depends in part on the code and how well it takes advantage of the specific environment.

For java you have to do less work to get the best performance then for c/c++ for some situations.

Re:Cool?

[egarland]

I agree with all your comments except that people like Java the language. I don't like Java the language. People usually dissmiss my objections to Java once I tell them I'm a perl guy but many of them are legitimate. Java is good but I have some serious gripes with it:

• I don't like the naming convention of firstSecondThird. first_second_third is simply more readable.
  
  
• I do like . notation and I'm happy it's spread to every other language.
  
  
• I don't like try, catch. It's important to roll up errors but try, catch just turns into a mess usually. Perl's "or die()" way of doing things isn't great but I do like it better.
  
  
• I don't like strongly typed languages. Dealing with an overloaded object as a basic type that automatically does what you would do normally, usually requiring less variable names and code is a win.
  
  
• There's too much overhead in Java. I believe that the only sufficient documentation for code is code. Comments can be wrong and never telly you precicely what is happening so a good programmer never relies on them, you have to read the code to figure out what is going on. Having to read through lots of overhead is a waste of programmers time. Things should be represented consisely so they can be read and understood quickly. Lots of programmers have a hard time with perl because it's so dense but I'd rather read a 1 line regex than a 20 line function that does the same thing any day.

Perl and Java are kindred spirits. They both compile to bytecode and run on VM's. They are both highly portable unless you use something OS specific. They were built for different reasons and definitely have different streangs but their architecture is similar. The language of perl5 predates Java and is slightly less advanced in many ways but they got many things fundamentally right that Java got wrong. The changes in the language for perl6 have fixed all the glaring issues I've seen with the and has added lots of new improvements that make it make it an example of how to do a language right.

From what I've seen, perl6 the language is superior to Java the language. It remains to be seen how perl6 the platform will compare.

Re:Maybe because it's slow ?

[Mr Z]

You still have to know to put the pointer in the list, which inserts inline code on many paths. (Maybe not as heavy as a call to free() or delete, but it is more code.

A better strategy for some apps is to have "arenas" that you allocate from for certain phases of processing. When you're done with objects from that arena, just forget the pointer (a'la Java, where you just drop your references to an object), and when that phase of processing completes, just reset the entire arena in a single step.

--Joe

Re:Maybe because it's slow ?

[Coppertone]

I have said it before, I say it again...

Guess what's the most popular BitTorrent client is written in? Java....

http://sourceforge.net/projects/azureus/

'Coolness'

[fiannaFailMan]

Enterprise-grade apps and "coolness" may be inapproriate bedfellows.

Says who?

Re:Maybe because it's slow ?

[the quick brown fox]

That's true; but I don't know anyone who does that.

WinXP?

[pjt33]

Java is not supported by all platforms, and is not supported by WinXP by default.

What languages are supported by WinXP by default?

Re:Maybe because it's slow ?

[mwood]

Consider that the "several instructions" to which a VM instruction maps can be hand-tuned code, whereas the compiler has no idea what we will throw at it and often produces code that we could improve. At the same time, the designer of the abstract architecture doesn't have to deal with icky real-world electronics issues and can spend more of his time designing something for which it is easy to compile well.

(OTOH I learned a lot about code tuning on the PDP-10 from reading the output of the Blis10 compiler. What a humbling experience.)

Re:Depends ...

[Skjellifetti]

assuming you are doing server programming, you might find ACE helpful.

2nd that. I've used ACE on Winnt, Solaris, HP/UX 10.20 and 11, and Linux. I'd also recommend reading Schmidt's various papers on design patterns. Many of these are implemented in ACE and greatly cut down on design/coding time as well as bugs in the code.

Ever encounter LD_LIBRARY_PATH?

[bharlan]

LD_LIBRARY_PATH isn't any better. Yes, you can specify directories, but you must instead name each shared object when you link.

Yes, you can use /etc/ld.so.conf for common shared objects. You can equivalently use $JAVA_HOME/jre/lib/ext for common jars.

Using a path is the single most common way to find dynamically loaded code.

Boot classpath

[pjt33]

No, you only need to use the -Xbootclasspath parameter when you want to replace one of the standard libraries - say to put some debug code into the Object constructor.

Top reasons why Java *is* cool...

[eyefish]

OK, so here's my list why Java *is* cool and is used by great programmers:

1. It runs everywhere unmodified. This has got to be the coolest thing of all, and the reason I adopted Java in the first place. At the beginning this was not always true, due in major part to the AWT graphics libraries, but today it is.

2. It's more productive to work with it, leading to fewer bugs. This is very important in business apps. I certainly no longer get C/C++ pointer problems, memory leaks, or perl syntax error problems.

3. It is fast (ok, it loads slow the very first time, but with JDK1.5 this seems to being addressed as well). Somehow Java lends itself so easily for users to write efficient code (i.e.: multithreading is a snap and platform-independent), that somehow the applications we've been replacing with it simply run at least twice as fast as the older C++, VB, and perl apps.

4. It is simple. Sure, some hackers like garbage-looking code because they think the harder to understand their code the cooler it is, but in my book the cleaner and simpler code wins any day, specially when programming in a team environment. I think Java should be given credit as the environment that brough simplicity back to programmers in the internet age (just as VB did in the client-server day).

5. You can use multiple tools to develop the same code base. Heck, and now with ANT (possibly one of the coolest tools in recent times) you can choose your IDE (or command-line if that's your thing) and move the project back-and-forth between IDEs to take advantage of each (GUI design, refactoring, etc). Choice is a good thing.

6. I'll repeat it again: How cool is it to develop in Windows and drop the app unmodified in Linux or OS/X and see it run as expected with NO changes to the code? Or if you prefer, develop in Linux and deploy in Windows. Either way it works.

7. It is standard. Sure, it is not open source but then again not everything has to be. I think the fact that open sourcers advocate freedom should be reason enough to allow other companies to choose if they want to free their software or not. It is their choice. The fact that it is standard means that Java is protected from the "Unix division plage" where now almost no Unix is compatible with any other Unix. Geez, even Linux is starting to become incompatible with all the different versions of itself. Sometimes centralized control is a good thing.

Re:Top reasons why Java *is* cool...

[pommiekiwifruit]

1. It runs everywhere unmodified.

The guy who was in for an interview today makes a living converting code from Java to Java (on mobile phones).

2. Each JVM has its own variety of bugs.

3. Java games take a while to start up, even they are quite small in terms of jar size compared to desktop apps.

4. You have to use outside tools, e.g. the C preprocessor, to get the jar files into a reasonable size, since it doesn't have compile-time constants or enums.

7. It is as standard as visual basic, and less unified (different variations/editions).

Re:Top reasons why Java *is* cool...

[bcrowell]

Hmm...I'd claim that 1-7 are all true of Perl, and 3, 4 and 7 are not true of Java.

Re #7, I actually wrote a Java GUI applet as my first significant Java app, back when Java had just come out, and then found that it wouldn't run when I tried it on Windows. (And the problems weren't minor, either. I ended up throwing away the code.) It wasn't until years later that I heard the phrase, "Write once, test everywhere," but I immediately knew what they were referring to. On the other hand, I've written a moderately complex (10,000-line) GUI using Perl/Tk that runs just fine on both Windows and Linux.

I have nothing against Java, really, except that its implementation sucks. If gcj ever really gets to the stage where it's useful, I might even write some Java code again.

The Code Name for C# was Cool

[GlobalCombatDotCom]

Oh the irony is killing me.

The code name for C# was Cool. Java is so un-Cool.

Then capitalism is working in your case.

[Baldrson]

Its good you'll rise or fall with your decisions in an identifiable manner. What companies are you driving into the dirt?

Re:Then capitalism is working in your case.

[WhiplashII]

Well, I prefer to use Slashdot in a psuedo-anonymous way so I'm not naming names. Let's just say that if I told you, you would have heard of one of them (and might cry for me...) although technically we are still showing a profit. Another company is in the process of being sold - when we took over operations is was on the verge of backruptcy, and now is profitable. I am starting a third company from the ground up - you'll probably be hearing about it very soon. It will be our biggest yet, and should reach 10% or so of the US households.

I like being involved in startups, and I've gotten pretty good at it. I lost everything in my first company (ended up in debt even). My second company broke even, though some investors lost money. My third company was killed by 9/11 (it was flight related, and chose a bad year to launch). Every company after that has shown a profit (4 so far). So I can't be doing that much wrong.

By the way, I strongly recommend that people try starting a business. It will help you to understand what motivates those over you in an organization, and help you to advance yourself. Besides, the American dream still exists in startups - I am technical a "Disabled" person, and I'm doing pretty well!

Re:Maybe because it's slow ?

[mwood]

I look forward to JRE 1.5, then, but it's not released so I haven't used it for production work.

Why I hate Java

[Animats]

• I own three "integrated development environments for Java". Support has been dropped for all of them.
• The Swing/AWT mess.
• The lousy GUI performance.
• CLASSPATH
• Libraries that come and go. Remember Java 3D?
• Garbage collection stalls.
• Nobody uses applets any more.
• Write once, debug everywhere. Try uploading Java servelets to a hosting service provider.

The language itself isn't that bad. It's Sun that's the problem. Java is a classic dot-bomb product - launched with great fanfare, given away, and heavily promoted. Of course it sucks.

It's the User Interface limitations

[Deeper Thought]

Name 2 or 3 Java applications that feature a "good" user interface, compared to the OS's native interface.

I've used several Java apps, and eventually get annoyed by the funky "open file" dialog or the weird ListControl. And the non-standard coloring. Yes, it's cosmetic, but on a daily basis, it's annoying and tiresome.

Java apps stick out like a sore thumb, due to the unpolished and slightly funky user interfaces.

Re:How about...I wish I could mod you up past 5...

[Bamafan77]

I'm just repeating what you said because you said it so well (and I feel this needs to be emphasized). You've nailed PRECISELY what I've been thinking for years. The conflict between "choosing the best tool for the job", the fact that there are a billion tools and being proficient enough in all of them to even be able to choose the right tool for the right job. As you said, reality is just not that simple.

Re:lame

[Seahawk]

Actually, I am a professional C#/ASP.NET guy.

But yes, I am ALSO a Java guy - the right tool for the right job you know!

And in the link supplied, much of his gripes was with the jar tool being slow compared to tar.

And with a Hello World program doing alot of extra stuff!

But those are things java really wasnt meant to do well!

THAT is why I find it silly to mod it insightful.

"Real Hackers" usually aren't

[Anonymous Coward]

I'm a Java guy because of the API. When I want to get something done right I don't want to re-invent the wheel, and I don't want to have to mix and match dozens of differently-written APIs. Java features a robust and (generally) consistently named and structured API. On top of this, the API is very well designed and tested, and caveats are well-known. It is not some obscure OSS library that lacks security/features/functionality and may still have unknown holes or bugs.

Also, all this talk of the "Coolness" of a language really got me upset and made me have to post. When I was in college, people like this pissed me off to no end. I had a compilers class and the assignment was to make a 4-stage compiler in the language of our choice. I picked Java and recommended others do the same. The responses that I got were "I want it to be quick, so I'll use C" or "I don't really understand Java, so I'll use C" or "No thanks, I'll use a real programming language", etc. So fine, I was the only one that used Java. In the end, my program was complete, worked 100% without error, was well-structured (having logical distinction between subcomponents), FASTER than the C programs, readable, and it took me LESS time to write it than the C-lusers that stayed up until Midnight helplessly trying to complete theirs. Some failed.

In the course of working on the compiler project, the 1337 C coders had memory management issues, segfaults, etc. Some of them could not work the bugs out of their hashtables/linked-lists/etc, and so resorted to bad practices such as bubble-sorts, arrays-of-arrays-of-arrays (instead of dealing with pointers), etc. Wasteful memory practices, inefficient algorithms, sloppy code, etc. -- hallmarks of 50-75% of every C program I've ever had the pleasure to clean up after. The ones that
DID manage to complete their projects were exquisitely proud of how great of hackers they were. Nevermind the fact that in their desparate drive to complete the project, they had no chase to sit back and think of nevermind implement hash-maps, etc. which would make their program efficient AND ELEGANT. Java allowed me the comfortable leisure to do all that, and I have the elegant code to prove it.

Now before anyone gets me wrong and says that at least these guys were getting experience with the algorithm knowledge they'd later need, let me correct you. I CAN do algorithms and memory management very well. I understand data-structures perfectly and have written my own in C-based data-structure classes. Java's structures are well-thought-out and allows GOOD programmers to focus on elegance rather than re-implementation.

And BTW... every "1337 hax0r" I've ever met has been nothing but a sham. The smartest programmers I've ever met favored C/C++. The second-smartest favored Java. Both wore normal clothes and didn't have the long hair, beard, etc. that the rest of the insecure programmers of my school would cultivate instead of actual ability. They enjoyed elegance instead of minutae, and knew that languages were just tools to get a job done right (Where right is sometimes incompatible with fast). That should be the real definition of a hacker.

Sincerely,

Enemy of Cool

Solve the real problem.

[DG]

You're applying a technical solution to what is, essentially, a management problem.

It doesn't matter WHAT language is the company lingua franca - if you are not holding regular code reviews (and instead trusting the B&D features of Java to do it for you) you WILL get bitten by maintainibility problems down the road. NO language is so obfuscation-proof as to not require review.

Furthermore, if you fail to do reviews, then you are denying your coders a chance to improve their own skills. There is no better way to learn new tricks and techniques than exposure to someone else's code.

And finally, coders are ego-driven animals. If their code is going to be subject to regular review and (especially) public critique, they will go to much greater lengths to ensure high quality of their code than if the code is safely hidden away where only they can see it.

That's one of the major lessons to come out of Free Software - the more people who examine the code, the better it gets.

If you make code review and code sharing a major part of your corporate culture, you'll wind up with a far better and more motivated group of coders - who, incidently, can probably adapt to whatever language is the order of the day.

DG

Re:Solve the real problem.

[WhiplashII]

Very true, however who will watch the watchers ;-}

Note that I did not say that programming language choice was enough by itself, only that the choice of a programming language should be in line with making a project easily maintainable down the line. It would be nice if everyone had code review. However, there are times that it is not feasible, and people tend to revert to minimal documentation and poor style when the crunch comes. Yes, it can be documented and fixed later during code review, but choice of an appropriate language can raise the minimum level of documentation possible. As a manager, it is my duty to do that. As a shareholder, it will result in my income increasing!

By the way, code review (and ego, as you put it) is a strength of open source, but it is not the primary one. Open source is a way to get other entities (companies, individuals, whatever) to share the cost of your NON-STRATEGIC IT functions. It is very valuable, if you know how to use it. Most CxOs do not seem to have this knowlege, which allows the companies I work with to outperform them.

Re:Solve the real problem.

[DG]

the choice of a programming language should be in line with making a project easily maintainable down the line.

ALL languages are equally good and equally bad when it comes to later maintainability. One can write perl that is spectacularly easy to maintain, and one can write Java that is so horribly obfuscated that nobody - even the original author - can recognise it 6 months later.

Maintainibility is something that gets written into the code itself; it is not an attribute of a language.

Open source is a way to get other entities (companies, individuals, whatever) to share the cost of your NON-STRATEGIC IT functions.

I disagree.

Our LDAP replicator program was released to the public under the GPL. It was performing a very strategic function - keeping all the corporate LDAP directories in sync with each other, which was a "if it stops we don't build cars" infrastructure component.

We did that specifically because it was a core part of the infrastructure, and thus we wanted to get as many eyeballs on it as possible to make sure it was as robust as it could possibly be.

It was also VERY specialized, and so we didn't get a whole lot of interest in it - this was no Samba. But even so, we DID get bug reports that were merged back into the production version.

DG

Re:Solve the real problem.

[WhiplashII]

I would say that your usage fits my definition of non-strategic. Giving it to your competition will not enable them to copy your product, it will merely make them more efficient. But if their efficiency increase is matched by your efficiency increase (as in the changes they give you are as valuable as the changes you give them) everyone wins. The everbody wins is the definition of Capitalism working. I believe most open source projects fit into this model.

Where it doesn't work is when you are building a web service, say for a bank. If you open source your web service, the bank can simply take your work and has no reason to use your product anymore. That is what I would call strategic. I'm probably wrong, so go ahead and correct me. (Hey, after 8 startups, 4-5 successful I'm finally going to get my MBA from Kellogg next year - I'm still learning)

Ha ha!

[n6kuy]

When I went to the site, one of the panels said:

Server Error
The server encountered an internal error and was unable to complete your request.

JRun Connector Protocol Error.

Re:Maybe because it's slow ?

[sbrown123]

Mod me troll flamebait, whatever - but the JVM is slow, not only on start up.


Ive written quite a few java apps. The startup is the only slowdown I have really noticed. There is some comparison where a JVM, which has garbage collection and such, will be slightly slower than compiled. Have to stress the "slightly" comment since most of those processes are pretty well tuned in todays virtual machines.

Java developers have screamed bloody murder over this for years. Sun has promised that the next version release (1.6) of the JVM will allow for multiple apps within a single JVM. This would mean you could start the JVM once (like on system startup) and never have to pay that startup cost on a per java app basis.

Show me a JVM app (app, not test case!) with a native compiled equivalent which is slower. You won't find any.

You generally wont find an app written in both C and Java. Developers usually pick one or the other. Why write the same app twice? This makes finding good examples pretty hard.

This reconstruction is computationally very expensive (google: decompilation problems) so only approximative algorithms are used, leading to non-optimal code.

I dug around on google. Honestly I could not find someone to collaberate your statement. Do you have a direct link?

I think LLVM is a nice project that could bring all the VM hype

Getting a 404 on the link you posted.

Re:Maybe because it's slow ?

[dnoyeb]

Typically any slowness has been tied to poor garbage collector usage, and/or poor understanding of Swing.

I believe Java 'appears' so easy to write in, it entices people to write apps that really do not know what they are doing.

Apps I have written in Java going back about 8 years have run just fine and have had no speed issues.

New Java versions are bringing speed because they have improved GC behaviors, but still people need to write good code.

Verbosity, verbosity, verbosity...

[herve_masson]

The reason why I love perl is its incredible concision and expressiveness. To me, Java and c# both suffer from beeing way too much verbose. This is not about laziness, nor about performances and/or compilation time; it's more about preventing the source code from beeing "polluted" uselessly. Better write comments than glue code ;)

No, languages have different expressive power

[darthscsi]

>Saying Java isn't cool is like saying Scheme or ML
> isn't cool. It's just a personal preference,

No, Scheme and LISP (as well as modern ML varients) have features that are more powerful than Java. They can express things that cannot be expressed in Java, mainly code generation and modification at runtime, closures (Java has an ugly hack added for AWT), continuations, syntax extention, etc.

It is said that everyone eventually settles on some language on the power spectrum. You look at the features of your language and are reasonably satisfied. You look at simpler/less powerful languages and you wonder "how could anyone program effectively without feature x" (where x is one of you favorite features not available in the simpler language). You look at more powerful languages, and being rather satisfied with your current choice, say "What do I need feature y for? I don't use it now and see no reason too since I can program what I need with my language." (where feature y is a feature the more powerful language has and its supports make a great deal of hoopla over, whereas your language does not).

I was happy with C++, I could do amazingly strange and terse things with templates, knew the language well, etc. But then I met OCaml, and now I wonder, "how did anyone ever get by without discriminated unions, closures, currying, first-class functions, GC, a static type systems that actually works, etc.". Now don't get me wrong, several of those features you can emulate in C++, but it is non-trivial to do right, and not very terse, makeing you not want to do it often. And I know Scheme is more powerful, it has a better macro system and continuations, but alas, I may be at that point I mentioned above.

Re:Maybe because it's slow ?

[dnoyeb]

Another point i wanted to add is that Netbeans and Eclipse have both botched their GC behaviors. Both seeming to hope the JVM creaters magically create a awesome Garbage collector.

But sun has stated that this is not possible because the JVM can not know what the app or user is really doing and that running the GC should be handled by the application.

For me, its obvious. You run the GC in a seperate thread when all other tasks are idle. If you do not the JVM will run the GC when it gets full and bring your app to a screatching halt! Or you can do what server mode does and run the GC all the time slowing down your app all the time.

Bad decisions makes bad performance. Why Sun cant write an app to take into account the philocophy of GC of their JVM is beyond me...

what would fonzie program in?

[mevets]

he wouldn't. Java isn't cool. It isn't any less cool than any other programming language. Programming isn't cool; it's a way to avoid having to get a real job. Get a life.

Re:Java pays!!!-Uphill all the way!

[DevolvingSpud]

This is true, except again in the government arena's special case. I can be fairly sure that the Department of Homeland Security is NOT outsourcing jobs to Pakistan.

Bottom line is, if your college offers a co-op program to any three-letter agency, and you want to be set for life as a programmer, take a job there during college. Once you have your tickets, you're totally set.

I can speak from direct experience here - after 10 years (including the co-op time) my compensation has nearly sextupled, and I've always gotten to work on neat projects. No need to take the management track, either!

As to doing commercial-side work, I bet it is difficult to get experience. Too many people are going into "programming" because it's currently perceived as the hot path for $$. I've done more interviews with out-of-college folks with absolutely zero knowledge than I can count. All people should be looking for from a fresh graduate is object-oriented design skills, the capability to read UML, and enough working knowledge of OO languages to answer basic questions about polymorphism, inheritance, etc. The rest is OJT, and frankly, it's way better return on investment to train up a promising student into a senior developer than to try to poach one from a competitor. That's why my salary is so high now :)

Tired of dull boring ignorance maybe?

[Fallen Andy]

Sigh. Yet again. I won't read all of the postings but I'll guess that "it's slow.. It's constraining like a
chastity belt" come up. Well. Dumb. I ported the UCSD p-system to loads of machines in my dark distant past and yes it was slow. That wasn't the issue then. Hmm.
Seems to me that many of the younger folks out there haven't considered the benefits of executing on an imaginary processor.

1. You have control (yes: you can play nazi today!). In parallel (maybe co-operatively? Hey I like that paradox)
2. Script kiddies jump off the local landmark (example the clifton suspension bridge in Bristol UK) just because they can't get the immediate gratification they figured that they would get from watching that anime cartoon...).
3. We have horrendously kewl CPU's doing squawt most of the time. I don't care if my machine discovers E.T. (who wants to meet E.T?). I want to have a meaningful discussion with the Admiral from
Romulus or Mr. Spock.

Sorry. I watched all of this the first time out. I guess I haven't matured at all...

(hick. Another glass of metaxa methinks...)

Re:Depends ...

[jarkun]

Java vs C/C++ is the wrong comparison!

C/C++ is great for embedded work, its the perfect abstraction for what you do in assembly, but this isn't what the "cool hackers" are doing these days.

They are doing higher-level applications with more abstraction. At this level Python/Perl/Php are extremely flexible/powerful/easy to use.

Before you drive your camry make sure you check out the saturns :-)

Re:PHP...PHP offers both....

[kjj]

I like Java as much as anybody but I agree with the previous poster and admit it is not really very cross platform compared to many other languages.

I notice you did not put any of the BSDs in your list. You can't just write off BSD as dead either. Yahoo and many hosting companies run it as their primary OS. Yes, I know there is a JDK for FreeBSD which you can build yourself, but how many big companies are going to go for such a solution. Also, JVM speed is still a major issue on BSD. Languages like Python, Perl and PHP are far better supported on BSD as well as many other UNIX platforms that may be considered too obscure by Sun.

As for C# I believe Mono and Portable .NET work on many platforms including BSD and I remember MS even released a more official implementation for BSD called Rotor. Like I said I am a big fan Java and would love to see Sun change the attitude and help make Java a truely cross platform system.

Strong != Static [nt]

[pkhuong]

cf Subject.

Strange

[MemoryDragon]

the last time I checked it lots of "hackers" used it, heck look at the jakarta project, 95% of the code the apache foundation produces is java related. java is an interesting language if you go for true multiplatform, it is a really interesting language if you are interested in total stability and design issues and software engineering, it is a lousy language if you want to do low level systems hacking, that basically sums it up.

Java Jobs and Cool

[catherder_finleyd]

One major aspect of "Cool" not discussed yet is how Java may enhance one's paycheck. In the past, a number of "skills du jour" have motivated employers to provide higher pay to those having those skills.

Unfortunately, Java is probably not "Cool" anymore on this score. When I read the Sys-Con article, I noticed advertisements for $10/Hour Java Coders. Java is definitely not a "cool skill", at least in money terms.

Java forces compliance w/ OO programming technique

[captain_macosx]

Java forces people to use objects for everything. While this can be a pain to write short programs, in the end this can be a real help in environments that require many people to work on a project. The software architect can easily design a class heirarchy that will be strictly adhered to because Java forces. Interfaces can be used to ensure that certain methods are implemented. Also, the exception handling speeds dubugging. Many of these things are not cool and prevent neat tricks that border on shameless hacks. However, they help enforce a compliance standards and make software easier to maintain.

Maybe because I'm young and went through college with Java being the language of choice, but a null pointer exception beats a seg fault anyday!

[Oh uh you can speed it up by using Mac OSX Java's built into the OS!]

failed-reading-comprehensionp

[pkhuong]

How about, because he, unlike others, does not seem to have failed 5th grade reading comprehension? He's never heard of a good programmer _who uses Jave_ outside of Sun.

Re:Maybe because it's slow ?

[chris_mahan]

Just because it's the most popular does not make it the best. I mean, look at MSWindows...

Besides, the Original bittorrent client was written in Python, not Java. There's a reason for that. Maybe the programmer would not have done it at all in Java, and never created BitTorrent.
Python is a great prototyping language, and "great hackers" like it because it hardly gets in the way of a quick hack.

If I had an idea on the way home from work, and wanted to hammer it out in 15 minutes on the olde pc "just to see", I certainly would not use java.

Which links against what, FUCKTARD???

[mosel-saar-ruwer]

All of the BSDs use GCC as the default compiler.

Obviously. But what does it link against???

Is "Hello World" contamination-free if you compile it with GCC on a FreeBSD platform?

It's a serious question; I'd appreciate serious answers.

Cool Matters?

[Fallen Andy]

Excuse me. I thought we were supposed to be
engineers. Cool. What kind of lame excuse is
that? We pick up the hot horse pucky and run with
it... Right?

a bit vague and unsubstantiated

[Abcd1234]

java can leak memory just like any other language

Yeah, but you have to work a *lot* harder at it.

but java might if you leave it lying around in some persistent collection.

Huh? What are these mysterious "persistent collections" you speak of? Yeah, if you hold a reference to a collection and leave an object in it, it won't get garbage collected. Duh. Don't hold onto the reference. And if you actually manage to create circular references, well, that's your own fault... the JVM can only do so much.

sure, you might not have header files, instead you have interfaces which allow different classes to depend on each other.

I'm not sure what your point is, here (especially the reference to interfaces). In C/C++, you need a source file as well as a header file, and need to track both. The advantage of Java is that the two concepts are merged, so you don't have these nasty dependencies to deal with.

java does alleviate the problem of pointers, but it has plenty of other problems it introduces.

Such as?

the stuff you mention isn't "crap," it's just that java masquerades most of those things

a) yes, it is "crap". ie, it's a bunch of crap that, in C or C++, the programmer has to manage (e.g., memory and header files). How, exactly, does java "masquerade" these things?

as the size of the project grows, java has as many problems as other programming languages.

Bullshit. At the company I'm working at, we're creeping up over the half million line mark, with half of that in java and half of that in C, and I can say unequivocally that C is a *much* larger pain in the ass to manage, build, and maintain. But, since you seem so sure of yourself, please, explain to me these mysterious scaling problems that Java has.

Re:a bit vague and unsubstantiated

[dollargonzo]

Huh? What are these mysterious "persistent collections" you speak of? Yeah, if you hold a reference to a collection and leave an object in it, it won't get garbage collected. Duh. Don't hold onto the reference. And if you actually manage to create circular references, well, that's your own fault... the JVM can only do so much.

"don't hold on to the reference" is equivalent to saying "free it." i have often used hash tables of one form or another to speed up lookup times into various data structures (indeed that's what they are for). they are especially useful when a system manages a dynamic set of objects, and there is no direct way to map from one representation of the object to another. anywho, these hash tables are kept around forever, so all objects need to be "freed" from the hash table. this isn't such an uncommon occurrence, so saying "don't hold on to it" is silly.

you are actually incorrect about circular references with respect to garbage collection (it handles them just fine), as if the GC didn't resolve them correctly, delegation would not work.

you imply that the problems in C are "scaling" problems. i have managed plenty of C projects, and, at least as i managed them, they were about as easy to manage as java (portability not-withstanding).

java introduces speed problems. by itself, it isn't slow, as many benchmarks will attest, but when you have lots of objects to garbage collect, the real-time guarantee is lost, since a full/tenured GC pass will take up a significant amount of time, so a lot of time is spent introducing caches and reusable objects, since setting an object to null will still require it to be garbage colelcted-- memory management problems just the same.

I'm not sure what your point is, here (especially the reference to interfaces). In C/C++, you need a source file as well as a header file, and need to track both. The advantage of Java is that the two concepts are merged, so you don't have these nasty dependencies to deal with.

if you have circular references between modules of a project (e.g. classes in different jars refer and call methods of objects in each other), then an interface is needed for them to compile separately. this is the *exact* same purposes of a header file. if everything was in one file in a C/C++ project, you wouldn't need header files either. these interfaces, unless managed well (like well managed header files) tend to grow just the same.

i am no claiming that java has all the problems of C/C++, as it definitely solves many pointer problems. some memory issues, and some cross-platform issues, it is not the end-all, be-all of languages, and as such, still has many (often ideosyncratic) issues.

Re:a bit vague and unsubstantiated

[ttfkam]

"don't hold on to the reference" is equivalent to saying "free it." [...] anywho, these hash tables are kept around forever, so all objects need to be "freed" from the hash table. this isn't such an uncommon occurrence, so saying "don't hold on to it" is silly.

You suck at programming in Java. WeakHashMaps have been around for years now (since Java 1.2). You used a language construct inappropriately and then turn around and call it a shortcoming of the language? There is a class in the standard library, it's well documented, and it does exactly what you needed it to do, but you didn't use it. Who's fault is that?

Re:a bit vague and unsubstantiated

[dollargonzo]

this is all well and good, assuming ofcourse that you don't use the hash table as the *only* access to the data structure at hand and that there is no reference to the key. personal insults aside, perhaps you should read the links you post and think how its uses might not be appropriate for all cases.

from the site: This class is intended primarily for use with key objects whose equals methods test for object identity using the == operator. Once such a key is discarded it can never be recreated, so it is impossible to do a lookup of that key in a WeakHashMap at some later time and be surprised that its entry has been removed.

another note: Thus care should be taken to ensure that value objects do not strongly refer to their own keys, either directly or indirectly, since that will prevent the keys from being discarded.

in the cases where i have used them, this was indeed the cases, so WeakHashMaps would have been useless. i have indeed used WeakHashMaps; they tend to be OK for things like hashing an index into some "collection" like data structure which has very expensive access, but can be indexed otherwise.

Re:a bit vague and unsubstantiated

[Abcd1234]

"don't hold on to the reference" is equivalent to saying "free it."

Not quite, because in C, you can lose a pointer to allocated memory and end up screwed. In Java, the only way to "leak memory" is to deliberately hold onto a reference in some fashion.

anywho, these hash tables are kept around forever, so all objects need to be "freed" from the hash table.

Deliberately holding onto an object until you're done with it does not a "memory leak" make. A memory leak is when you allocate memory, then lose the pointer for some reason, thus making the memory completely unrecoverable until program termination. In Java, this is impossible. IOW, the only way for Java to "leak memory" in the fashion you describe is by deliberately doing it. So, no, Java does not "leak memory", despite your claims. OTOH, it doesn't read programmer minds, either, so if you really *really* want to shoot yourself in the foot, there's only so much the language and JVM can do for you.

you are actually incorrect about circular references with respect to garbage collection

Ah, my mistake. I couldn't remember if they'd dealt with this properly and didn't bother to research it. :)

you imply that the problems in C are "scaling" problems.

Err, no, *you* implied that *Java's* problems are related to scaling to larger projects (you said "as the size of the project grows, java has as many problems as other programming languages."). And in my experience, the case has been the opposite... while C and Java both scale quite nicely, Java alleviates some of the pains that C creates (eg, having to manage header files).

by itself, it isn't slow, as many benchmarks will attest, but when you have lots of objects to garbage collect, the real-time guarantee is lost,

This is certainly true. However, "the correct tool for the job" rule applies here... I'd never consider Java for a real-time application. And for non-real-time apps, this issue typically isn't that important.

this is the *exact* same purposes of a header file

Err, not quite. First, the situation you describe strikes me as fairly unique (I know I haven't encountered it, and I've written a fair bit of Java). Second, in C/C++ header files are required because they describe an interface for a module. In C, they export symbol names and in C++, they provide whole class definitions. And, AFAIK, in both of those languages, they are required whenever *any* module wishes to export an interface. OTOH, in Java, the .java (and .class) file serves both as the code as well as the interface definition. This means that, for the vast majority of cases, you don't need any kind of secondary interface definition at all (as opposed to C/C++, where you need one *every time*).

Re:Maybe because it's slow ?

[Mr Z]

It's not a memory leak unless you forget where your "arena" is. It's just a poor choice of allocation/deletion strategy for that app. If you're truly running in steady state, then the traditional malloc/free (or new/delete) approach should work fine instead. Either that, or you shouldn't be allocating much any more.

If you do have discrete processing steps (e.g. sending off a bunch of queries, constructing a web page, whatever) that are largely self-contained, though, the arena strategy can work well. I do agree that it's best for batch-oriented tasks.

--Joe

Re:Maybe because it's slow ?

[Hulfs]

But the reason it is uncool is because, outside of stuff written just for Java monkeys, there is no Free software to speak of written in it. Free software is written in C (65%), C++ (25%), and Python and Perl (all but the last 1%). Free Software coders have avoided Java for lots of reasons, including its not-really-portability, its bad performance, its hasty and stupid language and library design, its corporate 0wnedness, and their own resistance to hype and idiotic jargon.

Are you flipping crazy (or trolling)?! Go to freshmeat.net, browse to the projects by programming language, and look at the number of projects writting in java (currently 3257, about what C++ is at). Are you telling me and everyone else that every one of those projects are both non-free and solely written for "Java monkeys"? What a total load (as are your "statisics").

Re:Maybe because it's slow ?

[Coppertone]

But you have to agree that Azerus is probably the best written client out there..

I do a lot of prototyping work in Java - that's because I am fluent in Java.... and I can do it just as quickly as most people who do it in Python!

Re:Depends ...

[Guppy06]

"(Any helpful links to a good C++ API (not GUI toolkits) which is both POSIX and Windows might make me use that some more.)"

Isn't the WinNT codebase supposed to be able to run POSIX apps?

The Rubber Never Quite Meets the Road

[taradfong]

In every computer language, after all the pretty abstraction is over, at some point, bytes need to be copied to/from hardware. The problem with Java is, they try and hide that ugliness. That's not a bad thing, and it doesn't doom other languages that try it (Perl, VB, etc.)

The killer is, Java tries to hide this ugliness *regardless of platform*. And in the process, it bleaches out the goodness of the target system and inevitably screws up something. Hence, you have to go through hoops (albeit easy ones) just to do a 'right click'. In Windows, if you have a menu pulled down, you can click the title bar and it closes the menu for you. Not so with Java (at least with Swing when I was last programming in it).

So, for any app that has to interface with non-universal software or hardware, Java creates pain. You have to write a wrapper to access the registry. You have to fight UI flaws and performance. Trying to make your server app launch as a service kind of works, but the implementation has holes you can never plug, and so on.

So, yes, Java creates this beautiful, perfect OO world that's a joy to program in. But it does so at the expense of dealing with the reality of the needs and capabilities of the platform.

Re:Maybe because it's slow ?

[orangesquid]

Yep. The Cray C compiler is this huge, slow, stinking mass of algorithms designed to figure out what high-level process (sorting, matrix multiplication, etc.) you're trying to write in medium-level C code, and then it drops in fine-tuned assembler code and makes a few substitutions, and, voila, your app runs on a multiprocessor supercomputer.

There's no reason a very well-engineered language aimed at solving the majority of common computer problems very well couldn't have a syntax where the compiler always knew what the programmer was trying to do, and could simply spit out bytecode corresponding to the different abstract steps that the program goes through; the interpreter would execute highly-optimized native routines, and this setup would easily outperform standard compilers for most tasks.

Of course, designing these types of programming systems is very difficult, indeed... but, to some extent, it *has* been done, there just aren't very many options yet...

Damn straight!

[Tony]

Besides, success is its own argument. If you can't understand why Java is so big these days, maybe that's your fault, and not the world's.

How true!

And the same goes for Budweiser, McDonalds, the Ford Escort, and reality TV, as well. Who cares if they are good or anything; they are popular.

Re:Damn straight!

[jjohnson]

My point is that, if it's popular, then there's a reason that it's popular--like maybe, a lot of programmers (good, bad or otherwise) have found it useful.

You can't blame Sun's hype machine for all of Java's success--lots of technologies have been hyped to Hell and back and still fallen flat on their faces.

Re:Maybe because it's slow ?

[Wavicle]

JRE 1.4.2_05 offline multi-language install is half that size. An online single-language install will require about 7.6MB of download.

It sounds like maybe you have the JDK.

State in Functional Programs

[MenTaLguY]

Use e.g. monads or "single-use" values.

Single-use values are used to represent the parts of the outside world that can change -- when, say, inserting a record into the database, you pass a value representing the database to the "insert" function, and it returns a value representing the modified database, and invalidating the previous "database" value.

Arguably the invalidation of the old value is still a side-effect, though, and it's still somewhat awkward to use.

Monads approach things the other way around, permitting you to set up purely functional "pipelines" through which state will be passed at runtime (but the state-passing need never be explicitly exposed, and in the pure sense cannot be).

Monads work very well, and maintain purity (without having to pass extra arguments around everywhere), but they're very, very mind-bending to think about until you get accustomed to them.

There are also other monad-like approaches (e.g. "arrows") which are possibly better, but this is an area that's still being actively researched.

So, it's possible today, but really it's an issue computer scientists have only recently started to experiment with in earnest; I expect we will have even better approaches for managing state in functional programs in the next few decades.

My Fantasy (outside your favourite mag?)

[Fallen Andy]

..is that we'd just appreciate the good engineering done by others and build on it rather than prattle on like little old ladies. Maybe I'll die of old age before this happens but I have dreams...

Yes, Java (the idea) was wondrous. But not new. The UCSD p-system is the root of most of these ideas. Sigh. C# is prettier (and I ought to contribute to mono (I feel guilty)). Don't we all. I have to eat, my brethren and so do you. The catch is that we don't want to sell our souls in a faustian bargain. I just looked at the previous sentence and realized I was threatening to be a cannibal (ouch).

oh well. Maybe I have the appropriate skills in dyslexia to become a U.S. president...

Incorrect points

[otisg]

I think there are a few invalid points:

- "Java has been considered slow"
Perl and Python are also not considered fast, but
those who use them consider themselves cool.
No, the speed is not such a big factor.

- "Swing disasters continue"
Yes, but do you see Perl and Python programers
write GUI apps? Ruby? Scheme?

- Java did not have a good IDE
I've never used an IDE to write Perl nor Python.
You don't need an IDE for them, most of the
time. That is precisely one of the factors that
makes them suitable for hackers. Hackers like
it lean and mean, and not big, heavy, and
complex, and that is exactly what IDEs tend to
be like.

Other than that, there are good points. Anything for the masses is not cool, and this is not limited to programming. Everything around us works this way. Any PL that requires you to write a pile of code before you see the effect is uncool. Perl, Python and Ruby all allow you to get something working very quickly.

Re:Incorrect points

[mabu]

"Java has been considered slow"
Perl and Python are also not considered fast, but
those who use them consider themselves cool.
No, the speed is not such a big factor.

True, but the use of Perl and Python in a real-time, interactive environment is bad design. Those languages were not meant for those types of applications. (despite Slashdot's use of Perl, which has been optimized, but I still contend if they used PHP, they'd be able to handle more traffic with less resources).

Re:Incorrect points

[mabu]

I agree. Java is so slow and resource-intensive it's not a good choice for high-traffic environments, which blows me away when I see some popular sites using this technology. They're destined to fail unless they spend ten times the money in hardware resources they'd otherwise need.

Re:One word - Cygwin

[gillbates]

Yup, nothing like having your Windows users install and configure Cygwin in order to use your Java app....

Top 5 Truisms About Hackers

[CyNRG]

1. A hacker is a good person; curious, but harmless.
2. A cracker is a bad person; curious, and dangerous.
3. Curiousity means you want to know how the damn thing works, all the way down to the hardware.
4. To get to the hardware (registers, port I/O addresses, etc) you need a programming language with instrinsic low level capabilities.
5 The most popular languages with a compiler on almost every piece of hardware is: "C", and "Forth". Of course "Forth" is usually used to bring up new hardware as a prom monitor, so it really is for the geeky (yeah, ok, me) :-)=====

COBOL - Caffeine Oriented Business Object Language -> JAVA

I use "C" for fun (24 years now), I use Java for a paycheck.

Re:Depends ...

[Lodragandraoidh]

I also specifically loved the good type checking and the like. I want that from my languages.

What you gain in stability you lose in flexibility.

Python/Perl have very smart primitive types (basically: string, array, hash [not correct terminology for either language - but a good approximation]) that can be retyped depending on the context in which they are used. For example, a string can be used in a numerical context for calculations without having to waste space translating the string to a number, then assigning it to a numerical type. This typecasting is automatic - something the programmer doesn't have to think about.

However, now the programmer is responsible for his own data integrity. In practice this is far less time consuming than in traditional 3GLs. Furthermore, for those 'one-off' administrative/glue type apps - you can ignore it entirely if the manipulation of the data is well defined (such as in filtering) - you don't have that luxury in Java, where you must define your variables up front - a fixed overhead cost to every application.

I don't grok functional-programming...

By functional-programming, I assume you mean structured programming? I think it is safe to say that every programming language, save Schema / Lisp, can be used in a structured (non-object oriented) manner. I can't imagine understanding OO without having first understood the basics of structured programming. Having the reverse be true boggles the mind...considering that structured programming is simpler than OO in most cases.

Re:Maybe because it's slow ?

[bwt]

As JIT technology matures for these languages (like psycho has for Python), statements like the above become less and less true.

The same advances also make java faster, but this is beside the point since I'm not actually knocking these languages for being slow -- I personally don't care that much about CPU speed so much as speed of development and clarity and reusability. In fact, I love perl, python, and ruby and I'm not a language snob. I was just pointing out hypocracy in others who throw mud at java and then use a slower language. In fact, I've used both jython and jruby and groovy for various tasks at work.

What are you doing with pointers that you have to spend any time at all debugging them?

What are you doing with pointers that you don't have to spend any time at all debugging them?

The three common failure modes are improperly initializing a pointer, bogus pointer arithmetic, and mistakenly assigning one pointer to another when the referenced structures are different. These situations usually don't appear to runtime and then often produce non-repeatable behavior.

Re:Maybe because it's slow ?

[cakoose]

If object-pooling is a prerequisite for a good program, then the runtime system isn't doing it's job. It is a pain to perform object pooling and you have to design your objects differently if you want to allow them to be pooled.

It would probably be a better idea to attach attributes to classes to provide hints about how they're going to be used. That way you don't have to actually change the way your program works to reap the benefits of pooled objects. Make the VM do it for you.

A lot of the time, a generational garbage collector can handle the deallocation of many short lived objects efficiently. In the canonical copying collector implementation (a generational GC is a copying collector) allocation is extremely cheap too (just incrementing a global variable) and has a good chance of being much faster than maintaining a weakly-referenced free list object pool.

Why is Java uncool?

[gillbates]

Because we all secretly wish we were still programming in COBOL.

The Kids Have a Saying

[VonGuard]

It's not just slow, it's Java slow.

Cool things about Java

[akuzi]

I think Java is most seen as uncool because it's simple (or atleast the complexity is pushed into the APIs) and it's used mostly for enterprise development that traditionally COBOL was used for, and not for desktop apps and systems programming (not that you can't do these in Java).

It does have some redeeming features tho (it certaining is a better COBOL than COBOL!)

1) Java has absolutely the best programming tools out there

There is nothing out there that touches the Java IDEs such as Eclipse and Intellij. Some of the advanced features they provide like intelligent code completion and some of the refactoring support are impossible to do with weakly typed languages such as Perl or Python, and very difficult to do with natively compiled languages such as C/C++.

2) Java seems to becoming popular for a lot of OO and software engineering research. A lot of the originator of ideas such as design patterns (Erick gamma), refactoring (Martin fowler), XP and test-driven development (Kent Beck, Ward cunningham) are Java people.

3) You can do some amazing hacks in Java, using features reflection, dynamic class loading and byte code engineering, etc.

C++ looks like it's more powerful than Java because it supports templates, operator overloading etc, but Java also has some features that let you do some quite advanced things. For example look at the Jakarta Byte code engine library (BCEL) and look how it has been used in AspectJ and Jython. For example in Jython you can run an embedded Python script in your application that can seemlessly call any Java code, catch Java exceptions and so forth - i can't think of any language designed for embedded scripting that is this convenient.

4) Java has a huge open-source development community

The average Linux desktop user probably doesn't realise this, but there is absolutely piles of open-source Java development going on. A lot of this is on libraries useful for server-side enterprise deployment, web frameworks, workflow engines, object-persistence layers etc. but there is no shortage of projects out there.

On the whole i think the Java world is more interesting that people give it credit for.

Re:One word - Cygwin

[graveyhead]

Yup, nothing like having your Windows users install and configure Cygwin in order to use your Java app....

You were paying attention, right? The parent asked about classpaths in unix-like system directories. Nobody asked about Windows compatability, and the discussion did not center around distributable Java products.

If you don't find the snipped useful, just fucking ignore it. Shithead.

Its slow.

[Silverlancer]

Very slow. I have done some programming in Java, and one thing I notice is that it does even the simplest processing, addition, subtraction, loops, recursiveness--all slower than C++. Much slower. Unless I add hardware acceleration, it takes 1/5 of a second to clear the graphics window on a fast computer. It also has annoying limits on things, like how deep a recursion can go. Even when compiled specifically for x86 (there's some java mod to do that, forgot its name though), it is still much slower. And the most annoying thing IMO is that Java doesn't give me options on how to do things--it makes me do things EXACTLY how Java wants me to do them, whether I like it or not. IMO, that is the worst part of Java.

Re:Maybe because it's slow ?

[chris_mahan]

Yeah, but YOU didn't write bittorent. A python programmer did.

You could write an AI expert system in javascript if you wanted to. I am not saying one language is better than another for this task or that.

All I am saying is that for people who are "hackers", Java is not as "attractive" as python.

This attraction is the "coolness" factor.

I agree that to build an enterprise-wide web-based data-back-end high availability, fast and robust multi-thousand user application, Java is the better tool.

But "hackers" don't want to develop billing software and reporting engine for banking or healthcare. They want to make things like bittorent, for fun.

And it's the "fun" that makes it "cool".

Re:You just made his point

[smack.addict]

I did not say Python was clearly better than Java. Python in general produces more bug-free code. There is more to a language than producing bug-free code.

In my projects, I tend to use Python or Java depending on the problem at hand.

Source is there if you look

[Midnight Thunder]

Depending on your definition of 'open source' then Java is or is not open source. If your definition of open source is that of the source being available, then the source for the J2SE (Java 2 Platform, Standard Edition) source code is available under the Sun Community Source License.

Re:Cool?

[heinousjay]

Well, I'll address some of this

I don't like the naming convention of firstSecondThird. first_second_third is simply more readable
That's personal preference. I personally hate moving my finger so far out of the letters to get to the underscore. Also, nothing stops you from naming things in java any old way you like.

I do like . notation and I'm happy it's spread to every other language.
sure, sure.

I don't like try, catch. It's important to roll up errors but try, catch just turns into a mess usually. Perl's "or die()" way of doing things isn't great but I do like it better.
The propogation of try...catch throughout a system is a design mistake, not the fault of the language. People that treat exceptions like non-exception error handling are the culprit here.

I don't like strongly typed languages. Dealing with an overloaded object as a basic type that automatically does what you would do normally, usually requiring less variable names and code is a win.
This statement makes no sense. Perhaps the concept of polymorphism is unheard of in your world? Not sure. The thing is, that whole second sentence is one of the greatest features of java, and all other object oriented languages. As a matter of fact, it's part of the definition.

There's too much overhead in Java.
True enough

I believe that the only sufficient documentation for code is code.
Here, you simply have no idea what you're talking about.

Comments can be wrong and never telly you precicely what is happening so a good programmer never relies on them, you have to read the code to figure out what is going on.
And code can be obtuse and completely unreadable, forcing you to spend hours deciphering what someone tried to write in a blur of speed.

Things should be represented consisely so they can be read and understood quickly.
Properly designed software ends up like this, with low level plumbing going on behind high level code that is concise, clear, and hopefully descriptive, if the names are chosen correctly. You can make an ugly mess out of any language. As a perl devotee you cannot disagree.

What it comes down to is you are complaining about poor java code, not java itself.

Perl instead of Java?

[mveloso]

Whoa, this guy doesn't write real software. He's a scripter, like a high-end VB guy.

Re:Maybe because it's slow ?

[bwt]

I'd count "choosing technology which does not require paying attention to useless details" as a more valuable skill and one that increases productivity more.

Since errors happen when there are more details than capacity to attend to them, we should strive to both eliminate details and increase attention capacity. The details in question here that are demanding attention are useless waste that should be eliminated.

If you love paying attention to details for its own sake, take up chess.

it's who programs java

[gstover]

It's because of the mean skill of Java programmers. "Lisp as an Alternative to Java"

Bringing objects to the masses, Java is the COBOL of object orientation. Java may be practical, but it's un-hip & un-fun.

Re:Why I consider Java uncool

[Anonymous Coward]

I agree with you mostly but: 5) Have to set things to NULL or the GC doesn't work as well. You're joking right? Hint: NULL is not even a Java term, null is. GC works 100% as designed. Or maybe you mean within one big fat method? I have seen the Java world polluted with untrained "programmers" but, that's the nature of any technology. First the good people do it and then all the slackers show up. My wife was a nurse and same thing. Now you're probably getting your healthcare from somebody with 2 years or less of education. They basically have replaced the RN's with CNA's which is bad cause the RN's were the hands of the doctor as it was! Same for coding. The times when your buddy next to you knew exactly what he was doing are well gone. Now it's a retirement field. Do the cool stuff at home.

Re:Go write me a distributed n-tier web site in c

[NitsujTPU]

Not really.

C is not constrained to writing operating systems. C can be used to write just about anything.

Java, however, cannot be compiled to native CPU code. Given that it could be, your control over the RAM of that system would be clumsy at best. Also, device drivers and such, would all be impossible to write.

C, however, could be used to write a web application.

Thanks!

What part of "for example" can't you grasp?

[theonomist]

The majority of his article did not revolve around advocating *nix over Windows

Correct. I gave one clear, obvious example of a questionable conclusion he reached by drawing all of his "great hackers" from a very small and non-representative sample of the working programmers on Earth. This is why I prefaced the example with the phrase, "for example". Because it was an example. See?

Perhaps the phrase "platform advocacy" was ill-chosen; perhaps I should have said "platform and/or language and/or tool and/or whatever advocacy". Hell, I could've gone on for a whole paragraph clarifying a point which was painfully clear to anybody who'd read the essay.

You probably didn't notice that another of his points had to do with saying that cool programmers don't like Java. That's understandable. After all, how could could you possibly have noticed a little thing like that, in the middle of 1000+ Slashdot posts about precisely that aspect of his essay? Whether it caught your attention or not, it is, once again, platform and/or tool and/or language and/or blah blah blah advocacy.

Bottom line: He says that smart people all like the same stuff he does, and anybody who makes different choices is an idiot, and that's an important part of what he's saying. This is often called "platform advocacy". It's more often called "bullshit", but that term was too general for my purposes. There's a wealth of bullshit in Graham's essay, and I wanted to be clear about which particular steaming pile I was asking the reader to sniff.

I love Java-write once

[MichaelPenne]

crash everywhere. Although ourtools is one fast, solid little jar:-)

Re:Java is unpractical!!!

[Indigenous Cowbird]

But, but, but... Java takes care of all that nasty memory stuff for the programmer, doesn't it?

It gets worse. If you don't fine-tune your runtime's heap size for each app, then you'll discover just how slow GC can be.

Setting the runtime heap size to the size of your machine's RAM might be a natural thing to do, but in a good many cases it's completely wrong.

Re:Depends ...

[ArmpitMan]

By functional-programming, I assume you mean structured programming?

No, I think he means functional programming. You know, that Lisp / Scheme ( / ML / Haskell / APL / Joy / ... ) stuff that can't be used in a structured manner. Non-imperative programming.

It's kind of an interesting field.

Re:Maybe because it's slow ?

[loraksus]

Please, do we have to hear this comment every time Java comes up? It was cool to say that in the 1990's, but it's a little out of fashion now.

Yes, perhaps because it is true. Or was in the 90's anyways when processors were a wee bit slower. I had a 700mhz Athlon and was taking some java classes years ago and it was horrendously slow even when making / using the simplest programs.
That said, it's better now, but seeing as it was all but useless for anything except perhaps for teaching oop 5 years ago, it might be a while before the stigma dissapears.

Re:Depends ...

[GrouchoMarx]

Oh, sure it's got an explicit full-on syntax, but I'm comfortable with that. What I was most impressed with was there was a vast amount of standard data types and APIs available to accomplish a very huge amount of stuff. Looking at C++ and the like, the APIs are anything but cross-platform. (Any helpful links to a good C++ API (not GUI toolkits) which is both POSIX and Windows might make me use that some more.)

Try Qt. In its current version (v3.x), the GUI and non-GUI APIs are somewhat merged, but v4 (currently in progress, due out soon) is supposed to have full separation between the two. Even now, it still works. It's write-once, compile-anywhere (Linux, Windows, Mac), GPLed if you're writing GPLed code for Linux or Mac, and has an OO library and design that is simply gorgeous. It's like C++ done by people who worship Java but hate Swing. :-)

KDE, Opera, and various others use Qt, so you HAVE seen it in action.

For the type of code I was writing at the time (oddly enough, server side stuff behind a web front-end, no GUI) I found I could always find a standard routine to do what in the past I've had to implement from scratch.

If you're doing web apps, definitely look at PHP. I use it for all of my web work, and love it. The new PHP5 has a reworked object model that is very Java-ish, but also has a lot of other features that make life simpler. I've also started using their Smarty template engine, which is a godsend (a web front end IS a GUI, just a different kind of GUI), and there's a huge online archive of code you can use in the PEAR archive.

Re:Maybe because it's slow ?

[unDees]

Really? I'm not a C++ guru by any means, but it's been a long time since I've had to worry about memory leaks (auto_ptr and its more sophisticated kin), buffer overflows (stringstream), and so on.

I still make plenty of errors -- plenty of 'em -- but these days they're overwhelmingly logic errors, for which I have nothing to blame but my own stupidity.

That said, I much prefer dynamic scripting languages like Ruby. Even though I don't always have the luxury of using them, I like to think they've made my C++ just a little better.

Re:Masses? hat Masses?

[mschaef]

"MS hasn't included Basic, Visual or otherwise, with its operating systems since,I dunno, DOS 3.3?"

Sure it has: DOS, through 6.22, included QBasic; Any version of Windows running MSIE (<6-7 years old) includes a copy of both VBScript and JScript. In later versions of Windows with WSH, it's possible to use either of these languages to usefully automate things. The only thing that's really changed is the relative importance of the programming tools in the overall system: When your system's editor is edlin and the only end user application is command.com, gwbasic [1] is a lot more important than it is in, say, Windows XP.

1] I remember Compaq using the BASIC interpreter to write sales demo software for their computers. They even had a little game they wrote, "Compaq Portable", in which the primary goal was to collect as many portable computers you could in 60-seconds.

Re:Depends ...

[pipacs]

By functional-programming, I assume you mean structured programming?

By functional programming I believe he means functional programming .

In all my years

[KidSock]

I have never seen so much utter nonesense that what I'm seeing posted in this forum today and my karma has been 5 since 1999. I code more in C now than I ever did in Java but clearly you people have no clue what makes a good programming language or how to program. Java is a great programming language. Most of these posts are downright incorrect. And why the opinionated ones get modded Insightful is beyond me.

Wait a minute . . .

[johnny_cobol]

I'm not cool?

Re: Java Myths

[ClosedSource]

Well, if a language is truly WORE it should be impossible to write a non-portable program by definition, no matter how bad the developer is.

Re:Go write me a distributed n-tier web site in c

[LnxAddct]

I responded to your grandparent post as well, but here we go correcting you again. Check up on things first :-) You said java can't compile to native code, and here it is The GNU Compiler for Java. Right on its front page it says
"GCJ is a portable, optimizing, ahead-of-time compiler for the Java Programming Language. It can compile:
* Java source code directly to native machine code,
* Java source code to Java bytecode (class files),
* and Java bytecode to native machine code."

Just give up hating java, it is truly an amazing language.
Regards,
Steve

*bzzzt* No, that's not the reason.

[devphil]

Java was designed to be easily learned

No it wasn't. Java was designed for one thing: to make money for Sun Microsystems. Everything else is secondary.

Yes, it's a good language. Not particularly innovative, but it has a nice clean design. It started out with a good-sized standard library, which has now become so huge as to be unlearnable. 8 points out of 10.

But it's also the only programming language in CS history to come with a corporately-chosen marketing slogan ("write once, run [never the same way on any two platforms] everywhere"). That's a bad bad sign, and you seem to have fallen for the hype. You're smarter than that.

No, it's not all hype. Yes, it's a fine language. No, it wasn't designed to be easy to learn.

Re:Maybe because it's slow ?

[BasilBrush]

I do a lot of prototyping work in Java - that's because I am fluent in Java.... and I can do it just as quickly as most people who do it in Python! Only if you are a lot smarter than the "most people" you are talking about. Heck, look at all the time you save not having to type semi-colons. in Python ;-)

Seriously though, not having to declare variables, that saves time. Getting automatic dereferencing in for loops saves time. Being able to do polymorphism without subclassing, that makes hacking using preexisting classes really quick. But the biggest win for Python is that it's list processing is second only to Lisp. For all it's container classes, you'll never be able to juggle quantities of data quite as easily or a flexibly in Java as you can in Python.

Funny in a weird way

[da_Den_man]

I run into other programmers that all want to be able to say "Yes, I program in JAVA" and will do so at the drop of a hat. When asked what they have built, it usually turns up to be a JavaScript page, or DHTML system. Not JAVA. I have worked with JSP, and find it to be easier to say "Oh, its coded in JSP/JAVA" than to try to explain to the client what was actually used to build the system. JAVA is a good 'buzzword' that unknowing persons understand, so it gets thrown around a lot for ease of use. I have built C/S apps using JAVA and found that there are other more effective ways to accomplish the same goal.

My notebook backpack is one I got at the first SUN JavaONE conference. It starts more conversations than I care to admit to because people don't know what JAVA actually is and confuse it with the 'end all beat all' way to build apps. Hell, in previous experiences, JAVA was how the project started, but was abandon due to the fact that it was 'TOO BIG' a solution to a complex program requirement. CGI/XML/JSP worked better and faster to develop.

Java Sucks

[mrnick]

If I need to bang out a script I use bash. If I need to write a simple cgi I use perl. If I am writing a full program then it is going to be writting in some variation of C (C,C++,Objective-C,etc). Java is OK for stuff on web pages but for that stuff I would prefer Macromedia flash.

Flame me if you want but I don't consider Java a real language. Esp since MS corupted it.

Nick Powers

Re:Java Sucks

[jimfrost]

Dude, if what you think Java is good for is putting animations on web pages then you have been very sorely mislead. That is, IMO, the worst possible use you could put it to because you see all of the things it does poorly and none of the things it does well. Frankly I think Sun did Java a huge disservice by pushing it in that direction initially (although it did get a lot of people using it).

Rather, Java is particularly well suited for writing server applications, especially extensible server applications. It's downright trivial to write a server application in Java. It's too bad about J2EE, one wonders why Sun felt it necessary to create an environment that seems custom designed to make it difficult to run your code.

As for Microsoft corrupting it, the truth in the matter was that Netscape's variants (there were many) were always far more bastardized than Microsoft's. If Sun were really interested in Java compatibility they would have sued Netscape first.

But that's ok, Microsoft surely is going to have the last laugh over that lawsuit since .NET is just their JDK 1.1 implementation with new language front ends. If .NET kills MFC (quite possibly the worst class library of all time) then it'll all be worth it.

I do rather wish C# had kept mandatory exception handling and virtual as the default but at least they didn't go back to having automatic type promotion.

Re:Maybe because it's slow ?

[brunson]

Possibly less so, since a great deal of the bounds checking is done at compile time.

A good friend wanted to write a CLI for a java app, but couldn't use his tried and true architecture because java won't allow jump tables and trampolining. That is to say the *compiler* won't let you use them, he wrote the CLI in Python, compiled it with Jython and now the EJB is happily running the code.

You can get around a lot of the Java security by using hand assembled byte-code.

Re:Depends ...

[mad.frog]

For example, a string can be used in a numerical context for calculations without having to waste space translating the string to a number, then assigning it to a numerical type.

Sorry, that's a bug, not a feature. I know this is a hopelessly unfashionable attitude, but all data conversions need to be explicit. The language should make this as terse as appropriate, but no terser... but I don't *ever* want the language to do anything under the hood without my explicit approval.

Furthermore, for those 'one-off' administrative/glue type apps - you can ignore it entirely if the manipulation of the data is well defined

Sorry, I don't believe in the existence of such code. If it's worth doing, it's worth doing with some confidence of reliability.

Java is not more portable

[Anonymous Coward]

OK, you lost me when you said that Neither Perl nor C move from platform to platform with the same ease Java allows. I disagree:

1. If we restrict ourselves to Linux, Windows, Mac, then there are GUI toolkits for both Perl and C which are cross platform (for C it's a recompile for each platform). Unless you program in the Metal/Java Look and Feel, Java programs tend to require a bit of tweaking on each platform (and Metal looks like ass).

2. If we do not restrict ourselves to "major" platforms, particularly if we are willing to scrap the GUI, then C becomes the most portable language. Ever programmed in Java on a PA RISC system? Probably not, because nobody has made a JVM for it (although this is dated knowledge).

The only place where Java wins big is in the emerging embedded market, where some companies are making their devices J2ME compatible and not providing a C interface. This market is growing and will likely be more important in the future (it is important to some people now).

Java's "best" is garbage collection, SWT, and Apache. Garbage collection is cool because, as the grandparent said, B coders can't screw up. SWT almost acheives all of the cross platform look and feel objective, at the expense of manual resource management (which is sort of odd in Java). Apache (and IBM) provides some of the most useful libraries and frameworks for developing enterprise applications.

Java's "worst" is installation. I used to think that applets and web start applications were kind of cool, until I noticed that everyone had an old JDK installed on their machine and I wanted to use the latest. If I program an application in Flash, I can redirect the user's browser to require a single click to download the latest player. Users seem to be Ok with this when it is required. For Java, the user is presented with three different things they are supposed to read and click through. Updating Java intimidates some users, just because of the way Sun has tailored the whole experience. Thank god apple updates their JDK through the system updater.

OK, InstallShield almost completely mitigates this problem, but it is still fucked up that Sun hasn't done anything about it.

The Bell Curve

[macrealist]

thanks for reading my long-ass post
you're welcome, thanks for posting it

However, I think you miss a few important concepts in your post.
1) Not all "A coders" are hackers.
- I've worked with the elite programmers that do believe that requirements and documentation are good and that a process produces better results. It seems that these are usually the elite and experienced, but not always.

2) Not all hackers are "A coders".
- "B coders" are hackers too. Seen it too many times. Just like anything else, there are more "B coders" and "C coders" that are hackers than there are "A coders". It is just a fact of life, that there is always an elite FEW, but and abudance of mediocrity. i.e., just because you are a hacker, doesn't mean you're good.

3) Managers are people too.
- There are many "B managers" and an elite few "A managers". And usually, an "A manager" is worth a team of "A coders" to a company.

4) Teams are usually a cross section of the population.
- Rarely are there teams full of code monkeys, or full of "A coders". Here is where a great manager is important. An "A manager" will allow enough room for each person to do what they need to, but ensure that each is able to work with the other. I've been lucky enough to have "A managers", and they make a world of difference to individuals and to projects.

5) Programming languages are just tools.
- Use the best tool for the job. Saying you choose a language based on your ability to do "neat hacks" is idiocracy. If I see someone putting nails into a wall with a screw driver, I think - "Damn, that guy is good with a screw driver", and "what a friggen' idiot".

Reading your post it is obvious that you are either an elitist with a lot of bad experiences, or someone with no experience. Either way, I hope your next manager is an "A manager", you really need some help.

Re:The Bell Curve

[pchan-]

well, i agree with everything you've said.* how about that?

i think many people responding to my post have taken it a bit too harshly. i'm not trying disparage all java coders. there are many good ones, and there are many terrible programmers in all other language areas. i'm just saying that, because java is a safe and common choice for projects employing the lowest common denominator of programmers, it is often associated with that type of work.

*except for this:
Reading your post it is obvious that you are either an elitist with a lot of bad experiences, or someone with no experience.

i have nothing against java. i use it once in a while. many of posters have taken to speculate about my language of choice, how good or bad of a coder i be, my attitude towards others, my work experience, software engineering abilities, age, rugged good looks, and other details. i'll tell you that i'm generally happy, because i do what i love to do, and get paid to do it. i hope you're all as happy at your jobs.

Re:The Bell Curve

[macrealist]

Reading your post it is obvious that you are either an elitist with a lot of bad experiences, or someone with no experience.

Sorry, that was not a very fair to make such an assumption.

exceptions suck

[sPaKr]

exceptions are for pussies. Return codes should be enough, and as a programmer I can decided to ignore or deal with a return code. Exceptions are nothing more then return code that force you to deal with them. How many times have you seen a java app bomb becouse an unhanled 'null pointer exception' the best part is if you talk to a professor Java doesnt have pointers, it only has 'refernces'. Its a crappy language made by non programmer quasi-intellectuals about how they 'think' programmers should work. If people dont understand memory manamgment the solution is not to hide memory manamgent in the language but instead educate the programmers. Lowering the bar just gets us shitloads of shit java applets.

Re:exceptions suck

[togofspookware]

> Java doesnt have pointers, it only has 'refernces'

-1 stupid

What the heck do you think a reference is?

Java's 'references' more closely C/++ pointers than C++ (or PHP, or whatever) variable references, if that's what you're getting at.

Re:exceptions suck

[sPaKr]

You have obvoisly never had to sit through a CS class where the prof drones on about how great java is becouse it takes care of memory mangment for you. They claim that there are 'no pointers' but if I have to allocate it its gdamn pointer no matter what the call it.

so-called "benefits" of static typing

[mad.frog]

There's nothing "so-called" benefits of static typing. Mr. Eckel seems to have the attitude that strong testing is more important that strong typing, and thus the former more than makes up for the lack of the latter... but this is like saying that if a car has airbags, it doesn't need brakes, especially since it will make the driver that much more cautious.

Strong testing is great. I'm all in favor of it. But give me strong typing too... to borrow a phrase from a source I can't remember, proper use of strong typing will allow me to eliminate a huge subclass of errors at compiletime rather than runtime. I'd be foolish to ignore such a tool.

Re:so-called "benefits" of static typing

[mad.frog]

Actually, when programming in (new) languages without strong typing, you still never run into the issue that you have the wrong type for something.

Um, wrong. I guarantee that Python won't know how to auto-convert a String into a MyCustomClass object if I mistakenly pass the former where the latter is expected. With Java, C++, etc., I can set up constraints such that I know that it's the right type. With Python, all I can do is fail at runtime. Unit testing to ensure that such a situation *won't* ever happen is all well and good, but why not also ensure that it *can't* ever happen?

You should try it before buying it.

Be careful with your assumptions. I've programmed a wide gamut of languages, from strongly to weakly typed, including those under discussion here. In my 20+ years of coding experience, it's easier to write and maintain reliable code with strong typing.

Re:so-called "benefits" of static typing

[pvcf]

Exactly. There is no replacement for diligence, attention to detail, and completeness when developing software. I see the article by Mr. Eckel in the same way. Although I agree that you can get lazy and "swallow" exceptions when "checked" you can similarly get lazy with your test coverage and readily put a time-bomb out into the open.

You either need the discipline to write the "reams" of code or you need the discipline and patience to write and run exhaustive test cases that will uncover all the exceptions you could so "conveniently" ignore. However, in my experience it usually isn't reams of code that need to be written, it usually has more to do with the amount of thinking that needs to happen. i.e. Ok, this has happened, what should I do about it?.

Perhaps the "real" problem with checked exceptions is laziness and not so much the mechanism itself? ;-)

Secondly, what are you really gaining? If you write two programs with identical functionality; one in say, Python and the other in Java; you will inevitably encounter nearly identical exceptional situations (network down, out of memory, disk full, etc. ad. nauseum). Just because you can ignore these errors up front doesn't save you from having to write "reams" of code to deal with them at some point; regardless of what language you write in. You simply delay the writing of such code until:

• you find it
• a tester finds it
• a customer finds it (with possible loss of time, money or life or any combination thereof)

....Paul

Re:so-called "benefits" of static typing

[greenrd]

Moreover, if you want to do rock-hard verification, not just "strong" testing, you need static typing. You can't do verification in general if "command()" could mean anything! (Unless it's within spec that command() could do anything, of course.) You have to pin down method semantics with types.

Re:so-called "benefits" of static typing

[pthisis]

You can't do verification in general if "command()" could mean anything!

You can't do verification in general anyway.

There are some somewhat interesting results about proof-carrying code (e.g. Peter Lee's ELF/ML work at Carnegie Mellon's Fox group, currently being extended to Java by a group at Princeton) that have implemented nontrivial applications in strongly typed languages and proven them "correct" (for certain definitions of "correct").

That said, many of the techniques used in static verification can be implemented in dynamic languages using run-time checks, such that you can know before the program is run that conditions A, B, and C will not be violated. George Necula (formerly of the Fox group) has done this to e.g. implement a system for making your C programs provably memory-safe (ie no buffer overruns, etc) and has plenty of results proving even stronger conditions in weakly typed languages.

And historically, plenty of work has been done on verifying Lisp code as well.

You have to pin down method semantics with types

True, but this doesn't mean that explicit type definitions are needed nor does it mean that static typing is required. Both dynamically typed and statically typed languages can benefit from type inference.

But I'm unconvinced that a verification approach is a good general approach to software engineering, though. For many (most?) projects, the functional specifications are pretty vague at best and subject to change without notice. Addressing that real-world situation is something dynamically typed languages do very well.

No, functional programming ...

[gstoddart]

I don't grok functional-programming...

By functional-programming, I assume you mean structured programming? I think it is safe to say that every programming language, save Schema / Lisp, can be used in a structured (non-object oriented) manner. I can't imagine understanding OO without having first understood the basics of structured programming. Having the reverse be true boggles the mind...considering that structured programming is simpler than OO in most cases.

No, I mean functional programming . Meaning all of that lambda calculus crap and the entire familiy of languages like Lisp and Scheme. Specifically, the exact opposite of what you think I meant.

Structured programming and OO I get. I've been writing code since the mid-late '80s. I learned on procedural languages. OO in something like Java is fairly intuitive because the language form is still, at it's core, procedural in flow.

However some of the bits required to perform functional programming I never successfully wrapped my craw around since, to me, thinking of everything as a mathematical function does not correlate to the way I conceptualize stuff and I never got the knack for it.

So, no, I did not mean structured programming. I do that every day of the week and have for a long time.

Re:No, functional programming ...

[Lodragandraoidh]

You are quite right - my brain fart. We are both of the same mind on functional programming. (insert foot firmly in mouth)

I can't think of anywhere I would use Lisp - save tweaking emacs macros...

Re:Because end users hate the applications

[Sj0]

Not off-topic, IBM has primarily used Java to power the aging OS/2 platform. If you were running OS/2, you'd be running a whole lot of Java Apps.

Of course, don't let a little bit of history get in the way of your -1, offtopic. After all, Windows XP is extremely innovative, Microsoft worked hard to get their MS-DOS monopoly, and Linux was written by AT&T, won by Berkley in a lawsuit and stolen by Linus Torvalds, only so he could be sued by SCO, right?

Why Java is "un cool"

[beforewisdom]

1. C programmers can't be as reckless as they would like to be.

2. C, C++ programmers would have to learn something new to use Java.

3. VB programmers find Java more complicated then VB and more demanding of their programming skills

4. OSS/*nix types do not like it because the OSS community did not make it.

5. OSS/*nix types do not like Java because they can't feel like they have made it more their own as sun does not allow every freedom in altering and redistributing the code.

plenty of safe languages are cool, Java is not

[dekeji]

Plenty of safe, clean language are cool: OCAML, Python, Scheme, etc.

What makes Java uncool is the fact that it is and remains a proprietary language. Also, it is uncool because both the language and the libraries are full of avoidable design flaws; Java's roots as a failed project for a set-top box programming language sadly still show to this day.

But foremost, what makes Java uncool is that it takes forever to get anything done in it: a language does not have to be cumbersome in order to be safe, and forcing programmers to write lots of LOC to get the simplest task accomplished does not make the resulting code more readable.

But whether Java is "cool" doesn't matter as much; what matters is that these problems with Java also get in the way of using Java for real work.

Re:Depends ...

[killjoe]

Don't forget Groovy

Re:Maybe because it's slow ?

[BasilBrush]

Depends what sort of speed you are interested in. For program execution speed, C/C++ > Java > Python. But if you are not doing something enormously processor intensive, or you are waiting for something very much slower, like a HTTP request to respond, or a user to do some input it may not matter. Likewise if you are prototyping it probably won't matter.

On the other hand, in terms of speed of program development, Python > Java > C/C++. That may well be more imporant. Especially when you are talking a 20x difference is productivity between C++ and Python, which is what I estimate mine to be having used C++ for years, and having since moved to Python.

But you were talking Java. Well, Java fit's in between those two extremes. It's more suited to production code than Python and it's more suited to prototyping than C/C++. It's a good fit for a lot of jobs.

The problem with Java, is not Java, but is Sun...

[neelm]

Sun wants to have the best of both worlds; hackers working on their stuff and yet keeping their control over it. When Java was released, Sun was very bad in working with the community on Java; it was Sun's way or it wasn't done. This lead to many hackers not wasting their time on it, and opened the door to Microsoft to play their games on Java.

Also, because Sun saw Java as a revenue product, marketing guys will want to sex it up every year. Java, Java Beans, Serverlets, and more. Versions that don't work with other versions.

Add to this it's history of preformance and lack of opensource support (there is the Apache Tomcat project, but take lots of care if you are going to build a deployment system with it.. and you would think sun would have addressed the java install issues for firefox/mozilla themselves). I really think now it will be a case of too little to late. Python is up and coming, and I think Python appeals more to a java programmer than a perl / php guy. That is, once you learn to love the bomb and stop usinging braces and semicolons =p

Stained by the dot-com era

[mysterious_mark]

I use Java myself, and do everthing from PDA applications to web apps with, also I frequently compile Java into native code for various platforms. I think the stygma started in the dot com era when anyone who could get "Hello World" to compile considered themselves a Java programmer, and thus a programmer in general. This was further compounded by the advent of Java script, managers and recuiters seem to frequently confuse these two, and even further confusion results now that Sun considers Java to be a 'brand' as opposed to a 'platform'. Seems like most of the 'Hello World' programmers LA majors, H1-B's etc., have now been pushed out of the industry. I use Java because it allows me to most effectivley and efficiently deliver applications to meet my client needs, granted its its the choice of hackers, but I don't hack, I write apps for my clients, and I want to deliver the best product for their investment. M

I code Java for a living

[HaiLHaiL]

I write Java code for a living. It makes me money. I enjoy it. It's the best tool for the kind of code I write.

I could really give a flying fuck what anyone else thinks.

What does it take, then

[Duhavid]

To write a Java app correctly?

They still don't get it...

[mabu]

Good programmers don't select languages because they're "cool!"

And this epitomizes what is wrong with Java. It's a technology that accompanies a marketing campaign. Why? Because for the most part, unlike other computer languages, Java doesn't address a specific niche or application area in any superior way. Therefore there is no substantive need for Java which explains why it has to be heavily marketed to be "cool" so people will use it.

Having been programming for more than 20 years now, I've noticed a dramatic increase in misguided questions newer techs ask me, specifically, "What language should I program in?" as if there is one universal language that will do everything. I've always found this annoying. I'm asked, "Should I learn Perl or PHP?" as if it's merely a question of picking a single language to do everything. While that may be possible, it doesn't do justice to the application if you try to hack a less-suitable language to address a scenario where another choice would be superior.

Java has been dead for a long time. More marketing isn't going to revive it. No computer language will last if it isn't OBVIOUS to developers that it is the best choice for an application.

The bottom line is that C/C++ is more portable than Java, despite the myth of Java being marketed as more portable. Java has better garbage collection and string handling and some higher-level abilities, but none of those features couldn't be plugged into C/C++ with a few libraries. Most Java applications are interpreted or p-code and run hundreds of times slower than lower-level counterparts.

A good example is Puzzle Pirates. A pretty nifty online game written in Java. Unfortunately, the thing is so goddam slow it really detracts from the experience. This application and the company is suffering because they chose an inferior technology as the base of their service.

Debunking the debunking

[Ian Bicking]

Well, Graham doesn't really need me to defend him, but I will anyway. This article doesn't really get the point:

Java has considerably fewer surprises: on this one he might have a point. I might say "Java has fewer orthogonal features" instead. For instance, there's little ability to do metaprogramming in Java (unless you use AspectJ). There's just lots of interesting things you can't do -- and interesting things can also be hard to understand or cause surprises. Java's compromise is arguably valid, though not very exciting.

Java has been considered slow: obviously he doesn't understand where Graham is coming from. Many interesting languages are slower than Java, including many of the languages that Graham suggests (Perl, Python, Scheme).

Swing disasters continue: again, he doesn't understand Graham. To address his criticism of Java, you must ask "is Swing fun to program" not "are Swing apps fun to use".

Java is strongly typed: well, sure. ML is a statically typed cool language. And Lisp, Python, and Smalltalk are all strongly typed. (If you don't understand the distinction between strong and static, read this.) The problem is really that Java doesn't trust the programmer, not the specifics of its typing. Though if you trust the programmer, static typing starts seeming a lot less useful. And yes, great hackers don't like languages that don't trust them, for obvious reasons.

Java has a vast library that is available to all Java developers: this is a guy with a Common Lisp background. He certainly has no problem with good libraries, and he never mentions any problem with extensive libraries. Programming in an open field can be fun sometimes, and can help you think about things differently, but libraries are never a detraction (you can always ignore them if you want).

Java did not have a good IDE: I don't think Graham said that great hackers really like Visual Basic, and that's why they don't use Java. I laugh just considering that argument.

Java is popular: if you ever listen to the users of languages like Smalltalk and Lisp, they will bemoan at great length that they are not as popular as they deserve. Though you'd only know this if you ever looked at these communities.

Java is an application programming platform: so are Lisp, Smalltalk, Python, etc. Most of the kinds of languages Graham is talking about are not systems programming languages.

It's nice this guy tried, but he really doesn't understand what Graham is talking about. Which is kind of the point -- to understand Graham's perspective you need to have the intellectual curiosity to do non-work-related projects, using environments that are unfamiliar to you. You need to reflect on those experiences and make judgements about what you like and what you don't like. If you've only used Sun and Microsoft languages, you won't get it. That doesn't mean you can't do good work in Java, but if that's all you do, then you won't be much of a hacker at all.

Re:Debunking the debunking

[Animats]

And yes, great hackers don't like languages that don't trust them, for obvious reasons.

Great programmers, however, do.

I know several people who were the primary authors of the core of major, widely used applications that work. They're all paranoid about bugs. They don't trust their own code. They all hate program crashes, and have no problem with putting in more up-front work to eliminate even a faint possibility of a crash later.

Incidentally, the programmers I'm talking about range from "well off" to "very wealthy". There may be a correlation here.

Re:One word [REVISED SCRIPT]

[graveyhead]

Note: I tried to use miniver's version that uses 'while read x...', but it doesn't work. The variables inside the loop are in a sub-shell and are not exported back out to the script-executing shell.

This slightly reorganized version lets you create a list of directories that you want to behave as we've discussed.

First off, create your conf file in /etc/java.conf:

/usr/local/java/lib/
$HOME/classes

Then this code will do the trick:

#!/bin/bash

unset CLASSPATH
for d in `cat /etc/java.conf`; do
for x in `find $d -name '*.jar'`; do
export CLASSPATH="$CLASSPATH:$x"
done
done
export CLASSPATH

You could wrap java's executable with this bit of script and it would behave as you want (at least on *nix platforms).

bleeding edge

[zugswangs]

I'm the coolest. I code with MyEmerald5, use HTXML 4.3.065 and run POSTron as my web server. Never heard of them? You must be from yesterday or something...

Re:One word - Cygwin

[_xeno_]

You can do something similar in a BAT script, although thanks to the way variables work in DOS, you need two of them. Basically:

buildCP.bat
-----------
FOR %jar IN (%PATH_TO_LIBS%\*.JAR) DO CALL appendCP.bat %jar

appendCP.bat
------------
SET CLASSPATH=%CLASSPATH%;%1

Of course, the way I usually deal with the CLASSPATH is make ant deal with the CLASSPATH and then just package everything into a mega-JAR and distribute that.

Not the best solution, granted, but...

The Admins perspective

[Venotar]

I'm not a coder. I do some scripting for administrative tasks and integration work, but mainly I maintain mass numbers of machines.

My hatred for java started with the bizarre things it used to do to my browsers. The browsers (and jvms) have evolved, now java in web pages is less likely to make my eye twitch.

Since then, however, I've seen java from the backend.

The application servers: I've not seen a single well documented Java application server. Tomcat, for instance, has tons of documentation on how to write and install your code. Nada on how to actually configure and administer the server. Sure, Oreilly has a pretty good book that came out, but that's a recent development. You'd think the guys responsible for as well documented a server as Apache would've done better.

Quality of Code: There are good (perhaps even great) java coders. I've seen one or two. The number of Java coders who suck far out number them. I can't begin to count the number of servers I've logged into that are bogged down to a crawl because some piss poor java application has three or four memory leaks that the developer can't seem to track down. I've seen whole development teams replaced three or four times before a qualified java crew was finally assembled. You can always tell they're qualified because code thats dragging the four way Xeon to it's knees could all of a sudden run on an old 300 Mhz Celeron with an eighth the memory and still have horsepower left over. And don't get me started on how most Java coders don't seem to care about exception handling. GRRRRR!

Re:Maybe because it's slow ?

[Frizzle Fry]

There is *no* way that a interpreted or JIT compiled language can be *faster* than native code.

This is like saying that C can't be fater than the assembly. In theory it's true: whatever assembly is generated by your C compiler could have been written by you by hand. But in practice, you don't write assembly the same way a compiler does and it is much smarted about optimizing it than you are. So we reach a point where good compilers can generate more efficient code than would any actual human would write if they hand-coded in assembly, even though they theoretically could write equivalent code.

Similarly, a good JIT will in practice be faster than running native C code. We haven't reached that point yet, but we will because the JIT and the runtime are free to do things (like reorganizing memory to reduce paging and to put certain things on the same cache line) that your C compiler can't do since it lets you have access to pointers to arbitrary memory (and lets you pass them around and do whatever you want with them), and because your compiler doesn't have the same information at compile time about how you use the program that the JIT and runtime do, since they get to see what happens at runtime.

Re:who cares what he says?

[obsidian head]

Slime for emacs is very good, kind of like Dr. Scheme. But it's hard to compare too closely of course.

Re:Go write me a distributed n-tier web site in c

[NitsujTPU]

I work on a project coding in java.

It's a great language.

I'm not trashing it.

It still would be at best awkward to choose java for certain tasks.

This conversation is getting to be like conversations with Perl programmers who wish to use Perl for everything. I am not trashing java... I just think that you would be better suited to use C++ for some applications.

Re:Cool?

[squiggleslash]

I don't like the naming convention of firstSecondThird. first_second_third is simply more readable.

This is a matter of personal opinion. Personally, I always rather liked Sinclair QDOS's "two module letters_name" convention, but it's not very scalable... Whatever the situation, making names less verbose would strike me as a good thing.

I don't like try, catch. It's important to roll up errors but try, catch just turns into a mess usually. Perl's "or die()" way of doing things isn't great but I do like it better.

I'm happy with try... catch. What I don't like is the abuse the Java library gives to exception handling. The major issue with try... catch isn't that it's inherently bad, it's that some programmers, unfortunately some of which work at Sun, think it's a great replacement for "goto". Perfectly reasonable conditions that are not errors and do not need to be "caught" in the way Sun thinks are routinely returned using exception handling. That's not acceptable.

I don't like strongly typed languages. Dealing with an overloaded object as a basic type that automatically does what you would do normally, usually requiring less variable names and code is a win.

Strongly typed languages are fine as long as you can translate between types and have means to specify groups of related types, all of which Java allows you to do. The major advantage of a strongly typed language is that it catches logic errors in the code before you even get to run it, and that's a good thing.

I know why people like weak typing, I used to be a fan of it myself, and it somehow "feels" easier, it just throws up a lot of errors when used.

There's too much overhead in Java. I believe that the only sufficient documentation for code is code. Comments can be wrong and never telly you precicely what is happening so a good programmer never relies on them, you have to read the code to figure out what is going on. Having to read through lots of overhead is a waste of programmers time. Things should be represented consisely so they can be read and understood quickly. Lots of programmers have a hard time with perl because it's so dense but I'd rather read a 1 line regex than a 20 line function that does the same thing any day.

This, for the most part, is a fault of the standard library which makes doing simple things much more complicated than it ought to be. But I covered that :)

Re:who cares what he says?

[obsidian head]

Common Lisp and Scheme are very different. If you encountered it in college, it was Scheme. Lisp has no bias for recursion; it is multiparadigm.

Re:Maybe because it's slow ?

[grammar fascist]

That being said, Java has no way of hinting to the compiler "this is going to be constant for a long while now", or "I'm going to run this loop a couple of million times in a bit, you might want to JIT it real good". Without those, the compiler doesn't really have a hope.

You're right, but that's not a problem with one certain method of JIT compiling: HotSpot's. HotSpot profiles the code as it runs, and decides the best way to compile something. It knows how often a test-and-branch will branch, and can arrange the native code accordingly.

There's an additional execution time hit at the beginning, but 1) it compiles faster code; and 2) it doesn't have to compile code that isn't executed.

You also failed to mention that a standard JIT compiler can make processor-specific optimizations that a normal compiler has no hope of making.

Then again, I've seen Java out-paced by many of these languages (most of which compile the program to byte-code at start-up faster than Java loads), which suggests to me that Java is just a poor interpreted language.

Most out-pacing from other interpreted languages is due to operation-specific optimizations that have nothing to do with the fact that either language is interpreted or JIT-compiled. (Or were you suggesting that these other languages are faster in everything?) I can't speak to Python or Perl, but I can give a Java vs. C++ example. Java's collection and string operations are much faster in the general case than the STL's, because of Java's choice of reference semantics and immutable strings. (Ironically - for people who accuse garbage collection of being a performance hog, anyway - it's the garbage collector that makes it possible.)

That some operations in other interpreted languages are faster than the same operation in Java doesn't really surprise me. I'd be much more surprised if any language were better at doing everything.

the problem is...

[bani]

java did promise to fill both embedded hardware and web-app space.

it failed on both counts.

Re:the problem is...

[LDoggg_]

Failing in the embedded hardware space is debateable.

But failing in the web-app space?

You ever hear of JBoss, tomcat, weblogic, Jrun, websphere, jetty, orion, oc4j, resin.. etc?
J2EE is going strong as ever.

Re:the problem is...

[darkarena]

Yah, I agree with LDog. What in the hell have you been smoking. In my opinion JAVA is pretty much the undisputed leader is serious Web-Applications.

Don't get me wrong, I like little languages like .PHP and Pearl, and you can do a lot of things with them. But there is a reason that serious large-scale software companies do not use these technologies.

As for the embedded market, look at the Cell Phones comming out, or even look at your American Express Blue card. Embedded JAVA processors have been amiditedly slow to break into the market, but they are starting to hit the market big-time.

IT WAS NOT COOL WHEN IT CAME OUT!!!!

[I judge you]

We all thought it was cool when it came out, but the promises really weren't true.

Speak for yourself, idiot. Many programmers thought it was unbelievably lame that a programming language had TV ads. Uncool from day 0.

Re:Maybe because it's slow ?

[figa]

Eclipse isn't that fast on Linux. Don't get me wrong, I use it daily, and I think Eclipse is one of the best arguments for coding in Java. However, it has its problems, especially on Linux. Ironically, I believe the slowness is due to Pango, which I'm pretty sure is written in C.

Aside from redraw, Eclipse is one of the slowest starting applications I've ever seen. It takes over 10 seconds to pull up the main window on a modern machine.

However, it's worth the wait for its refactoring capabilities.

I AM A POINTY HAIRED BOSS, AND....

[Anonymous Coward]

Okay, so I'm a Software Engineering PHB, having decided that 1.5X-3X the salary of an architect is nice to make, particularly when the job comes with arbitrary unearned prestige, the occasionally dishy secretary and the time and comfortable surroundings necessary to play Battlefield Vietnam and snack on occasional porn behind closed doors (use my own box and wrap comms out on 22 to home to avoid the sysadmin). So now that you have the appropriate amount of hate, pity or derision going for me, let me tell you what I see when I watch geeks like you argue for the best language, nerding over data structures, pointer math, two lines of this vs. one line of that and the like.

I see job security.

Because none of you have got an eye for the business imperative behind most language decisions: Make your software assets, your hardware assets and your people interchangeable.

Here's how it works. I'm in a mgmt meeting and the SPHB tells me that he thinks it would be reaaaal cool to put the temperature in Cleveland on the "About Us" page so his granddaughter can see how shriveled old gpa's testicles are. So I mention this change to the appropriate product manager and soon enough, resources are queued for that job and it gets passed out to a SNK (snot-nosed kid) for implementation. SNK immediately whines that we need Perl if we're a Java shop, Java if we're a Perl shop or a combination of struts, EJB's, an EJB-.NET bridge and some back-end VisualHappyHappy(TM) if he's had too many Mountain Dews that day.

Like WTF? "The best tool for the job" means crap to me when our software doesn't have to articulate the friggin Space Shuttle. If SNK goes and builds some monstrosity that only he understands, WhoTF am I gonna get to maintain it? If I let the nerds pick their favorite needle-nose pliers for every job, I'd have a whacko menagerie running on six different platforms in one month flat!

Thank you, I will retreat to my cave.

Re:I AM A POINTY HAIRED BOSS, AND....

[Anonymous Brave Guy]

Y'see, the thing about good geeks -- the ones who can discuss the relative merits of data structures, pointer math, and so on in an informed way -- is that they tend to understand programming. If you appreciated that, then you'd realise that any of those good geeks could easily maintain the trivial weather code written by that SNK, whether it was written in Perl, Java or VisualHappyHappy. Of course, if the SNK was himself a geek-in-training, he'd equally well have been able to write the trivial code you describe in whatever language/toolkit you were using anyway.

BTW, for future reference good geeks also hate PHBs who strangely assume that because said geeks know their stuff technically they do not also appreciate the business side of things. (Compounding this error by attempting to lecture the geeks in technical buzzwords that they understand and the PHB does not will not improve said PHB's credibility.) There are a lot of very successful senior developers/constractors/consultants reading this board who'd pretty much laugh in your face at your idea of business sense, and some of us are probably earning more than you, too. But go ahead and eye up your porn/secretary/games instead if it makes you happy; it'll keep you out of our way... :-)

Eeewww!

[gstoddart]

I can't think of anywhere I would use Lisp - save tweaking emacs macros...

Wow, both emacs and Lisp. That's like being able to change the colour of the rock I'm bashing myself over the head with when I could just put down the rock.

I'll stick with vi and non-Scheme-like languages thank you. =)

You want lisp in a box

[alispguru]

If you're looking for a GUI IDE, you'll have to go with one of the commercial Common Lisps, or one of the Scheme variants mentioned in other replies. However, lisp-in-a-box will get you hacking pretty fast - it's Common Lisp + emacs + slime (superior lisp mode for emacs) in one easy-to-unroll ball that should Just Work on the platform of your choice.

This link normally works, but common-lisp.net appears to be offline as I type. Google will show you the sites for various platforms

Let's measure it!

[sjasja]

The only problem I have is that the runtime takes so long to heave its vast bulk into memory and fiddle with stuff before the app. gets control.

I measure 105 milliseconds before main() gets called (1.7 GHz Pentium crippled by Windoze). Actually less, as that figure includes both application startup and shutdown. What do your measurements show? You have measured it before having a problem with it, right?

Is that a showstopper for many of the applications you write?

Re:Cool?

[egarland]

I don't like the naming convention of firstSecondThird. first_second_third is simply more readable

That's personal preference. I personally hate moving my finger so far out of the letters to get to the underscore. Also, nothing stops you from naming things in java any old way you like.

Java's naming convention is all through the standard libraries, you can't really avoid it. You either use it or end up with code that has multiple naming conventions which is even worse for readability. The first_second_third method of naming which while it may be slightly harder to type, is better for readability and readability is very important in languages.

I believe that the only sufficient documentation for code is code.

Here, you simply have no idea what you're talking about.

Don't I? Have you never run across documentation in source code that wasn't updated properly when the code was changed or simply was wrong from the start? Reading only comments is necessarily insufficient for understanding a program. Furthermore, if the program can be written in such a way that it's just as easy to read the code as the comments, it's redundant.

Comments can be wrong and never telly you precisely what is happening so a good programmer never relies on them, you have to read the code to figure out what is going on.

And code can be obtuse and completely unreadable, forcing you to spend hours deciphering what someone tried to write in a blur of speed.

But one of the goals of a language is to make code easy to read. Much of source code's roll is about people telling other people how to get computers to do things and as such, it should work like a natural human language. Some languages are better at this than others. C, for example, is notorious for requiring pages of code for something that in English would be described as "split this line up on spaces and put the first thing in this variable, and the second thing in that one, etc.." One of the measures of the quality of a language is how easy it is to read. Some of that depends on the programmer but a lot of it depends on how the language is structured and what operators it has. Java does OK there but is not exceptional. Python, for example, is much better.

You can make an ugly mess out of any language. As a perl devotee you cannot disagree.

True. Much of perl's bad reputation is that people often port shell scripts to it when the shell language just isn't quite good enough and the resulting mess is completely unmaintainable. This isn't an issue with the language but it does make it look bad. Of course, it's also not just the programmer's faults. Perl has some ugly things in it's language too.

You can't deny that there are things inherently inside the languages that affect readability.

As computers mature and standardize less code will be written from scratch and more will be read and slightly modified. In the future, a language's readability will be even more important to productivity than it is now. As such, it is possibly the most important aspect of language design.

it lacks elegance

[bokel]

java is more like a jackhammer than a dental drill. It surely has its places but its not fun to use.

Syntactic sugars aside

[Baldrson]

Even avoiding syntactic sugars the difference in expressiveness between languages like Java and languages like Perl/Python is about a factor of 5. That's actual measurement of actual code under comparable circumstances.

A factor of 5 is too large to discounty by any supposed greater "amount of mental effort" you hypothesize.

Re:Syntactic sugars aside

[good-n-nappy]

That's actual measurement of actual code under comparable circumstances.

I'm not sure which controlled study you're referring to here. Do you have a link? Did they measure task completion times and number of bugs? Did they control for programmer skill and experience level?

A factor of 5 is too large to discounty by any supposed greater "amount of mental effort" you hypothesize.

How do you know? Code length is a completely indirect way of measuring what you really want to know, which is how long does it take to solve real problems while minimizing bugs and supporting later maintenance. This includes many practical factors like Java IDE's providing better support for auto-completion since the language is strongly typed.

Re:Syntactic sugars aside

[Baldrson]

1995: Filoli Information Systems -- I ran a competition between Smalltalk and NextStep's Objective-C including Interface Builder. Gosling admits that Java is largely a take-off of Objective C and the Interface Builder is widely considered one of the most advanced IDE's of the mid-nineties. The programmers were both well versed in NeXTStep having both obtained the earliest versions of the NextCube produced and worked on contracts with the government over the course of almost a decade. One was reasonably familiar with PARCPlace's IDE, but had no where near the experience with it the other had with NeXTSTEP. We set them both on a starting gun with a pre-existing database and a bunch of forms to build with validated submission. The Smalltalk guy smashed the Objective-C guy 5 to 1. (Filoli failed, in part, I believe, due to the fact that management rejected our recommendation to avoid NeXTStep and go with the Smalltalk. Prior deals had been cut.)

1999: HP E-Speak project -- Software manager Joe Ellsworth ran a programming comparison between Java and Python. I wasn't present during the specification of this contest but the outcome was similar. Again, management over-rode the decision to go with the dynamically typed language.

2004: Project proprietary -- a major W3C standard, notoriously difficult to implement, was compared between ECMAScript and Java. The standard-specific ECMAScript file, with comments removed compressed to less than 7k whereas the similar Java code compressed to more than 70k. The implementation of the ECMAScript version took one guy 2 months of part time work. The implementation of the Java version took an open source team months and proposals to implement it by major players in the Fortune 500 are likely to take a year. You'll be hearing about the ECMAScript version soon.

The big picture

[xoombeeny]

Interesting discussion.

Although this is a site / topic aimed at developers, it seems their are some "big picture" things here being glossed over. IMHO.

For one, someone upstairs said, "different languages for different problems." Hear hear. No one language is great for everything. I can think of three different languages I use for three different problem domains. C for device drivers, perl for system admin functions, (even on Windoze machines), and yes, Java for "big" e-commerce apps.

Java IS an excellent, strongly typed, OO language. When a problem lends itself to a good OO approach, and I'm not required to measure clock ticks for performance, I prefer Java because it makes it easier to do.

On the downside. I've been frustrated in the past with lack of JVM support for various devices. (And too dang busy to write my own!!)

And this brings us to the final "big picture" issue. Have you ever taken a look at Microsoft .NET? The structure and goals of .NET look like the best of Java with other stuff thrown in. The point here? It's the marketing dummy.

We can argue about syntax, tool support, and performance all day. But in the end, one of the key things about Java is, JAVA'S NOT .NET! And why does that matter? Because without competition the MS machine will assimilate us all!!!

MS is rapidly advancing to take over everything from the palmtop to the desktop, the set top box, and even your automobile. We need more alternatives that don't wear an MS brand. I would like to see us break out of some of these old, tired issues, and start focusing on what we can do to advance the state-of-the-art in more competitive ways.

Re:Maybe because it's slow ?

[losinggeneration]

Try saying that if you used a 133 up until a year and half ago. On that, JAVA is slow....

Re:Maybe because it's slow ?

[dvdeug]

Free software is written in C (65%), C++ (25%), and Python and Perl (all but the last 1%).

The latest complete count of a Linux distribution was of RedHat 7.1, http://www.dwheeler.com/sloc/. Shell, Lisp and Assembly all beat out Perl, and Fortran is also above Python, then TCL and then Java. So Java's tenth, with a half percent of code, and there's a lot more variety than you would imply.

Re:Maybe because it's slow ?

[metamatic]

Damn right. There are plenty of situations where I would have used Java, if it wasn't for the startup time.

JEDIT JEDIT JEDIT

[Anonymous Coward]

Best editor ever! VI was my editor of choice before and still use it in a pinch, but JEdit blows it out of the water.

And if you're wondering, Emacs sucks.

Re:JEDIT JEDIT JEDIT

[BestNicksRTaken]

Yeah, you got that right - JEdit blows!

It's the slowest piece of #$@% I've ever seen - startup time, GUI responsiveness....

And the horrid UI "theme".

Mind you, a vi user recommending a text editor doesn't install much confidence.

nano or NEdit, that's what you want - jees, even XEmacs is better!

It's not so different

[maharvey]

Java is seen as uncool precisely because it protects you from your own mistakes... You're absolutely right about the ego trip, but the idea that C doesn't protect you from you own mistakes is an excuse, not a reason, and a false one at that. C does protect you from your own mistakes and does make programming approachable to the masses--that is why tens of thousands of programmers use C instead of assembly language. (And even assembler provides a layer of ease and safety over raw machine language.)

I don't like Java, but...

[tchernobog]

I don't like Java, but it's just because of personal taste (or, better, general personal taste about who usually programs in Java).

Trashing these prejudices (that I read between the lines of many posts above), it remains one consideration to do.

I think that Java works well for server apps. If you've to build a server backend with a commercial JVM, or a framework, it is a really good choice (though not the only one, obviously).

When it comes to GUI / client side application, using Java is synonim of suicide, imho. You can say Java is fast as C/C++ as much as you want. I simply don't believe it. Moreover, using Java for that isn't the most wise thing to do, when there are much faster and easy pls to go with.

There's another thing to say: I hate Java since it is not an open standard.

Ok, I'm a Free Software advocate, I admit it. Having Java as free software would be the best, that's for sure. But not having it open standard is a lot worse... you cannot do your free (as speech) compiler. You're tied to a company (Sun Microsystems). It's a monopoly driven by a single head... that can change its path -- and Sun has demonstrated many times to be as dangerous as Microsoft for the OpenSource/FreeSoftware community.

Let's only hope that gcj/gij will reach an usable status. Maybe then I could start using Java for everyday use. Until then, I'll go on with C,C++,Python,Perl,Scheme... and so on.

Re:I don't like Java, but...

[Coppertone]

First, go and download a copy of Azureus, try it and tell me what you think http://sourceforge.net/projects/azureus/

Secondly, you can get JVM from different people, like IBM, BEA and the like. It's just that those not in the know don't know about them.

I think I do like to see the standard being control by some corp., but sooner or later I think Sun will relingish control - due to the fact that they don't make much money from Java.....

Re:I don't like Java, but...

[tchernobog]

Secondly, you can get JVM from different people, like IBM, BEA and the like. It's just that those not in the know don't know about them.

Are they under the GPL, the BSD or some other Free Software License? Or rather they need to conform to the sun-bcla-java-vm?

I think I do like to see the standard being control by some corp., but sooner or later I think Sun will relingish control - due to the fact that they don't make much money from Java.....

Yes, when Sun Microsystem will drown, it can be possible it'll happen. Or maybe before, under IBM pressure. Also, Microsoft could buy a dying Sun Ms, and then we're double screwed, for the reasons I told (and many more).
Anyway, until it's not free standard, I'll continue to stay well away from Java.

Re:I don't like Java, but...

[Coppertone]

Well, personally working in the VM industry I don't like the way Sun is locking up the platform - But then I suppose the Core Class Library is pretty stable (and speced!) and I think Open Source VM (there are plenty out there, the problem is that no one want to use them so they aren't as developed) + ClassPath (80% of 1.4 spec except Swing/AWT and CORBA) + SwingWT is the answer....

Java is 20% VM 80% Class library, however the VM are the performance critical part...

I thought Apache produce has a lot of good open source Java library - there is no license limitation on what you run on most of these freely available VM and it is just one of those Richard Stallman puritian that is unhappy with the situation....

Re:Any "real" Java apps we can try?

[duffbeer703]

I've used some enterprise apps that run on AIX, HP, Solaris, Windows and DEC Unix.

Try looking at something like Apache Coccoon, you'll be impressed.

Newer Java apps aren't the stupid applets of a few years ago...

Re:Maybe because it's slow ?

[deadlinegrunt]

That is, in a nutshell, my point.

Just as Java developers hate hearing, "Java is too slow" C++ developers hate hearing, "memory managment, lack of garbage collector."

A legitimate complaint about C++ is its [in my opinion] less than exceptional exception mechanism. But then again all industrial strength tools have warts on them right? I think they are also known as 'weaknesses' and more popularly referred to in langauge flames as 'cons'.

Neat Hacks

[figa]

Unfortunately, I think a lot of the posters here, including the parent, have a very superficial understanding of Java. There are "neat hacks" in Java, and B coders screw them up constantly and produce incredibly bad code.

Foremost, Java is a language for object oriented development, and all the hacks are in OO design and development. A lot of B coders screw up Java by writing it like C. The B coders screw it up even worse when they apply patterns incorrectly.

I'm dealing with both cases. I'm maintaining code that in some places uses lables and other places simple objects are created by builders that create factories that create abstracted objects that have to be cast to the object I want.

I spend all day refactoring, and that's where the neat hacks come in. I clean up the design and shrink the code without losing flexibilty or functionality.

Unfortunately, OOD is hard, and in Java, it's where all the creativity and 31337ness lies. Java coding is incredibly satisfying when you're able to break up a massive switch statement into meaningful classes or correctly apply a design pattern and watch a giant class indented to column 80 dissolve into a few cooperating objects.

When I do that, I understand that the Java community has done something incredible. It's made maintaining code a creative activity. I imagine many developers, especially ones who favor scripting languages, never make it this far along in the process.

One final and related reason that hackers may not like Java is because it requires the ability to communicate. For me, one of the hardest parts of OOD is naming my objects. Whereas in C or perl it's common to keep names at one or two letters, in Java you really have to name parts of your program, or everything becomes a meaningless mass of FactoryAdapterConstructorBuilders. I've found that poor naming leads directly to poor design, and that's just not something many programmers are good at.

Java IS uncool.

[Cookie3]

ICRTABIRTH (I couldn't read the article but I read the headline). YMMV.

Java is uncool because whenever I load up a program coded in Java, it eats up between 40 and 60mb of memory, whereas a similar program coded in C++ takes up 20mb.

Java is uncool because the C++ program is faster on EVERY platform than Java.

Java is uncool because although it's supposed to be supported equally on all platforms, it STILL isn't, and you'll get oddities that only affect Windows or Mac or *nix, so instead of coding for one platform, you're coding for all three AND writing code to handle exceptions on each. In comparison, C++ could be written for Windows and be ported to Mac without having to worry about the Windows-specific bugs.

I'm not trying to troll, but I avoid Java programs whenever I have the chance, because typical Java programs make Windows itself look quick and lean by comparison.

Doesn't mean I don't use Java... in many cases it's inevitable (I play Go online, and my preferred server only released a Java client)... but if I ever had a choice between Java and C++/ASM/whatever, I'd pick C++/ASM/Whatever instead.. so long as "whatever" is Turing-complete (I've yet to see an infinite loop in Malbolge, so it doesn't count.)

Re:Depends ...

[Lodragandraoidh]

Sorry, that's a bug, not a feature...

There are thousands of developers that would disagree with your myopic viewpoint.

If it's worth doing, it's worth doing with some confidence of reliability...

Not every application need be gold plated - and still serve a useful purpose. Data integrity can be ensured in the data prior to reading into the application. For certain system administration tasks, you can make assumptions regarding formatting.

For example, the /etc/passwd file has a standard format that any program can read without explicit checks. Why waste time building an application that is going to be bullet proof - when you will only use it once or twice or for a clearly defined purpose?

This cuts to the core differences of the *nix OS and other less robust OSes - the tool making paradigm versus the monolithic application paradigm. I can get more done in a shorter time using tool building and interprocess communication than I can building stand alone apps. On the one hand you have the best of both worlds - you can build one-off apps, as well as full blown 'proper' applications; on the other hand (your hand) you can only build monolithic apps for everything - which leads you to try to build one app that does everything but nothing well.

Re:Maybe because it's slow ?

[Coppertone]

But then that will means that you abuse the variables - in Java you can declare variables when you need it, so it is just as convient, plus you strict typing so you don't get to do dodgy operations on your data.

Polymorphism is great if you use it properly, but it can be a performance hog if you abuse it. With Eclipse (http://www.eclipse.org) I can create subclass by just click 2 buttons like that so no problem there.

Deferencing in for loops is coming in 1.5, but Eclipse writes the loop deferencing code for you:

1) int[] arr; (or whatever array you are referencing)
2) type for
3) Ctrl-Space

and it writes the for loop for you, so I can do it just as quick!

I can juggle a large quantities of data just like that - give me a CSV I use StringTokenizer, I can read a file with a few lines and println to a file using the same code I do output to screen (System.out is a PrintStream, and I can set that to whatever PrintStream I like)

All programming languages are born equal - it is just the skill and experience of the programmer - would you say a oil painter is better(or worse) then someone who use Photoshop? (hmmm probably a bad example)

Re:who cares what he says?

[koali]

...that was replaced because it could not be maintained?

Re:Maybe because it's slow ?

[Coppertone]

Fine :-)

I will keep writing my program in Java and you do it in C or Perl or Python :-) I don't care. (I can write C as well mind you!)

I only care when people say Java is rubbish, it is so slow, as a lot of people in here do.

I do work on developing certain three letter vendor's JVM (no names!) and I say a lot of Java myth is simple not true - we have a lot of happy customer.

Re:Maybe because it's slow ?

[koali]

Actually, you only missed by half of that... It's 15Mb. Another 15Mb mistake like yours and Java downloads *faster* than Flash.

Re:Maybe because it's slow ?

[koali]

Hahaha. Where did you pull your stats out?

So I guess that freshmeat.net and SourceForge are run by Java-loving dweebs? Check their language stats sometime...

Would you point me to bigger open source repositories?

Re:Maybe because it's slow ?

[bwt]

But the reason it is uncool is because, outside of stuff written just for Java monkeys, there is no Free software to speak of written in it. Free software is written in C (65%), C++ (25%), and Python and Perl (all but the last 1%). Free Software coders have avoided Java for lots of reasons, including its not-really-portability, its bad performance, its hasty and stupid language and library design, its corporate 0wnedness, and their own resistance to hype and idiotic jargon.

Bullshit. There are 12436 projects on sourceforge.net in the java language folder. C and C++ each have barely more (13254 and 13440 respectively). PHP is fourth with 9201 followed by perl with 5321. Your percentages are crap. Java is more than double the popularity of perl there.

Where did most open source Xtreme programming innovation happen? java (JUnit, Ant, Maven, etc...)
Who has the best open source MS Office file format compatibility? java (POI)
Who has the best open source search engine? java (Lucene)
Who has the best open source MVC middleware solutions? java (Struts and/or Velocity)
Who has the best XML tools? java
Who has the best gui test editor? java (jEdit) [and yes, vi and emacs both SUCK]
Who has the best foss XForms implementation? java
Who has the best open source SVG implementation? java (Batik)
Most actively developed open source IDE? java (eclipse)

Frankly, most of the real innovation that is being done in the open source community is being done in java. Stroll on over to Apache Jakarta project and look around for a while.

Java is cool

[Cyno]

But what advantages does it have over Perl, Perl 6 and Mono/C#? I already know Perl and Perl 6 should be easy to learn, but if it need more from a bytecode interpreted language I'll look at C#.

I also wanna learn OCAML and C/C++ and some assembly. So I don't see how I'm going to find time for Java in the near future unless Sun decides to GPL it to give me more incentive.

Re:VB is not idiot proof

[faragon]

Yes, VB it is a clear management idiot proof.

some comments

[stevedekorte]

"Java has considerably fewer surprises..thereby resulting in a language where you cannot really make your friends go ga-ga at amazingly brief programming construct"

The real problem here is that C++ is a mess. "fewer surprises" here means that it has largely inherited C++'s mess. Java's verboseness is the product of putting in too much, not too little.
"Java has been considered slow for ages." [but isn't now]

It's true that the newer Java compilers do well on benchmarks. But it still *feels* slow when I sit waiting for 60 seconds for a small Java applet to start up or when my machine starts paging because a swing applet eats up 100s of megs of memory.
"Java is a strongly typed language therefore you have to tell the compiler exactly what you intend to use. And if you make a mistake in the way you use it, the compiler has the guts to tell you that you were wrong."

The problem here isn't about developers not wanting to know about their mistakes, but that strongly typed languages make it impossible to cleanly implement (and sometimes to implement at all) powerful dynamic design patterns.
"Java has a vast library..."

Java's APIs are it's weakest point. They are horribly complex. I once had to work with the Java Advanced Imaging APIs. IIRC, it has over 300 classes and yet functionally wasn't significantly more usefull than Cocoa's 3 image classes. Whenever you need to get at anything (say you wanted to change a pixel), you had to use a dozen classes. There are even classes that you have to instantiate to create parameter lists in order to pass to the instantiation methods of other classes. While not this extreme, much of Java's APIs seem to suffer from a similar explosion of classes and complexity.
"Java is popular. Anything that is popular has lost its elite status and therefore is not cool."

So Coke, Nike, Doom3, the PS2 and the NBA aren't cool?
"Java is an application programming platform. You cannot do cool things like device drivers and games, etc (until recently - but Java gaming is coming in a big way)."

AFAIK, Java fell flat as an application programming language. Today it is primarily used a server scripting language, just like the "cool" languages that Paul Graham mentioned, such as Python.

little projects

[bobo the hobo]

most hackers like to whip up chunks of code to accomplish small tasks. java is terrible for little hacked together projects. nothing is more annoying when you're trying to write a 100-line program than being forced to handle exceptions that you could care less about.

Re:Maybe because it's slow ?

[logicnazi]

What you can do is to *save* your interpreted code fragments. I know of at least one project that used this method essentially identifying small program segments and compiling these segments into native code.

I simply don't understand why Java programs don't do this and take advantage of the information they gather each time they run. In this manner you can actually make a *faster* app in an interpreted language sometimes because the interprater/compiler can benefit from the run-time performance of the program (i.e. better branch prediction etc..).

However, as a matter of fact I don't think java interprators save all this usefull state data. Why, I can't figure out.

Re:Maybe because it's slow ?

[Phleg]

A couple of guys (I can't find the link) ported QuakeII to java to get this statistic.

This is a bit misleading. They implemented parts of Quake II in Java, but had not ported the entire application. As I read it, much of the more advanced AI aspects as well as graphics features had not yet been converted into Java.

As a Language Geek...

[cgreuter]

As the fortune file puts it, "A language that doesn't affect the way you think about programming is not worth knowing."

Learning C was a mind-expanding experience for me because it let me do anything I wanted and because it taught me about self-contained functions. Learning Smalltalk was a mind-expanding experience because it was this giant, full-featured language built out of a few simple principals. Learning Perl was a mind-expanding experience because it was this hideous, misshapen monstrosity of a language where every single wart turned out to make my life easier. Learning Lisp was a mind-expanding experience because you could extend the syntax of the language itself from inside the language.

And Java? It's basically just C++ with some of the better ideas from Smalltalk (or Lisp, Eiffel, Sather, Modula-3 or whatever) grafted onto it. Been there, done that, got the T-shirt.

That's not to say that Java isn't useful--it is. It's just not exciting. There are jobs for which Java is the right tool and some of those are even interesting from a hacker's point of view. It's just that the language itself that isn't interesting.

The only time I consider brushing up on my Java skills again is when I'm looking for a job.

(As an aside, my take on Paul Graham's comments is that if a company is looking for Java programmers, it's a bad sign because it means that the suits are making technical decisions. I'm inclined to agree with that--if the company is run by people who think Java is cool, you have to wonder what other kinds of decisions they are making.)

Disclaimer: I've done very little in the way of Java programming, although I did once write a compiler for it.

Re:who cares what he says?

[alex_tibbles]

Windows 3.1, Windows 95, Windows 2000. The most successful software product line in history. Each was an almost complete re-write. Each re-write was necessitated by the predecessor being un-improvable (and no-longer-adequate). If we are talking market success, being re-written is a sign of success, not failure (since being funded to be re-written requires that the product made some money in the first place).

My favorite example

[metamatic]

In Perl, if I want to do something, I do it. It takes a line or two of code, and I'm done. In Java, to do something I have to prepare for it AND do it. I often have to create from 1 to 3 objects to finally get the object I need, then I can finally do what I wanted to do.

My favorite example of this is trying to write Java code to produce a datestamp in RFC2822 format. For example, Tue, 24 Aug 2004 16:09:23 -0400. Obviously this is something you want to do all the time when programming Internet stuff, and at least up until Java 1.4 it's ludicrously difficult to do. I usually cheat and force all timestamps to UTC to at least cut the code down to size a bit.

Perhaps some Java enthusiasts would care to try and come up with the shortest, simplest implementation of rfc2822DateStamp()?

package management

[perlchild]

I posit that the dependency tree for most java engines under most software distributions is too erratic right now, and not unified enough to encourage Java for the lazy programmer who doesn't want to depend on a software packaging specialist.

Software packaging specialists usually look at Java and faint(despite new inroads both by projects like InstallAnywhere and jpackage, which are definite improvements).

I can't wait for java package writers to automate package building the way dh-make-perl does on Debian, perhaps then people will see whatever power is in the language.

In the meantime, the work of getting say 15 java packages(including a jvm) on 50+ machines is a major undertaking using native system tools(meaning using scripting languages like perl to download a zip file on windows is cheating...)

How many cross-platform java developers can build .msi AND .rpm or solaris .pkg for their platforms? Sure server environments will have specialists to do that, and for-sale software as well. But for free software advocates, that's a strength of the language turned into a weakness. You support multiple platforms, but you have no control over their policies and practices, so you end up with more work.

Now I'm not saying multi-platform java is bad, but I'm saying that Java could use a page from Debian's packaging book along the way. Managing/upgrading software, and tracking dependencies is an important task that affects developers directly, and most of them are specialists... in something else. Giving them tools(CPAN comes to mind, as a resource, but without structure, it helps less than it could), becomes a must. Being able to make re-distributable packages without a java ide OR reading a manual would help too. (Jars are libraries, not packages, in my book, they do not register with the system to simplify removal, and they can be bundled together for dependency reasons, that excludes them from the "package" definition.

Does this do anything to make Java cool? No, Java is already considered a "barebone" language, it can't be cool anymore, at least in some circles, it does all the good things, and it has no quirky restriction that would limit it to an elite. Can it be a good, useful language yes, can it be used in a bunch of situations? Yes
Cool? Java doesn't really want to be cool, it's disruptive to businesses.

Re:who cares what he says?

[koali]

If you are talking market success, point me to a few other significant Lisp-run websites, please...

Java is simply bad

[ksc]

Java is uncool for many reasons:
- When it first came out, there were memory leaks ALL over the place.
- Java is still sluggish.
- Most Enterprise-level Java apps are really, really poorly coded, hangs often and are extremely sluggish.
- There are STILL memory leaks ALL over the place. - Java is overused.

Re:Maybe because it's slow ?

[chris_mahan]

Oh, actually, I agree. I personally looove jEdit, and that's all I use anymore...

Yet, for bootsptrapping, it's python for me.

Good example

[TheLastUser]

I'm sure that there are a lot of interesting web apps written for 8-bit processors.

Re:Maybe because it's slow ?

[molarmass192]

The real problem is that Java encourages lessor coders to do the work

You won't get any disagreement from me there. I think of this in the same lines as VB, it allows people who shouldn't be coding to get away with murder. Honestly, I think VB/VBA is even more accomodative towards poor coders since the language isn't even strongly typed.

Java is absolutely awful for the enterprise

[biggerboy]

Java is still too low level for the enterprise. As for encapsulating business logic, it requires too much programming to get any of it done.

That's why people are still using (today!) Cobol, and the most successful large enterprise vendors have gone to developing their own 4GL-like environment and develop in those toolsets rather than Java.

anonymous type is strongly typed?

[joe_plastic]

I dare you to find a list implementation in any type-strong language that doesn't require an upcast in this situation. You need it to be able to store objects of an anonymous type on a list.
c++ using the stl doesn't need it, because their lists are stronger typed than java's.
std::vector<char * > l;
l.push_back("A String");
char *s=l[0];
Look no casts required - anonymous type doesn't sound like strong type to me.

Just like with C

[pommiekiwifruit]

You should put all your DLL files into c:\windows\system32, since that is on the path. Nothing could possibly go wrong.

Re:Just like with C

[That's Unpossible!]

Don't be a smart ass.

- You can have multiple JREs if you need them.

- You CAN specify jars with classpaths if you want.

I was offering a simple solution for someone who doesn't want to keep adding new jars to his classpath to run programs. I didn't say it should be used in all situations.

I don't think Java is that un-cool anymore

[rspress]

In the beginning Java was billed as all the things it was not at that time, fast, fully cross platform, stable. Most of those problems have been tackled and most Java programs are OK in my book. Some my still say it is slow but as an OS unto itself it loads much faster than a bulking Microsoft OS does.

I think Java would have been farther along and a lot cooler if Sun had not made a deal with Microsoft to screw over Java. MS has done more against Java than they ever did for it and sun took it in the ass on that deal. I think that Java is just now emerging as to what it was intended to be. A cross platform programming environment. I actually use several Java programs that are fast loading and they get the job done. Thanks to those using linux we now have decent Java programs. With more people turning to Unix everyday I look forward to more and better Java programs in the future.

Java as a language vs as a platform

[Master Of Ninja]

I don't dispute your post. But most of this is because Java is a language and a platform. Yes there are many benefits to Java, and the language is great. Its just that there is so much additional unusuable crap that, while the server programmers love it, desktop users have come to hate a lot of Java and its poor performance compared to the rest of the desktop.

Re:who cares what he says?

[alex_tibbles]

orbitz.com (running http://www.itasoftware.com/) for one: see google groups.

Things that suck about Java and things that don't

[cbare]

Things that do suck about Java:

• Difficult to do very simple OS specific stuff, like opening an html doc in the default browser.
• Takes a long time to start up the VM. If your program is trivially simple, the overhead dominates over actaully running the program.
• The Swing and AWT mess. It's gotten better, but I think Sun made some fundamental mistakes right at the beginning and they are unable to acknowledge these mistakes and unwilling to start over and do it right. They're a server and OS company. What do you expect.
• It's a lot harder than it should be to call natively compiled code from a Java program. JNI is a pain in the ass compared to other languages.
• EJBs.

Things that don't suck about Java:

• Ability to cleanly express object oriented software designs.
• Speed. For applications suitable to the language, (for example high througput server-side apps) Java's speed is very good. For tasks not suitable for this kind of language, don't use it. Dont't write the 'ls' command in Java. Most of Java's reputation for slowness is based on people's experience with applets in 1996. Get some updated information.
• Security. Most C programmers think that only crappy C programmers produce code containing buffer-overflow exploits and similar memory allocation bugs. Most C programs do, in fact, contain plenty of these types of bugs. Go figure.
• Maintainability and readability. If that's not something you value, fine.
• Javadoc. Every language should have something like javadoc. A standard something.
• Garbage collection. Run-time optimization. Java's collection classes. Tomcat, Ant, JBoss, log4j, hibernate, JDO, aspectJ, JavaCC, eclipse, IntelliJ, this list could get really long.

What really sucks is senseless language flame wars. If you're smart, (I mean really smart, not just self-agrandizing) it's a matter of choosing a good tool for the job. I would say the right tool, but there's often several good choices, as well as not-so-good choices.

It's interesting to note that Perl and Lisp are a lot alike, not so much in the languages themselves, but in their community. Both feature an intensely loyal following of programmers willing to overlook truely bizarre syntax in exchange for the ability to implement some advanced programming language concepts cleanly and consicely. Both languages are similar in their retention of some very strange artifacts of history: cons, car, and cdr, for example, or the parts of perl adopted from shell scripting languages. Some members of both communities tend to be a little too convinced of their own superiority. But, both languages really do have some cool features.

And remember: If Java is to Cobol what Python is to APL and if Perl is to Linux what Visual Basic is to Windows and James Gosling is to Larry Wall what Elvis is to Hank Williams Jr., can you doubt that we were made for each other?

Common Java Myths

[smackdaddy]

I have to say as a Java Programmer a lot of people end up with slow Java programs cause they are bad programmers not due to the language. Most people think oh Java I don't need to worry about pointers or memory usages it will take care of it for me, and they proceed to write absolute shit for code. The amount that I learned after 2 years of programming the language full time was amazing. You really need to understand what you are doing in the language when are generating garbage when you are doing stupid things like creating a vector with 10 elements and then trying to stick 10,000 objects into it, instead of presizing things intelligently to avoid all the memory copies. I also used to see a lot of stupid things like people copying arrays in for loops instead of using System.arrayCopy. Anyway I suggest people learn how to actually use the language before they blame the language for their own personal inadequiecies as programmers. Of course this is the slashdot crowd so most of you couldn't write more than 10 lines of code anyway. The only complaint that is valid I think is startup time. People should be running the server vm and there is a startup penalty you pay with it, but really if you start your application and it takes 2 seconds it isn't the end of the world considering you will get c++ performance. If you run the client vm you will get faster startup, but poor application speed. Also there are a ton of bad swing programmers out there, who either A don't understand multithreaded programming or B don't understand good gui design, or even worse both. I suggest people spend some time on JGoodies Website to learn something about good looking swing UI's.

Re:who cares what he says?

[koali]

Woo-hoo!!! That makes two. Well, one if you consider that Yahoo Stores moved on from Lisp...

casts

[pommiekiwifruit]

The difference between a strongly typed language and a loose one like Java or BASIC (using Variant for all variables), is that the type can be checked at compilation time, instead of maybe possibly at run-time. This catches errors early, and is also more efficient. Java only supports heterogeneous collections (well, homogeneous collections of hidden pointers to objects), whereas in the majority of cases you need collections you should use homogeneous collections. If you intend to have a list of strings you should be able to say so, and the compiler should be able to check all references to the list and ensure the type is correct, rather than leaving it to the run-time library.

Re:casts

[Canberra Bob]

"If you intend to have a list of strings you should be able to say so, and the compiler should be able to check all references to the list and ensure the type is correct, rather than leaving it to the run-time library."

Which you can do as of Java 1.5

Re:Maybe because it's slow ?

[the quick brown fox]

You are aware that there exist garbage collectors for c/c++?

Yeah, I alluded to that at the end of my post (in my book, "automatic memory management" == "garbage collectors").

Also, in the example you give, you can know that a virtual method is never going to be overridden before runtime, you do need to link your .o files tho, so it is after compile time. THere is however no theoretical reason why you cannot decide at that time to recompile a bit of code to get the exact same optimizing as you could with java.

Can you do that if your output is a class library (.dll or .so)? This is an honest question.

No such thing as language of the masses...

[wtoconnor]

When will people get over this idea that there is or even should be a language of the masses. The masses just want there shit to play music, watch their video or view porn. They do not want to have to program the machine to do it.

Answer to REASON 1 is NOT

[wtoconnor]

Java is not considered to be a write once and debug everywhere laguage for nothing.

Re:Answer to REASON 1 is NOT

[kaffiene]

I've developed Java programs on Linux for use on windows and solaris platforms for years and *never* had a problem with running cross platform.

The 60's called; they want their technology back.

[uid8472]

Java is a strongly typed language therefore you have to tell the compiler exactly what you intend to use. And if you make a mistake in the way you use it, the compiler has the guts to tell you that you were wrong.

Leaving aside the fact that static typing and strong typing are not the same thing, there is more to life than FORTRAN vs. Lisp. Take, for instance, type inference --- which, at 20-odd years old, seems to be a little too cutting-edge for industry.

Re:Maybe because it's slow ?

[SpootFinallyRegister]

first off, data spread liberally over an address space does not ruin cache locality (unless you have a stupendously huge cache). learn how a cache works.

however, even if you were right about how a cache worked, youd be wrong in the argument. first off, malloc implementations usually scatter data just as much. though malloc can be implemented to stick all the data it can towards one end of the heap or the other, this results in an unacceptable level of heap fragmentation, and more wasted memory than you can shake a java-object-header-on-a-stick at.

also, most JVMs implement compacting garbage collectors. this means that most objects that have been around for a while end up very nicely packed into one contiguous area of memory -- something you wont ever get from C/C++, or any language implemented using malloc for allocation.

it shocks me that so many people who dont like java can only ever spout pseudo-facts about bad performance to bash on java; especially when there are so many actual barriers to using it in many situations. thank god you at least touched on lack of good, widespread VMs for portability.

and btw... its probably a bad idea to bash something for corporate 0wnedness in the same paragraph that you bash it for lacking market penetration. tsk, tsk.

Re:Maybe because it's slow ?

[jrivar59]

Here's sourcefore project percentages by language type, for types with 1000+ projects.

Name Count Percentage
Assembly 1235 2.15%
C 13285 23.10%
C# 1717 2.99%
C++ 13440 23.37%
Delphi 1525 2.65%
Java 12436 21.63%
JavaScript 1868 3.25%
Perl 5321 9.25%
Python 3316 5.77%
Unix Shell 1480 2.57%
VB 1876 3.26%

Total 57499

Stuiped lameness filters, i give up.. So correction:

C (23%), C++ (23%), and Python and Perl (all but the last 21%, which is java)

pointers

[khold]

How about C++? When you make a new object in C++, are you saying the fact that the new object is referenced by a pointer is bad?

Re:Depends ...

[mad.frog]

There are thousands of developers that would disagree with your myopic viewpoint.

No need to get personal here. There are thousands who would agree with my "myopic" viewpoint as well.

Why waste time building an application that is going to be bullet proof - when you will only use it once or twice or for a clearly defined purpose?

I contend that these are not mutually exclusive. Static type checking is not a detriment to "quick and dirty" programs, and in fact, is even more helpful in such cases, because it's less likely that extensive testing will be done on them.

Platform independence is overrated...

[Kazoo the Clown]

Java is uncool for some of the same reasons that X windows is uncool. Too much time is spent on capabilities that most users don't care about when they could have been spending that time on capabilities users DO care about.

Platform independence is for the most part, a convenience to the creator or marketer of the program, not the user of the program. With relatively few exceptions, users generally only want to run a program on one computer. Even if they have multiple computers, they usually have them configured for different purposes.

I learned something important years ago in the Apple II/Atari/C64/Amiga, etc. days when video games for home computers started to become multi-platform. What I learned was, if you buy games that run ONLY on your particular platform of interest, they'll be more likely to take full advantage of your platforms specialties, which is why I bought the particular platform in the first place. The least-common-denominator phenomena really divided the GREAT games from the mediocre ones. As a user I noted which games were multi-platform and which were single-platform, and it was the single-platform games that made the best use of my hardware. Guess where I spent my money?

Today, despite claims to the contrary, computer language still matters. Not many programs are written all in assembly language anymore, but if I come across one, I'll certainly take notice. Such programs will be blisteringly fast and have a very small footprint. No matter how much CPU power and memory you have, there is always a benefit to making something smaller and faster. And while few programs are in assembly any more, the OPPOSITE extreme is Java and .Net, and as soon as I see a program that seems like it may be interesting but I find out it's written in Java, I now tune it out as a matter of course. Slow, glitchy, incompatible, THAT'S ALL I'VE EVER SEEN in Java. Of course, I don't keep a finely tuned latest-rev-level Java VM on my system which probably would make a difference, but that's not what I want to spend my time doing. Developers who do, immediately make themselves completely out-of-touch with their user's experience and consequently, can't see what the problems are.

All Java developers should have a low-powered PC configured with the oldest and buggiest Java machine they can find, and run all their apps over the net using a 56K modem. Then they may have at least some idea how their app may be running out in the real world...

Re:Which links against what,

[NoOneInParticular]

Don't know about BSD but under Linux you link against glibc (LGPL), under Windows (mingw) you link against mscrt.dll (MS EULA). In both cases you can distribute your hello world code binary only, as long as you don't change either glibc or mscrt (ha!). I guess something similar holds under BSD.

Re:Maybe because it's slow ?

[Glonoinha]

Or you could just say fuck it and allocate stuff all over the place on the heap and just leave it hanging out there as objects get created and forgotten.
Based on the code I just inherited at work that's perfectly acceptable, I'm just saying.

Re: bogus SF.net statistics

[Euphonious Coward]

It's true that there are lots of Java projects on sourceforge. Of them, though, how many are just wankage for Java monkeys? Of the rest, how many are real projects, and not just a cute name and no code?

The latter is the real problem: by far the majority of projects on sf.net are empty shells. To tell what real Free Software is written in, you have to identify the software that is really being used, and then not just count projects, but count lines of code (or, better, kbytes of object code). Of course, that's work, and hasn't been done since RH 7.1 was current. Even then, the raw numbers count all the Java wankage.

So, try to think of Java programs that are used by anybody but Java monkeys, and that work. No, Eclipse, Jedit, and web server add-ons don't count. What are we left with? Some Windows bittorrent client? Anything else out there? Hello?

Re:Yes, FOUR

[narcc]

3. Assembler (not really a language, but what the hell).

Definantly not a language. You might have been thinking of "Assembly".

Then again, maybe you weren't...

Re:Maybe because it's slow ?

[SillyNickName4me]

> Can you do that if your output is a class library (.dll or .so)? This is an honest question.

First of all, it is purely theoretical, I am not actually aware of a compuiler doing this automatically but I have done it manually as a result of verbose compiler output a few times.

It is something that you can do well for anything that you have the source for and that is statically linked into your binary. You cannot do it that easily if at all for something that is linked dynamically, if only because in that case the actual linking happens at runtime, so after you do your optimizing, while compilation is completely independent of your project.

You could include a .so or .dll in your project and try this, but it will very likely break whenever some other binary tries to use this shared library, so not a good idea at all.

So, not for shared libraries, but if you build statically linked libraries specifically for this project you can.

What this of course gets you is a situation where if you have a shared library that implements a class with a virtual method, the runtime environment cannot do anything with the knowledge that it is not overloaded. This of course is different when running JAVA in a JVM.

If you were to run C++ in a VM, you would not have this limitation either, while if you were to run JAVA compiled to a native binary you would get the same limitations.

Java is NOT slow!

[SlashSpam]

One of the reasons that some consider Java uncool, is because of the myth that Java is slow. I call it a myth, and I will try to explain why it is a myth. (Actually, in theory, Java will outperform C++ soon).

Just to take a swing at another myth, while we're at it: When it comes to size of the stack, how you want the garbage collector to use memory etc., you CAN in fact give the JVM parameters to control this stuff.

Java isn't slow anymore. It may be true, that (small) Java applications generally takes a little longer to start up, if you didn't use an AOT compiler (like for instance the "free as in freedom" compiler GCJ or the more mature but proprietary Excelsior JET). Its true that early versions of Java were slow, but 1.4.x isn't generally slower than C++, in fact, I wouldn't be surprised if it outperformed C++ on general terms one of these days.

One of the things that makes Java "not slow", is actually the way memory is allocated. Its rather cheap to allocate memory in Java, compared to other languages, and its even cheaper to "free" memory, since you don't do it, you have the cost of the garbage collector instead. The garbage collector in Java is very fast, compared to older garbage collectors.

(For the interested, IBM has an article on "garbage collection in the HotSpot JVM", and another article that explains various garbage collection techniques, and finally they have an article that covers performance concerning garbage collection. They have a lot of other interesting articles, but I don't want to list all I know, if you like to check it out, here is the search I used to "refind" these articles.)

I make the claim that Java isn't slow, but don't just take my worth for it. (Not that I think you would). Go search on google or whatever. A word of warning though .. since older Java's were indeed slow, do note the version of the Java tested. It should be (at least) 1.4.x. I don't think 1.5.x is stable yet and I dunno if its faster or slower, but 1.4.x have a real nice enhanced garbage collecting subsystem. (Esp. 1.4.2 and above).

(On purpose, I didn't go for SUN benchmarks, as they might be (considered) biased, but sun does have a word to say about "Java Performance".)

Here is a couple of quotes from an article that considers performance of Java vs. C++, analysing some benchmarks of Java, C++ and other languages. While the article was updated this year, I was still unable to find a link to a benchmark diagram of the current 1.4.x JVM. It seems though, that the 1.3.x wasn't too slow, even without latest optimised GC-subsystem, which is one of the key factors that makes 1.4.2 faster.

Here are the quotes:

"Five composite benchmarks listed below show that modern Java has acceptable performance, being nearly equal to (and in many cases faster than) C/C++ across a number of benchmarks."

"Java is now nearly equal to (or faster than) C++ on low-level and numeric benchmarks. This should not be surprising: Java is a compiled language (albeit JIT compiled)."

Re:Java is NOT slow!

[Mybrid]

So a level of indirection is free?

Java -> VM -> system call
C -> system call

What computer science class teaches this?
There is no such thing as a free lunch.

The stack is always faster than the heap. A C program that doesn't use the heap will be most efficient.

Garbage collection defeats OS memory paging by moving memory pages antagonistic to the OS memory paging algorithm. Until the garbage collector is instrinsic with the OS that will always be the case. When the OS provides garbage collection then C will dominate again because it doesn't have to go through the VM.

Java programs are peformance opaque. In fact are arguably performance inhibited based upon differing JVM implementations. Java running in IBM's JVM for WebSphere may run far different than Java on Windows or with Sun's JVM. Does your JVM use kernel threads for garbage collection? What if it doesn't?

Re:Java is NOT slow!

[mabu]

Dude, saying "Java isn't slow" doesn't make it run any faster on the 5 different machines I have.

Keep saying that over and over if you wish. It doesn't change reality, but it may get you a job offer at Fox News.

Re:Java is NOT slow!

[SlashSpam]

Thank you for the input, its always nice when people provide arguments instead of merely saying "I disagree", or even "you're wrong", like seen in other posts here on /.

Without getting into more technical detail, than I can manage right now, I have a few comments on your post.

Mybrid wrote:

So a level of indirection is free?

Java -> VM -> system call
C -> system call

What computer science class teaches this?
There is no such thing as a free lunch.

Lemme start pointing out, that your argument stands, for Java JVM's around 1995, which is still used in some older browsers, to interpret applets on websites. That being said, I want to make a few corrections to bring us up to date:

Java HotSpot JVM, is a not only an interpreter, its also a compiler; a JIT compiler. A JIT compiler is a Just In Time compiler, which means that it runtime discovers which code needs optimising the most, and then compiles it. The JIT compiler usually uses a cache on the disk, so when it has run your program once or twice, it has already compiled the stuff that needs it. Thus, your programs gets faster by use.

In case of C, its by far most common to use an "AOT-Compiler". AOT == Ahead Of Time compiler, a compiler that produces bytecode or machinecode from sourcecode, like Java or C. The bytecode in C's case, is usually platform-dependent machinecode, while Java is generally transformed into "Java bytecode", which will then be taken care of by a JVM. Note: There is nothing hindering a compiler transforming C-code into Java-Bytecode, or Java-code into machinecode. In fact, as I pointed out earlier, there are more than one AOT-compiler available for Java, Excelsior JET even offers a "Mixed Mode", where most of your code will be compiled to machinecode, and code that for one reason or another isn't convenient to compile, is interpreted, and/or JIT-compiled).

Java:
======

Step 1:
Java source -> AOT Compiler, (AOT optimising) -> Java Bytecode

Step 2:
Bytecode -> JIT compiler (runtime optimising) -> Machinecode

Step 3:
Machinecode -> System call. (Some code will be interpreted by the JVM)

C:
===

Step 1:
C source -> AOT Compiler, with AOT optimising -> Machine code

Step 2:
- Nothing, we already have the machine code -

Step 3:
Machinecode -> System call

While you might be a very efficient C programmer, and write fairly good optimised code, its not like that for all programmers. Esp. when working against the clock, many tend to write code that might be a bit sloppy, but "does the job". This is where Java in my opinion really has an advantage: The compiler is a "JIT" (Just In Time) compiler, which means the code is compiled while its running, and further more, only code that the VM assumes is worth it, will be compiled. What is really interesting here, is that the compiler at this point will have runtime knowledge of the program, something a common C compiler wont have. This enables the compiler to optimise better, utilising the runtime info. (Which loops are heavy-duty, and should be unrolled, which loops are merely used, etc.).

Now, I wont make the claim that really well written C-code, optimised in every corner, and compiled for the specific platform where the code will run, is slower than Java. In fact, I'll assume that it will in general terms be faster, depending on the task (as I mention in my earlier post, memory allocation is generally cheap in Java, but of course, you could optimise C for this as well, even though it might be quite a dazzle.) The point is, you might gain very little from a great effort in C, since you might have to emulate the advantage of having a clever garbage collector making memory allocation cheap! (Read the next section for details!)

Let's get to the juicy stuff!

Re:Java is NOT slow!

[SlashSpam]

Dude, saying "Java isn't slow" doesn't make it run any faster on the 5 different machines I have.

Well, personally I think I made more than one argument as to why I think that Java being slow is a myth. I even provided links to benchmarks and articles analysing the performance of Java.

It seems to me that you're simply biased against Java. I dunno if you really have 5 different machines running applications of poor performance, but mind you, it is possible to write slow code in just about any language - even Java!

If I got it wrong, and you're really sad about the performance of your Java applications, maybe you want to take a look as these Java performance FAQs in order to try and improve the performance of these applications.

/Spam .

Re:Java is NOT slow!

[mabu]

It seems to me that you're simply biased against Java. I dunno if you really have 5 different machines running applications of poor performance, but mind you, it is possible to write slow code in just about any language - even Java!

You sir, DO have a point, and quite a poignant and significant one at that.

Any developer foolish enough to choose a language because it's "cool" regardless of whether it's the most suitable language for the application at hand, is in all likelyhood going to be a lousy programmer. Therefore, that would back up my contention that I've never seen a stable Java application that performed worth a shit. It's not necessarily the language. It's the programmers.

Of course, this still doesn't explain what Java is good for, besides getting a job with a company that's a slave to tech-fashion.

Re:Maybe because it's slow ?

[BasilBrush]

Declaring variables - In Java can only declare them at point of first use if they are local. Not class member variables, then you need to scroll to the top of the class declaration.

Polymorphism can be a performance hog with what language? My point is that in Python you can always hack an existing class from the outside because you can arbitrarily hand extra member variables off a class, or even off a single object of a class, and no data is private, so there is nothing you can't touch from the outside. None of this is performance hogging, it costs no more than if it were done within the class.

Your description of juggling data was pedestrian compared with the kind of data juggling I was talking about. I'm talking about complex manipulations of complex data structures in memory with a very few sparse lines, and no need to use libraries.

I certainly don't agree that all languages were born equal. That's as useful as saying every person is born equal. In some ways they are, but every person is better in some skills than others, just as some languages are better in some problem domains than others. There is no doubt in my mind whatsoever that Python is a quicker and more pleasurable hacking and prototyping language than Java - provided you are not doing a GUI prototype. It's also very suitable for in house production code. But for commercial production code, I'd go with Java or C++, depending on problem domain.

Have you tried coding with Python? I can heartily recommend trying it if not. Yes, I've tried Java, but never got that deeply in to it. But enough to know what problem domains it's best for.

slow? perhaps, but..

[arudloff]

is it cheaper to buy a faster system, or develop something in c?

time is a resource thats more valuable than memory and processors..

Re:who cares what he says?

[silentbozo]

I never said that I can't understand Lisp, only that my code tended to be undreadable (at first glance) after a while when using pico to do my text editing, when working on a large program (the 80 char wrap on the terminal I was working on did not help.) Everything was UNIX command line in the classes I took, which made the edit, load, run, and debug process rather tedious - at least to someone who was used to coding in a GUI ide.

I'm quite proud of the fact that I learned Lisp, and that I learned it the RIGHT way (ie, using recursion). Lisp is quite elegant, but it takes some thinking to code simply - a good form of mental training, no matter what language you code in.

Re:No

[Bastian]

That is NOT what reference books are for. Or at least, that's not a very efficient way to use them, even if it's often how you have to learn a language. Reference books are really for when you are already familiar with a library/API and you have a general idea of what you want before you're looking it up, or when you just need to brush up on something real quick.

If you don't have that pre-existing degree of familiarity, you're likely to do a lot of useless programming based on assumptions and instincts that are not applicable to the current platform. You put time into setting things up expecting the API to expect one thing, then you look in the reference guide, see that it wanted something else, and have to go back and retype a few lines of code.

Yeah, it's only a few lines here and there, but they add up until eventually it probably would have been cheaper to just code the thing in xxx less Perfect For The Job(tm) language from the beginning.

The issue is not that people shouldn't switch languages, ever. The issue is that if two languages, APIs, whatever are close enough in capabilities, it's a waste of time to go switching languages every time one fits the task better.
Let's do one from the classic tools class of analogies: Let's say I need to open a box that's taped shut. I have a choice of doing it with a box cutter that's sitting on a table on the other side of the room, or my house key that's in my pants pocket. Yeah, the box cutter may be custom made for the job and all, but I'll use the house key anyway. It takes me less effort to pull the key out of my pocket and mangle the box open than it does to get up, walk across the room, get the box cutter, and come back.

It's the same with languages. If there's one that I'm used to but isn't just perfect for some small job, I'll still use it if I'm not just really familiar with some option that is generally better, because it will take me less effort to mangle the solution together with the language that I'm a pro at than it will to use the Better Option(tm) but have to lean on a reference guide the whole way.

This has nothing to do with how a Real Programmer or a True Hacker would do it (re: a suggestion from an AC a few levels back on the discussion). It has nothing to do with pride, or ideals, or what the boss tells you to do. If you have to go with what the team says, or you have to nurture a sense of geek honor, or you want to learn a new language, or whatever else, go for it. I end up doing that all the time. I'm just saying what the path of least resistance is assuming there are no other circumstances.

Re:Masses? hat Masses?

[reallocate]

Yeah, your're right. My braincells were dozing.

I remember writing something to aggregate and analyze the results of a survey conducted by the weekly newspaper where I worked at the time. I wrote it at home, in my kitchen, on my trusty Commodore 64 using the BASIC Commodore bought from Microsoft. I.e., one of the predecessors to GWBASIC. It was also, effectively, the OS for the C64. Lotsa line numbers. (Once I got the survey code working, guess who got to do the data entry?)

Re:Maybe because it's slow ?

[kaffiene]

That such obvious FUD (other posters have proved the issue with statistics from freshmeat and sourceforge) can be modded as "Insightful" is an utter indictment on the general /. attitude towards Java. This indicates an unreasonable hatred of Java to the point of telling out and out lies about the language.

I've been a /. member for quite a long time, and I used to think it was quite cool, but now it's just a home for bigots (whether language or OS bigots, I don't care)

Re:Maybe because it's slow ?

[sbrown123]

Find, find me ONE commerically available ( NON-GAME ) application that you can buy at bestbuy, office depot, staples, CompUsa,

MoneyDance and pdf-Office are two I know of. Its hard telling since no one generally advertises what they made their product with. Whens the last time you picked something up at Best Buy that stated it was written in C++?

actually READ some of the links that are as a result the google search

And hey....go use Google yourself. If you want to show me something try posting a link next time. And heres a novel idea: make sure its a working link if you do. I have better things to do rather than follow down 5000+ links or go searching Google because someone else is too lazy to and keeps posting "its in google I swear". Hell, Im sure you can find pictures of a three headed cat out there if you look hard enough kid.

Oh, and about multiple apps within the same JVM...you mean what .NET does right now ? .NET does not have a multi-app virtual machine. You are confusing it with spawning which even Java can do.

At which point we'll be staring at impending LongHorn, where THE OS is .NET-ified, or .NET is OS-ified

Yes, Microsoft will probably install the .NET runtime by default in Longhorn much like the visual basic libraries are today (and still will be in Longhorn). Probably become another gaping security hole. Your point?

Because it is a pain in the ass

[pabtro]

No further comments.

Fortran OSes

[BlueStraggler]

Which OS is written in FORTRAN?

I once wrote for and maintained code for a 68000-based realtime parallel computing system. The individual computing nodes were pretty spare, but they ran Fortran code that was cross-compiled on a VAX, and then loaded into the compute nodes' memory. As a real-time data acquisition system, the application and OS were pretty much the same thing. Fortran is good at array/buffer processing, and the great math and science libraries available for it meant that you could do real data analysis right in the data acquisition stage of the pipeline. That was important for filtering out junk data and keeping throughput down to a level that the tape drives could keep up with.

Object Casting

[magnum3065]

Object casting is not a "feature." It's probably the biggest design flaw I can think of in Java.

The object casting in Java completely destroys any benefits of static typing. Casting does not cause it to fail early. It only fails compilation when you fail to specify the casting. By explicitly performing an object cast in my code I'm basically telling the compiler to ignore the static typing and delay the cast until runtime. When you run the application it's still quite possible to have a ClassCastException.

One line

[semios]

I often bang out a one liner like this:

java -cp $(echo ~/lib/jars/*.jar | tr ' ' :) com.blah.dee.Dah

Re:One line

[graveyhead]

java -cp $(echo ~/lib/jars/*.jar | tr ' ' :) com.blah.dee.Dah

Brilliant!

It's so terse, almost to the point of being glib!

Also, any code that contains a smiley gets like 50000 bonus points :) I myself like this bit of code which has a winky:

for(Iterator i = l.iterate(); i.hasNext() ;) { ... }

You, my friend, have won the prize for most useful and beautiful shell snippet ever posted to /. Unfortunatly, the thread is now so old the mods are long gone :/

Re:Maybe because it's slow ?

[Chasuk]

OFF-TOPIC POST

Does anyone else remember the series by Stephen R. Donaldson, The Chronicles of Thomas Covenant the Unbeliever, and its sequel series, The Second Chronicles of Thomas Covenant?

Well, its being continued in The Last Chronicles of Thomas Covenant, and the first volume (of four) comes out on 14 October 2004! Read an excerpt here

I've submitted this twice, but the powers-that-be aren't well-read enough to recognise it as newsworthy.

Re:Maybe because it's slow ?

[Coppertone]

This is valid Java:

class A {
public methodA() {variableA = 100;}
int variableA;
public methodB() {variableB = 10.0;}
double variableB;
}

But why would you want to do that? it makes things so much unreadble....

When you write code you want to expose certain interface but not everything - I want to keep some variables private so that no one would depend on them when I decided to change the implementation!

Complex data structure is piece of cake in Java - there is no need to worry about pointer, you just need to put all you need as class variables like Python and I find it a lot easier to do complex data structure in Java then in C!

Well Java, C and Perl served most of my need :-) so there is never an incentive for me to try Python....

Java lacks expressive notation

[MetalNoise]

Anybody who likes Java should spend two days with Python or Ruby. I can guarantee your appreciation of Java will diminish.

Java lacks the following:
first class functions(except by reflection, ugh)
anonymous functions, closures (except by using objects), multiple assignment,list literals,list comprehensions, co-routines or generators, multiple dispatch, A decent iterator mechanism (I know wait for 1.5), Templates (I know wait for 1.5).
Even templates, however, in a statically typed language make writing generic functions far more ugly than in a dynamically typed language.

Java forces everything to be an object. I find objects useful sometimes and sometimes I would rather just create a function.

Java makes some things irritatingly more verbose than say Python or Ruby.

Python examples:
list literal:
l = [1,2,3,4]

list comprehension
build a list of squares:
[x*x for x in range(4)] ==> [0, 1, 4, 9]

passing a comparison function to sort
def coord_cmp(c1,c2):
"""compare coordinate 1 to coordinate 2
sort top to bottom left to right"""
x1,y1 = c1 #multiple assignment
x2,y2 = c2
#cmp is built-in, returns -1 | 0 | 1
if y1 == y2: return cmp(x1,x2)
else: return cmp(y1, y2)
#list of coords
l = [ (5, 11), (1, 11), (3, 10), (5, 10) ]
l.sort(coord_cmp)
l ==> [(3, 10), (5, 10), (1, 11), (5, 11)]

#looping
for x,y in l:
print x,y
3 10
5 10
1 11
5 11

#using zip to combine separate lists
x_coords = [1, 10, 20, 30]
y_coords = [100, 200, 300, 400]
for x,y in zip(x_coords, y_coords):
print x,y
1 100
10 200
20 300
30 400

#reading from a file
#python has plenty of file operations, this is
#just a simple one.
f = file('xyz.txt', 'rt)
for line in f:
print line
f.close()

#a generic function. works on strings, ints, floats.
def max(l):
max = -sys.maxint - 1
for x in l:
if x > max:
max = x
return max

Of course max() is already built in

Spend a day reading the tutorial.
http://docs.python.org/tut/tut.html

Checked exceptions & static typing

[Khelder]

Eckel's articles are interesting and thought-provoking. I think he has a great point about testing, and looking at type checking as just another kind of test is a new perspective for me.

But I think he misses a really, really important point about both checked exceptions and static typing. In a data structures class in college, the professor suggested that we think about a program not as a way to tell the computer what to do, but as a way to tell other people what we wanted the computer to do. In this regard, checked exceptions and static typing are a huge help.

I've been a big Python fan for years, and I recently used a big Python codebase for a project. I found it hard to figure out what was going on and how I should use it, in large part because I didn't know what the constraints were on parameters to pass to functions. If they'd been typed, I would have known what methods they needed to implement. Of course, I could read the code, and that's what I did, but it's a lot harder than reading the javadoc (or docbook or pick your favorite automatically generated docs for C/C++ or Java).

Similarly for exceptions: if there are no checked exceptions, then as a user of a piece of code, I have no idea what exceptions it might throw. (Yes, if unchecked exceptions exist, I'll never know when they can be thrown.)

Of course, we could overcome all these problems with documentation. And if you believe that, I've got a bridge to sell you...

Re:Maybe because it's slow ?

[Knetzar]

"C is faster then other languages. If you want speed use Assembly. Enjoy debugging that code and good luck trying to read it in a few months."

Maybe it's just me who thinks that Java may be doing to C/C++ what C did to assembly

I mean think about it...10 years ago programming in assembly was much more common, and C/C++ was used mainly when programmer productivity or portability was more importent then speed. Now the same is becoming true for Java.

Sun an Java

[God of Lemmings]

I don't know if I could say Java is uncool. The debugger is
a pain in the ass sometimes, not letting you do something
perfectly sensible in other languages, but I can usually get around them.

The company itself perhaps...

Didn't Sun recently settle with Microsoft and now they
are doing road shows together?
Didn't Sun buy a SCO license for Solaris?
Have you read the licensing agreement for the Java desktop 2?

Google uses Java = Java is Cool :)

[AgainstHate]

...by the way Google is hiring senior Java software engineers....

Re:Google uses Java = Java is Cool :)

[2mcm]

hmm did ou notice that it isnt google that uses it ..... they are just considering using it for client based applications , but for the servers they use cpp.

FIXED: opening an html doc in the default browser

[PengoNet]

You can now [finally] open an html doc in the deafault browser.

JDIC, Java Desktop Integration Components provide more integration into the host desktop environment: integrating the native web browser, mail, registered document viewing applications and installation.

Includes things like a file browser, tray icons, and Screensaver SDK

https://jdic.dev.java.net/

Re:Maybe because it's slow ?

[logicnazi]

Very nice explanation, however, I don't think it is that applicable to Java. In particular the interpreted language can benefit three ways, either explicit runtime hints to the interpreter (which java doesn't seem to have), passive learning by the interpreter (branch prediction etc.. etc..), and tuning to the particular processor/machine.

While the last really is a benefit java posesses the other two aren't that relevant. In particular Java is going to be slow because most JIT or interpreters I know of don't seem to remember things from one instance to the next. Probably if the interpreter/JIT saved branch prediction information, profiling and even small compiled native segments it would be much faster but to my knowledge no java implementation does this.

Fast Interpreted languages/NEW OS

[logicnazi]

While many people on this board seem skeptical of fast interpreted langauages it really can be accomplished. The problem is that most modern interpreted languages don't bother with these optimizations.

I heard of one interpreter designed to emulate another processor architecture which could sometimes run code for the emulated architecture faster. That is sometimes you would get a speed improvement by compiling the software for the secondary architecture and then running it through the interpreter rather than just compiling it and running natively.

How can something like this work you might ask? Well in the following way. At first the instructions would be entierly interpreted (and thus much slower) but during program execution frequently executed chunks of code would be identified and converted to snippets of native code. Henceforth when this code section was encountered rather than emulating it again control was simply transfered to the pre-compiled piece of code.

This might seem like no better than a JIT compiler but the important difference is that these code snippets and various profiling and branching information would be saved between program executions. Thus after a program had been used frequently it would end up being quite fast, sometimes even faster than native code.

How can this code be faster? A couple reasons. First of all since this 'extra information' was just a local cache it could be optimized to the specific architecture/chip without any fear of compatibility issues (if you find your architecture has changed just whip this cache and go back to interpreting). This means that the code snippets it generates can be evaluated on the machine they run on to see what generates the fastest results (so a program might end up running differntly on a system with a fast memory bus than a slow memory bus).

Secondly real profiling information can make a big difference. Not only does this allow the interpreter to make good branch predictions it allows for a whole new kind of optimization. For instance one might have dynamic loop unrolling where the interpreter has saved code fragments corresponding to 10 itterations of the loop and one corresponding to 5 iterations and one corresponding to 1 iteration. When it realizes it is about to enter a loop with 66 iterations it runs the 10 iteration segment 6 times the 5 iteration segment once and the 1 iteration segment once.

As far as I understand it compared to schemes like this Java interpreters/JIT systems are pretty bad. So long as you don't save a cache of compiled program segments and profiling data you are usually going to be slower than compiling.

Personally, I think this would be a wonderfull concept to design an OS around. The operating system would have a standard virtual machine most programs would coded in...or perhaps several VMs one for java another for mono etc.. Each executeable would have two forks, the first would be the actual code in whatever virtual machine the second would contain a cache of code snippets and profiling information on the current machine. It would also have the wonderfull property that new OS updates could actually make your old programs run faster (better optimization algorithms).

Can someone tell me why this sophisticated sort of technology isn't being used for java? Or is it and I am just missing something?

Two words

[smagruder]

With regards to developing web applications: "Needless complexity" sums it up.

Irony

[still_nfi]

Does anyone else see the irony in a statement by a geek about something that is used to impress other geeks as 'cool'?

Or is it just me?

YES, My apps are restarting

[tlambert]

YES, My apps are restarting.

Of course they are restarting.

As an engineer, what I *do* is write apps, start them, test them, make changes to them, and then ... start them again.

Maybe you are right, that startup time doesn't matter when running applications.

But it sure as heck *does* matter when you are developing them.

Maybe Java is cool for people who run applications? As a developer, I have to say, it's not cool for me. I can't drink enough tea/water/whatever or find enough else to waste time on while I'm waiting for the JVM before I can do more work.

-- Terry

Re:Maybe because it's slow ?

[BasilBrush]

"But why would you want to do that? it makes things so much unreadble...."

In Java maybe. Here's Python:

class A:
def methodA():
self.variableA = 100

def methodB():
self.variableB = 10.0

Nothing unreadable about that. But in Python, you can also do this:

myA = A()
myA.methodB()
myA.variableC = "Hi"

At which point the object myA has both a variableB from the class function call, and a variableC tacked on to it from outside the class. Very useful when hacking. Of course in Java, you could have container class to hold the object and the extra data, or you could could subclass. But for quick experiments this saves time. And of course if a library creates the object itself, subclassing wont help you, and if it's buried in a data structure that the library has constructed a container class won't help you either.

"When you write code you want to expose certain interface but not everything"

Not in a quick hack or when prototyping. Which is what we are talking about as a problem domain. More specifically, when doing a quick hack, you don't want to have to make changes to a library class that you want to leverage. If the author of that class (in Java or C++) hasn't made a certain member variable or function public, you are stuck.

You're missing the point about the ease of juggling data in Python. I know what it's like in both languages, and it's not in the same ballpark, I assure you. If you don't know any Python or Lisp, you won't realise the difference. It can be easier and more natural than Java, I assure you.

"Well Java, C and Perl served most of my need :-) so there is never an incentive for me to try Python...."

Nor me for years after I'd heard of it. Then I had to maintain a bit of someone else's Python code, and I've never looked back. Sorry for evangelising, but it was a great discovery, and like any new convert I want to share... ;-)

Because what we're asked to do with it is crap!

[pkesel]

Java made it's way into the web paradigm. In the last 6 years I've never seen a web or any Java application taken nearly as seriously as anything I've been asked to do in C/C++. They just don't expect you to work as hard in the Java world. Anyone can do it, so it must be easy. If you're working hard at it you must suck.

Re:Maybe because it's slow ?

[GuyverDH]

Simply put.

Hello World - C or C++ less than 60k compiled.

Hello World - Java - Approx 7MB.

Bloat - Absolutely.
Slow - (At startup, or jsp recompile) Absolutely.

Have a crash in a java application - welcome to a nightmare trying to debug it, especially when it's not necessarily in the "application" that was developed, but in the application server, due to someone writing (or building it) on the wrong java version, or with the wrong garbage collection...

It might be more difficult to build an application from the ground up in C or C++, however, usually, in the end, it's a lot more stable.

Performance for an interpretive language, vs. a compiled to native machine code program is night and day.

If you want to write programs that perform functions all day long and need to stay in memory... write daemons.

Add to that the following issues.
Version compatibility.
Between JVM Versions.
Between JVM Vendors.
Implementation compatibility.
Between JVMs.
Between Application Servers.

And now we have even more headaches than when we dealt with simple C compiling issues, imho.

"it's such a language-for-the-masses."

[Dwonis]

"[Java is] such a language-for-the-masses."

....

...p..............

......b...w...

BAHAHAHAHAHA!

Re:Maybe because it's slow ?

[BasilBrush]

BTW, here's a couple of pages that show equivalent Python and Java snippets. They illustrate better than I have been describing how much easier it is in Python to hack something together quickly. And the result is far more readable too.

http://twistedmatrix.com/users/glyph/rant/python -v s-java.html
http://www.pycs.net/users/0000323/web log/2004/04/2 9.html%23P36

Oh sure, Java is great

[Dwonis]

I just happen to prefer programming in C++, Perl and maybe even PHP over programming in Java.

Ever tried to hack together a prototype of something that uses other people's code? For a number of reasons, unless the code you're using was designed to be hacked that way (which never happens), Java just makes it more of a pain in the a**.

Java is case sensitive.

[JoshRoss]

Why should I have to screw around and remember if I declared x or X.

Re:Java is case sensitive.

[cubicleman]

Well, if you follow the conventions, then you would know if it was x or X (member variables always start with a small letter, static final constants are upper case, etc..)

Re:Java is case sensitive.

[JoshRoss]

I can never decide which conventions to follow.

Whoah there, cowboy!

[truth_revealed]

Derivative systems - no big deal. I've worked in telco, supply chain management and finance fields - they are all the same except for the fact that the derivatives-related managers wave more money around, yell louder and have the biggest hissy fits. (And you talk of programmer prima donnas.)

Who do you think writes the very software frameworks that allow your B coder drones to plug away on day after day? Gee, I dunno, could it be... the A coders? You've likely inherited a successful software infrastructure from a buckaroo that came before you and you are merely milking and taking credit for it. And in spite of the great software you inherited it probably takes you six months to roll out the most minor feature and you think it's a huge victory for mankind.

Thank you for keeping the world running. I really appreciate that.

Re:Whoah there, cowboy!

[Edie O'Teditor]

"I've worked in telco, supply chain management and finance fields"

Translation: I still haven't found anything I'm good at. Or even vaguely competent.

Re:Whoah there, cowboy!

[dragongrrl]

"I've worked in telco, supply chain management and finance fields"

Translation: I still haven't found anything I'm good at. Or even vaguely competent.

Exactly. You may also add this line to the Translation: "I'd rather write a cool hack that gives me a boner than have to learn the business or worry about meeting the end-user requirements"

IDE's and Uber-cool languages

[Degobah]

Maybe I'm missing the point, but why do languages like LISP and Python have rather weak IDE's? No disrespect to emacs, but it seems to have stood still in the face of huge leaps in the quality of IDE's for other environments. I believe Java combined with a next-generation Java IDE (Eclipse or especially IntelliJ) can recapture much of the productivity that's supposedly lost to Python's terse syntax. Intelligent code completion gets around Java's rather wordy way of doing things, and refactoring support makes supporting that verbose code a breeze. IntelliJ is smart enough to figure out if you have a variable, what type it is once you declare it and can offer constructors to instantiate it without you having to do all the typing. IntelliJ can even find redundant bits of code and refactor them into a method for you. One of Python/LISP's main attractions is the interactive environment. Java's hot swappable classes combined with IntelliJ's debugger allow you to experiment and play around with your classes while your program is running, all the while inspecting your data structures, having conditional breakpoints, evaluating arbitrary expressions on the fly, etc. Really quite amazing how far java debuggers have come in the past few years. Plus java's remote debugger makes attaching to an already running process as easy as debugging locally which is great for debugging complex server side stuff. Checked exceptions is a big problem for Python0philes. You can get around that in Java by throwing RuntimeExceptions, but some find that sloppy. The right way to avoid having to declare a boatload of exceptions from a method, is to catch low level exceptions and throw a higher level exception (e.g. your library catches IOException, SQLException, throws LibraryException). I've got IntelliJ set up with a template to generate a new Exception with one click and just fill out the name of the exception, and, viola, you've got your higher level LibraryException and you've forever liberated your users from having to worry about an IOException when calling your method and allow them to do more sensible generic error handling. IntelliJ/Eclipse has tight integration with a number of standard tools like Ant (for builds), JUnit (for unit testing), XDoclet (for code generation), as well as plugins for tons of open source projects (by untalented non-hackers, according to the esteemed Mr. Graham) that make the task of getting work done a little easier by keeping you from inventing the wheel. So what you're left with is an IDE that can compensate for Java's supposed weaknesses and lets you enjoy Java's strengths, which have been enumerated by numerous prior posts (Robust Libraries, Strong typing, standardized Unit testing, standardized build tools, platform independence, strong documentation, very few nasty surprises). Which leaves me to wonder why, with all the great productivity and mind expanding power of Python and especially LISP (which had every f*cking feature back in '57 with McCarthy), do we struggle with vi or emacs, several slightly incompatible versions of LISP, shitty IO/concurrency libraries (for LISP), poorly documented libraries that you're not sure will work until runtime and even then may die on you unexpectedly in production when you blindly pass in some unexpected type, with decentralized pockets of apis scattered across the web in various states of disrepair? Java libraries seem to be a more organized affair, certainly from a documentation standpoint (the power of strong typing, checked exceptions and Javadoc are underestimated in my opinion and is one of the unsung features of the Java language) than most Python and certainly LISP libs out there. Why can't there be an IntelliPython, or IntelliLISP. My point here is not to bash Python or LISP or any language. I have done a bit of work with scripting testing with Python (Jython actually) and am making an effort to learn CLISP (from Paul Graham's ANSI Common LISP), if only to deepen my programming knowledge, through "bottom up programming" , macros, functional programming, etc. But, if I'm going to make the effort to learn a new language, I don't want to go back to the dark ages of friggin VI or emacs just coz Paul Graham says I can have better living through macros. It's the tools, stupid!

Static types.

[trouser]

import java.util.*;

class Hooray {
public static void main(String[] args) {
Hashtable h = new Hashtable();
String s = new String("This is a string.");
h.put("fred", s);
Integer i = (Integer)h.get("fred");
}
}

The compiler doesn't pick this up, it is clearly going to throw a class cast exception and it fairly clearly indicates (I hope) why Java's much hyped static typing is no substitute for just learning to write decent code.

Re:Static types.

[easter1916]

With Java 1.5 and the introduction of generics (typed collections) this goes away.

Python/LISP IDE's

[Degobah]

Sorry for the bad formatting, try this one:
Maybe a missing the point, but why do languages like LISP and Python have rather weak IDE's? No disrespect to emacs, but it seems to have stood still in the face of huge leaps in the quality of IDE's for other environments.

I believe Java combined with a next-generation Java IDE (Eclipse or especially IntelliJ) can recapture much of the productivity that's supposedly lost to Python's terse syntax. Intelligent code completion gets around Java's rather wordy way of doing things, and refactoring support makes supporting that verbose code a breeze. IntelliJ is smart enough to figure out if you have a variable, what type it is once you declare it and can offer constructors to instantiate it without you having to do all the typing. IntelliJ can even find redundant bits of code and refactor them into a method for you.

One of Python/LISP's main attractions is the interactive environment. Java's hot swappable classes combined with IntelliJ's debugger allow you to experiment and play around with your classes while your program is running, all the while inspecting your data structures, having conditional breakpoints, evaluating arbitrary expressions on the fly, etc. Really quite amazing how far java debuggers have come in the past few years. Plus java's remote debugger makes attaching to an already running process as easy as debugging locally which is great for debugging complex server side stuff.

Checked exceptions is a big problem for Python0philes. You can get around that in Java by throwing RuntimeExceptions, but some find that sloppy. The right way to avoid having to declare a boatload of exceptions from a method, is to catch low level exceptions and throw a higher level exception (e.g. your library catches IOException, SQLException, throws LibraryException). I've got IntelliJ set up with a template to generate a new Exception with one click and just fill out the name of the exception, and, viola, you've got your higher level LibraryException and you've forever liberated your users from having to worry about an IOException when calling your method and allow them to do more sensible generic error handling.

IntelliJ/Eclipse has tight integration with a number of standard tools like Ant (for builds), JUnit (for unit testing), XDoclet (for code generation), as well as plugins for tons of open source projects (by untalented non-hackers, according to the esteemed Mr. Graham) that make the task of getting work done a little easier by keeping you from inventing the wheel.

So what you're left with is an IDE that can compensate for Java's supposed weaknesses and lets you enjoy Java's strengths, which have been enumerated by numerous prior posts (Robust Libraries, Strong typing, standardized Unit testing, standardized build tools, platform independence, strong documentation, very few nasty surprises).

Which leaves me to wonder why, with all the great productivity and mind expanding power of Python and especially LISP (which had every f*cking feature back in '57 with McCarthy), do we struggle with vi or emacs, several slightly incompatible versions of LISP, shitty IO/concurrency libraries (for LISP), poorly documented libraries that you're not sure will work until runtime and even then may die on you unexpectedly in production when you blindly pass in some unexpected type, with decentralized pockets of apis scattered across the web in various states of disrepair? Java libraries seem to be a more organized affair, certainly from a documentation standpoint (the power of strong typing, checked exceptions and Javadoc are underestimated in my opinion and is one of the unsung features of the Java language) than most Python and certainly LISP libs out there. Why can't there be an IntelliPython, or IntelliLISP.

My point here is not to bash Python or LISP or any language. I have done a bit of work with scripting testing with Python (Jython actually) and am making an effort to learn CLISP (from Paul Graham's ANSI Common

Type system

[3.1415926535]

The one thing that really bugs me about Java that I haven't seen mentioned is its type system. The whole thing seems very poorly designed. To take a particular example, consider the Array:

class A { }
class B extends A { }

public class test {
static void f(A[] arr) { arr[0] = new A(); }

public static void main(String[] args) {
A[] okay = new A[10];
B[] bad = new B[10];
f(okay);
f(bad); // <-- Error!
}
}

How do they deal with this? Runtime type checks! To really deal with this, there should be read-only and write-only arrays, so that you can automatically upcast to a read-only array, and downcast to a write-only array. Oh well.

Re:Maybe because it's slow ?

[dvdeug]

other posters have proved the issue with statistics from freshmeat and sourceforge

They've given a data point, not a proof. My guess would be that the fact that Java is very popular on Sourceforge and Freshmeat, but about 0.5% on RedHat (and less on the Debian survey, but the age of the Debian source count could account for part of that), would be that people learn Java in college and run out and write programs in it, but the people who write the programs people actually use tend to still write them in C and C++, or at least haven't started rewriting old programs in Java.

Flash ??? !!!

[mort_au]

AaAaAJKLR:gh flash backs... flash backs! don't try and develop anything in flash! the code... goes... missing!!.. it just disappears!!!! really! macromedia deny all posibility of this happening - it's very intermittant and we haven't been able to provide a solid test case yet i would find a link about this but i have sort of psychologically blocked out that part of my life it's a joke! stay away!!!

cus it sux ?

[2mcm]

c++ is really quite 1337 to any of that java stuff.
or Visual C++ for that mater.
and of cource c shuder dont even rate agenst good ol
ansi c++ with g++.

Coolness == Abstraction

[Superfluid Blob]

Enterprise-grade apps and "coolness" may be inapproriate bedfellows. Besides, does any language offer both?

That'd be Erlang.

The FA missed the point rather badly, IMO - what makes Java 'uncool' is its lack of support for abstraction. When a programmer finds himself doing the same thing again and again, his first thought is "can I abstract this pattern?". In Java, the answer is all too frequently "no", and the programmer is forced to type in several lines of code to express one conceptual construct.

Sun's big mistake was in not separating the ideas of Java and the JVM more cleanly when marketing it - there are some very cool, hacker-friendly JVM languages (most notably Scala), all of which share Java's virtue of "compile once, run anywhere", but which have got practically no mindshare.

Re:One word - Cygwin

[graveyhead]

YES!!

I was hoping a .bat wiz would come along and show the light! Cheers!

Re:Maybe because it's slow ?

[Glock27]

The startup time is longer because it's NOT Just Loading the Program. The code ( class and Jar files ) are going thru the Byte Code Verifier. Java is checking security and authenticating the code. Verifying that your files Have Not been Hacked.

Nice, but overkill for traditional applications. My OS security (I run Linux for almost all real work) should be sufficient to protect local executables.

When's the last time your exe's were examined for correctness?

When they were compiled. With Java's safety features, most nasty unintentional problems don't happen, period. Further, gcj will compile java bytecode (already verified).

As I'm sure you know, Java programs don't run in a sandbox and can do just about anything to the local system, just like any other program. Bytecode verification won't help if it's out to do something malicious.

If you knew what Java were giving you you'd be very happy with it.

I'm quite aware of (and happy with) what Java is giving me. That doesn't mean I don't want more...like fast program startup and blazing runtime speed.

Why Java is unCool is because Windows Geeks are the Laziest bunch of programmers on the planet, and they do NO RESEARCH on anything other then the Simpleton coding paradiem Microsoft provides.

If you bothered to actually read the article, it's about why LISP programmers in particular, and OSS programmers in general, think Java isn't "cool". Stupid article, BTW - go check SourceForge for how many OSS Java projects there are.

Many "top hackers" like Java, simply because it is a fairly logical evolution of C, unlike C++ which is a mess. Java is well suited to large scale software development, and is quite productive as well. Advantage: Java. How many new LISP projects have you seen lately? ;) Sheer envy is the problem here.

By the way, you .NET Programmers should be KISSING SUN'S BUTT. If it weren't for Sun you'd still be coding in VB6 and Com+.

.NET programmer? Moi? ROFL.

Bzzzzt. Thanks for playing.

Re:Maybe because it's slow ?

[Coppertone]

But then the problem is that I want my prototype to be scalable and usable so that I don't have to rewrite the code after the prototype, or with little modification. I don't see the need for a prototype language - With a good Java IDE (cue Eclipse) I can do pretty much all the prototype easily - so why bother to write in Python to prove that it works then have to move it into another more advance language?

Coolness is irrelevant

[akepa]

As long as it can get the job done efficiently, and someone is willing to pay me to do it, I don't give a damn whether Java or any other language is considered "cool".

The nature of the project I'm working on and the IDE I use have far more of an impact on how much I enjoy programming than the language I'm coding in. I usually enjoy coding in Java much more than in VB not because Java is superior, but because Intellij Idea is much more pleasant to use than Visual Studio.

My point is this

[RLW]

The equality operator should work on dereferenced objects. If there is a need in Java to compare pointers then some sort of IsTheVerySameThing() function could be applied.

The C/C++ derefernce example does not apply. One has a choice when creating objects/structs in C/C++. These objects can be stack variables or heap variables. This makes it more important to specifically require a dereference operator. In Java objects are created on the heap. period. There is no pointer syntax, no dereferencing, no etc... So, the equlity operator should be used as a logical compare not a pointer compare.

Re:My point is this

[angel'o'sphere]

Hm ...

I disagree.

Please go and count how often your own code compares pointers: a1 == a2 and how often it compares contents *a1 == *a2.

90% will be the former. So why changing the syntax? Also I guess you are a C++ coder and don't like Java anyway, so why do you want to mess up the language for the Java coders?

Your proposal makes neither logical nor linguisticly any sense. If you had "==" for content comparision every java class would not eb able to overwrite it. As java has no operator overlaoding. OTOH, if a IsTheSameThing method would exist, you suddenly could mess up pointer comparision by overwriting that mathod, or you would need to make it final. Or even worth you would need to have it in System as static method. Sorry, but yoour proposal makes really no sense.

If you have not enough C++ code then use the Java runtime library and count calls to equls versus application of ==.

When I'm iterating over a container and comparing the object the iterator is pointing to with another object, I ALLWAYS want tidentity and never bitwise equality (except if I'm the author of that container and I'm writing a HashMap).

angel'o'sphere

Re:Maybe because it's slow ?

[BasilBrush]

What you are talking about isn't really prototyping, it's getting a v0.1 version up and running as quickly as possible. Prototyping provides you with a proof of concept, so that the decision can be made whether to go ahead, and what approach to take if you do.

Why did all the great artists do small scale sketches of paintings before starting work on the actual painting?

The quality of a finished app that has been prototyped first, is inevitably higher, and the total development time may well be shorter, because you learn about the problem properly before you settle on an approach to program architecture and data structures. "Write one to throw away" has been suggested in many programming methodologies since "Mythical Man Month". Why not do the prototype in Java? We're back to the issue that you'll hack together a prototype much faster in Python than Java.

BTW, thanks for this little exchange, I'm sure no one else is reading it, but it's helping to put my thoughts on the matter in order.

Re:Maybe because it's slow ?

[lphuberdeau]

I think you should search the slashdot history for benchmarks. Java is not slower in terms of processing, it's even faster in some cases. The only thing is that the virtual machine has to load first and it does consume a lot of memory.

Re:Maybe because it's slow ?

[beowulfcluster]

Azureus uses SWT though, not Swing.

Re:Maybe because it's slow ?

[Dan Ost]

What are you doing with pointers that you don't have to spend any time at all debugging them?

I just follow some common sense defensive programming rules:
- always initialize new pointers
- always check the value of pointers given as arguments
- always check that pointer arithmetic is safe before attempting it
- always check return values before using them
- always fix compiler warnings
- always name functions so that there is no possible confusion about what it returns

But most importantly, once I've determined that a design is too complicated
or too confusing, I take a step back and redesign it rather than just slugging
through it to the end.

Re:Maybe because it's slow ?

[banzai51]

And from every admin and user I've worked with and asked, they hate it. Slow, slow, slow, and doesn't respond like they expect. Just because IBM manages to bamboozel some high level execs, doesn't mean it's a good product.

Static vs. Dynamic, or why Java == C++

[blackhedd]

Java is an evolution of the static programming model also embodied by C++. Java's most important fundamental improvement over C++ is memory management. (I'm going to ignore all the flames about insert-your-favorite-Java-feature here- my point is about *fundamental* advances not incremental ones.) My experience is that this roughly doubles the productivity of a Java team over a C++ team.

Java is uncool for the same reason that C++ is uncool. It doesn't anticipate the way you think about your problem domain, and it doesn't get out of your way. This is both good and bad. By forcing you to be explicit about failure modes and method signatures, both languages facilitate programming by large teams. (This is a feature that is not shared by C, which is arguably "cool" for other reasons.)

Java is also uncool because its syntax is ugly (but not nearly as bad as Perl.), and really prolix. But the prolixity is a by-product of its static checking of your code.

The dynamic languages (Python) and the *really* dynamic languages (Ruby) are far more "cool" because they have a magical way of getting out of your way. They do this by not sweating the details about how you call your methods and raise your exceptions until runtime. That gets to be a problem in a large team when not every developer has the same intuitions about what is to be done, or over time, when your own intuitions change.

Which is better? No obvious answer, but my bias is toward the dynamic side, favoring small teams and tight, relatively short-lived projects. That's where the economic value is.

Re:Static vs. Dynamic, or why Java == C++

[Anonymous Brave Guy]

Java's most important fundamental improvement over C++ is memory management. [...] My experience is that this roughly doubles the productivity of a Java team over a C++ team.

I never understand claims like this. The advantage of Java's GC boils down to not having to write delete p; when you're done with something allocated dynamically. Since most variables in C++ aren't allocated with new anyway, and even in the occasional code where they are you usually use RAII to avoid the overhead of deleting them manually, how on earth does productivity double in Java?

Re:Static vs. Dynamic, or why Java == C++

[SlashSpam]

I never understand claims like this. The advantage of Java's GC boils down to not having to write delete p; when you're done with something allocated dynamically. Since most variables in C++ aren't allocated with new anyway, and even in the occasional code where they are you usually use RAII to avoid the overhead of deleting them manually, how on earth does productivity double in Java?

I wont comment on whether Java is more productive than C++, I don't know about that, but the gain of the garbage collector cannot be reduced to you not having to write delete p; or whatever your language of choice wants you to write. As I mention in another post on this topic, one of the reasons that Java is performing well these days, is that the garbage collector makes memory allocation cheap. In a language without Garbage Collection, you generally have to either create something like an "object pool", or pay for expensive calls to the OS in order to allocate memory.

Another benefit of the garbage collector is that you generally don't have to "pay", if you "accidently forget" to delete an object. Actually, to my knowledge, you cannot free objects in Java, save dereferencing memory (object = null;). Now, its no silver bullet either, but actually Java programmers does suffer much less than programmers without a garbage collector (or similar tool, RAII?) from having to debug memory leaks. A man with a spoon, and a man without a spoon might both be able to eat soup, but the man with the spoon might do better! (So maybe the real issue is whether you have a tool for memory).

I hope that helped clearing up that point.

/Spam .

Re:Static vs. Dynamic, or why Java == C++

[Anonymous Brave Guy]

I wont comment on whether Java is more productive than C++, I don't know about that, but the gain of the garbage collector cannot be reduced to you not having to write delete p; or whatever your language of choice wants you to write.

Of course it makes a difference to the performance characteristics of software written in Java as well; I'm certainly not disagreeing with that. However, in terms of developer productivity -- specifically, how long it takes a team to develop the equivalent code in Java vs. a non-GC language with otherwise similar characteristics -- I'm pretty sure that the missing delete (or whatever) is exactly what it boils down to...

Re:Throw, try, catch and other annoyances.

[AnyoneEB]

1. They do, it's called IOException. 2. Not sure why that would matter, for dev, the Java compiler and JVM should be the only things touching the files. For running a program, they should all be in a .jar, anyway. 3. Java's standard class libary doesn't use Hungarian Notation, so I don't know what you're talking about.

Re:Maybe because it's slow ?

[barawn]

While the last really is a benefit java posesses the other two aren't that relevant.

True. The grandparent post, however, was saying that an interpreted language must be slower than native code. This was the point I was trying to show was wrong - Java isn't the "prime example" of interpreted code, in my opinion. I actually think the Transmeta processors are much better examples, and I think we would all realize this if Transmeta had the money to make a true performance processor.

If you realize that interpreted code, emulation, and whatever you want to call the "RISC-in-CISC" design of modern processors are all the same thing, then the statement I was making - that those can be faster than native code.

It all comes back to the halting problem, and Wikipedia has a great point here: imagine the following algorithm -

int main(void)
{
BigInt i, j, k; /* assume arbitrary-precision integers */
for(i=j=k=1;--j||k;k=j?i%j?k:k-j:(j=i+=2));
return 0;
}

which looks for an odd perfect number, none of which are known to exist, but math has no idea whether or not they fundamentally do exist.

So there's no way the compiler can figure out that the comparison to stop the for loop may never come, but an interpreted language can notice that the likelihood of this branch ever being taken is virtually zero. There's in fact probably a formula for when the JIT compiler should start saying 'this branch will never happen - and if it does, the performance gains that come from assuming that it never happens will outweight the penalty for when it does'. Ballparking it, I can't imagine that it would take more than a hundred loops or so.

This is a bit of a poor example for an interpreted language, because there's not really any optimization that can be done here except branch prediction always assuming that the branch is not taken - although the JIT compiler could add the 'hint' to the hardware branch predictor of 'just ignore this branch' after it becomes obvious that the branch is never taken.

But you can imagine situations where an interpreted language could excel, especially given the relative "plateaus" of performance that modern PC's have:

registers>>L1-cache>>L2-cache>>main-memory>>hard -d rive

If an interpreted language can shift a program from main-memory bound to L2-cache bound, it can improve the performance massively.

In particular Java is going to be slow because most JIT or interpreters I know of don't seem to remember things from one instance to the next

Which baffled me, especially considering that, for instance, the Sun JVM on Windows stays resident after loading for the first time. Completely bizarre. Apparently the Sun JVM is very good at optimizing for lots of branches and jumps, though - hence the reason that the simple "nested loops" example that I linked to performed so well in Java, even compared to the Intel compiler.

In essence, the interpreter should at the very *least* act like a gigantic BHT (branch history table) for the processor, and expect code segments to act exactly the same the next time they're run, or at least identify segments that run identically, and feed the processor "very-likely/very-not-likely" hints. Given the performance penalty for branch mispredicts, this could have a serious performance boost, especially on long-pipeline processors like the P4.

Re:Maybe because it's slow ?

[freedom_india]

Seems you have not YET worked on Java on the server-side. Have you tried out building webserver/server based applications in Java and C++ (CGI, DCOM)? I have 6+ years of developing Java apps and managing IN production WAS4.0 servers in Solaris 8.0 and NT 4.0. It is not just about speed: it is about simplicity, elegance, and ease of deployment. Before you post someone's else comments make sure YOU have personal experience in them to validate if they are true. Java based web applications are MUCH faster than CGI or ASP stuff. I do agree Java AWT/Swing sucks. But that is a different matter since very less people use that.

OT: Prepare to tack

[lorcha]

I used to race little 16' boats. There was no preparing to come-about or jibe. It was just "DUCK!!" ;)

What the hell is a $CLASSPATH?

[lorcha]

I'm still trying to work out my $LD_LIBRARY_PATH!

Re:Maybe because it's slow ?

[mrlpz]

"MoneyDance and pdf-Office are two I know of. Its hard telling since no one generally advertises what they made their product with. Whens the last time you picked something up at Best Buy that stated it was written in C++?"

A) Oh Yeah ? You find it in the product catalog.
B) They don't have to, most commercial product out there have been written in a combination of C/C++/VB and when necessary, some scripting language. Java, has yet to be ( and will continue to not be ) accepted as an acceptable platform for commercial applications because the benefits it provides for the "Enterprise" aren't the same set of goals necessary for commercial success of a on-the-shelf product. Neither of those show up at BestBuy/CompUsa or Office Depot/OfficeMax...Where exactly did you say you could buy them off the shelf ? Oh, that's right, you didn't.

How many have on-the-shelf products have you done ? I have several ranging from programmable mice ( InterAct(R) Programmable Wireless Mouse ), to software used to produce some of the very commercials your TV is playing in the background, while you're on the eating your cheese doodles. The goals and needs of software that GrandPa Joe, and Auntie Sue would need to use, just AREN'T capable of being MET, by JAVA....at least not yet. How come we never hear about any usability studies done on Java desktop software.....that's because there aren't that many, and those that are, are VERY VERY vertical in nature.

"if you look hard enough kid."

I've been in this industry 20 years, and programming long before that....whippersnapper. And for that matter, sure, a direct link would've been better, but do some research....like I have. But then again, I'm not here to disprove your point, you're here to prove yours. Oh that's right, you didn't post a link to where to buy MoneyDance. Awww.

".NET does not have a multi-app virtual machine."

Au Contraire Mon Frere.... .NET most certainly DOES NOT spawn another "VM" to run a 2nd .NET application. Remember that .NET isn't "exactly" a VM, moreso an "Application Framework". You better do some reading.

Re:Maybe because it's slow ?

[mrlpz]

Of course a Mod has to set this as "Troll"...because of course that person has no answer to the question put before them ? I had mod points when this topic came up, rather than Mod this thread, I chose to contribute by posting my opinion, and of course, because someone didn't like it, and yet couldn't offer any substantive rebuttal, Modding me Troll was of course, the "adult" thing to do.

Suits me just fine....You don't like what I have to say....no problem, it doesn't change that I'm still right. Like some skiff boat captains.....

Two can play that game

[Paradox]

Umm, hate to break it to you, but the terser languages can (and do!) play that game. Lisp has some awesome IDEs (not to mention that Emacs is itself, essentially a big Lisp IDE).

The idea that your code is so tough to manipulate that you need an IDE to make it viable should say somethign to you about the language in question. When we talk about the future of coding and machine-assisted development, I don't think this is the vision we want to see.

Refactoring Java code can be very tedious, especially if you chage a type that goes into a collection. Even with the new Java Generics, this is going to be a huge pain. In Python or Ruby or Lisp, it's transparent. Heck, even in modern statically typed languages like Haskell and OCaml, it tends to be almost transparent.

Java's manifest typing model is outdated and cumbersome. This fundamental feature of the language lends itself to every aspect of work within. The Libraries may employ some great OO patterns, but they still can't escape the fundamental... well... clumsiness of the language.

As for the next argument against Java? Why doesn't Sun trust developers? Sun feels it's okay to use operator overloading on strings, why can't I use it for my complex number class?

The argument that "you might abuse it" is a lame argument at best. Bad programmers shouldn't program professionally. Do you let a bad basketball player stay on a pro team? Do you let a bad accountant manage your money? Do you let a bad contractor build you a crappy house? Do you let a bad manager control the fate of, um, your... company? ... Err, nevermind that last one. But you get the point, I hope.

The only reason I can see for this attitude is that Java wants to bring bad programmers into the fold. Why? Well... let's put on our cynical tin-foil hats and theorize for a second?

1. Good programmers tend to cost more than bad programmers, because of their reputation and experience and skillsets.
   
2. Modern HR policies seem to suggest "many medium-pay employees" over "one or two large-pay employees".
   
3. Java skill is so common that there is incredible competition for every job that appears.
   

Forgive me if I think someone is trying to screw over real software talent by commoditizing it. The sad thing about it is that this makes the consumer the ultimate victim, since they rely on poorly-made software.

And before you say, "That's just conspiracy theory" consider how much money there is in the software market, and how many people there are who have no fscking clue about what goes into good software making decisions on how it will be made.

Hanlon's razor could probably account for it just as well as my little tinfoil pirate hat.

Re:Maybe because it's slow ?

[bwt]

That's six "always" conditions. From a reliability point of view, "always check" isn't very reliable. You're advocating a system that relies and requires inspection (check this, check that) to achieve quality. That is a well known anti-pattern in quality engineering.

Re:[OT] Re:Java is bloated

[bwt]

To people who choose not to use a gui based desktop at all, I say get a life and at least update your tech skills to 1980. I'm a CLI lover, but if you don't ever use a windows environment by choice I can safely say your behavior is so outside the mainstream to sustain my "you baffle me" comment.

As to files on machines that don't have a GUI, fine. I edit such files using jEdit. If the file is on a machine that I can access via the network, then I can edit the files there via jEdit (using the FTP/SFTP plugin). For example, I have a linux firewall with no GUI (and no monitor). When I need to edit files on it, I use jEdit from my PC to edit those files in place via sftp. If the box doesn't have networking, I wouldn't use it to edit files at all (since I would have to create every character by hand every time). Instead I would create it on a machine with jEdit and transfer it using disk, CD, or RS-232 as needed. If we are talking about writing code, this is ESPECIALLY important, since I will probably be reproducing that code on multiple machines and so from a configuration management point of view I want not to have data islands.

So much for portability...

[gillbates]

So why not write my whole app in shell scripts, then?

I mean seriously, this is probably the worst example I've seen of Java's so-called "portability". Java's proponents rant about how "Java is so cool because it removes the #ifdefs of C and C++..." and then go on to further complicate the issue with CLASSPATH - which requires a different configuration for each architecture. So, I guess if you really hate the word "ifdef", Java must seem a godsend. But it doesn't qualify for the holy grail of "write once, run anywhere..." Basically, its a stripped-down, slower C++.

I do write in Java. But I realize that it isn't good for anything but internal development:

• The long startup times of the JVM (15 seconds is a _good_ time...) prohibit using it for commercially distributed applications. Slow startup times will leave a very negative impression with the end user.
• Swing is ok for internal use, but it has too many bugs and quirks - like "forgetting" to repaint menus, leaving areas unpainted, etc. Overall, it gives the impression that quality wasn't a concern. And it is painfully slow.
• An end user can run a native executable by simply copying it to their desktop. This works great for support applications - I need only send them an email attachment or CD. But with Java, I have _no_ idea how their particular JVM is configured, where _their_ CLASSPATH should point, etc... Let's face it - end users won't bother to download a JVM so they can use my app; if it doesn't start on the first click, they'll delete it and tell me it "didn't work".

Sorry to rain on your parade, but Java isn't the be-all, end-all of languages. It's okay for a narrow range of applications, but not good at anything, unless you count teaching CS.

Re:Maybe because it's slow ?

[Dan Ost]

10 seconds worth of preventative measures to prevent time-consuming debugging
at a later time seems like a bargain to me. What's the problem?

Anyhow, I'm not advocating any system. I was asked how it was that I didn't
have to spend time debugging pointer problems and I explained what steps I
took to prevent pointer problems in my code. These are all steps that a
good defensive coder (i.e. one who actively takes steps to prevent common
errors) is going to take regardless of what "system" (s)he uses.

Re:Maybe because it's slow ?

[kaffiene]

I think that shows what /. shows - the Linux community is hostile to Java. The claim was that there was no free software in java - that has been utterly refuted.

The fact that linux distributions don't use much Java is a reflection on Linux distributions, not Java or Java developers.

Re:Maybe because it's slow ?

[Edie O'Teditor]

There is *no* way that a interpreted or JIT compiled language can be *faster* than native code.

Well if the native code is produced by a bad compiler it could be really slow. So your "*no* way" is bullshit.

Re:Because end users hate the applications

[Edie O'Teditor]

Microsoft worked hard to get their MS-DOS monopoly

Legend has it that they worked harder than their rival, who bunked off to play golf when IMB came a-callin'.

Re:Because end users hate the applications

[Edie O'Teditor]

*cough* ... and didn't learn the lesson when IBM wanted to talk to him.

The language whose name is too short for a subject

[mr_mischief]

Ever heard of C or C++? Ever heard of a little group of companies which used to be AT&T? Is 99.999% uptime and 99.9% call completion "Enterprise Class" enough for you? That's right, phone switches are software. Mostly written in C.

Re:Maybe because it's slow ?

[dvdeug]

I think that shows what /. shows - the Linux community is hostile to Java. The claim was that there was no free software in java - that has been utterly refuted.

I think it's caused by three things. One, that both RedHat and Debian care about really free software, software that doesn't depend on non-free software, and Java doesn't have much of that. Two, all the old mature software--GCC, libc, Linux, emacs--predates Java. Three, and this is less obvious and more argumentative, there's a big difference between the software in Sourceforge and Freshmeat and software that someone actually cares to package for a Linux distribution. There's not a whole lot of important software in Java, IMO, which may be due in part to the fact that important software takes a while to mature.

Debunking "Java will be faster"

[Anonymous Brave Guy]

I'd mod your post Interesting, but I'd rather reply...

It's true that many people miss the point of JIT in Java and make poorly justified claims that C and/or C++ will always be faster. However, it's equally true that many Java fans make a similar mistake, in assuming JIT to be a silver bullet.

I'll begin, if I may, with a selection of excerpts from your post that I believe capture your argument.

Java HotSpot JVM, is a not only an interpreter, its also a compiler; a JIT compiler. [...] The JIT compiler usually uses a cache on the disk, so when it has run your program once or twice, it has already compiled the stuff that needs it. Thus, your programs gets faster by use. [...] The compiler is a "JIT" (Just In Time) compiler, which means the code is compiled while its running, and further more, only code that the VM assumes is worth it, will be compiled. What is really interesting here, is that the compiler at this point will have runtime knowledge of the program, something a common C compiler wont have. This enables the compiler to optimise better, utilising the runtime info. (Which loops are heavy-duty, and should be unrolled, which loops are merely used, etc.).

The first problem with this is limited potential. As we all remember from the first time we coded a bad algorithm, the little adjustments really don't make that much difference to performance once you've reached "good enough"; algorithmic complexity is usually what matters in the grand scheme of things, and while micro-optimisations help, you get diminishing returns.

Now, C compilers have 20+ years of experience with things like loop unrolling, eliminating common subexpressions, yada yada. C++ compilers have a somewhat harder job because the language is more complicated, but are rapidly catching up. Java's been way behind the pace for years, and JIT allows it to level the playing field somewhat, since it's finally running as a compiled rather than an interpreted language. It's important to realise that it doesn't do much more than that, however; it hasn't invented a dozen magic new optimisations that were unknown to the C compiler community before. Which brings me to the other flaw in the usual "JIT will be faster" argument...

That other flaw is that all this run-time optimisation is not free. Sure, you could just use a straightforward compile-on-load process, optimised for the particular platform in use, and you'd get similar performance to a C application compiled to target that platform once you were past that oh-so-annoying start-up lag (at least the first time). But to do the clever run-time stuff, the stuff you describe, requires actively monitoring the running code, and doing that is expensive.

To get an idea of just how expensive, consider the type of instrumented executable often used for profiling with C or C++. These can run an order of magnitude or more slower than a fully optimised version. If you want the kind of run-time customised optimisation you're talking about, you're going to take a huge hit in the monitoring code. Moreover, if you turn the monitoring code off after you've done the optimisation, you're going to be screwed if the data within your application changes significantly, so you'd have to leave some basic monitoring on even in the optimised version.

Now, if you're talking about an application that runs the same few subroutines thousands of times on similar data, it might be worth the overhead, but for most code, that simply isn't the case. The impact of the monitoring and recompiling/optimisation overheads will always limit the effectiveness of any JIT optimisation process, and since we're talking about diminishing returns micro-optimisations anyway, you're simply never likely to beat AOT-compiled C or C++ code of a similar quality just because of a JIT optimiser.

So, the bottom line(s):

• JIT compilation/optimisation has the theoretical potential to level the playing field a lot compared to interpreted by

OO and software engineering research?

[Anonymous Brave Guy]

Java seems to becoming popular for a lot of OO and software engineering research. A lot of the originator of ideas such as design patterns (Erick gamma), refactoring (Martin fowler), XP and test-driven development (Kent Beck, Ward cunningham) are Java people.

I agree with a lot of your points about bias, but this one irritated the hell out of me, I'm afraid. Although the people you mention may have popularised the terms you mention, the actual ideas behind them have been around for far longer, and used in many languages before Java. The latter simply makes a convenient buzzword to which other convenient buzzwords (like, say, "patterns" or "extreme programming") can be attached for the purposes of impressing PHBs and students.

and...

[Estanislao Mart�nez]

In dynamic logic, formulas are interpreted as state transition functions.

Yes, and It's called "C++"

[SoulSkorpion]

...directed at "Enterprise-grade apps and "coolness" may be inapproriate bedfellows.
Besides, does any language offer both?", from the original post.

I get very annoyed about the whole "C verses Java" business, and even more annoyed at the term "C/C++". They're not the same language, damnit!.

C++ lets you do what you like, and as much of it as you like. C forces you to do everything, and Java stands over you with a whip from the first line. Out of those, give me "do what you like" anyday. C++ allows far greater range of expression than C or Java. You can build powerful types that behave as if they were part of the language to begin with, and won't break if you accidentally trip over the wrong global or cast them the wrong way. If you want OO, you can use as much as you like without having to pay for any more. If you want compile-time type safety for you custom types, you can have that too.

And for God's sake, if a text editor can have exception handling, surely it's not too much to ask for?

C is ancient and crude. Java is a padded cell and straight-jacket. There is a middle ground.

Re:Yes, and It's called "C++"

[SlashSpam]

I am happy to see a post that while critical towards Java, doesn't mention performance. I guess its becoming more widely known that Java doesn't have the performance issues that it had back in 1995.

C is ancient and crude. Java is a padded cell and straight-jacket. There is a middle ground.

I will not comment on your view on C, and hopefully no-one else will, lest we want to see a full scale (OT) "language war".

When it comes to Java lacking multiple inheritance, I have never written much code in any language where multiple inheritance was possible, so I dare not comment much on this. However, I want to mention that Java has the "interface"-thing, that makes it possible to do at least some of the things you generally want to do with multiple inheritance.

So, for the rest of this post, I will assume that your point is that for you, Java is uncool because the compiler seems rather pedantic to you.

I need to comment on this, since I code Java on a daily basis and have a different experience. While its true that the Java compiler from SUN seems rather hysterical when you first start out with Java, the reason for this is the same as the reason that parents is usually very concerned about whether their child/children checks for traffic before crossing a road.

Now, 9 out of 10 times (it seems like more) when the Java compiler keeps complaining about '<identifier> might be uninitialised error in <line number>', I'm very happy about it the 10th time, where I actually forgot to initialise the variable. That being said, I often just initialise my variables early, to avoid this, but then again, then they *are* initialised.

Some prefer to manage stuff like this themselves, "Its not the business of a 'stupid compiler' how I write my code!", for them, C++ or even C might be a better choice. (Of course, sometimes you choose the language for the task, but both C, C++ and Java are all general purpose languages). Me? Well, I got used to Java, and I get much less problems with the compiler nowadays, I guess its become somewhat a challenge to write the code so that the compiler "eats it" as it is. Oh, and yes, I *do* enjoy having a garbage-collector to pick up my trash for me.

/Spam .

Re:Go write me a distributed n-tier web site in c

[togginho]

the question at hand: why would you want to write an OS in java? why would you want to write an n-tier web app in C?

programming languages are usually specific to a problem domain, where they should stay. i'll grant you that it's possible to write webapps with C, but I'd just love to watch you sit at it and curse. or is that ncurse for the C-fetishists??? :-)

Re:embrace change

[togginho]

i won't. all my C programs are so fast already, if i upgrade gcc, all i'll be able to see is the vapor trail in my syslog. and since i'm apparently not very cool, i like to sip hot coffee and actually watch what the application is doing ;-) let others read the realtime matrix

Discussion on speed of Java JVM's.

[SlashSpam]

Thank you for commenting!

I agree with much of what you wrote, I realise that I in fact did overplay the significance of JIT having runtime knowledge. I wanted to stress the fact that Java isn't simply an interpreted language, not even when you use the JVM from Sun.

The most important point of my post, though, is that "Java isn't slow" anymore. When I first got to know Java, it was dreadful slow. Now, its comparable to C++, and in some cases even faster, and has the potential to be even faster. Now, all this fuss about performance has really nothing to do with the Java-language, but has to do with the Java-platform, its not unrealistic to write a compiler for C that generates Java-bytecode for the Java-platform, but the point is that the Java-platform today proves that it does in fact work, that it doesn't slow performance, as seen in early stages. It has its strengths and weaknesses. One point I must make though, is that in my opinion, JIT is not the single key that Java has reached the performance of C++. Of course, JIT _does_ help a lot, esp. in CPU intensive code, but there are other factors as well. One really important point, is that Java Bytecode applications can allocate memory very cheap, as explained in my previous post.

That being said, lets discuss JIT a little...

Now, C compilers have 20+ years of experience with things like loop unrolling, eliminating common subexpressions, yada yada. C++ compilers have a somewhat harder job because the language is more complicated, but are rapidly catching up. Java's been way behind the pace for years, and JIT allows it to level the playing field somewhat, since it's finally running as a compiled rather than an interpreted language.

(Just for the record):

Its naive to assume that the cost of JIT is free, but its also naive to assume that Java compilers would not benefit from the last 20 years of experience on C compilers. The Java compiler from SUN is able to optimise the bytecode as well AOT as well as optimise the bytecode with JIT.

Your analysis on when JIT is beneficial, is very good, I do have a few notes though:

Now, if you're talking about an application that runs the same few subroutines thousands of times on similar data, it might be worth the overhead, but for most code, that simply isn't the case.

I don't think that this pose a real problem. The point is that "Most code", doesn't need much CPU, and thus the overhead of the JIT profiling, won't matter much, whereas the bonus from JIT-compiling critical code in CPU-intensive code will be a great gain for the JVM.

In C, when you write CPU-intensive code, you usually hint the compiler about optimising, in one way or another, since you know which code you want to be optimised. You may "inline" some code, ask to get an index variable kept in a register, and compile with flags / options like "-funroll-all-loops", "-funsafe-math-optimizations" and others. Usually, these hints will make the compiler able to make as good decisions as any JIT would be able to.

On the other hand, if you write CPU-intensive code, without paying attention to micro-optimising, chances are that the JIT-enabled code will run slightly faster (given the same algorithm, of course). With todays speed of CPU's, Code that is not CPU-intensive, will often seem to run at equal speed, from the users perspective, whether its interpreted or (JIT)compiled. (Even though they might actually be faster in the AOT code).

Here is an example where the JIT compiler seems to slow down the code, and how to mend that. Note that this type of code is very rarely seen in actual real life programs.

If we talk about really micro optimising code, I guess you would want to either write the code in assembler, or be really creative about how you optimise your code. As I mentioned in my first post on this subject, Java can also be compiled with AOT compiles! Another possibility, if you know that C is faster (or already have the optimised code in C source), is to use JNI (Java Native Interface), that lets you call native code. Note that this will of course invalidate any claim as to be "Pure Java" code.

I hit submit too early

[SlashSpam]

Sorry, when trying to preview the unfinished post, I hit submit by mistake. I hope the post still makes sense, it was almost done, but I like to read what I post a few times, before I post, just to make sure its how I want it to be.

/Spam .

on Biz App Bashing

[Tablizer]

It's pretty dull stuff, and that dullness has shaped how the language of choice is perceived. While Java jobs may outnumber C/C++ jobs a bit, I'm betting that once you limit the field to jobs that offer real technical challenges (i.e. the hardest part isn't figuring out what the PHBs want) or that otherwise involve doing something really novel with software, Java doesn't look nearly so hot.

"Technical challenge" is a little fuzzily defined here. If biz apps were "simple" or "easy" then it would all come in an off-the-shelf box. The trick is to automate and abstract the allegedly boring repetative stuff so that you don't have to keep doing it over and over. This is the same in any domain, not just business. I also notice "scientific applications" sometimes spend a lot of code reinventing stuff that a good database would make a snap. Personally, I think reinventing tools that already exist is kind of boring.

Anyhow, what is an example of an "exciting application" or domain from your perspective, and why?

Re:on Biz App Bashing

[BinxBolling]

"Technical challenge" is a little fuzzily defined here. If biz apps were "simple" or "easy" then it would all come in an off-the-shelf box.

This makes no sense. First, many business apps are at least somewhat off-the-shelf (see SAP for an example). Second, those that aren't off-the-shelf are that way because nobody has figured out a way to meet the varying requirements of a large number of customers with a single product. Technical difficulty has nothing to do with it.

What's exciting to me, personally? Systems programming. Right now I spend most of my day working on a multithreaded server that acts as a proxy for several network protocols. I deal with concurrency issues, reverse engineer protocol implementations from other software companies, build infrastructure components that get shared across multiple protocol implementations.

Before I found my current position, I spent about 3 years writing biz apps in a few different languages, including Java. I'm enjoying my work a lot more, these days.

From an overall perspective, is what I'm doing now more difficult than what I was doing back when I was building business apps? Not really. But back then, the big challenge I faced was figuring out what John Q. PHB wanted from the software he'd hired my company to build.

Nowadays the big challenges I face are much more technical in nature, which are far more interesting to me. And I think that this gives them more prestige in the eyes of the average hacker.

Re:Java forces compliance w/ OO programming techni

[Anonymous Brave Guy]

I think the important thing in terms of large (or even not so large) development teams is to have a strong underlying design, and development leads who make sure it's maintained and doesn't decay into special cases over time. OO can be a useful strategy for achieving this, but certainly isn't the only one. You can achieve just the same effect with procedural or functional programming, for example, or any combination of the three ideas, provided that all the developers have a basic understanding of the design and the leads are there to back them up.

BTW, I went through college when Java was being forced into the mainstream as well, but I'd still rather work in a language where the concept of null pointer exceptions simply isn't necessary. :-)

Comment removed

[account_deleted]

Comment removed based on user account deletion

Because why?

[Doc Ruby]

OTOH, you just found time to tell us about a cool app that's not cool because of its Java source language - it could have been written in Flash, or even a dedicated app for Windows/Mac/Linux. The "coolness" we're talking about is the Java language itself, and its dedicated tools, not the GUI or any features of the apps written in Java. Only if those were unique to Java would they make Java cool. How about the namespace management tools, threading model, libraries? I always thought the networked classloader was extremely cool, combined with the safe sandbox I'd expect to see a lot more "mobile network agents" running in Java VM application servers by now. Next time you take a break from the big money gigs to wax enthusiastic about Java, how about clueing us in to how cool Java actually does make your job. Fortran also works, but it's not as cool as Java.

Re:3-headed cat

[tomhudson]

Hell, Im sure you can find pictures of a three headed cat out there if you look hard enough

your wish is my command http://www.randomperspective.com/page.asp?2image88
or the article : Discovery Of Three Headed Frog Increases Demand For 3 Headed Pets - March 7th 2004 http://www.randomperspective.com/page.asp?1news/2/ 006

Back on-topic: The real reason C programmers don't like java is because it is wayToVerboseAndYouHaveToTypeALotToGetAnythingDone.

Re:Cool?

[Lord Kano]

We respect the Kung Foo of our enemies, especially when it is strong.

LK

Re:Depends ...

[BigBadDude]

let me second that:

ha ha ha

(im actually a java AND c++ developer)

Re:Depends ...

[BigBadDude]

NO!

lets face it, for the sysadm crowd of /. the python/perl stuff is COOL. for the real programmers (tm), python and perl are not really programming languages.

i dont say that to start a flame war, its just that not all software in the planet are designed to show some crappy web page or extract some crappy data from some simple odbc link....

the way i see it, you must have programmed assembler and C in complex projects to count as a real programmer. if you dont belive me, check the nearest job database :)