Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
The failure of java?

By delmoi in Op-Ed
Tue Mar 20, 2001 at 03:37:49 PM EST
Tags: Software (all tags)
Software

Ok, I don't think java has failed, I think it's great. Nearly all of the programming I've done on my own since 1996 has used the language. But some people seem to think it has, particularly salon's Simson Garfinkel. Garfinkel's initial article entitled 'bad java' is on the level of a Usenet flame, he calls insults Java for being slow, and even hard to read. (Making no distinctions between the API and the language itself). And his response to all the email he got isn't much better.


These articles bugged me, not so much for the fact that they attacked java, but for the fact that the author seemed to simply ignore things like JIT and other advancements in Java over the years. In Garfinkel first paper, he mentions an ACM case study in which grad students were given a string manipulation problem and asked to solve it in either C or Java. The 'majority' of the C/C++ programs worked in one to five minutes, whereas the java programs took between two and 30 minutes.

Never mind that Strings in java are formed of 16bit Unicode characters rather than bytes, and that they are bounds-checked arrays rather then pointers.

Most of the experiments I've seen done in the past few years indicated that Java was about 40-80% as fast as C or C++, in most cases.

Garfinkel also claims that the write-once-run-anywhere claim has fallen through. But I don't see that as happening at all. I've never once had a problem running code on one machine on another machine; not once. And while I'm sure there are subtle differences between JVMs, this is no different than the several different implementations of Win32 put out by Microsoft. Win2k broke a lot of poorly written 9x programs that never ran on NT. Yet, Garfinkel claims that we don't have to worry about platform neutrality anymore because everyone runs Windows. Hell I've had tons of problems getting Windows programs to run correctly on machines running the exact same version of Windows owing to COM object fuckups in VB.

And of course Garfinkel doesn't pay any attention to the server side of things, where Java is flourishing. A place where another interpreted language, Perl, was already popular.

At least until his mailbox was flooded.

Then his attacks get even more ludicrous, He claims, for instance, that a company spending $2 million on a server to run their java programs could only spent $1 million of they would have rewritten their program in C++. Of course, he uses no numbers to back this up, other then the 'java is slower' argument.

The most annoying of Garfinkel's slights is that java is more difficult to read than C++. To me, this argument seems ridiculous. Java's Syntax is much simpler then C++ overall, and less reliant on numerous Character Symbols. His main, and only as far as I can tell claim that Java is hard to read is that you have to do things like

Reader netIn = new BufferedReader(new InputStreamReader(mySocket.getInputStream()));
netIn.read();


rather than

mySocket.read();

And while, that is kind of annoying to type, I don't really think it makes it any harder to read, and in many ways, it makes it easier, because there's simply more there. Just like how Simplified Chinese is easier to write, but Traditional is easier to read (assuming you spend/spent the same amount of time on both)

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
Has Java failed?
o Yes 11%
o No 28%
o On the client side, but not the server 21%
o Perl is the one true choice! 8%
o It's goning to get it's ass handed to it by Ruby 5%
o I don't know, I don't care, but I do know Visual Basic sucks! 24%

Votes: 159
Results | Other Polls

Related Links
o salon
o initial article
o response
o Also by delmoi


