Java: Failure or Crime?

Posted 5 Feb 2004 at 18:49 UTC by ncm Share This

I posted this in the "I hate Java" board on orkut.com. It's easier to link to, here. Hint: this is not something to get angry about.

Many languages have failed honorably -- Eiffel, Dylan, Oberon, Icon, CLP(R), C+@, Oak, PL/1, Bliss, Algol-68, Pascal -- some more honorably, some less, but far too many to list, or indeed to count. Others struggle vainly along, confined forever to subsidized niches -- Erlang, Common LISP, REXX, Objective-C, Delphi, Ada. Only a handful of languages sustain a vigorous population of programmers using them, industrially, for their original purpose; we need not list them.

Java survived teething only by dint of billions of dollars of promotion. It was taken up most enthusiastically by hacks living in fear of losing their jobs to other hacks more experienced on Microsoft environments. Every promise made in its infancy has proved a lie. Designed and implemented in such frantic haste that a semblance of quality was the first criterion jettisoned, it could not but grow into such a monstrosity as we face today. Today its uses in applications where it was, supposedly, intended -- cellphones, browsers, rings -- amount to little more than nasty, brutish parodies.

It is no crime for a language to fail. What is a crime is for its failure to blight the careers of the myriad young, impressionable, and naive who fell for its blandishments. What is a crime is the forests felled, pulped, and printed upon, only to be discarded unread and obsolete. What is a crime is the thousands of good ideas, and the companies formed to build them, stabbed in the back by an inadequate implementation language. What is a crime is the gigawatt-hours of energy dissipated operating wasteful JVMs on huge servers performing jobs that a hamster could do (and does) on its bathroom break.

Java is far more than a failure, far more than an annoyance, far more than the laughingstock of many industries, far more even than the evil sire of C#. It is a bona fide crime against humanity. Capital punishment would be too good for it; that is to say, it does not deserve execution.

Only one fate can be ignominious enough to expiate Java's wrongs. Java must be consigned to use as an undergraduate teaching language.


there is no silver bullet, posted 5 Feb 2004 at 18:57 UTC by gilbou » (Observer)

maybe it is because that broad use languages are more "big" to learn while smaller and specialized ones fit the job even if they would suck in performance (or another point) in other domains. i feel that c is quite adapted for code that talks to hardware (that is how i like to use it most, writing code to talk to various hardware). i dont know a lot out of c but my excuse might me i do not have a job related to programming so it is more a personal hobby ;)
but i feel that a langage once born never really dies. cobol does not seem used today as much as java or c++ or something else, but when we had the pseudo-y2k problem and the hype around it, there were firms looking for people that knew cobol to "check" the y2k status of some of their programs and their trouble that new programmers were taught a lot of languages but not cobol so they had to hire old programmers that would teach young ones how to find those cobol problems (filtering them from code) and then a previous cobol programmer would come and fix if required ;)

Java :-P, posted 5 Feb 2004 at 20:43 UTC by Omnifarious » (Journeyer)

I've actually tried to decide why it is that I dislike Java so much. It isn't garbage collection, though I find that slightly annoying. It isn't static typing, which I actually like in languages designed for large systems. It isn't that it's slow exactly, because Python is a lot slower, and I really like Python.

I think, what I've finally decided as a reason to sum up my dislike of Java is this: "If I wanted an OS, I'd install one. I don't need one to masquerade as a programming language.".

Nobody ever wants to start a VM, it takes too long. They want to send a message to an existing one to run their class, sort of like starting a process on an OS. It has its own security model that's enforced by the language, not the OS. It has numerous other features that one typically associates with an OS, not a programming language.

When Sun brought out Java, it made sense, in some insane way, that it should be an OS. It looked like Unix might lose to Windows, and there needed to be some way to write programs for Windows in such a way that you weren't locking yourself into Microsoft's bletcherous API.

Now that it doesn't look like Unix is about to die, I think Java is a slow bloated nightmare that never really fulfilled its promise and should die. I symptathize greatly with the author of this article.

I _like_ Java, posted 5 Feb 2004 at 22:12 UTC by slamb » (Journeyer)

