The Artima Developer Community
Sponsored Link

Weblogs Forum
Java's Real Value Proposition

7 replies on 1 page. Most recent reply: Jul 14, 2003 12:58 PM by Gerry Giese

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 7 replies on 1 page
Brian Murphy

Posts: 1
Nickname: btmurphy
Registered: May, 2003

Java's Real Value Proposition (View in Weblogs)
Posted: Jul 7, 2003 11:01 AM
Reply to this message Reply
Summary
In his essay titled, "Java's Cover", Paul Graham explains why he thinks Java is a "stinker". Although some of the points made are valid, there are many misconceptions that are unfair or outright wrong, and need to be corrected. More importantly, Dr. Graham seems to miss the real value propostion of Java as a language and platform.
Advertisement

A few weeks ago, in his Artima blog, my buddy John McClain told us about an interesting essay by Paul Graham (located at http://www.paulgraham.com/hp.html) in which hackers (in the true definition of "hacker") are compared to painters. Well, anything John tells me to read, I read; because John has never steered me wrong. Heck, if it weren't for John, I'd probably never read Slashdot. Anyway, after reading the essay, I was impressed enough not only with the content of the essay, but also with the style and layout of Dr. Graham's web site, that I started rooting around the site; looking for other interesting things to read that might be there. Now, anyone who knows me is probably thinking, "That must be some site!"

You see, I've always been more of a 'pencil-and-paper' Math geek kinda guy, rather than a point-and-click-surf-the-web kinda guy. I guess I probably wouldn't fit in with the hackers. Although, like a lot of hackers, I've taken only one CS course in my life. That was in high school, a long time ago. I was so turned off by the processes and formalisms (like flow-charting) that were imposed on us that I swore I'd never take another one. But I do like to think long and hard about a program, and even make rough design sketches (in pencil of course), before I start pounding on the keyboard. And according to the author, that makes me not a hacker; I think he's probably right. I guess that makes me more of a ... well, a mathematician, posing as programmer.

And the author is right about another thing in that first essay: mathematicians do think they're smarter than everyone else. And this used to drive me crazy in grad school. With a few notable exceptions, most of my professors and peers in grad school had quite a high opinion of their own abilities. I used to wonder, "How can people who wear their pants up around their chest possibly be smarter than the rest of us?" Of course, that kind of attitude always got me in trouble with my professors and office mates. So I guess I was a misfit in the world of mathematics, just as I seem to be a misfit in the world of computers ... but I digress.

So, I don't surf that often, unless it's in the ocean. And I've not been known to root around anyone's web site, unless it's for free (as in free speech) software or free music; you know, the important stuff .... but again, I digress. The point is, the quality of the first essay, and the quality of the site where it's hosted, caused me to discover another essay by Paul Graham that people who visit Artima might find interesting as well. That essay is titled, "Java's Cover", and is located at, http://www.paulgraham.com/javacover.html.

Like the first essay, this one is very well written, and makes a lot of valid points that really hit the nail on the head. But there were some things the author said not only about Java, but also about Sun in general and its handling of Java in particular, that I happen to disagree with. At first, I thought I'd send Dr. Graham an e-mail containing the appropriate corrections. "Yeah", I thought. "He'll be so grateful that someone he's never met is nice enough to tell him all the things he's wrong about. Yeah, that's the ticket." But then in a brief moment of sanity I realized what an idiot I was. And besides, I'd never be able to bring myself to hit the 'send' button anyway; too much of a coward. So I was faced with a small dilemma. I felt that it was important that someone stick up for Java and Sun, but I wanted to remain somewhat anonymous. And then it came to me. I figured I could write up a reply and post it at Artima; who's going to read what I have to say there anyway? And if anyone does happen to stumble across my ramblings, I'm among friends, right? .... right!? So here goes nothin'.

Dr. Graham introduces his essay with a caveat in which he says he's not really writing about Java, but about hacker's radar. If that's true, then I suppose my comments below should be directed more at the misconceptions held by the hackers, rather than the author. But when you read the essay I think you'll probably come to the same conclusion I did: even though the author makes claims to the contrary, he himself has some serious, critical biases against both Java and Sun.

Some of Dr. Graham's criticisms of Java in particular, and Sun in general, are actually well-founded. And I'll try to point them out; hopefully, without getting myself into too much trouble with my employer. Fortunately for me, Sun has always been - and continues to be - an "engineer's company", as opposed to one of those companies where fear-and-loathing of management runs rampant. This has allowed for quite a bit of self-examination and even self-criticism. The reason for this, I believe, is because of leaders like Scott McNealy and Bill Joy. Because of people like McNealy and Joy, as well as other technical leaders like Rob Gingell, critical review without retribution has always been part of the culture at Sun.

Prior to joining the company, I always had a lot of respect for Sun. And I figured that upon joining Sun some of that respect would decrease once I saw what goes on behind closed doors. This is fairly typical of most successful companies; everything the public sees generally has some kind of "spin" on it. So I was pleasantly surprised when I joined Sun and found that for the most part, its a very well-intentioned company that's just trying to build good stuff; where the company will win or lose based on the merits of the stuff we create, not on "out-marketing" the competition. Of course, as Sun has grown, it certainly has acquired its share of self-serving, political "weenies" (the technical term), but those folks seem to be more than offset by the many good people still at Sun. Which brings me to my first reply to Dr. Graham's essay.

In the essay, Dr. Graham seems to credit all of Java's popularity on nothing but an aggressive marketing strategy that's laced with ulterior motives marked by a desperation caused by the current economy. Consider some of the following reasons Dr. Graham gives for Java being -- as he puts it -- a "stinker":

  • "It has to be energetically hyped."
  • "It has ulterior motives. ... the reason we hear about Java all the time is not because it has something to say about programming languages. We hear about Java as part of a plan by Sun to undermine Microsoft."
  • "Java .... happens to be controlled by a giant company. So the language is likely to have the same drab clunkiness as anything else that comes out of a big company."
  • "Its daddy is in a pinch. ... If Sun runs into trouble, they could drag Java down with them."

The statements above seem to paint the following picture:

  • Java is so big, bad, clunky, and useless that it has to be "sold" to developers like a good-for-nothing used car to an unsuspecting customer.
  • Sun is some kind of huge, evil company that has complete control over Java and its future; and has devised some kind of sinister plot to use Java to destroy its competitors.

I think Dr. Graham has given Sun way too much credit. First, Dr. Graham doesn't seem to understand that there are other companies (IBM and BEA just to name two) that exert an incredible amount of influence and control over Java. I know this from personal experience. My group's work has been directly and negatively affected by that influence; trust me, it's quite formidable. These companies make a lot more money off of Java than Sun does. They also are responsible for quite a bit of the hype (as well as the "clunkiness") that Dr. Graham is blaming on Sun. Granted, Sun has hyped -- and continues to hype -- Java, but to place all the blame on Sun is simply unfair. And then to say that Java has nothing to say, and that Sun is simply using it to undermine Microsoft is just plain ludicrous. Such a statement contains the same sort of arrogance that Dr. Graham seems to be crediting to Sun.

To support my rebuttal above, I think it's important that I say a few words about Scott McNealy. No matter what you may think about Scott McNealy and his antics in the media, my take on him is that he really is a true leader who believes deeply in technology. He's definitely not your typical CEO who just wants to make a lot of money while destroying his competitors along the way. I truly believe he wants to create great technology. And I believe he thinks there's more than enough money to go around for other companies who also want to create great technology.

At JavaOne 2002, I was listening to a keynote given by McNealy. I was sitting next to a colleague who had never heard him speak before. Her prior impression of him was the typical one: brash, anti-MicroSoft, a lot of hype, a typical CEO. After listening to the keynote, she turned to me and said, "Wow, he really wants to save the world, doesn't he?" And I thought, "She's right. He does seem to care more about good technology than about just making money."

Unlike other CEO's I've encountered, McNealy seems to understand that he's not smarter than everyone else; he actually listens to the techies he has advising him (people like Bill Joy and Rob Gingell). Unfortunately, as companies grow, it gets harder and harder to innovate because "the Bozo factor" begins to take effect (a term coined by McNealy himself). The Bozo factor occurs when a company grows so fast it can't be as selective as it could be in the early days. Mediocre employees, exemplified by "weenie" middle managers, begin to leave the sinking ships of failing competitors looking for a safe place to hide and avoid risk. As more and more of these well-meaning but misguided souls join the successful company, progress and innovation becomes more difficult to achieve because information flow is prevented in an effort to avoid risk at all costs.

This is why I am fairly certain that Sparc and Java would not exist today if they had been proposed at a company like IBM or HP or Xerox. At that time, those companies were much larger than Sun, and were infested with folks unwilling to risk violating the status quo. Paraphrasing Dr. Graham in his first essay noted above, '... startups win ... big companies want to minimize risk at all costs'. As Dr. Graham says, "Big companies win by sucking less than other big companies." So I believe Dr. Graham would concur with my supposition about Sparc and Java. And I think it's important to remember that when Sparc was proposed, and certainly when Java was proposed, Sun was not a startup; although McNealy continued to instill the startup mentality. Oh, and it's not just large companies that lack vision; people in the media seem to suffer from risk aversion as well. I can still remember the dire predictions of doom for Sun in the "San Jose Mercury News" that were motivated by Sun's decision to switch to Sparc.

Which brings me to Dr. Graham's criticisms of Java itself. Although Dr. Graham might agree with me that Java could not have survived -- and certainly could not have thrived -- at many other companies other than Sun, he certainly doesn't share my respect for the technology as a programming language or a platform. Before I respond to some of his criticisms of Java though, I should probably say a few words about my own views on programming languages; so that you can better put my words into perspective.

As I said above, I'm certainly not a hacker. I have a lot of respect for the hacker culture; and I wish I were good enough to be a part of that culture ... sigh ... but I know the limitations of my own abilities. But it's important for you to understand that I have programmed; whether it was good or bad programming is a matter of opinion. Additionally, I'm not a "software snob". You probably already know what I mean by that term. A software snob is one of those people who think their way is the only way; they're generally arrogant and condescending, and they almost always dismiss anyone who doesn't share their "religious" views. Although it could be a particular technique or pattern for solving a problem, software snobs are often characterized by a belief in a particular programming language. The first time I encountered true software snobbery was around the time OO techniques in general, and C++ in particular, were becoming popular with the "unwashed" masses. Prior to that, it just seemed like random encounters with arrogant, condescending people (although in Math grad school, such encounters were far more common than random).

I can remember sitting in design reviews for systems that had hard real-time signal processing requirements. Because the system was a large, distributed system consisting of components involved in non-real-time resource allocation and command and control, as well as real-time signal acquisition and analysis, some parts were written in assembler, some were written in C and C++, and some were written in (gasp!) Ada. The assembler and C folks were hard core signal processors -- FFT's, power spectrums, low and high pass filters, sampling, aliasing, that sort of thing. Although the C++ and Ada folks would gang up on the signal processors ("Assembler and C is for neanderthals. Our methodologies are better than yours."), the real fun was in watching the religious wars between the C++ folks and the Ada folks ("My language is better than yours. You idiot! That's not object oriented!")

In the end, all of the posturing and all of the animosity was just so unnecessary. The components that required assembler had incredibly high throughputs that could be achieved only with specially tuned assembler code. The C and C++ components didn't need assembler, but had certain requirements that Ada couldn't handle. And everything else had to be written in Ada because the customer required it. (Yes, I agree with Dr. Graham. The fact that the DoD likes Java has me a bit concerned too). So what was there to argue about? I can't tell you how many meetings I sat through listening to people whining about the inadequacies of the others' language of choice. It was a very interesting study in human nature. People seem to defend their turf and respective belief systems like they would their own children from an attacker.

Looking back on that experience and my participation in the project, I recall that I wasn't real particular about what language I was using. I was always much more interested in the problem that was being solved, and how to solve it. My interest in the language that was used to implement the solution was restricted to whether or not the language could support the solution. So I guess you could call me a "software slut" rather than a snob. I'd program in anything as long as it helped solve the problem. Fortunately for me, I had to program in all four of the languages used on that project. Except for C, I had never previously programmed in any of them, and I found all four to be interesting and valuable. They each had their positive and negative aspects, and they each taught me something that I didn't know previously.

So when all is said and done, my interest has always been in the problem at hand, not the language. Of course, it's great if the language you choose (or more likely, that's been chosen for you) is a language that you already know and love, but since that doesn't happen very often, I find that I have a lot less stress than the people who constantly grouse about being forced to compromise their artistic integrity. Which leads me to the whole point of this posting. Dr. Graham has some serious criticisms of Java as a language; some of them are deserved. But most of his criticisms sound a lot like the sort of closed-minded snobbery I experienced on the project described above.