Display: Sort:
The failure of java? | 80 comments (65 topical, 15 editorial, 0 hidden)
java java java (3.33 / 6) (#1)
by rebelcool on Mon Mar 19, 2001 at 05:14:34 PM EST

most people who criticize java haven't used it extensively, or are using the oldest tools (that is, java 1.0 et al)

Also given the fact that alot of java programs are poorly written. Theres a simple reason for that..it's a young language. It's only been recently that people have learned to write in the language well. Most "slow, not very portable" applications are written by inexperienced programmers. When used properly, java is *very* fast and *very* portable (poor VM issues aside, such as netscape's pathetic excuse)

As for the "java is slower" crap, not anymore it's not. Modern tools have made java nearly as fast as a C++ program (certainly the reduced development time and porting time if you're running multiple systems makes it worth it).

I'll use my favorite example of Java Done Right..Resin webserver. Static page serving speeds approach that of Apache, its JSP/Servlet handling is as fast as mod_php and it simply blows away mod_perl.

COG. Build your own community. Free, easy, powerful. Demo site

Not true at all (4.50 / 2) (#6)
by pope nihil on Mon Mar 19, 2001 at 05:31:18 PM EST

Modern tools have not made java nearly as fast as C++. I dabble using the latest JDK available from Sun. If you've ever used a big GUI program like Forte or JBuilder (2 free IDE from Sun and Borland respectively), you know how slow these applications really are. When I was running Windows 98, I couldn't even get JBuilder 4 to refresh the screen properly when I scrolled. As for Forte, it's almost unuseable in Linux as it creeps up X every time I run it until I can't access the menu bars. How can you accuse Sun of not writing in Java well?

Anyway, the author of this story admits that java is 40-80% as fast as C++. My application only runs at 40% of what it should?? That's an awful performance hit. It works fine for some small applications, but anything that uses a lot of menus is doomed to slow-land even on fast processors.

What I think they really need is the ability to compile a .class file into native binary executing at native speeds. Show me that, and I'll gladly consider using Java.

I voted.

[ Parent ]
gui slowness (3.66 / 3) (#9)
by rebelcool on Mon Mar 19, 2001 at 05:46:33 PM EST

You're talking about GUI slowless. Java isnt the best language for doing a GUI in. It's tedious and difficult work to do properly. The only environment i've seen that has GUI-building done right is Visual Basic.

I do server work. Writing back end servlets, JSPs and server applications themselves. Those don't have a GUI, and they run blazingly fast.

"What I think they really need is the ability to compile a .class file into native binary executing at native speeds. Show me that, and I'll gladly consider using Java."

I do believe a couple of such tools exist (though the name escapes me at the moment since I have no use for them)

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

Re: gui slowness (4.60 / 5) (#15)
by eLuddite on Mon Mar 19, 2001 at 06:31:08 PM EST

You're talking about GUI slowless.

So what? Gui programs loop bytes into and out of memory buffers just like any other program.

Looking through the run time stats for vaious non gui programs in Kernighan and Pike's The Practice of Programming[1], Java is slower than even Perl. Not coincidentally, every Java app I've ran ran slowly.

Why do uber Java advocates always insist on denigrating the end user's experience? What kind of convincing do you need before you realize that a program pretending to be a computer will never run another program as fast as the real computer underneath?

Of course Java is slow. It's advantages are two: (1) pedagogic; (2) the sand box. Some people will give you (3) cross platform support. Some wont.

 

[1] Timing for a Markov chain program run against the King James Bible on a 400MHz PII (LOC = lines of code):

C = 0.30 sec, 150 LOC Java = 9.2 sec, 105 LOC; Perl = 1.0 sec, 18 LOC.

---
God hates human rights.
[ Parent ]

Depends very much (3.00 / 1) (#17)
by weirdling on Mon Mar 19, 2001 at 07:01:54 PM EST

Speed of code depends very much on how good a programmer is and how much time is spent optimizing. Optimized to the metal code in assembler will always be the fastest and the most difficult to write. Niklaus Wirth pointed out, however, in defense of Pascal, that a higher-level language could make many optimizations unnecessary. As such, if you take a mediocre programmer and give him a task in Java, it will come out considerably more optimal than the same mediocre programmer in C/C++, which is why, for business use, Java often outperforms C/C++. Now, take a good programmer and knock the silly idea that he has to optimize code out of his head and he produces code at a much higher rate than in C/C++, thus making more money for your company as long as you can afford hardware to run it on, and you see why Java is so strong server-side.
It's not that server-side people ignore the UI; I write all my database access programs in AWT and they run fine; it's that the server is where Java shines.

I'm not doing this again; last time no one believed it.
[ Parent ]
it depends on context. (2.50 / 2) (#19)
by rebelcool on Mon Mar 19, 2001 at 07:21:44 PM EST

In what ways is "java slower than perl"? And using what compiler, what methods and virtual machine? If comparing server applications, what was the servlet container?

Java has many servlet containers available, JServ, the reference Tomcat, Resin and many, many others. And the speeds for them vary greatly.

When doing deep down kernel work, C is faster than java (from today's standpoint). However, when doing server work, java blows CGI (which is C) away. CGI launches new heavyweight processes for each request, whereas the servlet containers create new lightweight threads for doing it. Thus, the processing overhead is less for java than it is for C, making it faster.

It's absurd to call one language better than others in all contexts, because each language is good for something. It's the sure sign of an amateur to say "C IS BETTER THAN JAVA BECAUSE IT IS FASTER".. faster in some ways..slower than others. Any really good programmer has many languages in his toolbox, and chooses the appropriate and best one for the project.

That said, java is certainly not a "bad" language.

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

Re: it depends on context. (4.66 / 3) (#22)
by eLuddite on Mon Mar 19, 2001 at 07:43:33 PM EST

However, when doing server work, java blows CGI (which is C) away.

No, CGI is the Common Gateway Interface, not C. You can write CGI programs in Java, for example.

Now, even if I grant you that an httpd server with an integrated servelet engine runs java code faster than a cgi program written in C (which I dont, btw - not all or even the majority of the time) what makes you think that would be a fair comparison? Why not Resin (whose core server is written in Pike, not Java, btw) vs. fastCGI + apache? There goes your thread vs process advantage, ten times over.

The integratation of a web server with a language doesnt say a whole lot about that language unless you integrate all languages into the web server during the comparison.

Finally, Java was once heralded as a language for the web browser. Now all of a sudden its heralded as a language for the web server. What if I dont need a web server? What's resin going to do for me then? Its nice that Resin launches threads (which may or may not be faster than processes depending on the OS) but what if I'm not running a web server and need to launch Java processes several times a second? Business logic != web server.

It's absurd to call one language better than others in all contexts,

That's why I wrote that Java has advantages.

because each language is good for something. It's the sure sign of an amateur to say "C IS BETTER THAN JAVA BECAUSE IT IS FASTER"

If only you would convince a whole lot of Java people of that fact. You yourself just now argued that Java was faster than C/CGI.

---
God hates human rights.
[ Parent ]

get your facts straight (3.00 / 1) (#29)
by rebelcool on Mon Mar 19, 2001 at 09:29:16 PM EST

I have the source for Resin sitting right here, theres no Pike. If you don't believe me, go to caucho.com and look for yourself. The only thing you need to compile Resin is JDK1.2. It includes a few C modules for plugin support with other webservers.

Further, CGI is usually done in C++ because it's the best faciliator for CGI. To do CGI in java is beyond foolish, nor have I ever even heard of such a thing. Servlets are lightweight processes and don't have any of the processing overhead that a CGI script entails. Go look at the benchmarks if you want further proof. CGI is ancient technology, and hardly anyone uses them anymore for non-trivial things, much less intensive backend processing.

"but what if I'm not running a web server and need to launch Java processes several times a second?"

Easily done. Do you mean launching new threads in a non-server app (this is trivial) or new instances of JVM running entirely separate programs? That can be done, and rather quickly, but you don't see that a whole lot. In the case of linux, JDK1.3 launches threads as a new process (indeed, doing a top will show an entry for each individual thread..disconcerting until you realize its supposed to be that way)

Windows has more advanced thread handling, and so threads are internal processes to the program.

"If only you would convince a whole lot of Java people of that fact. You yourself just now argued that Java was faster than C/CGI."

Servlets are faster than CGI. They consume considerably less resources and overhead.

Question for you: Have you ever written a backend processor or server application in general? I dont just mean webserver, but a socket-listening client-server application.

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

Re: get your facts straight (5.00 / 1) (#35)
by eLuddite on Mon Mar 19, 2001 at 10:58:54 PM EST

I have the source for Resin sitting right here, theres no Pike.

I said resin's core server (since you mentioned the speed at which static files were served) which is roxen, no? I could be wrong.

Further, CGI is usually done in C++ because it's the best faciliator for CGI. To do CGI in java is beyond foolish,

That makes no sense. You can write a cgi program in any language you want (typically perl, not C or C++, not by a long shot) and the only reason people dont use Java for cgi is because java is so god awful slow to launch. CGI is perfectly adequate for 99.99% of all sites out there and is often the only option people are given.

nor have I ever even heard of such a thing.

Yeah, so? I have. Maybe you weren't paying attention to what was happening 3 or 4 years ago.

Servlets are lightweight processes and don't have any of the processing overhead that a CGI script entails.

Yes, servelets run in the web server's process space, eliminating the startup time required for a cgi app. If the running time for that servelet is longer than the startup and run time of the cgi, then it would clearly be slower, not faster. Sure, if all you're doing is marshalling some data off a web form for the sql backend, a cgi wouldnt look very good in a benchmark. If you're translating text or processing pixels, or crunching numbers, or any number of things, a cgi written in C could _easily_ outrun a java servelet. Can you at least see that?

Go look at the benchmarks if you want further proof.

I just told you that it is unfair to compare a cgi app with a server embedded language. If you write your app in C and have it communicate using fastCGI (which does not require a process launching) then your servelet engine will be blown out of the water. Completely fucking decimated. Furthermore, I can write any number of cgi apps that will outperform a servelet because (a) there exists many classes of problems for which java would be significantly slower and (b) fast process times (fork() on modern unicies is as fast as thread creation on windows) coupled with this modern technology called a unified vm and file buffer cache.

You, on the other hand, are claiming that servelets are faster because they arent ancient technology. Religion is a fine thing but it has no place in computer science.

CGI is ancient technology, and hardly anyone uses them anymore for non-trivial things, much less intensive backend processing.

Completely untrue. Most, by far, programs that execute on a web server out there are cgi programs.

Easily done. Do you mean launching new threads in a non-server app (this is trivial) or new instances of JVM running entirely separate programs?

The latter.

That can be done, and rather quickly, but you don't see that a whole lot.

Excuse me but what doesnt get done a whole lot? I dont care about web servers, I'm not interested in writing an application server that keeps a single instance of a JVM in state, and even if I had the money to buy one, none has been written for my needs. Ergo, every time my non web app needs to do some java logic, I have to launch the JVM. Ergo, Java is slow in my backroom.

The only way you're going to speed up java in my back room is if you integrate in into one monstrous application framework that attempts to the work of an OS: works around process launches, commits an additional level of memory management for its jit, keeps a pool of open reuseable sockets, etc. Duh. You can do that with any language. And if you did, you'd find java was the slowest of the bunch.

That's because Java, THE LANGUAGE, is slow.

In the case of linux, JDK1.3 launches threads as a new process

That's nice but it's not relevant since I need to launch a new JVM.

(indeed, doing a top will show an entry for each individual thread..disconcerting until you realize its supposed to be that way)

Is it, or is it Linux's braindead Linuxthreads? Not every OS implements threads as processes, you know.

Servlets are faster than CGI. They consume considerably less resources and overhead.

They can be both. They can be neither. This isnt an article of faith, you can easily be shown to be wrong. Dead wrong.

Question for you: Have you ever written a backend processor or server application in general?

Yes, in quite a few languages for many different operating systems.

I dont just mean webserver, but a socket-listening client-server application.

When I was a novice programmer working in a entry level position, sure. Using poll(), select(), threads, passing open file descriptors between processes (one of the faster if underused unix technique -- see Dillon's diablo newsfeeder) and a few other techniques in between. This is elementary shit.

---
God hates human rights.
[ Parent ]

more (none / 0) (#38)
by rebelcool on Mon Mar 19, 2001 at 11:45:46 PM EST

"I said resin's core server (since you mentioned the speed at which static files were served) which is roxen, no? I could be wrong."

You are wrong. It is all Java. Writing the "core" bits is quite easy and fast in java.

"Completely untrue. Most, by far, programs that execute on a web server out there are cgi programs."

Not anymore. Beyond trivial things (such as guestbooks, some webboards and other things..i mean backend database processing that passes data back and forth between subsystems) CGI is hardly used anymore. CGI might be used for some specialized things, but in what webserving mainly consists of - retrieving data from a database - CGI is all but on the way out since you can do it faster in perl, php, and of course, Java.

As a side note, oracle utilizes java for webintegration (the oracle application server is actually apache w/ Jserv and a bunch of oracle's own java tools which are *great*)

Excuse me but what doesnt get done a whole lot? I dont care about web servers, I'm not interested in writing an application server that keeps a single instance of a JVM in state, and even if I had the money to buy one, none has been written for my needs. Ergo, every time my non web app needs to do some java logic, I have to launch the JVM. Ergo, Java is slow in my backroom.

It depends on what you're doing. You havent provided a decent example of what you are saying, simply saying "if i have to load a jvm a bunch of times it will take awhile!"..well if for some reason I have to load any decent sized application many times over, it will take awhile too, but the question is, what are you trying to do?

Is it, or is it Linux's braindead Linuxthreads? Not every OS implements threads as processes, you know.

I do believe I pointed out that windows implements threads in a more advanced way. In this, I agree. JDK1.3 does threads far better on linux than previous versions, which makes it quite a bit faster on linux now.

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

Re: more (5.00 / 1) (#41)
by eLuddite on Mon Mar 19, 2001 at 11:55:17 PM EST

Well, it appears we agree violently more than we disagree.

---
God hates human rights.
[ Parent ]

What if you don't _want_ the sand box? (none / 0) (#71)
by pin0cchio on Wed Mar 21, 2001 at 04:17:15 PM EST

(2) the sand box

Sand box is a good thing if it's easy for users to turn it off for applications where the sand box is not desirable (applets that access local files or pull information from other servers). Thing is, most browsers don't allow the user to turn off the sandbox for individual applets; the developer can turn off the sandbox but not without paying hundreds of dollars per year to Veri$ign.


lj65
[ Parent ]
gui building (none / 0) (#53)
by hading on Tue Mar 20, 2001 at 12:09:40 PM EST

>The only environment i've seen that has GUI-building done right is Visual Basic.

If you ever have the time, you should check out any decent Smalltalk's approach to GUI building.



[ Parent ]
You are picking on the wrong guy. (3.00 / 1) (#10)
by darthaya on Mon Mar 19, 2001 at 05:50:47 PM EST

No one ever said anything about java's "superiority" in GUI. Look again, they are talking about server side execution speed.

[ Parent ]
Swing sucks, but java dosn't (4.00 / 1) (#14)
by delmoi on Mon Mar 19, 2001 at 06:12:18 PM EST

Swing, the Java GUI API is pretty slow. Mainly because it's all software graphics, and can't take advantage of 2d GDI acceleration the way windows/X programs can. For pure memory mapped graphics, Java is plenty fast.

And the reason to use Java even though it's slower is that it takes a lot less time to develop. Loosing 20% of the performance speed in exchange for loosing 60% of the development time is a tradeoff a lot of people would be willing to make. Java's standardized API for dealing with everything from the GUI to the network to SQL if fantastic (if verbose).
--
"'argumentation' is not a word, idiot." -- thelizman
[ Parent ]
old rant (3.60 / 5) (#7)
by spacejack on Mon Mar 19, 2001 at 05:36:38 PM EST

The Salon article reads like a rant I would have written about 4 years ago. He's right too -- when it comes to browsers, Java pretty much blows; Flash has quickly evolved into a much better solution (and beat it to game consoles too :)

OTOH, friends of mine who use it server-side tend to have much better experiences. I doubt Java will be making many inroads on the desktop anytime soon. But it seems to be doing okay on the server. OTOH, when doing server-side work, there are a lot of options to suit a wide variety of tastes and applications. It's just one more option.

And that's about all that I think needs to be said. :)

Flash, ug (3.00 / 2) (#11)
by delmoi on Mon Mar 19, 2001 at 05:54:54 PM EST

Flash does seem to be quite a bit more seamless then Java on the web, but I really wish it wasn't so. Flash is just so limiting, compared to the things a skilled programmer can do graphically in java, flash just sucks. Just compare the demo scene demos done in Java to the ones in flash

But, you probably aren't going to find to many skilled graphics programmers who are going to work for websites. Which is to bad, What I'd really like to see would be a powerful real-time graphics synthesis library for Java, because you really can do cooler things in it then you can with Flash.
--
"'argumentation' is not a word, idiot." -- thelizman
[ Parent ]
I feel your pain (3.00 / 2) (#13)
by spacejack on Mon Mar 19, 2001 at 06:11:08 PM EST

and I have seen impressive Java demos. I also dislike Javascript (ActionScript) as a language compared to C, C++, Java, Perl, etc, etc.

But Java simply isn't practical. Most of the work on a client-side web app is the interface design -- which is handled for you with Flash's authoring tools. It takes friggin forever to do this from scratch. And compared to F5, Java's built-in GUI widgets are hideous. Once you're freed from the work of building GUI code yourself, dealing with a limited ActionScript-style language isn't nearly so painful.

So no, in theory you can't do all the things you can in Java, but what you can do works really well on the supported platforms, and the production is fast enough that you can actually get jobs that will pay fairly for your time & effort.

[ Parent ]
Server-side (4.00 / 1) (#21)
by SlydeRule on Mon Mar 19, 2001 at 07:36:26 PM EST

friends of mine who use it server-side tend to have much better experiences
Bingo.

Server-side Java doesn't tend to exhibit the characteristic sluggishness for a number of reasons:

  • No GUI. Swing is by far the sluggiest part of Java.
  • JIT and reuse. Since the server runs on one single JVM throughout its entire session, each Java class is JIT-compiled no more than once per session. Subsequent uses of a class don't incur the start-up overhead; they run from native object code.
  • Not computationally intensive. Server-side Java tends to spend most of its time waiting on databases. Little processing is actually performed within the Java code.
Besides, when you plan on your server being up for hours/days/weeks on end, processing who knows how many transactions before it's restarted, a garbage-collected memory system is really desirable.

[ Parent ]
Re: Server-side (4.33 / 3) (#24)
by eLuddite on Mon Mar 19, 2001 at 08:57:52 PM EST

Besides, when you plan on your server being up for hours/days/weeks on end, processing who knows how many transactions before it's restarted, a garbage-collected memory system is really desirable.

Except that Java leaks resources everytime some Java programmer thinks _all_ his garbage will be collected. That's a myth, it wont. (How do you plug java memory -- Dr. Dobb's Journal, Feb/2000.) The fact that most Java programmers seem to believe this myth suggests that your hypothetical java server is going to be rebooted more often than you expect.

By contrast, C's exit() does all the garbage collection you'll ever need at the end of a transaction :-)

JIT and reuse. Since the server runs on one single JVM throughout its entire session, each Java class is JIT-compiled no more than once per session. Subsequent uses of a class don't incur the start-up overhead; they run from native object code.

Assuming you have gobs of memory for the jit cache and/or a small set of java programs and/or nothing else using the physical memory of the machine hosting the java engine. Typically, this is true but only because, typically, $x dollars you save on programmers translates into the $x dollars you'll need to funnel into additional hardware resources. Then you get slashdotted and have an epiphany about the proper allocation of dollars.

It's actually worse than that if you believe (as I do) that Java programmers are NOT as prolific as C (perl, whatever) programmers. It is certainly much easier to work with mod_perl or mod_php than it is to work with jsp. Java is a very strict, pedantic language. It is not ideal for rapid prototyping or rapid deployment at the web server.

But wait, it gets better. Last I checked, perl and php programmers cost a lot less than their java brothers. Can they do any less than jsp programmers? No. Is the code they write less x-platform? No, it is more. Do they need to collect their own garbage? No, they do not.

Basically, if you're a company that hasnt made an emotional investment in Java, your server is better off without it. What I see is a lot of people saying it doesnt suck on the server so lets use it because, hell, we have to use it somewhere, right? Maybe you wouldnt be saying that if a lisp httpd engine had been marketed as heavily. Or a smalltalk engine. Or whatever. On the _server_, much of Java's supposed advantage (xplatform, sandbox) doesnt come into play at all.

Server side java is as hyped as client side java. Its a nice technology but its a far cry from the panacea recent marketing is making it out to be.

---
God hates human rights.
[ Parent ]

Things don't stand still, though (3.00 / 1) (#44)
by slaytanic killer on Tue Mar 20, 2001 at 06:31:38 AM EST

I know for a fact that there are people doing strange things with the combination of Flash and Java, but there's not much I should say about that. However, this ZDNet article talks about improved web delivery and a new API for audio/video, which it previously lacked.

What people tend to miss is that many organizations do not aim at a 6-month term. They think more in terms of three years, and longer. Mainly it is just startups who think in terms of 6-month cycles.

And one should ask themselves, is it Java that should be doing the work of Flash, or an application written in Java? Graphics2D is not terribly slow, I've played halfway decent 3D games written in it (DON'T use the 3D API, I hear it currently blows); and plus it's a field saturated with other languages like Curl.

[ Parent ]
no, they don't (none / 0) (#55)
by spacejack on Tue Mar 20, 2001 at 02:50:08 PM EST

and Flash6 is already under development. Weighing in at ~300K it takes less time to upgrade than the Java VM does to invoke. Most users don't really understand or like Java because it crashes their machine, and that MS will no longer support since Sun yanked their license... somehow I think Java's days in the browser are numbered.

It's just too big and unweildy. Why would anyone want an 8+ meg VM that costs more to develop for when a lightweight 300K solution is already a major success? And Macromedia will likely have their 3D plugin ready before Java has any kind of media solution ready, let alone distributed.

What people tend to miss is that many organizations do not aim at a 6-month term. They think more in terms of three years, and longer. Mainly it is just startups who think in terms of 6-month cycles.

Hmm? Are you talking about the dev cycle for Flash/Java itself or the dev cycle for the content? The development of Flash itself started after Java and quickly overtook and replaced it for all practical purposes. As for building web doohickeys, you're almost always talking in terms of months, weeks, or even days. Beyond that it quickly becomes very hard to justify the kind of budget you'd need to build it.

And one should ask themselves, is it Java that should be doing the work of Flash, or an application written in Java?

Presumably whatever is already installed, supported and works should be doing the work of Flash. It's true you could write a Flash player in Java.. but why would you want to?

Graphics2D is not terribly slow, I've played halfway decent 3D games written in it (DON'T use the 3D API, I hear it currently blows);

Plus it's got no where near the install base as Flash and there's nothing to convince the public to get it either..

and plus it's a field saturated with other languages like Curl.

Ehh, funny their homepage has Flash on it :)

Lucasarts latest PS2 game already used Flash for all the interface and I hear it looks very sweet.

I'm not flaming here, I just can't see any way that Java can get there from here... Flash already won :/

[ Parent ]
Flash über alles? (none / 0) (#58)
by slaytanic killer on Tue Mar 20, 2001 at 03:44:45 PM EST

Getting into a flame would be fun, but I will lay out my perspective, so you see where I come from:

. Flash is something to be used in conjunction with Java. The most common Java practice I've seen is to build the visual spec in Flash and then develop in Java.

. When I said that companies tend not to think in 6-month cycles, I was talking about Sun. Sure Flash is smaller and flashy. From what I hear, so was a lot of really great software which was in more ways stronger than the competition than Flash. But which has more capabilities to leverage as clockspeeds, memory, and bandwidth gets faster? What will today's 6 meg download (WebStart) be like tomorrow, for something much more reusable?

. If Curl's homepage has a Flash animation on it, and itself is a web-delivery platform, then does anyone think that some platform will totally control the web-delivery world? No, it is a saturated arena. But while we separate the world into "powerful" languages such as C++ & Java, and "scripts" like Flash & PHP, is there any question about which language you'll reach for if you want something fully-featured? And BTW, with Curl you can do things you could never with Flash.

. How many hundreds USD$ does a pretty box from Macromedia cost? (Which is even more prohibitive overseas.) Yes, there is a 20 meg 45-day trial download, but you get a closed-source product which only survives if its niche survives.

Now, I am taking an absurd stance, since I like Flash. Until recently, I've never actually enabled it on a computer unless I really had to, but I may soon be doing fairly weird things in Flash. I hear that the C++ API to Flash is badly documented and whatnot (even missing?) so there may be humorous problems there, but come back in a month and I'll blab all about it.

[ Parent ]
uses, etc. (none / 0) (#59)
by spacejack on Tue Mar 20, 2001 at 04:20:43 PM EST

. Flash is something to be used in conjunction with Java. The most common Java practice I've seen is to build the visual spec in Flash and then develop in Java.

It's true Flash is a nice interface prototyping tool -- for any language/dev platform.

. When I said that companies tend not to think in 6-month cycles, I was talking about Sun. Sure Flash is smaller and flashy. From what I hear, so was a lot of really great software which was in more ways stronger than the competition than Flash.

Actually one of the things that bothered me about Flash (as far as the "gee whiz" factor) is its lack of accelerated hardware support. But being a pure software renderer is one of its primary strengths. It makes porting to Palms, celphones, WebTV, etc. -- anything with a raster display -- immediately feasible, not at the mercy of broken drivers, substandard HW, DX versions, etc.

But which has more capabilities to leverage as clockspeeds, memory, and bandwidth gets faster? What will today's 6 meg download (WebStart) be like tomorrow, for something much more reusable?

Actually if RAM bandwidth improves Flash is positioned very well to take advantage of it. I think a mature implementation on a PS2 for example will absolutely rock. It's hard to think of anything that could be more flexible. Doing as well as it does with limited bandwidth, it should be able to knock your socks off on high-bandwidth.

. How many hundreds USD$ does a pretty box from Macromedia cost? (Which is even more prohibitive overseas.) Yes, there is a 20 meg 45-day trial download, but you get a closed-source product which only survives if its niche survives.

Not entirely closed. As I understand it, the .swf format is open and there were already 3rd party F4 players built for Palms (and Linux I think). There are also 3rd party authoring systems from companies like Adobe as well as smaller independent shareware authoring systems. MM may eventually find themselves competing with other authoring products.

Now, I am taking an absurd stance, since I like Flash. Until recently, I've never actually enabled it on a computer unless I really had to, but I may soon be doing fairly weird things in Flash. I hear that the C++ API to Flash is badly documented and whatnot (even missing?) so there may be humorous problems there, but come back in a month and I'll blab all about it.

Do so! I will be interested. If you have it installed and you browse around (outside the tech circles) you'll see it surprisingly often. Gaming sites in particular use Flash spots all over the place, as do many news sites like CNN to provide animated visual aids.

[ Parent ]
Java is not dead .... (1.66 / 6) (#8)
by Komodo321 on Mon Mar 19, 2001 at 05:41:47 PM EST

End of discussion.

If only... (4.00 / 2) (#12)
by ucblockhead on Mon Mar 19, 2001 at 06:08:05 PM EST

There's never an end of the discusion when it comes to programming language religious wars...
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
What failed? (4.16 / 6) (#16)
by Inoshiro on Mon Mar 19, 2001 at 06:52:47 PM EST

Java the language? Java the virtual machine? Java the bytecode spec for a virtual machine? Java the APIs which are provided to work with on the portable virtual machine?

What failed is Sun Microsystems for making "Java" a nasty m'elange of many, many different technologies and components. They're not alone. What exactly IS DOT-Net? How about MS DNA? Kill the marketters who don't know what they're doing, and the managers that let them label things as such.

Sun would've done a lot better if they'd just provided either the improved OO language, or a virtual machine / library spec (ISO C & other libs) for consumption. Thanks to projects like GNU, things like binary-only programs targetted at virtual machines are dieing. Hopefully the Java lanaguage will get a new lease on life if it's implemented in front of a Java bytecode code to native code compiler.



--
[ イノシロ ]
Bytecodes (none / 0) (#20)
by sigwinch on Mon Mar 19, 2001 at 07:36:04 PM EST

Sun would've done a lot better if they'd just provided either the improved OO language, or a virtual machine / library spec (ISO C & other libs) for consumption.

But that'd generate about as much income as an ISO committee does (not much ;-). This should not be construed as ensorsement of Sun, however.

Thanks to projects like GNU, things like binary-only programs targetted at virtual machines are dieing. Hopefully the Java lanaguage will get a new lease on life if it's implemented in front of a Java bytecode code to native code compiler

If you're only talking about JIT compilation on selected platforms, I agree. But I still think bytecodes are nice. They give you sandboxes, and portability becomes a question of "Does this platform have a reasonably sane C compiler?" If my boss drops an obscure computer on my desk and says "Make Java/Python/Perl run on this," I can probably deliver a running solution. Replace "Java" with "VB", and I run screaming out of the room.

--
I don't want the world, I just want your half.
[ Parent ]

Java is the wave of the future (4.28 / 7) (#18)
by weirdling on Mon Mar 19, 2001 at 07:10:11 PM EST

Java is a largely misunderstood language. I totally misunderstood it back in my C++ bigot days. Java isn't about speed. Java is about ease of development. With a complete, totally functional library that is portable accross most platforms if you avoid Swing, and with modern software design theory including object orientivity and high modularity, and with a memory manager that isn't so slow as to constantly require reworking to get around it (Win2K/Visual C), with enforced safe references, and with garbage collection...
I could go on and on, but the thing is that even if Java is only half as fast (possible, but it takes a very fast CGI system to do twice as fast as JServ, normally Apache modules), it is still worth it, because of the reduced development time in an industry where programmers are the most expensive resource ($5k/month is a *lot* of server). Java and Java engineers remain relatively unconcerned about their performance (within reason), and memory usage (within reason, again), because it simply doesn't cost much more to put the thing on a bigger machine, and after you're done writing it, someone else can easily maintain it, and so on, but now I'm rambling.
Whether it is Java or some other language, the idea embedded in Java, which is ease of programming before speed, will happen sooner or later. It is an inevitability.

I'm not doing this again; last time no one believed it.
Server costs (3.50 / 2) (#33)
by Miniluv on Mon Mar 19, 2001 at 10:16:24 PM EST

Actually, $5K/mo is not nearly as big a server as you are thinking it is. What sort of cost arrangement are you talking? A $5K/mo payment plan from CDW, a $5K/mo Colocation, managed, from Rackspace or a $5K/mo cabinet from Exodus?

Besides, is this server a pure web server, or is it Web+DB? Does it have a separate SAN, NAS or other storage solution, or do we have to discuss large quantity primary storage solutions?

You see where I'm going with this? Sure, coders are a big expense...often one of the largest, if not the largest, in the overall business model. You can't go tossing around ridiculous statements like that when trying to make an argument, otherwise you end up sounding as bad as the article you're arguing against.

"Its like someone opened my mouth and stuck a fistful of herbs in it." - Tamio Kageyama, Iron Chef 'Battle Eggplant'
[ Parent ]

I was referring to strictly hardware costs (none / 0) (#57)
by weirdling on Tue Mar 20, 2001 at 02:59:34 PM EST

Co-lo, bandwidth, maintenance, all cost more than the hardware because they, themselves, involve paying engineers to do the various tasks associated with them. However, to simply double the number of cpus in your average system from one to two costs less than $1k, which is a fifth the cost of the monthly salary for an engineer. Even a $20k Sun or IBM begins to make sense when it is just four months development salary.
Don't confuse bandwidth cost and bus width cost and co-lo cost and maintenance contracts with *purely* cpu and memory costs, which are a tiny fraction of the other costs that a co-lo place will charge. Java only increases your cpu and memory costs; your management costs generally go down, and your bandwidth costs are driven by your HTML requirements, not your programming language, and your bus width is driven by your data model, not your programming language.

I'm not doing this again; last time no one believed it.
[ Parent ]
Fair enough (4.00 / 1) (#80)
by Miniluv on Sat Mar 24, 2001 at 11:38:12 PM EST

Though I would not make the blanket statement that you can "double CPUs in your average system" when referring to backend processing systems. SMP, at least dual processing, is becoming more and more common these days, so you're often talking moving from 2 to 4 CPUs.

Also bear in mind all those poor folks who bought AMD based machines and now need to double up on CPUs. Their cost is much higher, because they need to replace more than their counterparts on Intel hardware.

The final thing is that Java programs generally have larger memory footprints. This isn't inherently bad, just something that must be accounted for when designing systems to run said Java apps. RAM is cheap now, but that isn't always true and can make up a significant portion of your hardware costs.

Ultimately, yes, hardware tends to be cheaper than developer time. I don't know that that makes Java any better, but it is certainly a reality. To me that sounds like developers ought to be part time workers, since Java is such an easy language to develop powerful applications in. If they can write it once and run it anywhere, how long do we really need to employ these people?

"Its like someone opened my mouth and stuck a fistful of herbs in it." - Tamio Kageyama, Iron Chef 'Battle Eggplant'
[ Parent ]

As Not Seen On Media (1.57 / 7) (#25)
by exa on Mon Mar 19, 2001 at 09:09:26 PM EST

Java failed. Despite all the big-budget advertisement and marketing backing it..

On the other hand, there are a lot of 'really innovative' languages that do offer some 'new language features'. They were shadowed by Java because Sun probably paid a lot to make it a commercial success.

Of course Java has failed to fulfill almost every goal it claimed, and yes it is an inefficient and lame special pupose language & virtual machine & library.

Java is a retreat in programming languages. It is the original hype. What is it my friends? Is it portable? Oh sorry, I didn't catch that. In Debian there are thousands of software packages that have been ported to more architectures than Java has dreamt of. Is it net-enabled? And just what are interpreted languages like perl or python and countless other programming environments for us hackers to use? Does it offer us any new language or library feature? Nope. It's just a chopped down C++, an unnecessary garbage collection routine ripped off from god knows where, a stupid object model, dysfunctional debuggers, a lame library, smalltalk wanna be attitude, and a compiler and virtual machine that turns a bit-grinding processor to my old Atari 800XL. If I attempted at enumerating all the grand mistakes it embraces, it would take some 100 pages to write.

Ask yourself what is new. Standard C++ is new. Haskell is new. Dylan is new. Even Python is new. Java is not new in any significant way, except perhaps that it was one of the first languages that could be run within a web browser. But sure, tcl/tk people know what the truth is! (What a blessed thing is a web browser!!! A network program that morons can use. Wow!)

Aha, and now our CS department is teaching this imbecile language to undergrads instead of scheme or pascal. Bet they're taking a lot of donations from Sun. Let them turn the poor bastards into mindless zombies... 'Let me suck this Java/OO thing. Yes, it feels so good. Aha, it's good for us programming zombies who are supposed to write lame web frontends to lame databases and nothing else.'

I'm not buying your corporate language. Sorry!


__
exa a.k.a Eray Ozkural
There is no perfect circle.

Good thing you're not in the mood for a flame war (4.00 / 3) (#42)
by Scrymarch on Tue Mar 20, 2001 at 12:30:28 AM EST

:)

Of course Java has failed to fulfill almost every goal it claimed, and yes it is an inefficient and lame special pupose language & virtual machine & library.

Only argument in this paragraph: Of course.

Java is a retreat in programming languages. It is the original hype. What is it my friends? Is it portable? Oh sorry, I didn't catch that. In Debian there are thousands of software packages that have been ported to more architectures than Java has dreamt of.

And the next time I want 50 reimplementations of "ls" on a host of similar Unices I might go there to use them.

Is it net-enabled? And just what are interpreted languages like perl or python and countless other programming environments for us hackers to use?

That's hardly a sensible argument now, years on. In the beginning it was one of the few languages with good net support. Now everything has caught up, I'll just use Enterprise Python Beans ... oh, wait ...

Does it offer us any new language or library feature? Nope.

The interface keyword as a solution to the multiple inheritance problem. synchronized and transient keywords for concurrency and serialisation. Not exactly new, but not seen all in the one place before either.

It's just a chopped down C++,

Thankfully chopped down from the baroque mess of C++, which is in turn badly compromised by back compatibility with C.

an unnecessary garbage collection routine ripped off from god knows where,

gc is what gives Java most of its productivity boost. It's a tradeoff.

a stupid object model,

versus what? C++? Please.

dysfunctional debuggers, a lame library, smalltalk wanna be attitude, and a compiler and virtual machine that turns a bit-grinding processor to my old Atari 800XL. If I attempted at enumerating all the grand mistakes it embraces, it would take some 100 pages to write.

Java can have performance issues. It's a trade off of developer time vs machine time.

Ask yourself what is new. Standard C++ is new.

It's a Java ripoff! The STL is neat because it can use generics, though.

Haskell is new. Dylan is new.

s/new/dead/

Even Python is new. Java is not new in any significant way, except perhaps that it was one of the first languages that could be run within a web browser. But sure, tcl/tk people know what the truth is! (What a blessed thing is a web browser!!! A network program that morons can use. Wow!)

Doesn't do to have the peasants tramping mud into the manor, eh?

Aha, and now our CS department is teaching this imbecile language to undergrads instead of scheme or pascal. Bet they're taking a lot of donations from Sun. Let them turn the poor bastards into mindless zombies... 'Let me suck this Java/OO thing. Yes, it feels so good. Aha, it's good for us programming zombies who are supposed to write lame web frontends to lame databases and nothing else.'

If CS departments determined what to teach solely on donations they would all be teaching Visual C++ and Basic. That would be a tragedy.

They teach Java because:

  • It's used in industry (ref: web frontends and databases)
  • It has a strong object model uncluttered by irrelevant holdovers, eg, #define and the disgusting C++ compilation model. Although Eiffel etc has this see the first point.
  • Sun might give them some money. Probably not.
I'm not buying your corporate language. Sorry!

I hope I survive until morning.

[ Parent ]

"New Language" (none / 0) (#48)
by exa on Tue Mar 20, 2001 at 09:37:26 AM EST

Go on with web frontends, I'll go with a PL

I don't have the stomach for 'new economy's 'new language'.

I want to scream out loud that OO, at least the way simple-minded languages like Java implement it, is not the way!! Long live CLOS!

What we need is more declarative programming languages that free us from the burden of sticking to a particular architecture family.

Among all procedural languages, I declare Algol 68 to be the ultimate winner! Which was deliberately drown in the sands of time! Kudos to the Algol design teams! Algol then made the first truly orthogonal language design which superseded both Algol-60 and LISP.

Kudos also to Niklaus Wirth who cunningly crowned simplicity over bloat! Let CS students understand the brilliance in his Oberon designs!

May McCarthy's name be written on the door of every CS department, for he realized lambda calculus on a computer!


Though overdesigned, C++ brought generic programming to my home computer. That we cannot deny!

And yet, the future holds promise of new formalisms that will enlighten our programming experience.

Fortunately, Java has a unique and less than significant place in this scheme. It is associated fully with 'the web' which lingers on a few ad hoc technologies that will be ultimately replaced. For that is the way of the Internet! And for that reason Java itself shall be replaced by another programming language!

If that task is left in my hands, I will personally see to its accomplishment!

__
exa a.k.a Eray Ozkural
There is no perfect circle.

[ Parent ]
yep, in 10 years... (4.00 / 1) (#50)
by rebelcool on Tue Mar 20, 2001 at 10:27:27 AM EST

something else will come along and replace it. Just like java is replacing where C++ would have been used a few years ago. (no, not in all instances, but in the ways of server backends it is)

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

"Innovating"? (5.00 / 1) (#70)
by pin0cchio on Wed Mar 21, 2001 at 04:06:50 PM EST

The interface keyword as a solution to the multiple inheritance problem.

C++ has this too: #define interface class

synchronized and transient keywords for concurrency and serialisation.

Stolen from popular database manipulation languages.

Not exactly new, but not seen all in the one place before either.

Re-hashing old features is innovation only if you believe this man.

Thankfully chopped down from the baroque mess of C++,

So they replaced a baroque mess of language constructs into a baroque mess of 20 MB of libraries just to display one window.

Java can have performance issues. It's a trade off of developer time vs machine time.

Which makes it bad for cost-sensitive embedded devices (slower is cheaper) and for real-time gaming.

irrelevant holdovers, eg, #define

Well-thought-out #define statements (such as #define const  public static final) actually improve readability and decrease carpal tunnel syndrome. (Or do you like COBOL-esque masochism?) Other preprocessor features (e.g. #ifdef) are good for creating debugging and optimized builds and GUI and CLI builds (for those systems where you don't want to have to load megabytes of AWT libraries).

Doesn't do to have the peasants tramping mud into the manor, eh?

Java applets cannot access the local hard drive or any computer except the host from which the applet is served unless the developer pays through the nose every year to Veri$ign (who bought its biggest competitor Thawte) for a certificate so that applets can leave the sandbox without displaying a big "WARNING: THIS APPLET'S CERTIFICATE IS NOT TRUSTED BY VERI$IGN. THIS APPLET WILL MOST LIKELY MAKE YOUR COMPUTER EXPLODE IF YOU RUN IT." dialog that's designed to scare Joe Sixpack away from companies that haven't paid off Veri$ign.


lj65
[ Parent ]
Very well put. (none / 0) (#76)
by exa on Thu Mar 22, 2001 at 06:17:45 PM EST

You have answered with the rigor I have been unable to achieve. Thanks.

I rate your comment 5 for especially the following observations:

>>The interface keyword as a solution to the
>>multiple inheritance problem.

>C++ has this too: #define interface class

>>Thankfully chopped down from the baroque mess of C++,

>So they replaced a baroque mess of language
>constructs into a baroque mess of 20 MB of
>libraries just to display one window.

__
exa a.k.a Eray Ozkural
There is no perfect circle.

[ Parent ]
What a troll (none / 0) (#79)
by ashultz on Fri Mar 23, 2001 at 02:14:11 PM EST

As someone who's implemented a giant program in C++ and reimplemented it in Java - not just "websites and databases" but a major scheduling algorithm project - I have to say that this post was one of the dumbest I've seen in this thread.

The Java program was similar to the C++ program at the end, except it ran on multiple platforms right off the bat (no porting), it had fewer bugs, was easier to maintain, and generally made us much happier.

[ Parent ]

Reply to article (4.00 / 3) (#28)
by tnt on Mon Mar 19, 2001 at 09:22:47 PM EST

You said:

These articles bugged me, not so much for the fact that they attacked java, but for the fact that the author seemed to simply ignore things like JIT and other advancements in Java over the years.

Agreed. But don't forget about Java being compiled (straight) into native code; like done by the GNU Compiler Collection (GCC) and by Metrowerks' CodeWarrior (... there's probably others that can do this too).

You also said:

In Garfinkel first paper, he mentions an ACM case study in witch grad students were given a string manipulation problem and asked to solve it in either C or Java. The 'majority' of the C/C++ programs worked in one to five minutes, whereas the java programs took between two and 30 minutes.

The students (using Java) should have probably used a StringBuffer.

Later you said:

Garfinkel also claims that the right-once-run-anywhere claim has fallen through. But I don't see that as happening at all. I've never once had a problem running code on one machine on another machine, not once.

Well, unfortunatly, I have come across this problem. I have run the same code on Solaris and Win95 and had different `rates of success'. But like you seem to allude to, the success rate of running JVM executables to different platforms is better than trying to move Win32 exectuables around (on the various Windows).

I also agree with you that Java is pretty easy to read. I attribute this to the convention of Java (libraries) to spell everything out... and not use (cryptic) abbreviations. [But, like you said, there is alot of typing when coding Java... but then again, I do alot of copying-n-pasting anyways.]

You know, if he really wanted to argue something, then he could have argued that the design of the JVM was not forward looking enough to incorporated or even allow for the incorporation of a richer set of fundamental types and operations. Or that maybe the JVM being too low level pervents the ability to do various (high level) optimizations when changing things to native code (in the JVMs). But I'm getting kind of off topic.



--
     Charles Iliya Krempeaux, B.Sc.
__________________________________________________
  Kuro5hin user #279

Re: Reply to article (4.00 / 2) (#40)
by eLuddite on Mon Mar 19, 2001 at 11:50:13 PM EST

But don't forget about Java being compiled (straight) into native code;

Thereby nicely circumventing many of Java's _advantages_, including safety and run time linkage. Java is a better environment than it is a language; it's not Java if it's compiled. It's not Java without the JVM.

If all you need is range checking and garbage collection, derive new classes for C++ arrays and the new operator. If people insist on redefining Java's role in places where it confers no advantage (server, compiler, whatever) then they should at least be prepared to admit that it's a relative failure according to its original promise. There's more inertia than technology happening here.

---
God hates human rights.
[ Parent ]

Java has reinvented itself (3.33 / 6) (#36)
by ism on Mon Mar 19, 2001 at 11:13:02 PM EST

Initially, portability was one of the major selling points. The promise of "write once, run anywhere" appealed to me, but I quickly learned the phrase was really "write once, debug everywhere." Java is young. It needed help. Hype was the answer.

Netscape included a JVM with its browsers which pushed Java into the consciousness of every tech-savvy Net user. Netscape also tried to ride Java's coattails and renamed ECMAScript, Javascript. Combine that with a new Java version that breaks programs written in the previous one released every so often and you've got a confused populace. The hype backfired, and I suppose you can say it sunk the client-side aspects for the time being.

Java is a little older, now on version 1.3, but Sun calls it Java 2 Platform. Confusing, yes, but there's a pretty good reason. The emphasis isn't on the client side anymore. It's mostly server side, with some focus on embedded platforms. I think Java's found its niche here.

Developers have a lot more control over the server-side environment rather than client-side. Java is highly condusive to Model 2 and MVC architecture with a combination of Beans, Servlets, and Java Server Pages. That degree of abstraction also helps with maintainability. The existing API and sheer amount of third-party components and tag libraries help speed up development.

I don't think Java has quite failed on the client side. I just think it hasn't gotten there yet. Since I started using Java 6 years ago, I've seen a good advance, from basic AWT to Netscape's IFC, to Swing. Sure, Swing is over-engineered, but compare that to what AWT can do. It's getting there. So maybe Sun hadn't really broken its promise; it just hasn't delivered it yet.

JavaScript -> ECMAScript (none / 0) (#51)
by Per Abrahamsen on Tue Mar 20, 2001 at 10:55:54 AM EST

I think you got your history backwards, Netscape invented JavaScript under that name, and later submitted it to ECMA for aproval as a standard. At that point, it was renamed ECMAScript, hopefully because someone realized the original name was misleading.


[ Parent ]
Closer, but not quite (5.00 / 1) (#60)
by zhobson on Tue Mar 20, 2001 at 04:37:54 PM EST

Actually, Netscape invented LiveScript and changed the name to JavaScript before wide release, presumably for synergistic "marketing" reasons. The ECMA standards committee knew that the JavaScript name was misleading, and on top of that MS had called their implementation "JScript." As a result, the "official" name of the language as specified in the ECMA standard is ECMAScript.

-zack

[ Parent ]

Mostly portable, but... (none / 0) (#65)
by keyeto on Wed Mar 21, 2001 at 01:35:15 PM EST

The replacement of "run everywhere" with "debug everywhere" is a pretty common criticism of Java. I've had a considerable amount of experience with this. A couple of years ago I wrote an API in Java that did a pretty simple request/response for a stateless network prorocol.

I'm a pretty good programmer. Of course nobody will admit to being a poor programmer, so I'll try to back that up some. Seven or eight years ago I wrote an image processing library in C++, that came to several tens of thousands of lines of code. I don't work for that company any more, but I know some people that do, and in all that time they've found a total of three bugs.

But back to statless protocols. Now, this sort of program needs to use sockets. When you get down that far, you're messing with faciliites the operating system provides, and different operating systems implement sockets differently. Getting the same binaries to work on different operating systems involved some horrible programming techniques, involving putting pretty much every socket operation into a separate thread. It was ugly, but it was the only reliable way I found, and I tried many, many different ways.

In the two years I maintained that code, I only wrote one genuine bug, which was missing leading zeros off a hexadeciaml number that had to be a fixed number of digits. Doh. However, in order to make sure it ran on all those different platforms, keep it portable, I made about twenty different releases over that time period, all but the one of which came down to some incompatibility between Java platforms. And the incompatibilites were everywhere. The language itself gets pretty complicated when you try to use public/protected/private in inner classes, and every different compiler demanded something different. That one was solved by defining all the attributes for those few classes at package level. So much for encapsulation. The libraries provided with many Java platforms really, really suck, and don't even attempt to do the same as Sun's standard ones. Figuring out the bits that were missing ended up with almost entirely duplicating the functionality for a number of classes, and just using the standard library classes as wrappers for the data. It looked nice and clean and standard to the guys using the API, but I was sure glad they never got to read the source.

However, even with this record of pain, I'm still glad of Java. It's the best language I've found that I can actually get paid to write. It sucks, but it sucks less, which is about the best thing you can say about a vast variety of computing technologies.

Out of choice, for fun projects, I now tend to use Python, but for more serious projects
--
"This is the Space Age, and we are Here To Go"
William S. Burroughs
[ Parent ]
Java: language with an attitude (3.85 / 7) (#37)
by cezarg on Mon Mar 19, 2001 at 11:34:29 PM EST

I'm a confessed C++/C (in this order) affectionado. Sue me! I don't agree with any sorts of generalisations about anything but Java programmers tend to have a bit of a chip on their shoulder which doesn't go well with me.

For java programmers their biggest sin is their blind faith that java is a mighty fine language whatever the task at hand. As a result we had a java based office suite, java based browser and I'm personally involved in rewriting (in C++) a (soft) realtime java based(!) application that barely works because of the dreaded (overhyped) garbage collector.

The second problem with java is that (sad as it is) its enormous explosion in popularity attracted a very mixed pool of talent. Now there are some excellent java programmers out there but there are also many that probably just picked up one of those "teach yourself in n days" books and learned java in a weekend. Because of its simpler syntax it quickly became attractive to all kinds of rookies and cowboy programmers and underachievers trying to make big money "hacking" Java after having only a marginal exposure to any other programming languages. Hence java programs usually exhibit very low quality compared to C++ based software. This gives the language a bad name to such an extent that many software shops won't even hear about writing anything in Java purely on the grounds of prejudice.

My technical objections to java mainly apply to the language's syntax. As I explained in my earlier post java's lack of const or equivalent (no final static won't do) is a detriment.
Also I'd rather not have the array bounds checking and actually have my program bomb under out of bounds condition. The problem with java is that it handles out of bounds conditions by throwing exceptions so some java cowboys tend to have a sweeping catch(Exception e) {} statements that are... empty! This is not unlike piping all your compile warnings and errors to /dev/null ie. pretty much ignoring them. Frankly I'd rather if programmers really know what the hell their code does. At least add a frigging print statement in those sweeping catch statements!
Java containers are a joke. They are designed in the way that was en vogue in C++ back in 1992. If you're jumping to defend java containers, don't. Gosling himself wants to see parametrized types in Java so go figure.

My last beef with java is its runtime environment. JVM is big and slow. Sun can promote java as an embedded platform all they want but the truth is that java is simply too big for a desktop! I still can't get over why it needs to load > 20MB just to run a simple app with one main window and a single dialog box.
As for the often touted garbage collector it's only good when this is the behaviour you want but it pretty much renders java useless for any sort of realtime systems. At least in its current form it's just plain too unpredictable to be even good enough for writing an mpeg video player.
Java lacks a good debugger. I would consider java for serious development if it had anything approaching the usability of the built-in MSVC debugger. I refuse to debug my code with cout/printf/println. That's what debuggers are for and if a language doesn't have one it's not a serious development environment. Please, don't tell me that debuggers are essentially redundant because they aren't. Particularly when bugs appear across platfoms ie. one platform works just fine while another one crashes or works erronously. Debuggger is a must, period.

But it's not all grim in the javaland. Java has a nicely designed networking library. The crossplatform socket classes in java is really what saved the language. I feel that if it wasn't for java's rich networking capability java would be dead and buried by now. Java's threading is nice too. I like having threads built into the language. I miss that in C++. They synchronized statements are simple and elegant and so far have been sufficient for my (limited) threading requirements.

Wrap up. Java isn't dead by any stretch of imagination. But then again it's not what Sun hyped it up to be either. It has found its niche in the server side applications and will probably coexist with all other languages for a long time to come. But if you're a java programmer and you're thinking that java is on the verge of taking over the world you really need to look outside of your cubicle. There is mucho stuff happening that java would simply be a bad choice for.

Shoulder chipping (4.66 / 3) (#43)
by SlydeRule on Tue Mar 20, 2001 at 01:58:25 AM EST

You make a number of good points. Lemme ignore all of those, and instead I'll concentrate on where I don't fully agree ;-)
For java programmers their biggest sin is their blind faith that java is a mighty fine language whatever the task at hand.
Unlike, say, Linux boosters? It seems that every computing technology has a group of fanatics who make all the noise. That shouldn't be taken to mean that everyone agrees with them.
java programs usually exhibit very low quality compared to C++ based software
My experience has been that programs usually exhibit a depressing level of quality regardless of whether they're written in C++ or Java. The Java programs tend to be a little less awful than C++ only because the hack coders aren't able to do the really nasty stuff like make weird operator overloads.

It's not the language that's the problem, it's the hack coders, and they're not going away. But that's a different issue, for a different article.

java's lack of const or equivalent (no final static won't do) is a detriment
I recognize that perhaps an overwhelming majority of programmers who're familiar with the issue that you're talking about would agree with you. However... as C++ has shown, the notion of const attributes is fraught with annoyances, and eventually brings about things like the mutable wart. Trying to make a C++ system of any size truly const-correct is a challenge which probably does not deliver benefits in proportion to the effort.

As for const arguments to methods, these are only necessary in a language such as C++ which doesn't have the notion of value types vs. reference types, and in fact even allows objects and primitive variables to be simultaneously used as values and references.

In Java, primitive types have value semantics, as does the immutable class String. If the formal argument is of a primitive type or of class String, it is effectively const. If the formal argument is of a mutable class, it is effectively non-const, and the use of such a formal indicates that the method reserves the right to call mutator methods on any object passed in that position.

I'd rather not have the array bounds checking and actually have my program bomb under out of bounds condition
If only you could count on it bombing in C++. The last time I had one of these in C++, most of the time it clobbered unused memory so I didn't even know there was a problem. After it got into production, about one time in a thousand, it'd clobbered a quantity which was in a network transmit buffer, a buffer far removed from the code doing the clobbering. It only took a year and a half to track down the customer complaints about occasional erroneous amounts (and even that discovery was by accident).

Java will throw the exception. Yes, many hack coders choose to ignore the exception. But at least the erroneous memory access doesn't cause random problems in other parts of the program. And good coders will find the exception to be a useful feature.

Java lacks a good debugger.
Huh? JPDA provides the ability to debug multi-threaded apps running on an entirely different system. I use it from WinNT to debug EJB code in a JVM running on Solaris. What essential features are missing that cause Java debuggers to not be "good"?

[ Parent ]
if( JBuilder == JPDA ) { JPDA = bad; } (none / 0) (#49)
by cezarg on Tue Mar 20, 2001 at 10:26:35 AM EST

I'm not sure if Borland JBuilder's debugger is based on JPDA but the last time I tried to use it I had very little luck with it. I gave it my jar file and it sat with it for a good few minutes and then it went belly up and that was the end of it. Granted my code uses a couple of native libraries but still we're talking about a debugger here for crying out loud. It's not supposed to just die with a gpf no matter what I throw at it.

[ Parent ]
what C++ compiler? (5.00 / 1) (#54)
by SEAL on Tue Mar 20, 2001 at 01:51:46 PM EST

If only you could count on it bombing in C++. The last time I had one of these in C++, most of the time it clobbered unused memory so I didn't even know there was a problem. After it got into production, about one time in a thousand, it'd clobbered a quantity which was in a network transmit buffer, a buffer far removed from the code doing the clobbering. It only took a year and a half to track down the customer complaints about occasional erroneous amounts (and even that discovery was by accident).

I don't know what C++ compiler you were using, but that sounds like a problem with an optimized build. In Visual C++, if you build a debug version, memory is reserved just before and after an allocated block to detect overrun errors (this is with DEBUG_NEW defined).

The error cezarg is talking about is an array out of bounds and would be easily caught and debugged with this setup.

Your error - you weren't really specific. If it was truly just memory off in space somewhere, and not a simple overflow, then you have more problems with your code than just C++'s lack of bounds checking.

- SEAL

It's only after we've lost everything that we're free to do anything.
[ Parent ]

Haven't tried BugSeeker, have you? (none / 0) (#61)
by Wojina on Tue Mar 20, 2001 at 06:39:31 PM EST

You said:
Java lacks a good debugger. I would consider java for serious development if it had anything approaching the usability of the built-in MSVC debugger.
Take a look at Karmira's BugSeeker for Java2. It hooks in through JPDA, and I use it for all of my debugging needs.

[ Parent ]
It's pike that's with an attitude! (none / 0) (#63)
by szap on Tue Mar 20, 2001 at 10:03:38 PM EST

It's "Pike, the language with an attitude". (Checks page). Oops. Well, it used to have that tagline attached to the name, but it seems like they removed that now. Pity, spoils my reply.

To make up for it, here's an mini MLP for comparing programming languages: The Great Computer Language Shootout. Take it with a grain of salt! Java seems to be doing very well. Pike is close, though.

[ Parent ]

debugger (none / 0) (#78)
by ashultz on Fri Mar 23, 2001 at 02:10:13 PM EST

As far as "java lacks a good debugger" maybe I'm crazy but I find a formal debugger much less necessary in Java than in C++ because of its exceptions.

A large number of bugs that in C++/C required me to fire up debugger now are exposed to me by an exception which graciously tells me what line they happened at. So I go there, look at the line, and often damn, there's the bug. A nice change from my days of "hm, there's a null pointer error somewhere in the code. Better start this up in infinitely-slow debug mode."

Obviously, exceptions alone aren't all of debugging, but more rigorous syntax and types plus exceptions eliminates 90% of the time-wasters I used to chase.

[ Parent ]

I'm a C++ programmer, but... (5.00 / 3) (#52)
by Per Abrahamsen on Tue Mar 20, 2001 at 11:06:11 AM EST

...it is obvious to me that Java hasn't failed. It is probably the most successful new language introduced since C++. Just see the number of Java programming jobs or the different places Java is used.

Technically, it is neither a revolution nor a step backward. A number of well known concepts have been combined, creating a language with a different set of trade-offs than the other popular choices. It is neither better, not worse, but suited for different situations. Basically, I think the language is better suited for an "average" programmer than C++.

The most annoying thing about the language is the marketing hype, however this together with timing is probably also the main reason for its success, technical issues set asside.


Java, like many languages... (4.66 / 3) (#56)
by jd on Tue Mar 20, 2001 at 02:50:59 PM EST

...is extremely good at what it has been designed for.

Java is a very strongly-typed object-oriented language, which makes it excellent as a teaching language, as it forces new programmers to think about what they're doing. Spaghetti coding is possible in Java, but it's also much more obvious.

It's also good for learning about multi-threaded and/or parallel programming -- concepts which are traditionally either barely taught at all, or covered amazingly badly.

However, it's not a miricle cure-all. Other languages are also good at what -they- are designed for. If you're going to do coding which is 99.9% re-used at all points, use Forth. The overhead of sequential languages, at that point, becomes silly.

On the other hand, if you're dealing with a lot of predicate logic, PROLOG, PARLOG or any other predicate language will always beat any other hands-down for ease of coding/maintenance and probably speed, too. Because those are the problems such languages are designed for.

A custom solution will ALWAYS be superior to a generic solution, for a custom problem. Generic languages will have a better -average- rating (by some measure or other), for all problems, but within a narrow field, the custom solution will always win.

Java, IMHO, is a custom solution language for multi-threaded, object-oriented problems, which have a fairly high level of re-use, don't require fine-grained hardware control, and which don't violate too many type constraints.

Anything outside of that domain (and there's plenty that is) either won't be writable in Java, or won't be writable cleanly.

A screwdriver can be ideal for what it's designed for, but it really does make a lousy hammer. Learning to use tools means learning to know what they're designed to do.

Agreed (none / 0) (#64)
by philc on Wed Mar 21, 2001 at 08:22:48 AM EST

I think you've hit the nail on the head there (pardon poor pun on aforementioned screwdriver analogy :). I do most of my work under C++ (mainly due to a large existing codebase), but I love Java. At the risk of sounding a little arrogant, I think Java is the best thing to ever happen to C++: it's taking C++ out of the hands of idiots^H^H^H^H^H^H less competent programmers. There's no two ways about it, C++ is hard language to learn, and often to use. Considering that most programmers work on general purpose application development, rather than writing "system-level code", e.g., code that has to get down and dirty with the hardware, is doing hardcore number crunching, or has tight memory constraints, it seems fitting that they should be using Java. Languages like C++ will always have a place, but given todays hardware technology, that place is not necessarily your everyday application code.


"No Neal, after you" - Buzz Aldrin
[ Parent ]

To those who say Java is bloated and slow... (none / 0) (#62)
by nstenz on Tue Mar 20, 2001 at 09:15:59 PM EST

A lot of JVMs are big and slow (Sun's, for example)... However, it's not the language's fault. People are writing the firmware for cell phones in Java... and set-top boxes... as well as other embedded applications. Obviously Java has something going for it. I agree that it can be slow, and there are probably a decent number of crap Java 'programmers' out there... But the language is far from dead.

Not a failure, just not meeting the hype (none / 0) (#66)
by RandomPeon on Wed Mar 21, 2001 at 02:01:04 PM EST

Java was supposed to revolutionize the world - everything except the OS and the JVM itself were going to be written in Java in the not-so-distant future. This hasn't happened, suprise - no sexy technology lives up to its hype. Some reasons possibly why:

1. I think it's largely because efficency still matters in more areas than Sun thought - games, computationally intensive software, bloatware(Office in Java? Ouch), and compilers(Arg - official JDK compiler is written in Java - much slowness).

2. It never got support from the "hacker" types. Java is a proprietary language to some extent - Sun tries awfully hard to get on the open-source bandwagon, but a Big Evil Corporation still controls the direction the language will take. Furthermore, if you're giving out source code, you can always have people compile it to their platform, and take a massive time-hit once rather than taking a little one every time. Java doesn't let you poke around for stability/security reasons - there are pointers, but you can't know them, and so forth - it has the same lack of appeal Windows does - there are certain things you can't know.

3. Sometimes the abstraction and object-orientation gets out of hand. The AWT classes are a good example - my head hurts when I have to use them. The File class is another meaningless abstraction I recently used - it represents "abstract file objects" or something like that, but's it not an abstract class.

That said, I think Java is part of a historical trend toward higher level-programming.

Assembly->C->C++->Java

In theory, as you move up the chain you trade efficient programs for effcient coding. With Java, I'm not sure the tradeoff is favorable - the increase in the ease/reliability of coding may be outweighed by the substantial loss of efficency the language entails.

Ahem.. Assembly->C->C++->? (none / 0) (#68)
by exa on Wed Mar 21, 2001 at 03:33:59 PM EST

Well you get the point.

Assembly->C->C++

Assembly->C->Java (damned editor prunes ws)

But definitely not the edge C++->Java. Of course backward evolution does occur in Nature, so....

It's just that C++ is a step in one direction and Java another. I can't say that Java is a higher level language than C++. They are both imperative class based languages. They are in the same family of programming languages so saying what you claim would be totally misleading.

Ah, I know that's what Java's authors claim, too. But not all claims reflect the truth.

Regards,
__
exa a.k.a Eray Ozkural
There is no perfect circle.

[ Parent ]
C++ (4.00 / 1) (#74)
by delmoi on Thu Mar 22, 2001 at 12:46:00 AM EST

The thing about C++ is, it's very flexible and versatile. You can write C++ that looks like C, and you can write C++ that looks like Java. Or anything in between or beyond.

(Hell, you can write C++ that looks like Pascal, or COBOL, or even line noise if you want)

In some cases, C++ won't look as advanced as java, due to the lack of use of stl things and the such, other times it will look more advanced, using templates. It all depends on the context.
--
"'argumentation' is not a word, idiot." -- thelizman
[ Parent ]
Java is a pedagogic device (3.00 / 1) (#67)
by exa on Wed Mar 21, 2001 at 03:25:54 PM EST

In my experience Java is good to teach people the basics of object oriented programming. Even though basic OO programming gives only a small fraction of the whole programming subject, it may be one of the starting points. That said, I unfortunately see no merit in trying to extend Java beyond its rightful use as a pedagogic device and for programming "web applets".

Those who do intend to practice the art of programming have to learn a general purpose application language because Java is too inefficient and severely limited in scope.

Also note how Java is defended by the majority of non-hackers. :>

As I previously said, there is only one big reason why Java became the memorable programming language hype. Java, dear colleagues, is the only programming language which has been allied with the force of advertisement and marketing. C# supposedly is to be the second in this programming language advertisement trend.

Look when a language becomes widely used without being supported in this way by international corporations.

Indeed, C++ suffered almost the same, if not altogether extremely as in the case of Java, consequences when it was declared by corporations 'the language of the future'. Many companies jumped on the bandwagon and it was discovered that C++ didn't immediately provide a magic improvement in neither quality or development. As an accompanying symptom, it was seen that the majority of C++ users were people with little or no insight into computers and programming (those who we used to call "lamers" in the demo scene.) You may imagine that part of the reason to attract these people to the C++ game was to

1. sell them developer tools
2. sell them books

which is just another incarnation of convincing people to purchase things they don't need. On the other hand, the circumstance with Java is I believe even more pathetic. Almost everybody who has had a computer for more than a month think that they are programmers because they "know" Java. Although, it would be great if that were really the case it isn't. And although I'm a CS graduate, sometimes I encounter people, say from a graphics design department, who ask me whether I know Java, as if that would be a key to determining how skilled I am in programming. This constitutes the personal side of my problem, because I believe I'd read the entire reference manuals since the first Java release and by training I should be able to understand any formal language.. and surely I had had a lot of experience using it. It would be impossible to tell a random Java programmer that Java is only one of a multitude of formal languages in existence. Lamers rule planet Earth once again.

Let alone this personal note, Java is quite useful as a pedagogic device. A friend of mine who has been teaching CS102 showed me the code with which they would demonstrate people MVC design pattern adequately using Java, based on an OO example code I'd suggested before. It was brilliant. It would be almost impossible to show the same thing using C++, because the programmers would have to be familiar with a lot of more intricate aspects of systems programming, such as using a GUI library or having a handle of the more complex C++ standard library.

However, I will have to stress my previous point. Java is not enough. It does not even stand as a contender to more mature compiled languages for general purpose programming. Don't waste your time trying to use the same hammer for every problem. Also be wary of corporations that would like to control how programming is done by controlling the programming languages/environments and trivializing programming so that only they hold "the edge"· Java in that respect not at all different from m$ "technologies" like ActiveX/ASP. It would be a saint's course to be skeptic of the innocent looking cup of coffee.


Regards,


__
exa a.k.a Eray Ozkural
There is no perfect circle.

Not a general purpose language? (none / 0) (#73)
by delmoi on Thu Mar 22, 2001 at 12:42:48 AM EST

How, exactly, is Java not a general-purpose language? Sure, it may not have all the features of C++, but then again it has a lot more features then C, or Visual Basic.

Would I try to solve every problem in Java? No, probably not. I wouldn't try to do an OS in Java, or other kinds of low-level things. And due to the faulty timing in Java on windows9x, I probably wouldn't try to do something that needs a smooth display (on win9x, you can't get better then 50/60 millisecond timing resolution, even though native apps can get 1ms)

But anything else? Sure. Of course, I'm just a 'hacker', and I'm not doing 'enterprise solutions' or anything like that. Most of my programs are just for my own use, or experimentation. Why would I want to have to worry about memory leaks, plain C holdovers, #IFDEFS and other annoyances if I don't have to?

Java as a language does not have any limitations, Java as an environment does, but then so does every other environment. And really, who cares if a program 20% slower then it could have, if it only took a third of the time to develop?
--
"'argumentation' is not a word, idiot." -- thelizman
[ Parent ]
Here is why (none / 0) (#77)
by exa on Thu Mar 22, 2001 at 06:24:04 PM EST

With a general purpose language you should be able to write any kind of application. Including an OS. C, LISP, or C++ is that kind of language.

It seriously limits the programmer in the number of things that can be performed... First reason: it doesn't let you deal with pointers as it should, and second you can't have objects with semi-dynamic scope (means allocated on the stack I hope ;)... Countless other limitations that make it the 'web applet' language.

By the way 20% performance loss is imaginery. I like to say that in Java you lose all the performance available.

Regards,

__
exa a.k.a Eray Ozkural
There is no perfect circle.

[ Parent ]
It's a troll you putz (4.00 / 2) (#69)
by Bob Abooey on Wed Mar 21, 2001 at 03:34:05 PM EST

Holy cow, how thick can you be.... When someone writes an article like that they are trolling for stuff like this to happen. They want to get linked in slahsdot and other popular weblogs so the traffic shoots up and people start buzzing about their article. Good God man, If I wrote that stuff in a post on slashdot I would be cricified and get a ton of death wishes in email. But a Solon writer does it so it has validity.... okay whatever. The fact is that YHBT YHL HAND.

However, that said, the point about java not being very readable is valid. Of course the coding style which is encouraged doesn't make it a bad languaage, but it doesn't help it. I really don't understand how you can say that

Reader netIn = new BufferedReader(new InputStreamReader(mySocket.getInputStream()));
netIn.read();

is just as readable as

mySocket.read();

You're just being silly if you actually belive that. I'm a fan of following a certain consistant coding style, but why not try to make it friggin read-able. I've never read a book ThatWritesStuffLikeThisInIt. Use lots of white space and use variables and function names which are short and to the point...

char *read_from_socket(int file_descriptor)

makes great sense to me... it reads like a book, you know, with spaces between the words.... But alas, I'm veering off topic.


-------
Comments on politics from a man whose life seems to revolve around his lunch menu just do not hold weight. - Casioitan
I didn't say I *liked* it (none / 0) (#72)
by delmoi on Thu Mar 22, 2001 at 12:29:51 AM EST

doesn't help it. I really don't understand how you can say that ... is just as readable as ... You're just being silly if you actually believe that

Well, I didn't say I *liked* it, I would much rather be able to do mySocket.read(), the flexibility of writing one class that can write to files, sockets, or anything else is nice (I actually did derive an OutputStream once in one of my projects), I don't see why they couldn't just have made OutputStream a interface and let everything implement it.

But it still seems *readable* to me, and in fact that line contains a lot more *information* then a mySocket.read() function would have in it. Whether or not that information is needed is another issue.
--
"'argumentation' is not a word, idiot." -- thelizman
[ Parent ]
right-o (3.00 / 1) (#75)
by Bob Abooey on Thu Mar 22, 2001 at 09:09:15 AM EST

Understood. However, my point was that my_socket() is much more readable than mySocket(), in other words I am promoting a style of coding which separates words, just like the written language. We write like this for a reason, because it is more readable ThanIfWeWroteBooksLikeThis, or_can_you_tell_me_that_this_is_harder_to_read ThanThisBecauseIfYouDoIWillHaveToQuestionYourSanity.

Yours,
Bob


-------
Comments on politics from a man whose life seems to revolve around his lunch menu just do not hold weight. - Casioitan
[ Parent ]
The failure of java? | 80 comments (65 topical, 15 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest © 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!