I like Java. Yes, there were unfulfilled promises. Yes, the VM is bloated - starting a program is something you don't want to do often, given the memory requirements and time spent doing JIT compilation. But look at Java's advantages over C++:

  • A simple syntax
  • Immunity to buffer overflows
  • Reflection. (More than just RTTI.)
  • Good exception support. (Better than C++'s, I would say. No slicing problems; you can wrap exceptions in other ones and such with no problems.)
  • A fairly complete API, with lots and lots of available code building on it. Apparently you feel it's pretty poorly-designed. I could see that for the graphical portions, but there are parts that are quite good. Besides, C++ doesn't really have this at all - there's the standard library (which of couse you know much better than I do, having written an implementation and all). But it's "just" standardized data structures and algorithms; there are no interfaces to system calls. For that, you have to drop down to C code. In theory, it's possible to write a good API on top that takes advantage of C++'s features. In practice, I haven't found one I like, which is why I'm writing my own, along with everyone and their dog. It would be nice if there were a standardized, good API like this.
  • API documentation! Yes, there was good API documentation before Java came along, in some places. Yes, embedded API documentation tools existed before Java came along. But Java popularized them. I wouldn't have learned about doxygen if not for javadoc. I bet a lot of other people can say the same.

Of course, all the language features can be found elsewhere. But can you say the same about the comprehensive, well-documented APIs? That's why I think Java is unbelievably powerful.

Granted, the API is largely due to the amount of money Sun threw at it. But...so? It's done, so I'm going to take advantage of it.

I _like_ Java, posted 5 Feb 2004 at 22:14 UTC by slamb » (Journeyer)

I like Java. Yes, there were unfulfilled promises. Yes, the VM is bloated - starting a program is something you don't want to do often, given the memory requirements and time spent doing JIT compilation. But look at Java's advantages over C++:

  • A simple syntax
  • Immunity to buffer overflows
  • Reflection. (More than just RTTI.)
  • Good exception support. (Better than C++'s, I would say. No slicing problems; you can wrap exceptions in other ones and such with no problems.)
  • A fairly complete API, with lots and lots of available code building on it. Apparently you feel it's pretty poorly-designed. I could see that for the graphical portions, but there are parts that are quite good. Besides, C++ doesn't really have this at all - there's the standard library (which of couse you know much better than I do, having written an implementation and all). But it's "just" standardized data structures and algorithms; there are no interfaces to system calls. For that, you have to drop down to C code. In theory, it's possible to write a good API on top that takes advantage of C++'s features. In practice, I haven't found one I like, which is why I'm writing my own, along with everyone and their dog. It would be nice if there were a standardized, good API like this.
  • API documentation! Yes, there was good API documentation before Java came along, in some places. Yes, embedded API documentation tools existed before Java came along. But Java popularized them. I wouldn't have learned about doxygen if not for javadoc. I bet a lot of other people can say the same.

Of course, all the language features can be found elsewhere. But can you say the same about the comprehensive, well-documented APIs? That's why I think Java is unbelievably powerful.

Granted, the API is largely due to the amount of money Sun threw at it. But...so? It's done, so I'm going to take advantage of it.

I _like_ Java, posted 5 Feb 2004 at 22:14 UTC by slamb » (Journeyer)

I like Java. Yes, there were unfulfilled promises. Yes, the VM is bloated - starting a program is something you don't want to do often, given the memory requirements and time spent doing JIT compilation. But look at Java's advantages over C++:

  • A simple syntax
  • Immunity to buffer overflows
  • Reflection. (More than just RTTI.)
  • Good exception support. (Better than C++'s, I would say. No slicing problems; you can wrap exceptions in other ones and such with no problems.)
  • A fairly complete API, with lots and lots of available code building on it. Apparently you feel it's pretty poorly-designed. I could see that for the graphical portions, but there are parts that are quite good. Besides, C++ doesn't really have this at all - there's the standard library (which of couse you know much better than I do, having written an implementation and all). But it's "just" standardized data structures and algorithms; there are no interfaces to system calls. For that, you have to drop down to C code. In theory, it's possible to write a good API on top that takes advantage of C++'s features. In practice, I haven't found one I like, which is why I'm writing my own, along with everyone and their dog. It would be nice if there were a standardized, good API like this.
  • API documentation! Yes, there was good API documentation before Java came along, in some places. Yes, embedded API documentation tools existed before Java came along. But Java popularized them. I wouldn't have learned about doxygen if not for javadoc. I bet a lot of other people can say the same.

Of course, all the language features can be found elsewhere. But can you say the same about the comprehensive, well-documented APIs? That's why I think Java is unbelievably powerful.

Granted, the API is largely due to the amount of money Sun threw at it. But...so? It's done, so I'm going to take advantage of it.

Oh shut up, posted 5 Feb 2004 at 23:37 UTC by judge » (Master)

Many people are zealots and hide it well. However ncm can't disguise his zealotry.
Ok pardon that, but I just tried to replicate the argument against java that ncm makes. IE it's just a factless accusation.
Sure java sucks to do quick hacky programs. It also sucks when one has to integrate tightly with the rest of the system.
However, java also provides a standard api. This is something that seems to be unheard of in most languages. It provides a unified api that allows one to use networks, gui, threads, etc while remaining portable. It elminates a lot of headaches that other "established" languages create when trying to be portable between something other than unix systems. Furthermore it does all this with very reasonable perfomance.
Every language has weak points, but no language deserves as many pointless/uninformed "this sux" comments as Java gets. I wish this kind of slashdot-reasoning wouldn't plague the open source community.

Rant Etiquette., posted 6 Feb 2004 at 00:53 UTC by ncm » (Master)

Can't you guys tell a rant when you see one?

You're not supposed to reason about it. You're supposed to top it.

Die, Java!, posted 6 Feb 2004 at 03:10 UTC by tk » (Observer)

Damn, why do people always compare Java to C++ only? Are Java and C++ the only languages in the world? I shouldn't need to say it again, but we have Smalltalk.

Smalltalk had an extremely clean syntax, a relatively standardized API, portable virtual machines, and embedded documentation, even when Java was still in diapers. Yes, we can always say, "maybe X existed before Java, but Java popularized X", but Java `popularized' these things in a broken way.

Wait, who's the zealot?

Can't both be bad?, posted 6 Feb 2004 at 03:44 UTC by ncm » (Master)

Or all three, if you want to count Smalltalk?

My rant was about Java. If you want to rant about C++, Scott, be my guest.

One thing is clear. Smalltalk hasn't done any substantial amount of damage in the world, so it's hard to rant at. Anyway, you can't rant about how much you like a language, so any discussion of Smalltalk's (or any language's) virtues is way, way out of place here.

Smalltalk, posted 6 Feb 2004 at 06:15 UTC by slamb » (Journeyer)

Yes, Smalltalk certainly had a lot of these things before Java. But when I choose a programming language, I'm making a pragmatic decision. I don't care which one was more groundbreaking, just which one is more effective for me to use. And, like it or not, the size/quality of the community is a big part of that. So I use C, C++, Java, Perl, and Python. That's pretty much it, although I keep meaning to play more with one of the more popular functional languages. (OCaml, maybe? I did some SML in a class, it seemed like a decent language.) (Plus I use specialized languages like SQL or XSLT.)

That's also partly why I'm not designing my own programming language. It'd be a lot of fun, but the language itself is only part of making it useful, and I couldn't do the rest. It's hard enough to get a community around a library; a whole language is all but impossible. I think most language designers are in it for the experience rather than expecting it to succeed. Java was something else...

ncm: Yeah, okay, they're both bad. I think I've got the C++ rant out of my system for now. The reasoning thing is a habit I can't break.

Sorry about the triple post, btw. My request timed out twice, and I didn't realize the post had gone through.

The only real problem with Java..., posted 7 Feb 2004 at 20:31 UTC by dej » (Journeyer)

...is that it is proprietary.

I cannot legally use Java in any way, without giving Sun the ability to impair my business. This does not hold true for C++.

The license that accompanies the JRE you can download from Sun gives you the right to use it to test your own applications. It does not give you the right to run other people's applications arbitrarily. I suppose you can buy a JRE from Sun for this purpose. But then Sun controls the license and pricing. Perhaps Sun will move to an annual subscription model. The subscription rate may be modest today, but that is not guaranteed to hold in the future. Do you really want to lock your business into that model?

There are "competitors" to Sun's Java, such as Kaffe but there's a catch in Sun's specification license that can put them out of business. If you implement Sun's spec, you guarantee that you will be able to pass a conformance test suite within six months of Sun releasing a new version. Open-source projects likely cannot meet that requirement. And never mind Sun's patents. Perhaps Sun has not enforced this to date, but that does not mean that they can't in the future.

C# has the same problem. Sure, the CLR and language itself are ECMA standards (assuming you can even implement the damn things without infringing on a patent) but the .NET class libraries, which are the whole point behind C# are, and will be, proprietary.

I'll stick with C++ thank you.

Java, the first progamming language with a PR budget, posted 7 Feb 2004 at 22:22 UTC by sej » (Master)

I knew something was fishy with Java the day I read an ad for it in my local Sunday paper (albeit the San Francisco Chronicle). Who had ever placed an ad for a programming language before? Why did it need a PR department? Oh yeah, that network effect thing. The emulation of Microsoft business techniques to fight Microsoft. And the whole Internet bubble mentality didn't help.

Java doesn't scale...down, posted 7 Feb 2004 at 23:25 UTC by davidw » (Master)

Ok, so there is the embedded device version, but that's not the same java that one uses elsewhere. And I mean it in a broader sense... the tools, the processes, everything seems to require a lot of ramp up both in human and machine terms. Lots of memory, lots of time to understand all the little pieces, and all the API's. It seems very difficult to "just whip something up". Which is probably no big deal if you are dealing with a huge project, but there are are a lot of times when you want to do something quickly. And Java does not do that well. My ideal language would scale better in that direction.

Press articles, posted 8 Feb 2004 at 03:59 UTC by Omnifarious » (Journeyer)

Philip Greenspun speaks. And I partly agree with him. Though really, that handling of SQL bind variables is quite abysmal. There's a C++ library that does it right, letting you associate local objects with bind variables, so I don't see why Java couldn't have done it that way is well, instead of using the horrible '?' construct.

And, someone at The Register has something to say as well. Though I think this person is dead wrong, mostly by omission. He ignores every other programming language in existence and decides that Java is the solution to the fact that C isn't very safe. Truth be told, even C++ is pretty safe if you don't use it like 'extended C' and take advantage of the language constructs that largely free you from most low-level memory management decisions. And I would recommend Python as a 'safe' language over Java any day anyway.

It also takes as an article of faith the fallacy that your programming language, not your OS, should be responsible for enforcing your security model. IMHO, OS security models are in need of some serious overhaul in order to deal with mobile code effectively, but the 'security model' (the model by which programs are granted access to system resources) is the OS' job, not theprogramming language's.

Another, posted 8 Feb 2004 at 14:44 UTC by ncm » (Master)

The inimitable Nick Moffitt posted this one, called The Language of Tomorrow, elsewhere.

:), posted 9 Feb 2004 at 03:02 UTC by gilbou » (Observer)

ncm : thanks for the link about nick moffitt's page. reading the part about oberon gave me my first laugh since 3 days. very good. makes me recall an oberon zealot that talked me about oberon and pascal all the time because he saw me coding some c code (was just an example of how to use va_args - pretty lame sh*t)

if is not a function!, posted 10 Feb 2004 at 15:22 UTC by redi » (Master)

Another reason I hate Java is because some people I know were taught to programme in Java and were taught that there should be no space between keywords such as if, while etc. and the following parenthesis:

    if(this->ok())
    {
        goto school;
    }
    else if (this->ok())
    {
        continue;
    }
I mean, come on! That's disgusting! It's not a function call!

This wasn't just a personal preference, this is what was taught! I hold Java entirely responsible for this.

If anyone needs me I'll be out the back, being sick.

Don't blame Java..., posted 11 Feb 2004 at 20:27 UTC by slamb » (Journeyer)

...blame the professors. Sun's coding standards say otherwise. Besides...

This wasn't just a personal preference, this is what was taught!

That just means it was someone else's personal preference. It's one I agree with (keywords should stand out) but your argument sucks.

blame the language designers ..., posted 11 Feb 2004 at 21:08 UTC by mslicker » (Journeyer)

for their inconsistent use of parenthesis. In C they have at least five meanings, operator (force precedence), function declaration, function call, syntatic sugar (if, while, switch).

..., posted 11 Feb 2004 at 21:14 UTC by mslicker » (Journeyer)

I said five, and listed four. Another might be to distinguish between parametric and non parametric macros.

Re: blame the language designers ..., posted 12 Feb 2004 at 03:27 UTC by tk » (Observer)

mslicker: The brackets for "if" aren't syntactic sugar, they're needed to separate the condition from the substatement. The alternative would be to adopt Perl's solution, which is to require every substatement of "if" to be in braces.

Recycling tokens for multiple uses isn't that bad either. Do you want something like APL, which has tons of weird symbols that don't even appear on the QWERTY keyboard?

redi: Actually some people also write function calls with a space just before the opening bracket.

C, posted 12 Feb 2004 at 14:02 UTC by mslicker » (Journeyer)

Technically, the following would work within the context of C:

if expression then statement

then could be replaced with any other token which doesn't introduce ambiguity. C has one extra token it doesn't need, so I think this is a form of syntatic sugar.

I don't consider C or any of the derivatives as good language design. It is not simply reusing tokens to mean different things. For type systems and type expressions I much prefer the Hindley-Milner system of type inference used in the context of the ML languages. C type expressions can be so incomprehensible I think there is even a program which translates them to english. Using two languages: a macro language which does text substitutions, and an actual context free language is simply horrid. Thankfully not many languages have repeated that mistake. There are many more things I don't like about C, but I'm too lazy to look through the standard and repeat them.

C too easy, posted 12 Feb 2004 at 16:19 UTC by ncm » (Master)

Complaining about C is shooting fish in a barrel. Most of its design comes to us unchanged from over 30 years ago. (The function prototypes in C89 were swiped from C++ more recently.) The languages designed since should be held to a higher standard: people designing languages today should know better. Despite that, not only do they fail to learn from experience and fix details that C got wrong, they often fail even to copy forward the details that C got right! C++ was constrained by its need to accept C89 programs. None of the other new languages (e.g. Perl, Java) have that excuse.

Selected quotes of Bjarne Stroustrup (designer of C++), posted 13 Feb 2004 at 05:19 UTC by mslicker » (Journeyer)

Bjarne Stroustrup's FAQ
"The first version of C++ was used internally in AT&T in August 1983."

"The first commercial implementation was released October 1985 ..."

"C++'s C compatibility was a key language design decision rather than a marketing gimmick."

"I consider C++ the best choice in programming language for a wide variety of people and applications."

"I never saw a project for which C was better than C++ for any reason but the lack of a good C++ compiler."

"The more general aim was to design a language in which I could write programs that were both efficient and elegant."

I post all this to point out the author of C++ would like you to consider C++ as a serious programming language on its own merits.

My personal opinion is that C++ is either a grand act of self promotion or gross display of incompetence.

Re: Selected quotes of Bjarne Stroustrup (designer of C++), posted 13 Feb 2004 at 08:32 UTC by tk » (Observer)

mslicker: When it comes to technical merits, C++ is one of those few languages that allow you to do low-level stuff, compiles to compact and efficient code, yet also has concise powerful syntax (how many languages allow you to specify matrix multiplication by saying a + b?). Perhaps Stroustrup is overselling C++ somewhat, but when I use C++, do I really care what he says?

Hey! This is supposed to be a rant about Java., posted 13 Feb 2004 at 13:31 UTC by Omnifarious » (Journeyer)

I consider C++ to be flawed, but workable, which is not the same opinion I have of Java. I'm very pleased with Nick Moffitt's article as it points out that Java isn't new in hardly any respect, and it mostly got all of its design decisions wrong.

I originally thought Java was a fantastic thing. It seemed like one of those technologies that Microsoft had to adopt, but couldn't because it destroyed their lockin. My opinion changed honestly, by actual use of the language.

On the Internet, nobody..., posted 14 Feb 2004 at 18:20 UTC by ncm » (Master)

On the Internet, nobody seems to be able to tell Java's a dog.

Java, posted 14 Feb 2004 at 19:56 UTC by mslicker » (Journeyer)

Yes, Moffitt's analysis in interesting, he even gives a nod to Forth which is rare in any commentary on programming languages.

I don't have a good critique of Java. The obvious thing to me is that it is sort of a least common denominator of programming languages. It is a programmer leveler, from my limited experience there is not much opportunity for advancement. The syntax is clunky, TheNamesAreOverlyVerboseAndUgly, the semantics are almost at the same level of C. I don't think there is a single aspect which functional languages like Caml don't do better.

Sun has fundementally the same objectives as Microsoft, they want to control the platform for which people develop and use software. If you control the platform you can turn the screws of anyone dependent on the platform. The design of Java is really secondary, mostly they want to apeal to what they thought was the present aesthetic, C-like syntax and semantics, object-oriented constructs.

I'm just glad no one is forcing to me program in Java or C++. Unfortuantely no one can completely escape the atrocities of the computing industry.

rantback, posted 17 Feb 2004 at 14:23 UTC by redi » (Master)

slamb, it's not an argument, it's a rant, and as such it doesn't suck; it's an opinionated, angry over-reaction over something fairly trivial. IMHO it's one of my better rants of the year so far!

tk, yes. I've seen people put spaces between function names and the parentheses too. I don't like that either. I'd blame Java for that too, if I thought I could. Bloody Java.

mslicker, this is about Java, not C++! Start your own anti-C++ rant somewhere else!

Some people just don't grok ranting.

Java: A Passive-Aggressive Rant, posted 17 Feb 2004 at 16:48 UTC by emk » (Master)

Java's a lovely language, if you want a server-based thingy that enforces a straightforward (i.e., minimal abstraction) coding style, and you don't mind the fact that basically every Java VM ever built is a festering pile of dung.

You know, if you took a real native-code Java compiler, and add support for closures, generic functions, hygenic macros, module-level code, and a syntax slightly less verbose than COBOL, then Java could be a really sweet little language. Oh, yeah--I'd like access to native system APIs, too.

My real complaint about Java is that it's a strictly less-expressive language than Common Lisp, but somehow manages to be far worse implemented. You know, MCL allowed you to write svelte Macintosh programs with native GUIs a decade ago, back on 25MHz 68040 processors.

Now, I can think of dozens of ways to improve on Common LISP. It could be made more accessible, less crufty, more optimizable, and given an infix syntax. It's not like it's the holy grail of programming languages. But it's a perfect example of the standards Java failed to meet. It's sad, really, to suck for no reason. Even C++ has some plausible excuses.

(This was a passive-aggressive rant. If you'd like a purely aggressive rant, ask me about people who try to use Java for real-time Windows multimedia applications.)

Sadly, neither, posted 18 Feb 2004 at 22:53 UTC by realblades » (Journeyer)

Mostly I agree with this, but IMHO Java is an utterly hideous teaching language. Amongst other things, it advocates an unproven silver bullet paradigm, is a (practically) proprietary platform and insanely heavy. All capital crimes.

Theoretically, you see the arguments and they make sense, but in practise it all falls apart. Arguing about it is most likely not worth the time.

Damages Walls, posted 19 Feb 2004 at 15:12 UTC by ncm » (Master)

Heads don't damage walls, Java damages walls!

While we're ranting..., posted 19 Feb 2004 at 15:48 UTC by tk » (Observer)

...I have reason to believe that Java is responsible for the 9/11 attack, the Holocaust, and other horrors. You see, when Arab students in the US encountered the Java language, they were so repelled by it that they decided to join the Al-Qaida, and you know the rest.

As for the Holocaust, well, Java didn't exist then, but Nostradamus did predict the rise of Java centuries ago, and this prediction itself was so powerful that it ate away people's brains and their ability to think critically. If a mere prediction has so much power, what do you think the actual language itself will do to your intelligence?

:-B

Re: While we're ranting..., posted 19 Feb 2004 at 23:26 UTC by mpr » (Journeyer)

Sorry, but I have to say that that was in rather poor taste. You've just asked for someone to come along and invoke Goodwin's law.

By the way, if this isn't enough of an argument to stay away from Java, I don't know what is.

Java Sucks! Lets fix it!, posted 19 Feb 2004 at 23:36 UTC by mjw » (Master)

How can this dicussion be without the famous java sucks rant of jwz!

Lets fix this once and for all!
Escape The Java Trap!
Free Software solutions at FOSDEM.

Re: While we're ranting..., posted 20 Feb 2004 at 03:37 UTC by tk » (Observer)

mpr: I saw that some other comments weren't exactly in good taste either, and I decided that it can't get that much worse... :-\ OK, I'll stop talking about politics and ideology on this thread (unless ncm decides otherwise).

Yes, Escape The Java Trap! Write In Assembly Language! :B :B :B :B :B

Kidneys?, posted 20 Feb 2004 at 04:17 UTC by ncm » (Master)

I'm still waiting for somebody to mention fetid dingos' kidneys, in context. That is all.

mooooooo, posted 20 Feb 2004 at 10:17 UTC by gilbou » (Observer)

come on. those fetid dingo's kidney are nothing compared to cows. cows will reign over this earth once we're wiped ourselve's out of it, and the sooner the better. if evolution has to be proven a good thing, we must annihilate ourselves :D

Godwin's law is *descriptive* dammit, posted 20 Feb 2004 at 13:58 UTC by mwh » (Master)

For the n-millionth time, Godwin's law is an observation, not something you invoke.

Hum, can't think of anything else to rant about today. Need more coffee, obviously.

Undergraduates, posted 20 Feb 2004 at 16:21 UTC by ncm » (Master)

realblades: It might seem a pity to sacrifice undergraduates to the cause of eliminating Java from the workplace. But, what the hell else are undergraduates good for?

So what makes Java so more widely used than Lisp?, posted 22 Feb 2004 at 00:01 UTC by atai » (Journeyer)

I know Java has "marketing" behind it, but we are talking computer-literate developers here, not the general public. The usage of Java vs. Lisp/Scheme should be much closer than what is it today. What have the common Scheme/Lisp implementation failed to make them popular (and there are much more of them than Java implementations)

how do you define computer-literate?, posted 22 Feb 2004 at 04:50 UTC by mslicker » (Journeyer)

There are probably a good number programmers familer primarily with C++. Someone who's primary expereience is with such wretched language is ripe to taken with a language like Java. I have heard this expressed, in this article and outside this article (to paraphrase), "Java is much better than C++". The comparison is solely with reference to the previous (current?) most popular language. Why was that language popular? What about the language before that? The assumption that language choice is informed is simply wrong.

Maybe in open source era things will change. Languages and operating systems will thrive on merit. At least one can hope.

Re: So what makes Java so more widely used than Lisp?, posted 22 Feb 2004 at 08:28 UTC by tk » (Observer)

The "computer literate" are, of course, not immune to market forces. Market forces affect what university m*n*gement decides to teach, and what the university types teach influence what the students learn, and what the students learn decide what language they use to code Free Software.

But now that MIT is aggressively marketing Scheme, the situation may change.

mslicker's analysis is incorrect. From my observations, those who actually know C++ tend to continue to use C++, despite Java's presence. Those who claim "Java is better than C++" often have next to zero C++ coding experience. What people say about languages has no relation to what languages they've actually used.

Re: So what makes Java so more widely used than Lisp?, posted 22 Feb 2004 at 16:22 UTC by mslicker » (Journeyer)

From my expereince it is the case that those who have done projects in C++ have taken to Java, but maybe that is the problem with this example, these two situations can coexist and we still don't know the reason for Java's popularity.

What is taught is important, because these people eventually work in industry and also write free software. Students are often not given free choice of language on programming assignments. Programming assignments in some industry fad language degrade the quality of computer science education and reinforce the sutibility of such languages. Besides one who only has experience expressing solutions in these languages is unlikely to grasp more abstract and expressive languages like Forth or Lisp.

Nonsense, posted 22 Feb 2004 at 16:42 UTC by ncm » (Master)

Languages taught in school have very little effect on what is used either industrially or for Free Software.

The advent of high-powered marketing has changed the landscape, because such marketing is aimed at hiring managers. Coders with no taste respond most strongly to what the help-wanted ads say, and so have been the vanguard of Java adoption. Fortunately they are not in the industry for the long term. Unfortunately, they are the ones who seek "advancement" to management roles, where they are in a position to do even more damage.

LISP, and Scheme, have been around for decades. They have had plenty of opprotunity to capture industrial usage, and they have had occasional, short-lived successes. (E.g. DSSSL.) That they have failed, ultimately, indicates something fundamentally lacking (or harmful) either in the language and its variations or in every one of literally hundreds of implementations. Everybody finds it fun to play with Scheme, but the things that Scheme is good at are not the same things that engineering rigor demands of a language.

The prototypical Java conversion, in the late '90s, ran like this: "My programming platform is fading fast -- everybody's converting to Windows. There's no way for me to pick up Windows programming fast enough, and anyway I could not claim years' experience in it. Java, though, is completely new, so nobody is ahead of me on the learning curve. I can start with Java now, and will still have a job when my shop converts to Windows." Meanwhile, managers saw that with all the hype, they would have ready access to lots of cheap Java coders. None of this process has anything to do with any merits or flaws in the language or its implementations.

Today, of course, anybody starting with Java is way "behind the curve", as they say, already. Fortunately, now there's GNOME and dot Net to start the churn over again.

The promise of portable skills was the impetus for the Pascal juggernaut two decades back. There was less money behind the hype, but Pascal (in all its forms) became as firmly entrenched in many places as Java is now. It was all washed away by C, and then C++. Pascal was taught in schools for years after it washed out of industry, but today not even cranks use Pascal (Kylix aside). Java has nothing to save it and anyone dependent on it (not least Sun) from the same fate, besides Sun's billions, but those won't last.

These hypefests must be recognized as the froth on top of the industry. It all blows away in the next windstorm. The bedrock used to be FORTRAN and COBOL. Now it's C and C++, although there's still lots of COBOL.

industry influence, posted 22 Feb 2004 at 17:49 UTC by mslicker » (Journeyer)

Java is an industry language, but so is C++, and so is C. All three have been marketed in one way or another. All three have had prominent positions in computer science education. Does anyone seriously sugest C++ would have been as popular as it was had it not been a product of Bell Labs, not been based on C, not been touted as the succesor of C? This is not even to touch the whole object-oriented fad which C++ has benefited from. The marketing of C and Unix to universities goes some way to understand their prominence.

My point was of the ultimate influence of industry, not of the intermediary influence of schools. The schools, for the most part, have subservently followed suit to whatever the present industry fad happens to be. This might not be the case with Pascal, but that is not to say computer science education is completely unaltered since days Pascal was taught.

Re: Nonsense, posted 22 Feb 2004 at 17:52 UTC by tk » (Observer)

But returning to atai's question, why's Java more popular than Scheme even among developers? Is it simply because Java's new and hyped? Also, I thought the conversion to Windows happened much earlier than Java -- Win95 was introduced in, well, 1995, and my current university was still teaching Pascal at that time.

(I also wanted to rant about Prolog, Lisp, and a certain dialect of Forth, unfortunately these are off-topic...)

I've long wanted to ask?, posted 22 Feb 2004 at 18:42 UTC by cmm » (Journeyer)

ncm: what is this "LISP" (note all caps) thing you keep mentioning?

Re: Nonsense, posted 23 Feb 2004 at 00:25 UTC by ncm » (Master)

tk: Why is Java more popular than Scheme among developers? It's not, really. Java is popular among managers, and is used by whatever monkeys they hire. Any time you post about how inadequate Java's design is, they pipe up about how language choices don't matter, they're all just tools, as if choice of tools doesn't matter. (Plumbers like that would wreck your pipes.) Still, it's true that it really doesn't matter to anybody they come into contact with.

That's not to say that Scheme actually is popular among developers, except in some abstract, wistful sense. Real developers deploy with C and C++. The reason was elucidated by Bjarne: C++ has more dynamic range than any other industrial language. That is to say that, having embarked on a project using C++, you will never discover that the problem has grown too big for the language to organize, nor that the language will prove unable to offer enough control to address low-level details.

A language with the heady semantics of Scheme, the level of control you get with C, and the architectural support you get with C++ could be instantly popular with real developers,and even supplant C++ for serious work. Nothing less will.

Java ain't it, that's for sure.

cmm: LISP as "Lisp" is a neologism. I write it as LISP out of respect for the people who made something truly new, almost fifty years ago.

OK, posted 23 Feb 2004 at 14:33 UTC by cmm » (Journeyer)

ncm: well, I could call C++ "BCPL" out of respect for the people who made something truly new (I'm not sure BCPL is deserving of that, mind you, this is merely an example), and then I'd say it failed.  nah, wouldn't work: nobody confuses C++ with BCPL the way almost everybody confuses Common Lisp with LISP 1.5.

btw: why do you mention this "LISP" together with Scheme, then?  that's another popular but completely unwarranted confusion.

(if you are bored with this, feel free to ignore me.  nice rant, anyway)

LISP, posted 23 Feb 2004 at 15:56 UTC by ncm » (Master)

cmm: Looking back at the original posting, I find I wrote "Common LISP". That's a typo, apologies. Common Lisp is one variant, Scheme is another, LISP includes them all. I mentioned Scheme, particularly, only because atai and tk did.

C++ did, in fact, introduce something wholly new: it made the STL possible. Java brought nothing new. Advancement wasn't Java's purpose. With a nod to Alex Stepanov: Java is really the world's first fear-oriented language.

real developers, posted 23 Feb 2004 at 16:52 UTC by mslicker » (Journeyer)

ncm, your message reminds me the phrase "real programmers use Fortran", I guess it is now "real programmers use C and C++". I think this is a sort of a rallying call of those using outmoded antiquated tools.

I'm hesitant to make sugestions to such "real developers". If you have learned to use such languages and do not see anything obviously wrong I don't know that there is much hope in this case. Far better languages do exist, including those with much greater scalability than C++. Those that are interested do not have to look to far.

I avoid C++ like the plague. I've never seen anything good expressed in the language, I've never seen a reason to use such a lanugage. It is takes the ad hoc quality of the C design to even greater extreme, in that sense maybe it really is C++.

oh well, posted 23 Feb 2004 at 16:57 UTC by cmm » (Journeyer)

> I find I wrote "Common LISP". That's a typo, apologies. Common Lisp is one variant, Scheme is another, LISP includes them all.

you try to be nice and don't tell people outright that they don't know what they are talking about, and they just ignore your hints.  I'll be more direct, then: your lumping Scheme and CL into one category tells me that you haven't really looked beyond the syntax, much less used both Scheme & CL seriously.  so why talk about stuff you don't know much about?  your rant won't be any worse if you just don't mention "LISP" there at all.

> C++ did, in fact, introduce something wholly new: it made the STL possible.

STL is an amazingly labor-consuming and pointless thing to use (and an exceptionally ugly thing to look at, to boot), which anyone familiar with either serious polymorphic type systems or Lisp macros could tell you, and I'm sure some had; having sinked untold man-years into learning how to fight C++ both makes a man stronger and seriously blind him to reason.  STL can surely be considered an innovation, if your main metric is pain.

> Java brought nothing new.

Java brought the first mainstream programming language that is both reasonably general-purpose and reasonably safe.  that's the idea, anyway.  shame about the current implementations, but nothing rational precludes better ones (you could consider C# to be a better implementation of Java, broadly speaking.  C# is surely miles closer to Java than Scheme to CL, so why not?).

Re: real developers, posted 23 Feb 2004 at 17:46 UTC by tk » (Observer)

mslicker: Real programmers use machine code.

And, since you can't stop ranting about C++, here's a rant of mine...

First, do we all agree that any language which is more painful to use than even assembly language, isn't worth looking at? Yet, such a language exists, and is even touted as a "more abstract and expressive language" right here. Consider:

  • Writing "Hello world" in nasm is relatively straightforward; in the More Abstract And Expressive Language, even specifying the string "Hello world" is an operation to be attempted only by wizards.
  • x86 assembly gives you direct access to 7 high-speed storage locations (= registers); the More Abstract And Expressive Language only allows direct access to 2 (or maybe 3), and makes you play silly games just to deal with more variables.

But of course, those who complain about the More Abstract And Expressive Language clearly have no taste, and no skill, and are seriously brainwashed! Sorry, but what I said above applies regardless of taste, skill, or brainwashing.

Oh well, some people are just looking for a fight.

Testy, testy, posted 23 Feb 2004 at 18:01 UTC by ncm » (Master)

cmm: There's no call for testiness here. LISP refers neatly to a whole family of languages. The common heritage of CL and Scheme is evident to the most casual observer. ... That was a pretty good rant about the STL, albeit a bit out of place here. ... As mainstream, general-purpose and safe languages go, I think Python predated Java. I do see C# as just a minor improvement to Java. Very minor; but its designer is clearly way, way smarter than Gosling, despite that he kept in many of the most stupid design features of Java. (Anybody want to buy a used stack VM?)

mslicker: Again, ranting about C++ is a bit out of place here. I wasn't just expressing an opinion about deployment languages; that was objective fact. Look at the implementation language of the packages in your favorite distro's repository. Among the compiled ones (i.e. excluding scripts) you'll find they're mostly C, with plenty of C++, and not much else (although among which, notably, is unison in OCaml), except among the stuff that's just for the monkeys already obliged to use Java.

If you fail to understand precisely the virtues that have made C, and that make C++, successful, you will certainly fail to recognize what makes a language "far better". Instead, you will spend your career grousing about sour grapes as you potter ineffectually. It wasn't massive marketing ploys that made C++ successful; C++ got all of US$3000 in marketing support from AT&T. It wasn't because engineers with serious responsibilities are en masse much more stupid than yourself. Suffice to say here (getting resolutely back on-topic) that Java lacks those virtues.

Re: real developers, posted 23 Feb 2004 at 18:30 UTC by mslicker » (Journeyer)

tk, if a language causes you pain, then move along.

I've not experienced pain in language we are both privy to.

For those scracthing their head, the language in question doesn't have the concept of strings built in. Of course to implement strings would require more or less the same code that is included in languages that support strings.

The simple reason for no strings, is that the language has a small close-nit community and no one has used the language for text processing. The standardized version of the language supports strings by default and can express Hello World in following program:

." Hello World"

As probably most who read this know, register computation is nice until to you have to actually start making your own abstractions. I would not recomend a language which does not support higher levels of abstraction.

No I'm not looking for a fight. The heritage of Java is C and C++, no one can deny this. If Java is called for being unprincipled, I think C++ should be treated similarly. An instant user base was more important to the designer than taking any kind of principled stand on language design.

Experience with Java HotSpot, posted 23 Feb 2004 at 20:35 UTC by nymia » (Master)

I remember quite vividly my experience using Java HotSpot running on a Solaris box. Boy, it was terribly slow. I figured those guys who developed HotSpot must using a really fast machine, though.

Java Generics, VM, posted 23 Feb 2004 at 23:39 UTC by nymia » (Master)

Anders Hejlsberg commented about Java's strange implementation of strong typing in the area of generics, in relation to the aging VM. And it is quoted below.
Java's generics implementation was based on a project originally called Pizza, which was done by Martin Odersky and others. Pizza was renamed GJ, then it turned into a JSR and ended up being adopted into the Java language. And this particular generics proposal had as a key design goal that it could run on an unmodified VM [Virtual Machine]. It is, of course, great that you don't have to modify your VM, but it also brings about a whole bunch of odd limitations. The limitations are not necessarily directly apparent, but you very quickly go, "Hmm, that's strange."

For example, with Java generics, you don't actually get any of the execution efficiency that I talked about, because when you compile a generic class in Java, the compiler takes away the type parameter and substitutes Object everywhere. So the compiled image for List<T> is like a List where you use the type Object everywhere. Of course, if you now try to make a List<int>, you get boxing of all the ints. So there's a bunch of overhead there. Furthermore, to keep the VM happy, the compiler actually has to insert all of the type casts you didn't write. If it's a List of Object and you're trying to treat those Objects as Customers, at some point the Objects must be cast to Customers to keep the verifier happy. And really all they're doing in their implementation is automatically inserting those type casts for you. So you get the syntactic sugar, or some of it at least, but you don't get any of the execution efficiency. So that's issue number one I have with Java's solution.

Issue number two, and I think this is probably an even bigger issue, is that because Java's generics implementation relies on erasure of the type parameter, when you get to runtime, you don't actually have a faithful representation of what you had at compile time. When you apply reflection to a generic List in Java, you can't tell what the List is a List of. It's just a List. Because you've lost the type information, any type of dynamic code-generation scenario, or reflection-based scenario, simply doesn't work. If there's one trend that's pretty clear to me, it's that there's more and more of that. And it just doesn't work, because you've lost the type information. Whereas in our implementation, all of that information is available. You can use reflection to get the System.Type for object List<T>. You cannot actually create an instance of it yet, because you don't know what T is. But then you can use reflection to get the System.Type for int. You can then ask reflection to please put these two together and create a List<int>, and you get another System.Type for List<int>. So representationally, anything you can do at compile time you can also do at runtime. [1]
More info can be found in the talkback section.

Rant?, posted 24 Feb 2004 at 00:42 UTC by ncm » (Master)

That Anders Hejlsberg is hardly incoherent at all. I can only understand how appallingly awful C# is by assuming that there were corporate political reasons to copy most of Java's worst ideas unchanged.

Re: real developers, posted 24 Feb 2004 at 02:14 UTC by tk » (Observer)

mslicker: Gah, modern assemblers have macros, and everything else that Your Favourite Language Dialect has. It does support the "higher levels of abstraction" you have in mind (whatever those are). Allowing direct access to only 2 values just means that you're forced to think at "higher levels of abstraction" when you can simply bang in the solution at a lower level. w00t!

And yes, it's a "close-nit community". The nits in the language dialect are closed and treated as sacred, to remain there forever and ever, until the Grand Creator decides otherwise.

Your Favourite Language Dialect is strictly more painful to use than assembly language, regardless of taste, skill, brainwashing, community, or even problem domain. It's not worth looking at. This is an objective fact.

Java's sin isn't being "unprincipled". Programming languages are created to let people do tasks, not to adhere to so-called "principles". And for Java and Your Favourite Language Dialect, there's no task in which you can do better in this language, than in some other language.

The minister of truth returns!, posted 24 Feb 2004 at 02:40 UTC by mslicker » (Journeyer)

So glad you could visit, and proclaim the opposite of reality. Which modern assembler can mix interpretation and compilation? Which modern x86 assembler supports procedures? What is that I hear? You need a calling convention? So you have a clusmy C without the portability of C, what an advance for programming!

The the only close nits I see here are fools who arrogantly proclaim to know objective truth then procede to fall flat on their face.

What is that? Did I hear a *sigh* ?

Sigh, posted 24 Feb 2004 at 02:54 UTC by ncm » (Master)

Yes, that was a sigh. The topic here is what stinks about Java, and why. Please talk elsewhere about how stinky your bastardized Forth is, unless you can demonstrate how its particular foulness resembles Java's.

wrong, posted 24 Feb 2004 at 02:59 UTC by mslicker » (Journeyer)

The topic is about disgruntled C++ hacks complaining about their Java replacements.

Re: wrong, posted 24 Feb 2004 at 03:53 UTC by tk » (Observer)

mslicker:

Yes, Mr. Minister of Truth. It's so typical of Your Excellency to dictate what the subject of a thread is.

And you keep talking about the "principles" of language design like some sort of religion. I say, the only principle I follow is that a language must be relevant to the world. A language feature's only important if it contributes to the solution of some practical task.

(But wait, mixing interpretation and compilation is sooo useful, you know! By the way, how many times have you used this feature for anything other than substituting constants and other static structures, or just doing administration like loading blocks?)

(And procedures? It's next to trivial to adopt the same calling convention as Your Favourite Language, but I have the freedom not to. Freedom is a good thing, no?)

ncm: One resemblance is that both are touted to support "high-level abstraction"... well, but only one of them has actually been used for real high-level tasks.

What is Java's "sin"?, posted 24 Feb 2004 at 04:01 UTC by mslicker » (Journeyer)

Getting back on topic, as if I am dictating it!?! The Minister has talked about sins, what are they? Which commandments of the Minister did Java break?

Java is not safe, it is not general purpose, it is a pile of steaming dung, posted 24 Feb 2004 at 08:40 UTC by Omnifarious » (Journeyer)

I can still easily get a NULL pointer exception in Java, and my program dies just the same. It is not safe. In fact, you could argue that Java is less safe than C because routine IO errors that most C programs ignore cause fatal exceptions that crash the program if improperly handled in Java.

I despise the stupid "It's safe!" argument for Java. It's not only wrong, but it's a bad reason to choose a language. A language should be chosen for what it allows you to express easily, not what it prevents you from doing.

Java is also not general purpose. Java is useful for only one thing, writing programs for the JVM OS. The JVM OS is an ad-hoc creation with an ill-defined, constantly changing specification that relies on the details of the language the programs are implemented in in order to implement such rudimentary concepts as memory protection. It has a poorly implemented security model that's a vague reach towards some sane capability based model, but falls rather short. Not only that, but it runs on no real hardware, and requires a whole extra OS underneath it to function. Until Java 1.4 it didn't even have a decent IO multiplexing capability and you had to wade through a nightmare of hundreds of threads if you were going to write a serious server application.

Lastly, the language is very poorly expressive. Until recently, it had no generic type manipulation facility. It still doesn't have continuations or closures. It has no concept at all of a function as an object to be manipulated. Yet, it is statically typed, and runs more slowly most of the time that languages compiled to native code. One would think that a garbage collected language might have some decent features like closures, or continuations. But, no, it has to leave those things to Python, Ruby, lisp or perl. It can't even get introspection right. Java's introspection is extremely clunky to use if you're used to Python or lisp, (and possibly Ruby) where introspection is built right into the language constructs.

I don't understand how anybody could actually defend Java as a serious programming language and mean what they say.

If you want things to run fast, or need access to low level details of how the machine works, then use C++ (or maybe C). If you need expressiveness and rapid prototyping, use Python, Ruby, lisp or perl. All of those languages are much better than Java, even perl.

But still...., posted 24 Feb 2004 at 14:08 UTC by Malx » (Journeyer)

If you look at Java as a platform, not a language...

Still there is such a thing as "Java Applet". And there is not such a thing for any other _compiled_ language. You will not find that other one in IE or Mozilla package.

JavaScript (and other scripts) are not compiled. It is essential for commercial (esp. banking) applications.

If you do not know what is special in Applet try to search for "sandbox".

The same thing for Java-MobilePhones. And (IMHO) for Java web server modules. You just limit java application to certain abilities and not more.

Please, when you would post new comments specify that you are talknig about Java-language, Java-libraries, Java-embeded or Java-VM-OS thing. They are all different thing. And please make flames about "Java-VM-OS vs Linux,Window", "Java-language vs C++". Do not mix them! :)

Re: But still...., posted 24 Feb 2004 at 17:40 UTC by redi » (Master)

Malx:
JavaScript (and other scripts) are not compiled. It is essential for commercial (esp. banking) applications.

Surely only if your banking application has to be browser-based? There are plenty of compiled (and even networked!) applications that aren't written in Java. You can wheel out the argument that Java applets are more portable, but I'll need quite some convincing that most of them work with any VM other than that which ships with Windows.

The most common uses of Java applets I see are as small animations to (for example) demonstrate the movement of particles in a physical model, or show the behaviour of sorting algorithms in real time. Even most games on the web use Flash instead of Java. I realise there are more useful applets that I don't see, but we're not exactly talking killer apps, are we.

mslicker:

The topic is about disgruntled C++ hacks complaining about their Java replacements.

Haha! Nice one. Until this remark I thought you were serious. You had me going there, I didn't realise you've been joking all along. Well trolled. ;-)

Free Software Builds, Open Source Begs?, posted 28 Feb 2004 at 02:55 UTC by ncm » (Master)

I had posted these in response to ESR's begging Sun to hand him Java.

The Open Source world (or, anyway, the Open Source Initiative, or maybe just ESR) is in pretty sad shape when it finds itself pleading with some rapacious corporation to free a badly-designed language created, in the first place, just to attack some other even-more rapacious corporation. Sun is free, and welcome, to make itself irrelevant to Free Software, and the world at large. It would already be forgotten if not for its multi-billion dollar bank account, which (incidentally) feeds OpenOffice and SCO alike. Java itself is already irrelevant to Free Software: Java needs Free Software, but Free Software doesn't need Java. (I.e., there is substantially no Free Software written in Java for use by anyone not already obliged to use Java.) As Sun fades from our minds, so will Java, and good riddance to both.

It makes me feel better to think that Free Software is not in similarly sad shape. Then I look at the Mono and dotGNU projects. They're not begging anybody, exactly. One might say, rather, that they're asking for it. I'm not sure which is worse.

I guess this is what the mainstream is like: fools make themselves irrelevant, the rest of us (or "them", maybe) go about our business, and it all comes out OK, because we're not in the middle of an apocalyptic struggle any more.

and
First, Sun is not interested in sharing success with Free Software, even if not sharing might mean failure. All the value for Sun in Java lies in its possible use against perceived competitors; to give that up would be to eliminate all its value, because it has no monetary value. As we will see, it wouldn't matter if they were willing, but it degrades Free Software to be seen begging for scraps when it is, in fact, in the position of strength in the real world outside of the Java fence.

Second, Free Software would not benefit from any influx of Java usage; it is to our credit that Java usage is substantially confined to those already obliged to use it for various more-or-less proprietary reasons, and that JVMs are only very spottily deployed on Linux and BSD hosts. Java's design was meant to attack problems that Free Software just doesn't have, and its means of solving those problems actually interferes with addressing the problems we do have. Every problem solved without Java is to our credit, and every problem solved with it creates further problems.

Third, any merit that might be found in Java inheres necessarily to a greater degree in C#, which is already substantially Free (as an ECMA standard) and which corrects many (but not most) of Java's fundamental design flaws. While C# has the same fundamental problems alluded to in the second point above, it bypasses the legal and proprietary problems Sun has imposed, even though it still reserves a rapacious corporation's ability (via promotion of proprietary libraries) to stab Free Software in the back at any opportune future moment.

Therefore, if Java were the answer to anything, C# would be a better answer, and any attention devoted to begging Sun for Java bones would be better spent on implementing the ECMA C# standard. Contrariwise, if C# is not the answer, then Java certainly isn't. The only value in either language is to the proprietary software industry. Any Free Software attention to them delivers value to the Free Software community only insofar as it helps lead proprietary software users over the fence to freedom.

What about D?, posted 2 Mar 2004 at 22:14 UTC by jds » (Journeyer)

So how come nobody has pointed us to D already?

http://www.digitalmars.com/d/

Looks cool.

Re: What about D?, posted 2 Mar 2004 at 22:29 UTC by mpr » (Journeyer)

These people are so cool, they even provide a compiler for Linux. A closed-source compiler:

Put dmd/bin on your PATH, or copy the linux executables to /usr/local/bin

Yeah. Mad cool, yo.

Re: What about D?, posted 3 Mar 2004 at 03:33 UTC by ncm » (Master)

Great, D sounds like Gcj, but without a standard library, and built-in strings... but it can call C libraries! Order today!

Altogether more interesting, at least in an academic sense, is XL. It's not clear if it has a brighter future than D, but at least it explores new territory. The ML family of languages, particularly OCaml, have demonstrated some practicality, but I haven't seen any variants, yet, that aren't GC-ridden.

If there's anything the world doesn't need, it's a rehash of Java.

Java is obviously better than C++, posted 3 Mar 2004 at 05:37 UTC by trance9 » (Master)

"I can still easily get a NULL pointer exception in Java, and my program dies just the same."

try {
     thirdPartyComponent.doWhatever();
} catch (Throwable t) {
     logger.trace("Skipping functionality X: it's buggy");
}
doTheMainThing();

At worst one user transaction failed because of the NPE; the system did not segfault; it did not corrupt memory; it did not crash. It probably returned an error to the user on this request while continuing on serving other users, and it probably served the next request from this user just fine as well. It did not do what C++ would have done, which is crash down the whole application, killing off every thread, even though none of the others encountered any error.

Also, C++ on unix system is a bloody disaster. Nobody can agree what API to use, and so you can't usefully link components together into a whole application. Everybody re-invents the wheel, and writes their own stupid collection of utilities, which everyone else has already written. Your application can't be linked with mine because you used KDE and I used GNOME. It's retarded. At least on Windows everyone uses a standard set of APIs and as a result you can combine C++ applications together into cohesive wholes--on Unix C++ simply sucks.

If you and I independently write some server-side application in Java and then try and integrate our work together we will succeed: it will turn out that we both used the servlet API, we both used JDBC, we both did our name lookups with JNDI, we used the same garbage collector, we used the same format property file, etc., etc., etc., and so it will turn out that everything just works. Had we gone off to write independent C++ then GOOD FRIGGING LUCK ever getting them to link together into a single application. We'd probably even argue over what compiler to use, let alone agree on everything from database access through directory lookup. Unless of course we wrote our C++ application on Windows, in which case we'd have a chance as we _might_ have used the same Microsoft APIs. For all their warts the Java APIs are standard and widely used, and that fosters interoperability and integration to a level that C++ programmers on Unix simply don't comprehend.

I called this post "Java is obviously better than C++" but also PERL is better than C++. Even lowly shell scripts are better than C++, and of course C++ is better than Java, shell scripts, and PERL as well: it always depends what you are doing. If you only know one language you will start rants saying that some other language sucks, or that your language is better, or whatever. If you are a real developer you know four or five programming languages and you know that each one has its purpose. Whoever thinks Java and C++ compete doesn't really understand either langauge. They are different langauges with different purposes. Use C++ to write low level system components, and Java to write middleware. Use PERL to parse logfiles. Init scripts ought to be written in Bourne shell. And so on.

Now please, will you all shut up?

Common API my foot, posted 3 Mar 2004 at 06:54 UTC by tk » (Observer)

trance9: Unless you write a server-side application using WebMacro, and I write a server-side application which uses anything other than WebMacro. Now try integrating that.

Your comparison is bogus anyway. You talk about GUI applications in C++, but server-side applications in Java. If I try to integrate two GUI applications in Java, one application uses AWT, and the other uses Swing... Common API? Yeah, right!

And I can easily catch NULL exceptions in C++ too, just by setting a signal handler. I guess that's what Java also does internally, except it adds a huge bloated layer on top of this simple mechanism.

Using Java to write middleware is a joke. I may as well use Python.

Oh, wow., posted 3 Mar 2004 at 12:40 UTC by ncm » (Master)

trance9: That started out as a pretty good rant -- ignorant, bombastic, even if strictly off-topic -- but it devolved into trying, tediously, to make sense, and then failing. I would be embarrassed to post something demonstrating so conclusively that I had missed the whole point of the thread.

webmacro, posted 4 Mar 2004 at 03:58 UTC by trance9 » (Master)

Tk: If you built one page with WebMacro and another with JSP they still would both be based on the servlet API, so they would share session objets, authentication tokens, resource dispatchers, connection pools, thread management, garbage collection, collections APIs, and so on. Not every API in Java has been standardized. Certainly some people use log4j while others use java.util.logging; certainly I've advocated WebMacro in place of JSP. There are a lot of exceptions, but the point is that so many important APIs _have_ achieved standardization. Nobody thinks about using the servlet API, JDBC, Java collections, etc., they just do--and as a result everything integrates well, such as WebMacro pages sharing session objects with JSPs. With C++ you still think about whether to write your web application as an Apache module or something else: there's no standardization for that. It's also true I gave a wide range of examples from GUI to server-side, but if you want to concentrate just on server-side APIs consider the problem of competing garbage collectors and memory managers, database access libraries, authentication mechanisms, web session architectures, and so on

The point here is not that there is some intrinsic superiority in the Java technology but rather that the API standardization effort that is now encapsulated in the JSR process has had benefits: replacing log4j with java.util.logging is a hell of a lot easier than redoing your entire approach to session management.

As for signal handlers instead of catching null pointer exception properly, that is SO PAINFUL. It does not localize control over the fault in the specific module where it occurred, it does not allow you to determine easily what segments of processing are now unreliable, and it doesn't work all that well in a multi-threaded application. What I need is a way to wrap calls to a third party component that I don't necessarily trust and catch any nonsense coming out of it cleanly and effectively, which means all acquired locks are properly released, database connections and filehandles properly closed, etc., and all of that is virtually automatic with Java exceptions. Sure there is a cost--the exception handling code in Java is *very* expensive, at least compared to a signal handler. But we were building middleware applications, not database servers, so that's OK. Use of time-saving abstractions that guarantee correctness is not an argument agaisnt a language used primarily to develop middleware.

- -

ncm, my point is that Java is a better choice than C++ for many classes of problems, C++ is a better choice for others, and PERL is better than either language for still other categories. You think I'm missing the point because all YOU want to talk about is how this or that thing said by some toothy Sun marketing droid turned out to be vapourware, and this or that initial strategy or claim didn't pan out.

So what?

I don't give a rats ass what Sun thinks I should do with Java, and honestly neither does anyone else. We use the language because it fits our purpose. Who cares that our purpose is not what Sun expected? We repurposed the technology to our own ends, and Sun _reacted_ to that by rolling out the "Java is enterprise" strategy to catch up with what we were doing. I implemented the Model-View-Controller idea for Java servlets in WebMacro (and I was not alone: freemarker, etc.) long before Sun _reacted_ to our way of doing things by creating Model2 JSPs. Sun may spin it as they please--but they have essentially played the role of mediator, rolling key technologies or ideas developed or proposed by others into a standard framework. That's now the explicit manner of Java's extension, in the JSR process.

Your assertion is that there has been some "crime" and that implies a criminal somewhere who controlled everything and made all the choices and decisions: there was NO SUCH PERSON. Sun had no idea how we would wind up using the technology, and it matters not one bit that what we wound up doing is somewhat different than they predicted. To accuse Sun of being somehow criminal is to pretend that they had far more control over the things Java wound up being used for than they actually did.

Sun spent many marketing dollars marketing the Java security model and in the end nobody much cared: practically everyone ignores the security manager. They promoted some kind of inane GUI interoperability for AWT, and nobody in their right mind uses it. On the other hand I get immense value out of my servlet containers, out of JDBC, and the truth is that write-once/run-anywhere IS a reality for everything I actually do: server-side, client/server, middleware, non-GUI, daemon type stuff. I routinely deploy my code across heterogeneous platforms without giving a thought to what OS is running there--I just promote it through some network API and it goes live. Was it NT? Was it Linux? Was it Solaris? How should I know? Why should I care?

You missed the point when you concentrated on what Sun said rather than what we did.

Apologetics, posted 4 Mar 2004 at 05:00 UTC by tk » (Observer)

Sure there is a cost--the exception handling code in Java is *very* expensive, at least compared to a signal handler. But we were building middleware applications, not database servers, so that's OK.

Wow. Middleware applications should be as slow as a dog? Where did that excuse come from?

It [C++] does not localize control over the fault in the specific module where it occurred, [...] What I need is a way to wrap calls to a third party component that I don't necessarily trust and catch any nonsense coming out of it cleanly and effectively, which means all acquired locks are properly released, database connections and filehandles properly closed, etc., and all of that is virtually automatic with Java exceptions.

And that's probably because you see C++ as nothing but a `souped-up' C, without noticing its more powerful features. For example, if you define an object in a C++ lexical scope, when the object goes out of scope the destructor automatically kicks in... and, C++ does have exceptions.

Proving My Point, posted 4 Mar 2004 at 06:18 UTC by ncm » (Master)

trance9: It's not necessary to demonstrate my last point so forcefully and repeatedly. We know of your kind.

Poor lost lamb, when in ten years all your Java experience is valued alongside your high-school "permanent record", will you look back fondly on your time churning out reams of code to be discarded at Sun's first hiccup, or will you gnash your blackened teeth and writhe fitfully in your filthy cell, spitting and cursing your undeserved fate? Only time will tell.

Crippling Flaws, posted 5 Mar 2004 at 03:59 UTC by ncm » (Master)

From LWN:

It diverts resources from production of more robust tools and applications. Java programs are unavoidably crippled by language-design choices meant to serve proprietary companies' need to distribute closed binaries. Free Software has no such need, yet suffers as much or more from the crippling.
Could you elaborate more in the subject, please ? I've been programming in Java for a few years, and although I agree it has many flaws, I never had the feeling that my programs were crippled for the reason you say.

Execution of Java programs on Free Software systems has long suffered from the inadequacy of the JVMs available. Some of these inadequacies are incidental, and might someday be fixed. Others arise directly from the language definition, making it impossible to optimize as fully as if source code were available. The language itself interferes with optimization, as well, so that Gcj (which compiles to native code) cannot optimize as well as a good (e.g.) C++ compiler can.

Surely you've noticed that your programs run much more slowly than the equivalent C++ program? Doesn't running half as fast, achieving half as many transactions-per-second, taking twice as long to finish, costing twice as much, or needing twice the processing power, count as crippled?

But there's more. The language's cargo-cult design makes any program written in Java substantially longer and more full of "noise" text than in a more thoughtfully-designed language. Its exception apparatus adds enormously to the textual overhead needed to handle errors, without making programs correspondingly more robust or simple to maintain. Its enforced garbage collection means that you have little control over the memory management, and general resource management, needed to tune performance and compensate for the poor low-level performance of the JVM. The garbage collection interferes with cache locality, so that programs often run from main memory instead of from cache, at an enormous speed penalty.

How closely are these flaws tied to the requirement to deliver machine independent binaries? How much is just bad design, how much immature implementation, and how much is fundamental to the goal? It doesn't matter much: absent the requirement, the flaws do not arise.

Java's aims oppose Free Software's, posted 5 Mar 2004 at 16:40 UTC by redi » (Master)

trance9:
the point is that so many important APIs _have_ achieved standardization

How standard?

Java APIs are standard and widely used, and that fosters interoperability and integration to a level that C++ programmers on Unix simply don't comprehend.

I think you'll find C++ programmers on UNIX are quite aware, and quite fond, of the high level of interoperability and integration that they get from UNIX's Standard (as in real standard, not proprietary) libraries and the high level of source code compatibility you get on POSIX platforms, even with C++. But those features of UNIX that fostered the Open Source revolution are almost directly opposed to Java's targetted uses.

At least on Windows everyone uses a standard set of APIs and as a result you can combine C++ applications together into cohesive wholes
At least on Windows noone has a choice of APIs so the question of standards is irrelevant. Anyway, that's only one platform. If you consider any one UNIX platform such as KDE, or GNOME, you'll find a common set of APIs and libraries. And that platform works on multiple OSs and multiple architectures. What was your point about Windows again? That you can link binary objects from separate sources? Why would you need to do that if you have the sources? Oh, so you mean "at least proprietary libraries on a proprietary OS on a single architecture work together" ? Stunning. That degree of interoperability simply leaves me breathless. This "advantage" shared by C++ on Windows and Java is of no benefit to me or, as ncm maintains, to Free Software.

With C++ you still think about whether to write your web application as an Apache module or something else: there's no standardization for that.
God forbid you should have to think about the best way to deploy your application and consider the choices available to you.

I wouldn't ask you to stop using Java, but please don't ask me to use it, or even appreciate it for its merits.

sum, posted 6 Mar 2004 at 01:46 UTC by trance9 » (Master)

tk: Nowhere did I say that middleware applications should be slow. What I said was that proper exception handling is a higher level abstraction than signal handlers and there's nothing wrong with paying a price for that: If you implemented the equivalent logic in C++ not only would your project be late because of all the extra work you have to do, but it'd also be much slower than jumping to a signal handler. Yes, C++ does have exceptions, how well are they working for you? Are they turning your segfaults into exceptions? Are they freeing all the resources allocated when they throw? Can you implement this method in an exception safe manner: template <class T> T Stack<T>::Pop()?

- - - -

redi: By "standard" I mean defacto standard: widely available, widely used, and well specified. I'm not speaking to the standards process, but rather whether two applications are likely to have done the same things in the same way. My point about windows (and Java) was NOT that you can "link objects from different sources" but rather that, given the source code, you can work them together into a single application without much difficulty. The C/C++ standard libraries are good enough that indeed you can can compile your program on any platform. That's not good enough. I need to be able to integrate independently developed high level abstractions together as components or else the language is useless for middleware. To be blunt, "fopen" and "strcpy" are simply not in the same league as "extends HttpServlet" and "InitialContext.lookup()". The corresponding C++ abstractions, at that level, are not standard at all, and any two applications likely rely on radically different architectures, making them hard to integrate whether or not you have the source code.

I'm not asking you to use Java. I am pointing out that for large classes of problems it's a better language than C++ is. Here's my point, again, in different words: I am a C++ developer. I am a Java developer. I am a PERL developer. I am willing to use whatever language best suits the task I have before me. These languages do not compete with one another. They are good at different things. It's your loss if you limit yourself to using a hammer when you encounter a screw.

Stupid C++ myths debunked, posted 6 Mar 2004 at 06:49 UTC by tk » (Observer)

trance9:

Wait, have you ever heard of #include <iostream>, #include <string> and their ilk? And do you know just how standard these things are? Do you know that try, catch, and throw are keywords in C++?

Where do you get your C++ information from anyway?

True, different languages can be good at different things. But Java is good for nothing.

To add, posted 6 Mar 2004 at 08:36 UTC by tk » (Observer)

By the way, when was the last time anyone used strcpy() in C++-only code? Pretty long ago, I guess.

In any case, I don't find the argument that "Java is good, because it leaves people with no choices" very appealing.

tk, posted 7 Mar 2004 at 18:17 UTC by trance9 » (Master)

iostream/string are extremely low level abstractions. Low-level file manipulation and the existence of strings are somewhat trivial compared to JNDI, JDBC, Servlet, EJB, and so on. If you want to play in the middleware space C++ will have to grow up a bit in this respect.

You didn't followup on my gripe about C++ exception, see if you can spot the errors in this code:

template <class T> T Stack<T>::Pop() {
  if (vused_ == 0) {
    throw "Empty stack";
  }
  T t(v_[vused_]); 
  --vused_;
  return t;     
}

Tricky huh? That's because exception handling in C++ causes more problems (aka resource leaks) than it solves. Yes you have the keywords in the language now, but no they don't simplify automatic resource and lock release, which is what exceptions are for. In fact, they make it more complex, introducing new classes of subtle errors, as the above example shows.

Go Away, posted 7 Mar 2004 at 21:25 UTC by ncm » (Master)

trance9: Q: Which is worse, to be tedious, or wrong? A: It doesn't matter, when you're both.

Do you really want to be exposing your deep ignorance so assertively and publically, where anybody googling for Justin Wells will easily find it?

try it ncm, posted 8 Mar 2004 at 00:29 UTC by trance9 » (Master)

Hey, I could be wrong--if I am, I'm mature enough to take it. Here's my understanding: the implicit copy in the return from the above can throw an exception, which happens after the counter has been decremented, and so it's impossible to restore the stack to a valid state in any catch clause. My understanding is that it's for this reason that the STL implementation splits it into two methods, one which accesses the top element, and a separate one that pops the stack with a void return. I could be wrong--let me know if I am.

You started this rant but now it looks like you can't take it. Reading back I note that you've never made any substantive points--others have compared material aspects of the two languages features and capabilities, but you've just posted base speculation with absolutely nothing to back it up. My guess is you know nothing about it.

Come up with some substantive material to back up your inane claim or go away yourself.

Exceptions and middleware and reuse, posted 8 Mar 2004 at 08:31 UTC by tk » (Observer)

trance9:

Constructors throwing exceptions are problematic, but the problem isn't that insurmountable.

And on high-level abstractions: oh, Heaven forbid that a middleware program should ever use those primitive things called iostreams! No, the future lies in interfaces with names like AgentBrokerHandler, WankageBreaker, GenericBusinessObjectAbstraction, ... no one knows if they're really needed, but they're high-level, and high-level is what matters!

And why write cout << "Hello world!\n"; or even System.out.println("Hello world!"); when you can take advantage of the myriad high-level abstractions to create the ultimate generic bloated "Hello world" that'll work with all kinds of objects? Yes, software reuse all the way! Eat recycled food!

Finally, how could a site like Advogato ever be developed without the help of all the benevolent high-level technologies like JNDI, JDBC, and EJB? Of course, it must've been secretly developed using Java!

article.close(), posted 8 Mar 2004 at 15:32 UTC by trance9 » (Master)

Tk, you're right, the problems aren't insurmountable. It is in fact possible to write a Stack::Pop in C++ that is exception safe--just not the way it's written above. My point was just that exceptions in C++ are error-prone in subtle ways. In general in C++ what you don't know can and will crash your application. In Java if you don't know something the compiler will tell you about it, or at worst you'll wind up writing some extra code where you could have used a standard API.

You're also right that the future is in things like AgentBrokerHandler or GenericBusinessObjectAbstraction. Standardizing low-level IO was interesting in the 1980's. In the 1990's the interesting areas in the IO arena were standardizing XML APIs and object serialization. In this decade the IO focus has moved on to transparent object migration and automatic O/R bindings. Some people still hack out applications that use IOStream directly, just like some people still hack out assembler. There's a huge infrastructure of old code that forms the foundations of more modern components and someone has to maintain it.

I think we've kicked this dead horse for long enough. C++ is a worthy language. I use it when I develop low-level components. It's just not sane to apply to problems involving high levels of abstraction. Ten years ago I'd have said something different--but ten years ago SQL was considered to be a "high level of abstraction". Now SQL is low level code. Times change, software becomes ever more abstract. The old technologies don't die--they continue on being good at what they do, and new technologies arise to handle newer tasks.

article.close(): Invalid argument, posted 8 Mar 2004 at 17:10 UTC by tk » (Observer)

trance9: And exactly what "newer tasks" are these WankageBreaker objects suited for? Of course, every "era" has its "interesting" and "important" problems like how to create the grand unified meta-meta-infrastructure to solve all the meta-meta-problems in the meta-meta-world. So what?

Some people may treat SQL as "low-level code" and glue it below a big fat layer of "middleware", but I may just use plain text files and I'm done. Is that somehow wrong? Because it doesn't do XML, object serialization, O/R bindings, etc.? Do I needs those?

And nobody's saying that C++ is an easy language, so what's your point? That because people can trip up when using C++, that automatically makes it useless for your "high-level" things (which are really "low-level" tasks with tons of useless abstraction heaped on them)?

Even in those areas where C++ is unsuitable, before one even considers Java there are countless other smaller and less verbose languages waiting in the ranks, such as Python, Perl, Ruby, Haskell......

Pompous Windbag Fuck Off, posted 8 Mar 2004 at 18:29 UTC by ncm » (Master)

This is the second time the miserable infant Justin Wells has pretended to "close" the discussion. tk, I know you mean well, but you're just feeding trolls. After all, the title of this thread is "Java, Failure or Crime", not "Tedious, Ignorant Maunderings by Justin Wells". The topic is things amusingly wrong with Java; any other language is equally as off-topic as a troll's ignorant maunderings (never mind how insecure he feels about his career choice).

I close with a (resolutely on-topic) curse for a Java monkey: "May you be condemned to maintain your own Java code long after everyone has ceased to do anything new with the language." Of course that has already started.

It's a sin!, posted 9 Mar 2004 at 00:22 UTC by exa » (Master)

Heh, your article is a little trollish but if you've read my posts that criticized Java heavily you should know that I agree with you in principle.

Java tries to be a practical imperative programming language, and it fails miserably in that aim. It is not merely somewhat inconvenient or inadequate, it is grossly incapable and mostly deficient.

Java is a joke. That is not to say that C++ is so much better, I don't think there is any imperative language design that rightly deserves to be called "the" practical imperative programming language. However, Java fares so awfully that it is nowhere near the top.

Java, to me, is still a balloon of 90% hot air and 10% innovation. Its only significant feature I have found useful is the working package system. It is a proof of the fact that object-oriented imperative programming is no panacea.

Think again.

They said it's the future of desktop. It didn't happen. They said it's the future of embedded. It didn't happen. They said it's the future of networking. It didn't happen. They said it's the future of server. It didn't happen. They said it's the future of PROGRAMMING. I HOPE it DOESN'T happen!

What next? This is marketing at its lowliest, please realize! Open your eyes! Don't let your respectable CS department adopt this silly language! I can tell, I assisted CS101 for an entire semester!

My choice of language is ocaml, btw. I'm not some antique C coder of spaghetti delight and unnecessary hacks, so heed my words young programmers!!!

Regards,

-- Eray Ozkural

To be "on-topic"..., posted 9 Mar 2004 at 02:15 UTC by tk » (Observer)

...one amusingly wrong thing about Java, is what one must do to read a text file line-by-line. I forgot, what was it again? new BufferedBagbiter(new FileFlusher(fileName))?

Even C++'s <fstream> + <string><?tt> isn't half as bad.

To be "on-topic"..., posted 9 Mar 2004 at 02:16 UTC by tk » (Observer)

...one amusingly wrong thing about Java, is what one must do to read a text file line-by-line. I forgot, what was it again? new BufferedBagbiter(new FileFlusher(fileName))?

Even C++'s <fstream> + <string> isn't half as bad.

InvalidThreadException, posted 9 Mar 2004 at 04:05 UTC by trance9 » (Master)

Well then, ncm, the whole thread is off topic because Java is neither a failure nor a crime. The only argument against Java put forward here is that what "they" said it would be used for turned out to be different than what hundreds of thousands of projects actually use it for. Why would you define success as "used the way Sun said" anyway? Normal people would define success as "projects successfully rolled out on". I've replaced so many ailing C++ systems with better, faster, cleaner Java systems that I can't even count them anymore, so this thread just makes me laugh.

As for reading a file line by line--who in gods name does that in 2004? Haven't you people advanced out of the 1980's yet? Really, who reads in files line by line in 2004? Try one of these instead:

         // you saved some state?
         ObjectInputStream ois = 
                 new ObjectInputStream(new FileInputStream("foo"));
         MyObject o = (MyObject) ois.readObject();
 
         // oh it's not binary? ok, maybe it's properties:
         Properies p = new Properties();
         p.load(new FileInputStream("bar.properties"));

// not properties? how about XML? JAXBContext = JAXBContext.newInstance("com.example.foo"); Unmarshaller um = context.createUnmarshaller(); MyObject o = (MyObject) um.unmarshall(new File("foo.xml"));

I mean these ARE all part of your standard library, why hell wouldn't you use them? Oh wait, let me guess.. is that because you are still hand coding the damn parser? Incredible. Wake up: it's 2004!

Tedious Asshole Fuck Off, posted 9 Mar 2004 at 05:24 UTC by ncm » (Master)

trance9: Which part of the word "tedious" do you have such enormous difficulty comprehending? Anyone who is not terminally stupid would have caught on by now that your tiresome blather is neither entertaining nor meaningful. Furthermore, it neatly demonstrates both your pathetic ignorance and your subhuman reasoning capacity. (In that context, I would like to call your (well, everyone else's) attention to the article The Basic Laws of Human Stupidity.) Probably futile hint: When you find yourself stuck in a hole, first stop digging.

This is a poetry thread, with an incidental theme of "Java Shortcomings". You have demonstrated, repeatedly, that you are not only unable to compose even a single pleasingly poetic polemic, but are unable even to recognize the thread's true topic, after numerous and increasingly broad and insulting hints. Justin Wells is, simply, too stupid to continue living. Please, for your sake as well as ours, go jump off a bridge, immediately. Don't worry, you won't be missed; small children are waiting to urinate delightedly on your bloated corpse. Don't disappoint them (too).

catch(Throwable ex) { System.err.println(&quoJava bites the bag&quo); }, posted 9 Mar 2004 at 05:48 UTC by tk » (Observer)

trance9:

ncm did also put up another argument: "What is a crime is the gigawatt-hours of energy dissipated operating wasteful JVMs on huge servers performing jobs that a hamster could do (and does) on its bathroom break." Java's slowness has nothing to do with what Sun says. What do you say to that?

Ailing C++ systems? Tell me about them. I won't be surprised if the Big Fat Bosses Above wanted to do the same stupid thing with C++ that they're doing with Java: create the grand unified meta-meta-infrastructure to solve all the meta-meta-problems in the meta-meta-world. That way lies failure, no matter what the language.

Automatic parsing? I don't need automatic parsing for my guestbook, I just need a way to read and write lines of text verbatim. Notice how each of your 3 approaches require using 2 classes and not 1? And how each of these methods involve a boatload more computation underneath, just to do the same silly job that a C++ or Perl program can dash out. You call that progress?

Finally, stop harping on the year being 2004. Programming isn't a fashion contest.

Re: Tedious Asshole Fuck Off, posted 9 Mar 2004 at 05:53 UTC by tk » (Observer)

By the way, should I mention those dolts who write scientific computation algorithms in Java?

OOPLs, posted 9 Mar 2004 at 05:56 UTC by tk » (Observer)

exa: Actually, Java isn't a "proof of the fact that object-oriented imperative programming is no panacea". Java isn't even worthy to be a representative of OOPLs.

And to be more poetic..., posted 9 Mar 2004 at 07:12 UTC by tk » (Observer)

Here's a spoof of Geoffrey James:

A Java programmer was once assigned to code a simple financial package.

The Java programmer worked furiously for many days, but when his master reviewed his program, he discovered that it contained a generic GUI template, a set of generalized object reflection routines, a third-party component interface, but not the slightest mention of anything financial.

When the master asked about this, the Java programmer became indignant. "Your methods are outdated", he said. "This is the programming methodology of the future."

speed, posted 9 Mar 2004 at 21:22 UTC by trance9 » (Master)

On Java "slowness": I know some of you aren't interested in a thinking conversation--it looks like ncm's a script kiddy in disguise, I'm guessing next he'll try and packet me--but for those of you who are a little more adult here's the best answer I can give from my eight years experience with the language.

I have never encountered a non-GUI java application where processing power was an issue. Never. I have seen the benchmarks showing that C++ is in theory faster than Java for many common tasks. In practice in every application I've worked on the CPU is idle most of the time, and processing speed has simply never been an issue--even apps that served 1200 requests/second weren't bottlenecked by the CPU. So the "Java is slow" is sort of a complete non-issue in the conventional sense.

I have seen GUI applications that were slow. Swing/AWT/etc. have all been dog slow in the past. Recently IBM's SWT library has helped a lot, and even Swing is getting a lot faster, but in the past, the GUI was slow. I've never really worked on a large GUI project, and I probably wouldn't choose Java as my implementation language if I thought GUI performance were going to be an issue. In actual practice I never use Java for these tasks, I use it for middleware: glue that sits between some network client and a database. There's typically no GUI component, so it doesn't bother me that it's a poor choice for GUI development--pick a different langauge for that.

A fair criticism, and what I have frequently seen, are Java applications where *memory* has become an issue. It has never been a "Java problem" in that the villian always turned out to be some poorly implemented code. But to be fair, culturally, it does seem that a lot of Java developers figure that since there's a garbage collector lurking in the background they never need to think about allocation. Well the GC can take awhile to get around to cleaning up your heap, and if you aren't good about nulling your references you can leak. It's always been possible to resolve the issue by correcting the poorly implemented code, but sometimes that code has been in third party libraries--so from a platform perspective, there's an issue.

On that front I'd still take Java over C++ though: the memory problems I've had with Java have never caused my application to crash. With C++, applications with memory problems simply crash and die. I'd rather my appw as slow until I fixed my broken code, than that it crashed until I did the same.

It's interesting to me that people never PERL, PHP or Python as being too slow. It seems the reason is that they contrast those languages with interpreted scripts, and call them "fast", even though they are orders of magnitude slower than C++, and slower than Java too. The reality is that, like my Java experience, my experience with PERL has been that the processor is almost never the issue even though the language is in theory "slow".

Java apparently is required to have C/C++ performance because it is an object oriented language with C/C++ like syntax. Never mind that Java adds all kinds of additional runtime checks that improve the safety of your application, that it has a GC safety net, that it can be distributed in realtime over a network--people apparently think they're going to get all those benefits for free, without any performance cost. Obviously there is a cost--but as I said, it seems to me to be a worthwhile tradeoff, especially since I've never *actually* encountered a Java application that was "too slow" because of processor speed.

Tedious Java Apologists Can Be Funny, posted 9 Mar 2004 at 23:21 UTC by ncm » (Master)

I have created a separate article for Justin Wells to post his tedious self-important maunderings. Anyone who actually wants to read his drippings is welcome to follow him there.

In the meantime, we can make fun of him: "I've never actually encountered a Java application that was 'too slow' because of processor speed."" This is a code expression common among Java monkeys. It means, "I've never written any code that mattered to anyone, so nobody cared how fast it was either." The expression, "I'd rather my app was slow until I fixed my broken code, than that it crashed until I did the same" really means, "If it doesn't actually crash right away, I might not have to fix it at all; anyway, I can always blame Java."

OK, Nathan, show me the code, posted 10 Mar 2004 at 03:05 UTC by trance9 » (Master)

The best public example of a performance oriented site I've developed in Java is here. You've claimed a couple of times Java is too slow. Show me the code to prove it, or get lost.

Re: OK, Nathan, show me the code, posted 10 Mar 2004 at 03:43 UTC by tk » (Observer)

trance9: Ha.

Another spoof (of 7.3):

The Magician of the Java Tower brought his latest invention for the master programmer to examine. The magician wheeled a large black box into the master's office while the master waited in silence.

"This is an integrated, distributed, general-purpose workstation", began the magician, "ergonomically designed with a Java operating system, high-level abstractions, and multiple state-of-the-art user interfaces. It took my assistants several hundred man-years to construct. Is it not amazing?"

The master raised his eyebrows slightly. "It is indeed amazing", he said.

"Corporate Headquarters has commanded", continued the magician, "that everyone use this workstation as a platform for new programs. Do you agree to this?"

"Certainly", replied the master. "I will have it transported to the data centre immediately!"

And the magician returned to his tower, well pleased.

Several days later, a novice wandered into the office of the master programmer and said: "I cannot find the listing for my new program. Do you know where it might be?"

"Yes", replied the master, "the listings are stacked on the platform in the data centre".

again: show me the code, posted 10 Mar 2004 at 05:01 UTC by trance9 » (Master)

I'm still waiting, Nathan. More rhetoric from you, but still no code to back up your claim.

More Translations, posted 10 Mar 2004 at 05:34 UTC by ncm » (Master)

When a Java monkey says, "I wrote fast code", he means, "I don't work there any more."

When a Java monkey says, "Shut up" or "Get lost", he means, "I'm feeling very insecure about my career choices right now." (Those children are still waiting...)

code?, posted 10 Mar 2004 at 06:02 UTC by trance9 » (Master)

Nathan, I'm gonna try and tone this down. I don't know if you're up for that. I would very much like to hear something solid demonstrating this claim that Java is too slow, etc., I'm serious. Yes it's slower than C++, but so is PERL, and I still use that too. Who cares?

You're damn right I don't work at AV anymore: I worked at there on a contract to deploy my software. I was away from home for nearly a year on that project--longest I've ever been gone. My wife stayed in Toronto, and I was glad to get to know her again when the thing was finally over. I'm Canadian, I grew up here, my wife is here, my life is basically here in Toronto, and I really never had any intention of being away even that long.

As for my career--short term it seems pretty safe. The job market for Java in Toronto is strong now--recruiters offering cash for referrals and all that. Long-term maybe all our jobs will go to India, in which case I doubt it matters what language you code in--maybe we should be brushing up on our sales skills. Ugh. I hope that never happens--I love coding, and I hope I can continue doing it without having to move to Bombay.

Clue, posted 10 Mar 2004 at 07:12 UTC by tk » (Observer)

trance9: Clue.

The fourth evil..., posted 10 Mar 2004 at 07:42 UTC by badvogato » (Master)

"The fourth evil is loneliness. Basing his conclusions on the researches of Harry Stack Sullivan, Wieman considers loneliness the most unendurable evil to which man is subjected. It occurs when he becomes aware of the fact that others understand and appreciate him only in conventional terms -when they fail to recognize and appreciate him in terms of his original experience. This gives rise to the feeling of personal isolation, and may produce aggressive tendencies and the resultant evils."

"Are you lonesome, tonight?" Shall we hum our blue tunes ? God is listening appreciatively and attentatively. And night soon be over for a new break of dawn...

The clue is if you cann't discover any church that'll allow you do your worshipping to glorify God's grace the best you can, found your own. How many disciples Jesus got? not many. How many Christians do we have now. Too many.

Thank God for Badvogato, posted 10 Mar 2004 at 14:03 UTC by ncm » (Master)

Here comes the cavalry, riding over the hill. Cue music.

I'm amused, posted 10 Mar 2004 at 19:09 UTC by Omnifarious » (Journeyer)

trance9 hasn't bothered to read or understand a single word spoken here, yet feels that we should all listen to his opinions and take them as gospel. I feel that he is doomed to become a manager. But, he is probably looking forward to the prospect.

Oh, well. I'm not going to post a reply to that other post, as I largely choose to ignore it.

Parody or Not? You Decide!, posted 10 Mar 2004 at 19:12 UTC by ncm » (Master)

This is the funniest thing I've seen this week. Thanks to mbp and Kimbro Staken for finding it. Check it out:

Understanding Object Oriented Programming
On the "parody" side of the argument is the file name, "ppoop.html", but that could be simple obliviousness. Mirror it before they take it down out of sheer embarrassment!

That's just AWFUL, posted 16 Apr 2004 at 06:08 UTC by haruspex » (Journeyer)

Surely this is meant as a joke. Nobody could seriously quote this in defence of Java, surely?

As for reading a file line by line--who in gods name does that in 2004? Haven't you people advanced out of the 1980's yet? Really, who reads in files line by line in 2004? Try one of these instead:
         // you saved some state?
         ObjectInputStream ois = 
                 new ObjectInputStream(new FileInputStream("foo"));
         MyObject o = (MyObject) ois.readObject();
 
         // oh it's not binary? ok, maybe it's properties:
         Properies p = new Properties();
         p.load(new FileInputStream("bar.properties"));

// not properties? how about XML? JAXBContext = JAXBContext.newInstance("com.example.foo"); Unmarshaller um = context.createUnmarshaller(); MyObject o = (MyObject) um.unmarshall(new File("foo.xml"));

deadly aweful, posted 19 Apr 2004 at 19:39 UTC by badvogato » (Master)

as if he'd be chanting we all have to learn how to grind coffee beans in our mugs if we ever wish to smell good java steam without consenting to take a mugshot by the security guard to enter starbucks mushrooming all over this planet earth. But i can live by drinking tea, eating rice with spice tofu in friends' house, can you?

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

X
Share this page