Is there something Java should do?
Simply because of its ubiquity and its relative security at running untrusted code, I think Java would be an good platform for large-scale distributed computing. caveat - I've spent the last 3 years doing Java almost exclusively for server side development (i.e. I know nothing of the java.awt.* and javax.swing.* packages) --MarkAddleman
I doubt there is a meaningful large-scale
distributed computing application that isn't a fiction of the UML diagrams describing it. Don't you just end up in runaway complexity trying to avoid race conditions? For server-side development, I prefer using Perl (and/or ANSI/ISO C/C++). -- SunirShah
- I think when he says "Distributed Computing" he's talking about something like SetiAtHome or the recent RCx cracking contests. Java could work well for that, but SetiAtHome prefers to issue an optimized binary for every type of machine, and probably runs on one or two machine types that don't support Java. Also, would you really want SetiAtHome running on your Java-enabled WAP phone or PalmPilot? -- EdwardKiser
We're all most productive in the language we like the best. I prefer using Java. Java isn't better than Perl -- and vice-versa
-- it just fits my programming comfort zone better. Come on, LanguageWars
are out of style. I vote that this page be deleted; WhenShouldntWeUseJava
covers similar ground and is more helpful. --JimLittle
- I didn't see this page as a flame at all; I saw it as more of a "Now I've got the shard, but what do I do with it?" kind of page.
It's legitimate to claim that certain languages are better than in others in particular contexts. In fact, this is what the seminal LittleLanguage
discovery was. I claim that Perl is better at server side development than Java. I back it up by stating that Perl has better foo
for any given foo
than Java. In fact, this might suggest that Perl is always better than Java. This is indeed what I claim. Note that Java phones don't actually work yet. (Even iAppli has been having major problems.) And if you've managed to find a model that hasn't been recalled, it's not profitable. Note that way back in 1993, Java was conceived as the quick hack language to write code to run portably on HandHeld
devices of that
day. It's 2001, and Java has become far more than it was ever intended to be (Jini was meant to be the main show), and has become far less than it was set out to be.
Simply put, there is no niche that Java has managed to crawl into that Perl hasn't come along and done better; or, conversely, there isn't a niche that Perl has traditionally done better that Java has come along and failed at. Even marketing wise, Perl is doing well. I don't think eCommerce solutions count in particular because eCommerce solutions haven't succeeded. See the point about Java phones. Still, mod_perl + Apache or the Perl IIS extensions still outdo any Java solution. By the way, Perl is probably one of the, if not the
, most strictly powerful languages ever to exist. So, it's naturally going to be better at foo
than Java, which is one of the weakest languages to ever exist (by intention).
Try Perl. You'll like it. If you don't like it, you can change it. Try doing that with Java, the language where Sun will 0wnz j00 if you do something as trivial as puting programmatic statements in comments (What does this refer to?)
. -- SunirShah
, your friendly neighbourhood Java hater ;)
- Actually it seems easier to switch to RubyLanguage from Java than to Perl. Perl's object-orientation seems to be a bit of a hack. But Perl has one advantage: mod_perl. When I recompiled my Apache with mod_perl, it sped up my PersonalWiki by about twenty times. -- EdwardKiser (much later) (Note: mod_ruby now exists)
Note that Java phones don't actually work yet.
Yes. Are Perl phones doing any better?
This page has two meta benefits. First, it's one concentrated place where I can rip into Java without derailing the rest of Wiki. Second, I actually do want to know if Java has a purpose. I have yet to find a single
place where Java has any merit except for money-oriented programming. But while I honestly do believe that SoftwareIsReallyPointless
, and thus MOP is a legitimate reason to use a terrible technology, perhaps you can convince the human in me that Java has a purpose. -- SunirShah
Okay, Sunir, I'll bite. But don't expect me to argue that Java is better than Perl; I've ridden the advocacy bandwagon and found it an unfriendly trip. Still, I don't mind saying what I like about Java.
Allow me to establish a little credibility: I learned Perl before Java and I've written significant applications in both. My biggest Perl app was a server-side HTML templating language compiler. It took HTML and a little language of my invention and turned it into server-side Perl code. Since then, I've worked in Java, on larger projects involving more people.
Some of the things I like about Java:
- Object-oriented programming. Java follows popular OOP conventions. It may not be "pure" OO, but it's easily understandable to people who know C++ and other popular OO languages.
- Team development. Java's idioms are generally straight-forward. I find it to be mostly free of "gotchas," and I rarely wonder how to do something. When I do, it's a matter of finding the correct library, not figuring out a language issue. Exception handling seems to be an exception. Hah.
- Consistent standard library. Java has a very large standard library that I find to be consistently well-designed. It's usually straight-forward and simple. There are exceptions, of course, but overall I like it. It usually follows what I understand to be accepted patterns.
- Good exception handling. Some people complain about Java's exception handling, but I think it's very well done. I like to write software that doesn't crash, and in Java I've done that, without a lot of effort.
- Strong tool support. Java has some good IDEs (JavaIde). My favorite is IntellijIdea for its built-in refactorings and understanding of the code. JakartaAnt is also a nice tool.
- Smart compiler support. Since Java doesn't have a preprocessor or header files, and since it has late binding and strict file location rules, it can be compiled quickly. My last project, at 1300 classes, compiled in about 30 seconds.
- Cross-platform enough. I like being able to develop on my desktop OS and deploy on a completely different server OS without re-testing. Some might say that I'm foolish for doing that with Java, but I've gotten away with it so far.
Again, I'm not comparing to Perl. I'm just saying what I like about Java. That doesn't answer the question in the page title... but it's a strange question. Java should "do" what any language should do: be used as a human interface for writing programs. I've found it effective for that.
(PS: I agree with your sentiment about distributed applications.) --JimLittle
I think I should concede some points before this page degrades into an unhumourous trollfest (humourous trolling is all well and good, of course). Java is obviously the best answer to many applications given the large contingent of developers now trained in Java exclusively. Similarly, there are now a large contingent of developers trained in Perl exclusively. I'm not sure which group is larger, but I'll bet the average age of the exclusive Java developer is much greater than that of the Perl crowd. (Would this suggest that Java will die soon because it is not "cool" with the next generation?)
On the contrary... I think Java is the only language that the next generation truly has faith in. C++ and Perl are seen as somewhat old-fashioned.
Many clients (those with actual
money) have environments that use Java, especially e-commerce customers that have gone with anything other than IIS or Apache. This means we program in Java. CustomerFirst?
Finally, the W3C has adopted Java as its defacto language. While this is unfortunate for a standards body given the licensing restrictions that come with Java, that's just how it is. This has generally made Java the language of reference implementations on the Internet. Doing the equivalent in Perl or Haskell or Smalltalk would not be accepted. Of course, doing the equivalent in C or C++ would be accepted.
I dispute every single one of your points above, by the way, but that would be trolling for nits. ;) -- SunirShah
Let me answer your question by saying `yes'. Java should replace C++. The only reason Sun hasn't released a Java compiler (or released the spec) is because they can't make any money that way. It's trivial to adapt the Java syntax to gcc.
Replace C++ at doing what, exactly?
Java should replace C++ everywhere it can. C++ code is just too easy to screw up. I spent several years reviewing code written by mid level C++ programmers. They weren't senior, but they weren't junior either. The number of pointer and manual garbage collection errors convinced me that C++ is too fussy for most programming. Using Java helps avoid these problems.
oh my lord! while an early adopter of java back in 95/96, i've wished for years it would just go away! CeePlusPlus was (and remains) a significantly richer language. Anybody who cannot code in CeePlusPlus should go into management or become a DBA.
And everyone that cannot crank-start a Model T Ford should hire a chauffeur or ride the bus.
(Is there a more informative/polite way of saying that ? ItsNotAboutDiscipline
? From the perspective of 5 years of Java programming, I think it should disappear sooner rather than later to make room for real progress.
Just to state the obvious: yes, there is something that should be done in
Java, namely, writing Web Applets. Or am I missing something?
, ActiveX, and MacromediaFlash
. -- SunirShah
No, I mean Java. E.g. I have written some applets as courseware on numerical mathematics:
I still don't think it couldn't be done in anything but Java, given the requirements:
- Cross-platform (at least *nix and Windows)
- Runs on a web browser
- Runs downloaded without network access
- Reasonable performance & stability
- Easy to mix with a document in LaTeX
What about Squeak?
Requires a plug-in to be downloaded, cannot be easily mixed with HTML (generated
from LaTeX). I suspect that numerical performance is less, although I haven't
tested it, so take that with a grain of salt. It wasn't available when I
wrote those applets. -- sh
Since a fair amount of this page seems to be JavaVsPerl?
I will continue this theme. I have only a passing familiarity with Perl, so please correct any of my misconceptions
Java has these advantages over Perl:
- Applets - When you need a complex GUI to be downloaded to a web page.
- Scalability and Maintainability - In terms of project size, not performance. Large Java projects are easier to understand than ones written in Perl.
- Secrecy - Some vendors don't want to release source code, and even want JavaObfuscation?.
- Performance - JDK 1.4.1 and beyond is challenging even C in some areas.
- Dynamic loading - Subclass definitions can be automatically downloaded with JavaRemoteMethodInvocation.
- Standard interfaces - APIs such as JDBC are standard for all vendors and implementations.
- Multiple Vendors - You can get Java from IBM, HP etc.
- J2EE - Does Perl have anything equivalent in terms of scalability and high availability?
- J2ME - Java works in small environments, all the way down to smart cards.
- Compile time type checking - More programming errors will be found before the code runs.
- Modern IDEs - Eclipse is very nice. I'm ignorant of a Perl equivalent.
- Powerful Debugging - JDK 1.4 can reload classes and restart stack frames.
Note that the large majority of these advantages are true for ServerSideCode?
, not for ClientApplicationCode?
. A lot of people seem to have negative opinions of Java based on its client side GUI performance several years ago.
In general I would expect Perl to be superior for smaller programs and as the requirements and complexity increase Java comes into its own.
Is this a serious thread? I've been working in a major US Bank for the last 5 years using Java for, well, just about everything. Perl's nice too but ever tried to maintain it? If you admit that you don't know java then why make ignorant comments about it? - Paul Hill
Ever try to maintain a legacy java application? I have, even ones I have written. Maintenance tends to be a language-neutral pita.
It is interesting to note that almost all of the benefits listed for using Java are nothing to do with the Java language per se. When people talk about Java they are usually lumping three independent things into that one word. The Java langage, the Java Runtime Engine, and the standard set of Java libraries. Most (if not all) of the usual Reasons for using Java
are to do with the JRE or the Java libraries - eg security, web capability, GUI, cross-platform equivalence of binaries, etc. Look at the list given above. How many of those are specifically about the language? Maybe Scalability and Maintainability
, although that one could be argued back and forth. Probably Compile time type checking
(the thing I hate most about using Java!) is clearly a matter of personal preference. It is interesting to note that Alan Kay, who invented the term Object oriented programming
has said that Extreme late binding of everything
is one of the most important aspects of a true object-oriented programming language - NOT compile-time type checking
, Scheme, Lisp, Basic and several others. Because these use the JRE, and have access to all the standard Java libraries, (as well as any other Java class files you happen to have), you will find that they share most or all of the usual Reasons for using Java
- but without the downside of having to use the Java language! (BTW, since the Parrot runtime engine claims it should be able to run Java compiled code, this would imply that the standard libraries are independent of the JRE - don't know how that one plays out in practice). As to which is better, Java or Perl, I like this quote I found somewhere on the internet: "I would rather use Perl than use Java .. and I would rather be eaten by a crocodile than use Perl!" My response to the question "Is there something Java should do?" is "No". Glenelg Smith
u are right in that there are three separate parts to the argument. Unfortunately you give too much credence to part#1: the language itself. ALL languages suck. The major reason to chose a programming language should be for the libraries and documentation/support ecosystem. The notable exception is for embedded systems where memory/cpu resources are scarce: in this case just stick to C and dont waste your time reading these blogs
What's all this about Java phones not working right? Android is a completely java-based platform. -- Michael Parks
thats only because of Google's iron fisted approach. They needed to do it so as to ensure app providers only had to develop once to support the many different hardware platforms. This was a marketing decision to aid its bid to catchup to the iOS juggernaut. Its all about standards, even though you may not like the language. However, Android itself is Unix ... and I would argue its actually a C-based platform. To my knowledge, there is no bare-metal platform based on a JRE
Yes, it should go away :-)