I've programmed in a lot of the languages Dr. Graham claims were developed for the masses (the so-called "mediocre programmers"); languages like Fortran, C++, and (gasp!) Ada. I've also programmed in a couple of the languages that Dr. Graham calls the "good languages"; C and Perl for example. While I have to admit that I liked programming in both C and Perl, and I can see why there might be some religious fervor for each, I'm not sure I would (or could) use either of them to do what I'm doing now with Java. You see, I need to move objects around the network.

Reading Dr. Graham's essay made me think back on all the projects I've worked on, the problems those projects addressed, and the languages used to implement solutions to the problems. This caused me to come to the following realization. Throughout my career the languages I used always changed from project to project, but the problem being solved has always fundamentally remained the same. Whether the problem domain was command and control, signal acquisition and analysis, transport and robotic control, telecom middleware, etc., the problem ultimately was always a distributed problem that required disparate components on remote systems to communicate and cooperate with each other. Being able to move objects allows one to better build such systems. And when building such systems, I also need distributed agreement and distributed security. Java either provides these things for me, or it allows me to provide them.

I realize that this aspect of Java might get lost in the marketing hype surrounding Java; especially when all that one looks at is the cover. And I have to admit that after attending the most recent JavaOne that it appears that Dr. Graham is right about another thing. The "committee" Dr. Graham refers to that controls Java from Sun's perspective has decided to de-emphasize the code mobility capabilities of Java and instead add "features" that will make it even more attractive to the masses. (By the way, that so-called "committee" is a lot smaller than you'd expect. Some might even say that it's really just one or two people. Of course, this doesn't include all the people from outside of Sun that are driving Java). Nevertheless, when you open the "book" and look inside, you see that (in my opinion of course) Java's true strength lies in its ability to move code; not in generics or meta tags, or built-in XML parsers, etc.

