Why is Java Considered Un-Cool? 1782
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?"
What is this responding to.. exactly? (Score:4, Interesting)
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 [paulgraham.com], 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.
Paul Graham? (Score:2, Interesting)
a few reasons (Score:2, Interesting)
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
I'd use it (Score:2, Interesting)
uncool vs ....? (Score:1, Interesting)
Making an interface (Score:1, Interesting)
Also Speed (Score:2, Interesting)
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.
Language for the masses? (Score:1, Interesting)
Java's uncool image (Score:1, Interesting)
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.
Paul Graham isn't Cool, Duh. (Score:4, Interesting)
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.
Java pays!!! (Score:5, Interesting)
Uncool to me (Score:2, Interesting)
Re:COBOL (Score:1, Interesting)
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:Maybe because it's slow ? (Score:3, Interesting)
Enterprise grade and Cool (Score:5, Interesting)
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:COBOL (Score:3, Interesting)
Swing (Score:3, Interesting)
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:COBOL (Score:4, Interesting)
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.
This is mostly babble. (Score:5, Interesting)
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 [ericsink.com]), 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.
Perhaps hackers like hacking? (Score:2, Interesting)
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 ? (Score:3, Interesting)
Re:Maybe because it's slow ? (Score:1, Interesting)
Re:Why is Java Considered Un-Cool? (Score:2, Interesting)
oh please. Most programmers can deal with pointers just fine, but like using a high level language to get more done.
Re:Maybe because it's slow ? (Score:2, Interesting)
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:Maybe because it's slow ? (Score:3, Interesting)
many mallocs - zero frees == bloated crapware
while in Java:
many news - zero "= null"s == bloated crapware
Re:Too verbose (Score:2, Interesting)
Server slashdotted (Score:1, Interesting)
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:Its just a tool (Score:3, Interesting)
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:a few reasons (Score:2, Interesting)
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+
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:COBOL (Score:3, Interesting)
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:Why is Java UnCool? (Score:3, Interesting)
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
cheapest that still gets the job done... (Score:4, Interesting)
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:Strongly typed - Good or Bad? (Score:3, Interesting)
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:Maybe because it's slow ? (Score:2, Interesting)
Regards,
Steve
Because it is a limiting language (Score:2, Interesting)
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:Java is slow, bulky, and mostly useless... (Score:3, Interesting)
This annoys me! (Score:1, Interesting)
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:Why, Perl, of course. (Score:3, Interesting)
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:Maybe because it's slow ? (Score:3, Interesting)
Re:Go write me an OS in Java (Score:3, Interesting)
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.
Java Basher vs. Java Apologist (Score:5, Interesting)
``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.
Mauve Was Cool In Its Day (Score:4, Interesting)
In its day, mauve was all the rage: -kgj
Re:Oh come on (Score:2, Interesting)
Re:Maybe because it's slow ? (Score:3, Interesting)
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:Too verbose (Score:3, Interesting)
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.
Depends ... (Score:5, Interesting)
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 (Score:2, Interesting)
Re: Totally mis-informed (Score:2, Interesting)
Re:Why is Java Considered Un-Cool? (Score:3, Interesting)
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
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.
rubbish (Score:2, Interesting)
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:Are your apps constantly restarting? (Score:3, Interesting)
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.
I could go on from a programming side as well, but that's off-topic on this thread.
Masses? hat Masses? (Score:3, Interesting)
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:Well... (Score:2, Interesting)
Java is NOT just a language but a VM also. Most people forget that.
Re:security (Score:3, Interesting)
Re:Maybe because it's slow ? (Score:2, Interesting)
Re:Maybe because it's slow ? (Score:2, Interesting)
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:Maybe because it's slow ? (Score:3, Interesting)
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 [uni-karlsruhe.de] preserves much more information than JVM code.
A possible solution
I think LLVM [slashdot.org] 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.
Site error (Score:2, Interesting)
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.
Re:Lack of Flexibility (Why *I* don't like java) (Score:2, Interesting)
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.
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.
MOD PARENT UP (Score:2, Interesting)
Re:Debunking Pro-Java Myths (Score:2, Interesting)
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++.
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?
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:security (Score:4, Interesting)
Re:Maybe because it's slow ? (Score:3, Interesting)
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/ [utwente.nl]. 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… (Score:3, Interesting)
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:
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:What is this responding to.. exactly? (Score:4, Interesting)
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
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:Paul Graham isn't Cool, Duh. (Score:3, Interesting)
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:the real reason (Score:2, Interesting)
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 (Score:2, Interesting)
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:Its just a tool (Score:2, Interesting)
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:Well... (Score:5, Interesting)
Please break it gently to Google!
Re:Are your apps constantly restarting? (Score:5, Interesting)
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:Who cares? (Score:3, Interesting)
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:Maybe because it's slow ? (Score:3, Interesting)
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...
Re:What is this responding to.. exactly? (Score:3, Interesting)
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 [mindview.net].
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 [mindview.net]. 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:Why I consider Java uncool (Score:1, Interesting)
Re:the real reason (Score:5, Interesting)
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:Well... (Score:5, Interesting)
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... (Score:2, Interesting)
Debunking the debunking (Score:5, Interesting)
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 [artima.com].) 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:Its just a tool (Score:3, Interesting)
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 [agilemanifesto.org]. 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:Java's problem is Sun's mismanagement (Score:2, Interesting)
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.
JEDIT JEDIT JEDIT (Score:1, Interesting)
And if you're wondering, Emacs sucks.
I don't like Java, but... (Score:2, Interesting)
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.
As a Language Geek... (Score:5, Interesting)
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:Why is Java Considered Un-Cool? (Score:3, Interesting)
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
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.
Fast Interpreted languages/NEW OS (Score:3, Interesting)
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?
Re:Why am I still hearing this? (Score:3, Interesting)
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.
Python/LISP IDE's (Score:2, Interesting)
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
Re:What is this responding to.. exactly? (Score:2, Interesting)
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