Slashdot Mirror


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

123 of 1,782 comments (clear)

  1. What is this responding to.. exactly? by Defiler · · Score: 4, Interesting

    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.

    1. Re:What is this responding to.. exactly? by skaffen42 · · Score: 5, Funny

      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.

      --
      People couldn't type. We realized: Death would eventually take care of this.
    2. Re:What is this responding to.. exactly? by LWATCDR · · Score: 5, Insightful

      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.

      --
      See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
    3. Re:What is this responding to.. exactly? by mwood · · Score: 4, Insightful

      "the managers that choose Java"

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

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

    4. Re:What is this responding to.. exactly? by jimfrost · · Score: 5, Insightful
      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.

      --
      jim frost
      jimf@frostbytes.com
    5. Re:What is this responding to.. exactly? by TheWanderingHermit · · Score: 3, Interesting

      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.

    6. Re:What is this responding to.. exactly? by Tassach · · Score: 3, Informative
      [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.
      --
      Why is it that the proponents of "one nation under God" are so eager to get rid of "liberty and justice for all"?
    7. Re:What is this responding to.. exactly? by zipwow · · Score: 4, Insightful
      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
      --
      I don't know which is more depressing, that 2/3 didn't care enough to vote, or that 1/2 of those that did are crazy.
    8. Re:What is this responding to.. exactly? by jimfrost · · Score: 3, Insightful
      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++.

      --
      jim frost
      jimf@frostbytes.com
  2. Why is Java Considered Un-Cool? by illtud · · Score: 4, Funny

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

    1. Re:Why is Java Considered Un-Cool? by Aardpig · · Score: 3, Informative

      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.

      --
      Tubal-Cain smokes the white owl.
    2. Re:Why is Java Considered Un-Cool? by das_cookie · · Score: 5, Insightful
      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.

      --

      You! Yes, YOU! Out of the gene pool!

    3. Re:Why is Java Considered Un-Cool? by BeBoxer · · Score: 4, Insightful

      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.

    4. Re:Why is Java Considered Un-Cool? by daBass · · Score: 5, Insightful

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

    5. Re:Why is Java Considered Un-Cool? by brianjcain · · Score: 3, Insightful
      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.
  3. How about by antifoidulus · · Score: 5, Insightful

    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.

    1. Re:How about by Bastian · · Score: 4, Insightful

      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.

  4. Its just a tool by hoofie · · Score: 4, Informative

    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.

    1. Re:Its just a tool by Lodragandraoidh · · Score: 3, Interesting

      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.

      --

      Lodragan Draoidh
      The more you explain it, the more I don't understand it. - Mark Twain
  5. Wait by Lord+Grey · · Score: 4, Insightful
    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?

    --
    // Beyond Here Lie Dragons
  6. COBOL by sql*kitten · · Score: 5, Insightful

    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.

    1. Re:COBOL by Marlor · · Score: 4, Funny

      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.

    2. Re:COBOL by RetroGeek · · Score: 4, Interesting

      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.

      --

      - - - - - - - - - - -
      I am a programmer. I am paid to produce syntax not grammar. Deal with it.
    3. Re:COBOL by dinog · · Score: 4, Insightful
      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.

  7. Too verbose by random_culchie · · Score: 4, Insightful

    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.

  8. Not responding by gr8_phk · · Score: 4, Funny

    The site must use a lot of Java code.

  9. What's not to love about Java? by wayward_son · · Score: 5, Funny

    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!

  10. Re:Maybe because it's slow ? by Anonymous Coward · · Score: 4, Informative

    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.

  11. Who cares? by Anonymous Coward · · Score: 5, Insightful
    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.

  12. Paul Graham isn't Cool, Duh. by freality · · Score: 4, Interesting

    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.

    1. Re:Paul Graham isn't Cool, Duh. by Fnkmaster · · Score: 3, Insightful
      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?

    2. Re:Paul Graham isn't Cool, Duh. by mmusson · · Score: 4, Insightful

      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?

      --
      SYS 49152
  13. Java pays!!! by KrisCowboy · · Score: 4, Interesting

    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.

  14. Well... by thrill12 · · Score: 4, Insightful

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

    --
    Slashdot: stuff for news, nerds that matter, matter for news, stuff that nerd
    1. Re:Well... by Rattencremesuppe · · Score: 4, Insightful

      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?

    2. Re:Well... by black+mariah · · Score: 5, Insightful

      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?

      --
      'Standards' in computing only impress those who are impressed by things like 'standards'.
    3. Re:Well... by AKAImBatman · · Score: 5, Insightful

      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.

    4. Re:Well... by AKAImBatman · · Score: 4, Insightful

      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.

    5. Re:Well... by the+quick+brown+fox · · Score: 4, Informative
      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.

    6. Re:Well... by nickos · · Score: 4, Interesting

      Conversely, if you program a web-based app in C, you're a fucking moron.

      Please break it gently to Google!

    7. Re:Well... by Theatetus · · Score: 4, Interesting
      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.

      --
      All's true that is mistrusted
  15. Re:Maybe because it's slow ? by Ignorant+Aardvark · · Score: 3, Interesting

    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.

  16. Re:Maybe because it's slow ? by xer.xes · · Score: 5, Funny

    It's really time to dump your 386 and move on to at least a Pentium.

    --
    xer.xes -- 4181
  17. Why is Java UnCool? by DesScorp · · Score: 5, Insightful

    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.

    --
    Life is hard, and the world is cruel
    1. Re:Why is Java UnCool? by pthisis · · Score: 4, Insightful

      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.

      --
      rage, rage against the dying of the light
  18. Enterprise grade and Cool by DG · · Score: 4, Interesting
    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
    --
    Want to learn about race cars? Read my Book
  19. Oh come on by Phaid · · Score: 5, Insightful

    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.

  20. If *Java* is uncool.... by revscat · · Score: 4, Funny

    ... where does that put C#? In the basement with the red Swingline?

  21. Re:lame by Cocoronixx · · Score: 3, Funny
    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.
    --
    "Obscenity is the crutch of the inarticulate motherfucker." - cloak42
  22. Re:a few reasons by lmsig · · Score: 4, Insightful

    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.

    --
    .plan!! what plan?
  23. Re:Also Speed by Ignorant+Aardvark · · Score: 4, Insightful

    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.

  24. Totally mis-informed by brunes69 · · Score: 4, Informative

    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.

    1. Re:Totally mis-informed by Anonymous Coward · · Score: 4, Insightful

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

  25. Maybe it's because... by blackmonday · · Score: 4, Insightful

    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.

  26. Re:who cares what he says? by SparafucileMan · · Score: 5, Insightful
    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.

  27. First Impressions, then second by Ozwald · · Score: 4, Insightful

    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

  28. Java's problem is Sun's mismanagement by Master+Of+Ninja · · Score: 4, Insightful

    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.

  29. Oh double negative, why do you haunt me!!! by pottymouth · · Score: 5, Funny

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

  30. Re:Maybe because it's slow ? by CurMo · · Score: 5, Informative

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

  31. This is mostly babble. by theonomist · · Score: 4, 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), 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.

    --
    "Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive" -- hey, that's me!
  32. Re:who cares what he says? by alex_tibbles · · Score: 3, Informative
  33. Re:Maybe because it's slow ? by nkh · · Score: 3, Interesting

    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.

  34. Re:Maybe because it's slow ? by Florian+Weimer · · Score: 3, Insightful

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

  35. Re:Maybe because it's true by EmperorKagato · · Score: 4, Informative

    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.

    --
    ----- You know you have ego issues when you register a domain in your name.
  36. Re:Also Speed by Stephen+Williams · · Score: 5, Funny

    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

  37. Who Gives A Shit? by jjohnson · · Score: 4, Insightful

    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.

    --
    Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
  38. Re:Maybe because it's slow ? by danheskett · · Score: 4, Insightful

    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.

  39. Re:Maybe because it's slow ? by dtfinch · · Score: 3, Informative

    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.

  40. Re:Maybe because it's slow ? by mwood · · Score: 4, Informative

    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.

  41. Overheard in a recent Sun board meeting... by Junior+J.+Junior+III · · Score: 3, Funny

    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?

    --
    You see? You see? Your stupid minds! Stupid! Stupid!
  42. Are your apps constantly restarting? by FatSean · · Score: 3, Insightful

    Mine aren't. They run for weeks and months at a time. Startup time is irrelevant in the enterprise.

    --
    Blar.
    1. Re:Are your apps constantly restarting? by Switchback · · 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.

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

    2. Re:Are your apps constantly restarting? by dasmegabyte · · Score: 4, Insightful

      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.

      --
      Hey freaks: now you're ju
    3. Re:Are your apps constantly restarting? by kill+-9+$$ · · Score: 4, Interesting
      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.

      --

      -- A computer without COBOL and Fortran is like a piece of chocolate cake without ketchup and mustard
  43. Debunking Pro-Java Myths by Frankie70 · · Score: 4, Informative

    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.

    1. Re:Debunking Pro-Java Myths by brunes69 · · Score: 5, Insightful

      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.

  44. cheapest that still gets the job done... by dpilot · · Score: 3, Interesting

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

    --
    The living have better things to do than to continue hating the dead.
  45. Re: Cheap Shot by freality · · Score: 5, Funny

    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.

  46. Re:who cares what he says? by Anonymous Coward · · Score: 3, Informative

    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.

  47. Re:who gives a shit about paul graham? by bay43270 · · Score: 3, Insightful

    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

  48. Same reason as everything else by Kohath · · Score: 4, Funny
    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.


  49. Re:Why, Perl, of course. by sean23007 · · Score: 3, Interesting

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

    --

    Lack of eloquence does not denote lack of intelligence, though they often coincide.
  50. Re:Why, Python, of course. by TeknoHog · · Score: 4, Insightful
    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.

    --
    Escher was the first MC and Giger invented the HR department.
  51. Re:Maybe because it's slow ? by Cyberax · · Score: 3, Informative

    JRE is about 7Mb.

  52. Java Basher vs. Java Apologist by RAMMS+EIN · · Score: 5, Interesting

    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.

    --
    Please correct me if I got my facts wrong.
  53. Mauve Was Cool In Its Day by handy_vandal · · Score: 3, Interesting
    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
    --
    -kgj
  54. Depends ... by gstoddart · · Score: 5, Interesting
    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.

    --
    Lost at C:>. Found at C.
  55. Why am I still hearing this? by kahei · · Score: 5, Insightful


    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.

    --
    Whence? Hence. Whither? Thither.
  56. Bad article by photon317 · · Score: 4, Insightful


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

    --
    11*43+456^2
  57. Re:One word. by dajak · · Score: 3, Insightful
    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.

  58. Java still playing catch up with Smalltalk by sideshow+Pablo · · Score: 5, Insightful
    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

  59. Re:Maybe because it's slow ? by Glock27 · · Score: 3, Informative
    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.

    --
    Galileo: "The Earth revolves around the Sun!"
    Score: -1 100% Flamebait
  60. Great Programmers? by Fujisawa+Sensei · · Score: 4, Insightful

    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?

    --
    If someone is passing you on the right, you are an asshole for driving in the wrong lane.
  61. Re:One word. by graveyhead · · Score: 4, Informative
    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!

    --
    std::disclaimer<std::legalese> sig=new std::disclaimer; sig->dump(); delete sig;
  62. Re:Swing by Malc · · Score: 3, Insightful

    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.

  63. Re:Maybe because it's slow ? by StillNeedMoreCoffee · · Score: 4, Insightful

    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?

  64. Re:Maybe because it's slow ? by Euphonious+Coward · · Score: 3, Insightful
    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.

  65. Re:One word. by Atzanteol · · Score: 4, Insightful

    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.

    --
    "Ignorance more frequently begets confidence than does knowledge"

    - Charles Darwin
  66. Re:Maybe because it's slow ? by markbthomas · · Score: 4, Insightful

    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.

  67. Re:Maybe because it's slow ? by SkyWalk423 · · Score: 4, Informative
    System.gc() suggests running garbage collection, doesn't force.

    http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ System.html#gc()

  68. Re:Also Speed by Tassach · · Score: 3, Insightful
    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.

    --
    Why is it that the proponents of "one nation under God" are so eager to get rid of "liberty and justice for all"?
  69. Re:One word. by That's+Unpossible! · · Score: 4, Informative

    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.

    --
    Ironically, the word ironically is often used incorrectly.
  70. Re:Depends ... by Saucepan · · Score: 4, Informative
    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.

  71. Why I Dislike Java by Prien715 · · Score: 5, Insightful

    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.

    --
    -- Political fascism requires a Fuhrer.
    1. Re:Why I Dislike Java by Capt_Troy · · Score: 5, Insightful

      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.

  72. the real reason by pchan- · · Score: 5, Insightful

    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.

    1. Re:the real reason by fakeplasticusername · · Score: 5, Insightful

      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.

    2. Re:the real reason by Anonymous Coward · · 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.

  73. Re:Depends ... by stormcoder · · Score: 3, Informative

    Open source cross platform C++ libraries include Boost, ACE, STLSoft, and Loki to name a few.

    You should give Python a try as well.

    --
    Sorry my bullshit sensor overloaded.
  74. Re:Words from a programmer rather than a end user by BigGerman · · Score: 3, Insightful
    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.

  75. Re:Lack of Flexibility (Why *I* don't like java) by toriver · · Score: 4, Insightful

    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.

  76. Re:security by Fooby · · Score: 3, Interesting

    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.

  77. Re:Java doesn't play nice with other children by hikerhat · · Score: 4, Informative
    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.

  78. Re:Lack of Flexibility (Why *I* don't like java) by Big+Boss · · Score: 4, Informative

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

  79. Top reasons why Java *is* cool... by eyefish · · Score: 5, Informative

    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.

  80. Re:Maybe because it's slow ? by Hulfs · · Score: 3, Insightful
    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").

  81. Re:Because it is a limiting language by graveyhead · · Score: 5, Insightful
    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...
    --
    std::disclaimer<std::legalese> sig=new std::disclaimer; sig->dump(); delete sig;
  82. Damn straight! by Tony · · Score: 3, Insightful

    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.

    --
    Microsoft is to software what Budweiser is to beer.
  83. The Bell Curve by macrealist · · Score: 5, Insightful

    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.

    --
    I am living proof of the Peter Principle
  84. Debunking the debunking by Ian+Bicking · · Score: 4, Interesting
    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.

  85. As a Language Geek... by cgreuter · · Score: 4, 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.

  86. Things that suck about Java and things that don't by cbare · · Score: 3, Insightful
    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?

    --
    -cbare
  87. Java is NOT slow! by SlashSpam · · Score: 3, Informative

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