For years the hype around Java was "Write Once, Run Anywhere" (WORA); for some it still is. And it was a simple and easy-to-understand message. But people -- even some of Sun's own people -- didn't see what WORA actually brought to the table. WORA allows for code mobility because it places the agreement at the appropriate place in the system -- in the language and in the interfaces you define.

A lot of people (again, even some Sun people) seem to think that the term "code mobility" means that you write and test an application on one system, and then zip it up, "walk it over" to another system, install it, and run it on that other system. They think that that is what WORA brings to the table. But in my opinion, that is not what code mobility is. To me, code mobility is when an application already running on one system can receive and run (securely and without prior knowledge other than interfaces) another piece of code from (a proxy to) an application that's running somewhere else. This, in my opinion, is what makes Java special. And this is why I use (and will continue to use) Java.

And so it's important to be careful when judging a book or language by its cover. Since a lot of people have no interest in problems in distributed computing, they overlook this important aspect of Java. They view Java as "just another language", which may or may not stand up well against their particular language of choice, depending on the type of problem they're trying to solve. I happen to have a particular interest in distributed computing. I believe Java addresses that problem better than any other language I've used so far. I don't use Java because of marketing or hype or because it's "pseudo-hip" or because everyone else is using it. I use Java because it allows me to move code.

Dr. Graham says, "From what little I know about Java, there seem to be a lot of protocols for doing things." On the contrary, Java actually allows us to free ourselves from such dependencies (see "The End of Protocols" by Jim Waldo, at http://developer.java.sun.com/developer/technicalArticles/jini/protocols.html). As I said above, whenever a distributed system is defined, generally some form of agreement must occur some place in the system. It might be that your component and some remote component must agree on the structure and meaning of a certain set of messages that are passed back and forth. Or it might mean that a special XML parser has to be defined and installed on every node in the system. And it might mean that in either case, when a change is necessary, a new parser must be installed everywhere; or every component might need to be brought down, re-compiled, and re-started to accommodate new messages. I think the strength of Java is that it allows the placement of the agreement in such a system to be in what I consider to be the right place. The agreement doesn't have to be in the message protocols or the parsers. Java allows the agreement to be in the language itself and the interfaces.

Once you agree that your components are written in Java, and you agree upon, and define, your remote interfaces, everything else is local and private; all communication protocols are private details of the implementation. You don't have to get any third parties to agree to the meaning or structure of your messages, or to install any parsers; they only have to agree to use Java, and to honor the contract reflected in the interfaces that make up the system.

And so this is why I think Java is not just another language. This is what I think is special about it; what its real value proposition is. And why it's not just for the masses. Java provides a well-defined system for contractual agreement that enables the movement of code; ultimately resulting in an elegant mechanism for building truly distributed systems. As John McClain puts it, "Java allows you to move objects onto the network."

Well, if you've made it this far, then I have to admit, I'm impressed. Most people, walk away after the first or second sentence. Although I seem incapable of making my points in any kind of short, concise, or coherent manner, I guess the main points I'm trying to make are that Sun really isn't an evil company, Java really isn't a bad language that's good only for the "dumb programmer", and the language one uses is just a tool used to solve a problem. The language isn't the end in and of itself; it shouldn't take precedence over the problem it's intended to solve.

Just because you love a particular language, because it has all the "right" features, and it's got the right amount of elegance, deserving of a programmer of your stature, it doesn't mean that that language is appropriate for any and all problems. If I'm a carpenter who needs to cut off the end of a board, I certainly can use my favorite hammer to pound on the end of the board until it breaks off. But that particular problem would probably be better solved if I used my saw; even though I really like my hammer a lot more than my saw, and even though I usually use my hammer to solve most of my problems. Sometimes my saw is the appropriate tool to use to solve the problem at hand.

So I would ask Dr. Graham not to write off Java so quickly. I believe it does have value; it does address certain problems better than most other languages. It just may be that he doesn't know what those problems are. And it may be that IBM and BEA (and even Sun) doesn't know what those problems are either. But a boy can dream, can't he?

Thanks for having patience with me.

Regards,
Brian


Hugh Fisher

Posts: 5
Nickname: laranzu
Registered: Jul, 2003

Re: Java's Real Value Proposition Posted: Jul 7, 2003 9:23 PM
Reply to this message Reply
Not sure whether I count as a real hacker or not, but I can offer a view on why hackers don't always like Java.
<p>
It's not (much) to do with Sun or Scott McNealy. I find it reassuring that Sun is still run by technical types.
<p>
A major reason is that Java, as in the complete language, virtual machine, and class library promoted by Sun, <b>is</b> for language snobs.
Take your signal processing example:
<i>
Because the system was a large, distributed system consisting of components involved in non-real-time resource allocation and command and control, as well as real-time signal acquisition and analysis, some parts were written in assembler, some were written in C and C++, and some were written in (gasp!) Ada.
<br>
...
<br>
Looking back on that experience and my participation in the project, I recall that I wasn't real particular about what language I was using. I was always much more interested in the problem that was being solved, and how to solve it.
<i>
<p>
Exactly. Good hackers still indulge in language wars, as demonstrated by Paul Graham, but they're much more good natured and thoughtful about it than most.
<p>
Now comes the contradiction of your message. After this fine example of multi-language system development and how it couldn't really be done any other way, you move on to distributed system design:
<i>
I think the strength of Java is that it allows the placement of the agreement in such a system to be in what I consider to be the right place. The agreement doesn't have to be in the message protocols or the parsers. Java allows the agreement to be in the language itself and the interfaces.

Once you agree that your components are written in Java,
<br>
...
</i>
<p>
This is where hackers get uppity. Hey, suppose I have hard realtime requirements too? What about all this Python code that runs the user interface?
<p>
Java, as currently shipped by Sun, is for language snobs. Use our language, our class library, our virtual machine. We have all the answers.
<p>
What about the JNI? Sun have made it unnecessarily difficult and complex IMHO: mixing Python and C++ is much easier.
<p>
Compiling other languages to JVM? Yes, it's possible, just as a Turing machine can run any possible program. It's clear from the lack of, for example, nested scopes and pass by reference parameters that the JVM was designed solely to run Java.
<p>
I'm not saying that it is impossible to mix Java with other languages, just that the message coming through from Sun, intentional or otherwise, is that Java is the Answer to Life, the Universe, and Everything.
<p>
Which would be OK if, and it's a big if, the computing industry hadn't been through this before. COBOL was going to solve everyones problems. Then PL/I. Then Ada. Java? Been there, done that.
<p>
Even in the particular topic of distributed systems, I'm skeptical. The Internet, a "Traditional Distributed System" by Jim Waldo standards, hasn't exactly been a failure due to specifying protocols rather than languages or even APIs.
<p>
Lastly, another take on Java on an interesting web site:
<p>
http://www.jwz.org/doc/java.html
<p>

James Britt

Posts: 1319
Nickname: jamesbritt
Registered: Apr, 2003

Re: Java's Real Value Proposition Posted: Jul 8, 2003 9:11 PM
Reply to this message Reply
I'm not saying that it is impossible to mix Java with other languages, just that the message coming through from Sun, intentional or otherwise, is that Java is the Answer to Life, the Universe, and Everything.

That's the message I get, too, an underlying attitude of "We know better." A good part of that is built in to the langauge; it's mostly OO, but not so much that a developer might do something too, um, too dangerous I suppose, such as subclass Integer, or add new methods to String.

It is, as A. Stepanov said [http://www.antiquark.com/escape/public_html/stepanovusa.html], designed for MOP: Money Oriented Programming. Which is fine. Sun is a profit-oriented business and will do what it needs to enhance business. That it produced an interesting and worthwile language as a by-product is great, but its design and development is focused on allowing certain types of developers to accomplish certain tasks.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Mobile Code? Posted: Jul 10, 2003 1:36 AM
Reply to this message Reply
That's it? That's the basis for liking Java? There have been many other more sucessful systems for mobile code. NextStep's PDO was brilliant and any Smalltalk implementation will have a more efficient code/data implementation with fewer typing issues than you run into with Java.

Those who refuse to learn history will repeat it with less style each time. I dislike Java because it is gratuitously complex and underpowered all at the same time. Am I a language snob? I program equally well in C, C++, Java, Objective C, and Smalltalk. Apart from C, these languages divide neatly into flexible/dynamic/elegant/simple and static/complex/fragile/work intensive. Where to draw the line is left as an exercise to the reader.

Frank Mitchell

Posts: 37
Nickname: fmitchell
Registered: Jan, 2003

Re: Mobile Code? Posted: Jul 13, 2003 3:08 PM
Reply to this message Reply
> NextStep's PDO was brilliant and any Smalltalk
> implementation will have a more efficient code/data
> implementation with fewer typing issues than you run
> into with Java.

Que? I used PDO back in the day; it was a brilliant dynamic RPC system that avoided the problems of generating stubs a la CORBA and RMI by leveraging the Objective-C runtime.

However, it did *not* provide mobile code in the sense of JINI and some RMI: servers and clients could exchange interface information, but not implementation code. (In fact they couldn't, since OPENSTEP could theoreticaly run on Mach/Intel, Solaris, or NT/Intel.) Each side still had to implement the PDO protocol. Contrast to JINI, where a proxy could use RMI, IIOP, DCE-RPC, XML-RPC, or any daft thing to communicate back to its server. For that matter, contrast to J2EE where one can upload a binary to a server and be sure it's (a) the right instruction set and (b) can be dynamically loaded without any (more) risk of core-dumping the server because it was compiled with outdated header files or screws up memory usage.

Granted, the ability to download or upload new code at runtime is underused in most Java apps I've seen. (Also, the one aspect of JINI I didn't like was the presumption of a JVM on both sides, as opposed to an implementation-independent discovery protocol that can provide Java class files.) But PDO is certainly not a replacement, unless NeXT or Apple added something after I left for the Java world in 1997.

Frank Mitchell

Posts: 37
Nickname: fmitchell
Registered: Jan, 2003

Re: Mobile Code? Posted: Jul 13, 2003 3:23 PM
Reply to this message Reply
OK, I reread the comment after my morning caffeine, and realized most of that comment pertained to Smalltalk systems.

While I don't know the Smalltalk world, my impression was that each vendor had its own proprietary representation for objects and classes. Maybe vendors allowed runtimes to dynamically import and export code, but except for a textual representation it's hard to imagine a way for products from two different vendors to exchange code.

If the medium of exchange was text, it's in principle no different from exchanging Tcl text, and maybe a step back from exchanging Python bytecodes (as the Pyro system does). Which does prove the point that Java doesn't do anything unique, but it does have an interesting combination of abilities for a mainstream language.

Gerry Giese

Posts: 18
Nickname: gerryg
Registered: Feb, 2003

Re: Mobile Code? Posted: Jul 14, 2003 12:35 PM
Reply to this message Reply
I'm going to agree with the article author in most of his points. Sticking to the meat and potatoes of the argument, I'll agree that Java's ability to declare and use mobile code is a big plus. Java's network awareness and focus in general, though not perfect all the time, is one of it's best qualities, along with it's ability to run on multiple platforms with minimal effort. It's a general-purpose programming language with a high degree of flexibility and extensibility.

Like 'em or not, applets started the whole thing off. Think back some years ago and remember your amazement at the ability to run an application *inside* a browser without having to specifically go download, install, and manage it locally (keep file space for it, uninstall/upgrade the application regularly, etc.). It's still there, and getting better all the time.

Add on Java's networking capabilities and you have a smart program interface with remote servers. And now add the latest WebStart and JNLP, and you've got a great application distribution and management system.

Sure, Perl was great for web apps in the early days, and C was used a lot, too. But it wasn't easy for large applications. Servlets and JSP turned a *lot* of heads, and the ability to write large web applications became a reality for a much larger group of programmers. Web Services were an easy add-on, as was support for truly "mobile" code, in the phone sense with J2ME communicating with servers.

Java has always been network-friendly and relatively programmer-friendly. It's easy enough to develop for and doesn't require onerous loads of development tools to develop small, smart, easy-to-deploy applications. Sure, it's sacrified a measure of performance, but that was *by design*. People always seem to think that Java was positiioned as a replacement for all previous languages when it wasn't. It was designed with specific purposes in mind, and happened to do a wide of things well, which is why it caught on.

Sure, it's not as "pure" as smalltalk in it's OO and language features, but that was *by design*. I still remember the earlier days of small talk when Parcplace and others had runtime images of 50+ MB back at a time when network backbones were just starting to upgrade to 10baseT and we were eagerly anticipating hard drives of 1GB. I don't know what smalltalk is like today, but when Java appeared it was a blessing to have small and easily deployable applications. Oh, and it was free. Took a while for a reasonable smalltalk distribution to get there, basicly after the commercial vendors started giving up on it. And as Frank mentioned, vendor interoperability just wasn't there. Sun really was brave to make Java free, and while they've never been able to truly capitalize on Java, they could have.

One last point - Java does have warts. It could really use a few changes - remove all deprecated methods, make primitives into real object, and a wee bit of API cleanup to make things consistent. But warts and all it's still a really good programming language (and platform layer, if you want to call it that, too). C# has provided an alternative that has fixed a few of Java's flaws, but C# has it's own flaws as well.

Java should always be considered a tool in the toolbox. It happens to be more like a Leatherman than anything else, and you still need hammers, saws, drills, etc. for other tasks. Someday Java will be replaced by a much better language. It wouldn't bother me if Sun is the one that came up with it, as they've been a good steward for Java. I plan to keep Java in the front of my toolbox for forseeable future, and like any good geek, I'll keep looking for something better and I'll keep using the other tools when I need them.

'Nuff said.

Gerry

Gerry Giese

Posts: 18
Nickname: gerryg
Registered: Feb, 2003

Re: Mobile Code? Posted: Jul 14, 2003 12:58 PM
Reply to this message Reply
Erggg. I should have hit preview, as there's no 'Edit' button my my previous post. 5th paragraph, last sentence should have been 'wide range', not just 'wide'.

Flat View: This topic has 7 replies on 1 page
Topic: Standards: Doomed to Repeat Itself? Previous Topic   Next Topic Topic: Exploring the Java Research License


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us