Slashdot Mirror
Beyond Java
Anml4ixoye writes "I recently got sent a copy of Bruce Tate's newest book Beyond Java - A Glimpse at the Future of Programming Languages. Having read Bruce's Bitter Java and Better, Faster, Lighter Java, I was intrigued to see what he would have to say about moving beyond Java. In short: If you're a hard-core Java (or to a lesser extent, C#) developer who thinks Ruby is something that goes on a ring, Pythons will bite you, and Smalltalk is something you have to do at parties, you are in for a rude awakening." Read the rest of Cory's review.
Beyond Java: A Glimpse at the Future of Programming Languages
author
Bruce A. Tate
pages
185
publisher
O'Reilly
rating
9
reviewer
Cory Foy
ISBN
0-596-10094-9
summary
Excellent book for Java developers who haven't been exploring what else is out there
Let's get down to it. For many people, Java pays the bills. For dealing with big problems, it is a wonderful language with a myriad of libraries for solving domain-specific problems. The author thinks that this focus on the larger applications is causing Java to alienate the developers who need solutions to small, real-world problems, like babysitting a database with a web site.
Bruce starts out in Chapter 1 discussing a disrupting experience he recently had when he discovered how much faster and more productive he and his team were when they switched mid-stream to Ruby on Rails. He gives some controversial numbers that discuss this improvement. This experience leads him to realize that maybe Java is dying - or at least fading in certain areas.
His next sections (Chapters 2 and 3) discusses the "Perfect Storm" that led Java to become the leader it is today. How it traded the OO purity of Smalltalk to woo C++ developers. And how the programming environment was calling out for a language like it.
But that landscape is changing, and Java is having a hard time keeping up. In chapter 4, he gives an example of servlets. Earlier servlet specs allowed you to get a Hello, World servlet, albeit ugly, up rather quickly. That same example now requires deployment descriptors, packaging into WAR files, configuration files, etc, etc. For Java developers, this is the norm, but for a developer new to Java, who wants to learn all that?
Chapter 5 is a discussion of what Bruce feels is the Rules of the Game, or what the next "Killer language" will need in order to beat out Java. This was a very good treatment, highlighting some of the good and bad of Java and languages as a whole. For example, he rates high that you will need some sort of Enterprise Integration, Internet Focus, and Interoperability. He also feels things like dynamic typing, rapid feedback loops and dynamic class models (making reflection more natural).
Most importantly, it needs a killer app to act as a catalyst to get people's mindsets changed. In Chapters 6, 7 and 8, he gives examples of some killer apps - Ruby on Rails and Smalltalk's Continuation servers (like Seaside). Chapter 6 is a kick-in-the-teeth intro to Ruby (which left me wanting to go out and pick up Dave Thomas' Programming Ruby book). Chapter 7 shows a sample Ruby on Rails application, and Chapter 8 gives a very interesting look into Continuation servers and the work being done by the Smalltalk community on it.
Finally, he closes the book with a list of Primary and Secondary contenders that could up and replace Java. Primaries include Ruby, Python, Groovy, and .NET (C# and VB.NET). Secondary contenders include Perl, Smalltalk, PHP and Lisp, which he summarizes as: "Perl's too loose and too messy, PHP is too close to the HTML, Lisp is not accessible, and Smalltalk wasn't Java". To which he adds, "...go ahead and fire up your GMail client and your thesaurus, and drop me a nasty note. Ted Neward reviewed this book, so I can take a few more euphemisms for the word sucks".
Thankfully there is nothing in this book that would cause me to write a nasty note to Mr. Tate. In fact, if you haven't begun looking at other languages and are heavy in the Java world, I would highly recommend picking up a copy of the book. It's a fast, intriguing read with great insights and the chance to save yourself from looking around 4 years from now wondering what the heck happened, and why all of these developers can afford jewels and play with snakes while chatting among themselves."
You can purchase Beyond Java: A Glimpse at the Future of Programming Languages from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Let's get down to it. For many people, Java pays the bills. For dealing with big problems, it is a wonderful language with a myriad of libraries for solving domain-specific problems. The author thinks that this focus on the larger applications is causing Java to alienate the developers who need solutions to small, real-world problems, like babysitting a database with a web site.
Bruce starts out in Chapter 1 discussing a disrupting experience he recently had when he discovered how much faster and more productive he and his team were when they switched mid-stream to Ruby on Rails. He gives some controversial numbers that discuss this improvement. This experience leads him to realize that maybe Java is dying - or at least fading in certain areas.
His next sections (Chapters 2 and 3) discusses the "Perfect Storm" that led Java to become the leader it is today. How it traded the OO purity of Smalltalk to woo C++ developers. And how the programming environment was calling out for a language like it.
But that landscape is changing, and Java is having a hard time keeping up. In chapter 4, he gives an example of servlets. Earlier servlet specs allowed you to get a Hello, World servlet, albeit ugly, up rather quickly. That same example now requires deployment descriptors, packaging into WAR files, configuration files, etc, etc. For Java developers, this is the norm, but for a developer new to Java, who wants to learn all that?
Chapter 5 is a discussion of what Bruce feels is the Rules of the Game, or what the next "Killer language" will need in order to beat out Java. This was a very good treatment, highlighting some of the good and bad of Java and languages as a whole. For example, he rates high that you will need some sort of Enterprise Integration, Internet Focus, and Interoperability. He also feels things like dynamic typing, rapid feedback loops and dynamic class models (making reflection more natural).
Most importantly, it needs a killer app to act as a catalyst to get people's mindsets changed. In Chapters 6, 7 and 8, he gives examples of some killer apps - Ruby on Rails and Smalltalk's Continuation servers (like Seaside). Chapter 6 is a kick-in-the-teeth intro to Ruby (which left me wanting to go out and pick up Dave Thomas' Programming Ruby book). Chapter 7 shows a sample Ruby on Rails application, and Chapter 8 gives a very interesting look into Continuation servers and the work being done by the Smalltalk community on it.
Finally, he closes the book with a list of Primary and Secondary contenders that could up and replace Java. Primaries include Ruby, Python, Groovy, and .NET (C# and VB.NET). Secondary contenders include Perl, Smalltalk, PHP and Lisp, which he summarizes as: "Perl's too loose and too messy, PHP is too close to the HTML, Lisp is not accessible, and Smalltalk wasn't Java". To which he adds, "...go ahead and fire up your GMail client and your thesaurus, and drop me a nasty note. Ted Neward reviewed this book, so I can take a few more euphemisms for the word sucks".
Thankfully there is nothing in this book that would cause me to write a nasty note to Mr. Tate. In fact, if you haven't begun looking at other languages and are heavy in the Java world, I would highly recommend picking up a copy of the book. It's a fast, intriguing read with great insights and the chance to save yourself from looking around 4 years from now wondering what the heck happened, and why all of these developers can afford jewels and play with snakes while chatting among themselves."
You can purchase Beyond Java: A Glimpse at the Future of Programming Languages from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I can understand why he noted Ruby as a primary contender with Java. I've been learning it from an online primer, and it seems quite flexible and elegant. Java, on the other hand, is much too bloated.
On vit, on code et puis on meurt.
I think digitalmars D is the next big language.
See it here http://www.digitalmars.com/d/
Its probably nice to compare different programming languages but comparing java with something like perl is stupid. Perl is a scripting language to do things more neatly than C/C++, but its not a replacement for Java in any sense. Comparing with C# is much better and should be more detailed.
They called me mad, and I called them mad, and damn them, they outvoted me. -Nathaniel Lee
In short: If you're a hard-core Java (or to a lesser extent, C#) developer who thinks Ruby is something that goes on a ring, Pythons will bite you, and Smalltalk is something you have to do at parties, you are in for a rude awakening.
If you half ass your job in any professional field, you are in for a rude awakening. This is not news.
Mod me down with all of your hatred and your journey towards the dark side will be complete!
If I'm to dump Java and use Ruby then someone's going to have to show me the money.
boxlight
The typical response is to post some obsfustacted perl with a good reg exp thrown in for good measure and some cute comment about ascii explosions. These are red herrings. To these I say:
Any langauge can be obfusticated and C is perhaps the easiest to obfusticate.
Built in reg exp are extreme useful - learn to used them and do not fear them. Or good coding style requires you to document them. A single line reg exp can replace pages of code.
I don't understand as a developer what dynamic typing does to help a language, and what real world advantages it offers the developer. I find that dynamic typing doesn't really open up new doors, and ends up creating bugs that would have been caught at compile time had static typing been used.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
Ruby / Rails is really cool. I've not done any application development in it though, other than tutorial type stuff.
Other than some pureist OO stuff, and a really nice framework, I fail to see what Ruby on Rails brings to the table that say, perl, php and other P type languages don't already offer in terms of actual functionality. I'm not saying it's unneeded or anything stupid such as that. More=better as far as languages go.
JSP also allows for some RAD-like work. The languages I've mentioned clearly do. Why is Ruby the next big thing? To sell more books?
It's just like the whole AJAX hype storm. No tool is a one size fits all. Do I need to go back and add an AJAX layer to all my newsletter signup boxes? Do they suck if they don't dynamicly provide feedback?
Do I need to bind all my database structures to my objects?
Do people really think that way?
What I've found is that it really is much faster in initial development. Rails has an explicit separation of model, view and controller code, while in Java it tends to become convenient to mix all but the lower levels within .jsp pages. Another worry I have is the packaging system, which is harder to manage than Java's dom.company.package.subpackage structure. I could imagine that namespace conflicts would be inevitable in Ruby as with other 'scripting' (sorry to use that word) languages.
I haven't gotten much further than that.. Once I get to the point of having to maintain and expand on a larger codebase I'll no doubt have stronger opinions on its strengths and weaknesses, but for now, I'd say that most of what people are doing in Java can be done more simply and faster in Rails (or perhaps a Perl framework). I'd be concerned about its resilience and scalability on larger systems, as well as its industry or 3rd party support (Java's support, esp from Apache, is outstanding).
Well, if it's dynamic, it must be good, right?
I pray that the future will not be dynamically typed. We have enough run-time bugs as-is, and while I am in no way opposed to doing prototyping in dynamically typed languages, I would much prefer my everyday applications to be written in languages that don't constantly segfault because of pointer arithmetic, raise null pointer exceptions because nullable and nonnullable types are not distinguished, or give syntax errors at runtime because they happen to be fully interpreted.
Most static type systems suck, which is why people don't like them, but people who have used, say, SML or Haskell, tend to agree that static types can be something very natural and useful (the SML community has a saying which goes, roughly, "if it compiles, it's almost certainly correct").
I don't know about you guys, but I'd much rather have a slightly harder time with dynamic module loading, reflection (which, IMHO, is vastly overrated, considering the correctness/safety/usefulness tradeoff) and perhaps side effects than having to find all of my bugs (rather than 5% of them) through testing.
Just my EUR 0.018.
-- Christoph
One nice thing about Rails is that the unit tests are built in. Rather than having to go out and use JUnitWebTest or whatever, once you start writing Rails code the basic tests are generated for you and writing new tests involves fairly readable code, like this:
It seems like the folks who are writing Rails are aware of the whole web development picture; not just getting a web app up but also making sure it's well tested. It's certainly making RubyForge much busier...
Oh, and, book plug!
The Army reading list
And no, the Batmobile doesn't count as a "commuter car".
I have been thinking that 'Lisp is not accessible' for years. I regret all these years beyond expression. Don't believe it. It's horrible lie. Here's the proof.
Actually, I've been thinking about this for a while, and Perl seems "messy" to some because it has so much special syntax, that other languages just have as functions.
Example, if you had a list of files, and you wanted to print files from a list that exist (not contrived, I was doing this the other day) you would probably write something like:
foreach (file in files) {
if (Exists(file)) {
print file;
}
}
A programmer who has never seen the language before could read through the code... "for each file... if it exists... print it". In Perl, I would do:
print grep { -e $_ } @files;
Although I would think "print all the @files that match the condition (they exist)", someone who has never seen Perl before would be like "whoa". Sure, it looks like nonsense, but that's only if you don't understand Perl. It's clear to me what it does, and I am no Perl-guru. People who think Perl is messy should take the time to learn it before slagging it off.
Guy asked me for a quarter for a cup of coffee. So I bit him.
On any large development project, by the time you've actually rolled into production, the toolset you selected is already out of date, and you have to start an "update the back end" project. And of course next is the project to unify your companies approach to delivering solutions, which means projects to bring the other projects in line. And when you're done that, it's time to revisit the back-end again.
I'm only 35 and I'm so tired of it. I don't want new languages. I just want to work with tools the team truly understands.
I have a life outside of work. The days of my wanting to read through stacks of documentation in the evenings to learn the latest new thing are gone.
So I'm being groomed for what I think is the natural progression for the tired but still knowledgeable developer... project management.
I only use Perl for quick scripts, but compare the following:
Perl:
Java:
It is telling that I had to go look up the Java interface (I am a professional Java developer and have been for 8 years), while the Perl came naturally (I am pretty good with Perl, but I only use it for scripting support).
Java does NOT have built-in regular expression support, at least not at all in the same way that Perl does.
: If you're a hard-core Java (or to a lesser extent, C#) developer who thinks Ruby is something that goes on a ring, Pythons will bite you, and Smalltalk is something you have to do at parties, you are in for a rude awakening
If I thought all those things, I'm probably at the wrong web site.
I'm always wondering why Python is left out from this kind of conversations.
Python is the best language I've ever worked with. It's very human friendly, no need to learn/read/write hieroglyphs, like in Ruby or Perl. Very compact, no need to write a pages of text to print Hello World, like in Java. It's very oo, supports multiple inheritance, what makes code reuse a reality. Has a wide range of modules, a wonderful application server, called Zope, a code generator, that eats UML and many many features, to make it an outstanding choice.
I thought nothing, a void, Java is a black hole that just keeps sucking. Its what happens when a Sun goes supernova.
I haven't thought of anything clever to put here, but then again most of you haven't either.
I read this book too, and my impression overall was the author is a cheerleader for Ruby. Which is fine, because Ruby has made some important OO design contributions. It seems like a very elegant language, what Python could have been.
The book's assessment of Perl seems superficial. I am sure I could write bad code in Ruby if I wanted to. Just because Perl embeds regular expressions into the language syntax rather than making you import a library, this doesn't mean Ruby (or any other language) would be any more readable if you had to put regular expressions into its source code. Sooner or later, you'll have regexes in your code regardless of the language. Try writing something useful in clean, elegant REXX which has no regex support!
The PHP snippets are something no PHP programmer would write, and make me wonder if the author knows anything about the language. I don't think PHP gets a fair shake. Curious that PHP and Perl both don't impress the author much, and both are real-world, get-it-done languages. The author tends to like Ruby, LISP, etc more.
The author does get credit for looking seriously at non-mainstream alternatives like LISP!
I don't remember the author mentioning that Python can run in a JVM and give you an instant, full-featured scripting language for your Java object framework. I love Jython, even though I'm not a big Python fan in general. Listen up, Ruby evangelists: You need to get Ruby running natively in the JVM like Jython! Then you'd have the KILLER language.
Overall, the author doesn't mention that the goal of my-favorite-scripting-language is to rewrite CPAN's core modules in the language. It's like a language used to have to compile itself. Now, a new language has to have a huge standard library to be serious. Library inertia is what will hurt Ruby, Python, etc - after spending huge amounts of time writing to the Perl or PHP core modules, am I going to rewrite all my web site's code in a new language, or try to learn a lots-of-little-differences syntax for a new standard module library? Probably not.
Overall, a thought-provoking book whether you agree or disagree.
I program Java. Recently had to do a C# project.
My first thought - Hey! This is a whole lot like Java. Only took me a couple of hours to learn the syntax differences. I'm off and running!
Two hours later I hated it. If you'd like to know why, allow me to offer you the following observation/puzzle.
In C#/.NET, create a form. Put a text box on it, and a button. Have the button create a thread. Have the thread write "Hello world" in the text box.
Because I'm feeling generous, here is the Java code:
private class myThread extends Thread {public void run() {
jTextPane1.setText("Hello from a thread");
}
}
private void jButton1ActionPerformed(java.awt.event.ActionEven
new myThread().start();
}
Good luck with the .NET code. I'll give you a hint though. It requires a delegate function, because C# .NET forms aren't thread safe. If you manipulate the text box from the thread without a delegate it dies. As a bonus, you get a really illuminating error when that happens:
[System.NotSupportedException] "An error message cannot be displayed because an optional resource assembly containing it cannot be found"Wonderful language. Really.
Weaselmancer
rediculous.
By the way, the author, Bruce Tate, is not a programmer. By his own admission, his qualifications are based on experience "reading code" and hiring developers. I listened to him speak at a conference, and I was underwhelmed with his presentation's technical content.
Lisp isn't accessible? Is that because of the parens or some other reason? If it's the parens, then obviously people are too superficial to look past the syntax (which is minimalistic to say the least). I've coded (and continue to code) in PHP, which has C-like syntax. When I first saw Lisp it was a bit different, but that's all it was: different. In fact, because there is so little syntax to worry about it makes the language even MORE accessible than C-like languages.
I've been reading Practical Common Lisp, and I have to say I love Lisp so far. I'm down to the practical examples and continue to enjoy the experience of reading, learning and coding lisp. It's certainly an excellent book and it shows, since it is a finalist in the Jolt awards.
Paul Graham is a big advocate of Lisp. He made big bucks selling is 3 year-old company to Yahoo, a company that was built off of software coded in Lisp.
Of course, one can't forgot the quote from Eric Raymond's 'How To Become A Hacker': LISP is worth learning for a different reason -- the profound enlightenment experience you will have when you finally get it. That experience will make you a better programmer for the rest of your days, even if you never actually use LISP itself a lot. I especially like these quotes from the blurbs section of the PCL website:
"This book shows the power of Lisp not only in the areas that it has traditionally been noted for--such as developing a complete unit test framework in only 26 lines of code--but also in new areas such as parsing binary MP3 files, building a web application for browsing a collection of songs, and streaming audio over the web. Many readers will be surprised that Lisp allows you to do all this with conciseness similar to scripting languages such as Python, efficiency similar to C++, and unparalleled flexibility in designing your own language extensions." --Peter Norvig, Director of Search Quality, Google Inc; author of Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp
"Please don't assume Common Lisp is only useful for Databases, Unit Test Frameworks, Spam Filters, ID3 Parsers, Web Programming, Shoutcast Servers, HTML Generation Interpreters, and HTML Generation Compilers just because these are the only things happened to be implemented in the book Practical Common Lisp.--Tobias C. Rittweiler, Lisp Programmer
Lisp was once in the same position C, C++ and now Java were/is in. It was one of those languages you had to know if you were going to get a job in programming. The only reason why it isn't still in that position is because it was ahead of its time. It was once thought to be slow, but Lisp compilers can compile to machine code and run as fast or even faster than C/C++. Lisp gives you the flexibility to code quickly to get features working and it also allows you to go back and optimize your code to perform at C levels.
So don't make the mistake of thinking Lisp is simply a worthless, academic language. Just check out Practical Common Lisp and see for yourself!
You shouldn't need a dynamic scripting language to be productive. If you want something with the productivity and brevity of Ruby with performance >= Java, you should check out Boo (http://boo.codehaus.org/).
.NET Framework, has Python inspired syntax (wiithout the annoying quirks), and advanced language features not even found in Java like: properties, events, closures, extensions, macros, partial classes, etc.
It can run on mono/.NET which gives you access to the
It can run in interactive mode (without needing a compile) or compiles down to CIL giving it the same performance as C#.
If he had tried, he could have gotten insightful and well-thought-out contributions from developers who are experienced with the kinds of things he talks about. He could have edited them down to be concise and reasoned expositions on the benefits and pitfalls that might lie ahead for the Java developer interested in change. Not everyone is a cheerleader, lots of people with lots of experience and investment in these other technologies are willing to talk about them in reasoned ways, and offer some real wisdom about the good and bad. But he just talked to a bunch of Java guys. No offense to those guys, but transcribing a few email exchanges into a book isn't cool.
What ever happened to programming stand-alone application programs? For several years now I've seen almost nothing discussed on Slashdot other than web programming. It's all about scripting websites and accessing databases, etc. Is application programming no longer interesting, or profitable, or fashionable? Is it an activity now considered contemptible?
Looking at Java, the only thing I found interesting was the ability to write platform-independent applications. Even for that, Java appeared to have some significant shortcomings. I'm sure I'm not the only one who felt that way -- considering how few stand-alone Java apps I have installed on my computer now. Let me count. . .
Three. I have three Java apps. I have more apps built in REALbasic than in Java. So much for Java taking over the world, eh? And now people are buzzing about Ruby. Ruby? Man, it's an *interpreted* language! If I were coding a CMS, sure, I'd consider it. I may use it as a scripting language for my apps, it should be very spiffy for that. Will I code the apps themselves in Ruby? No!
Recently I've been learning my way around Mac OS X, with Objective-C and Cocoa. It's not perfect. But. . . For what it's designed for, for developing stand-alone GUI-based applications, I haven't seen anything dramatically better. And you know, I have doubts about whether I'm ever going to. Nobody is working on languages oriented toward application programming anymore. Some of the newer languages can do it, but they aren't focused on it. Apps and GUIs are a sideline, an afterthought.
C# runs just on well on Mono.
.NET Framework has a more feature rich consistent API that 'actually follows their own naming conventions' and doesnt need 2 different attempts at writing Date classes (and still getting it wrong).
>slow, slower,
It is just as fast if not quicker than Java, and can actually be used to create performance acceptable GUI's.
>hillariously ad-hoc,
The
>and owned by Microsoft.
Mono unlike Java, is 'open source'.
You, like many people, seem to be confusing two independent concepts: static v. dynamic, and strong v. weak typing. Read up here: http://en.wikipedia.org/wiki/Datatype
Dynamically typed language like Python or Ruby are also strongly typed. This means that the language absolutely *prevents* you from accessing an object incorrectly (breaking type safety).
C on the other hand is statically typed, but also weakly typed....the exact opposite!
C++ and Java are also in the same camp--static and weak; although both are much much closer to being strongly typed than C ever was. Although you can argue that Java is static/strong except for some low-level exceptions; or that C++ is partly dynamic (with template meta-programming)
Just for completeness, assembly is most always dynamically/weak; and Haskell is static/strong.
BTW it is the weakly-typed behavior of C (casts, void pointers, array bound checking, etc) that causes probably 95% of all type-error bugs. In fact this falacy that dynamically typed means the same as weakly typed is probably the primary reason that so many people seem opposed to dynamic typing. Dynamic != Weak.
I haven't done any real programming in a long time.
Is it sensible to compare java with purely scripting languages? I think python is a great language - as scripting languages go. But, I don't think I would try to write a substantial application in anything that doesn't enforce pre-declared variables.
To clarify, Java doesn't even load in the entire library at startup: it simply gives the library a virtual address (via mmap()) so that it can be automatically loaded by the OS when it is actually needed. This resuls in less actual memory usage because different processes can share the memory pages, but it makes each process in top appear much larger.
However, to combat the illusion that Java uses a ton of memory, they're changing it in 1.6. Full details here: http://weblogs.java.net/blog/xiaobinlu/archive/200 5/08/perception_real.html
I'd have said that C bloated _precisely_ by becoming C++ (and ObjC, Visual C++, etc.). Sure, there are other things that have been added since K&R v1, but mostly it was the "let's take C and add object-oriented programming" that opened the door to lots of new complexity.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
I've heard this crap before, and usually on slashdot where the editor's BIAS against Java is demonstrated ably by the utter crap anti Java FUD they promote to the main page.
/. FUD, that is not because of "marketing" or "hype". You can't survive over a decade on hype - eventually you need to walk the walk, which Java has done and is still doing.
/. editors' own bias against the language.
/. will be the language to do it.
Java is omnnipresent in the marketplace and contra the usual
Java utterly dwarfs Ruby or Python in the workplace, and that's not because Ruby needs more time - Ruby has been around for ages already, it's just not what people want to use. The fact that Rails is a nice solution to ONE single problem domain doesn't make the Ruby language a success - in fact, a simple perusal of the numbers shows that Ruby doesn't even figure. Go read the book sales numbers for Ruby - all but nonexistant compared to Java.
Show me where the tool support for Ruby is. Show me Ruby for cellphones, show me Ruby on embedded devices. Show me enterprise level Ruby. Go look at eBay - running Java, go look at Google - running Java, go look at IBM and Apple - strong proponents of Java. Why? Not fucking hype, but because it does the fucking job well - DESPITE the bleating of whiney assed slashbot fan boys. Grow the fuck up, Java is successful because it is good at getting stuff done. End of story.
Sourceforge is now dominated by Java - more FOSS is coming out made in Java than C or C++. Compare the supposed "Java killers" like C#, Ruby - they don't even figure.
This whole "Java is dead" thing is utter crap and merely reflects the
Java will be superceded at some point, all languages fade from the number one spot at some point, but none of the current crop of tin pot alternatives being bandied around on
You've never done anything in Java yet you know all about it? I present the typical Slashbot slackjaw.
"Java is an advertising name"????
FFS, this is typical anti Java FUD. You don't go from new to used by IBM, Apple, Google, eBay, most fortune 500 companies in the world by advertising. People like IBM and Google have actual engineers -you know, people with brains. The kind of people who probably even try technologies before presuming to pass judgement on them.
Moron.
for small and even medium sized sites you're right, of course. Using WARs is an unnecessary pile of pants EXCEPT that it makes your site portable. If your server dies, you copy the war (a single file) somewhere else and your site's back.
When you start getting into bigger sites with clustering and multiple layers & tiers and whatnot WARs kind of bring sanity to the front-end. You create a WAR, you distribute it across the presentation-layer servers and you have a handy package with which to build a presentation server. If you have load balanced across 2 servers and you need it across 4 WARS are really handy for the distribution of that code.
They can be an almighty faff though.
How about sending "Hello World!" by E-Mail? In Java you just use the appropiate E-Mail class and the programm will only be about 3 lines larger. Those 3 lines will set FROM, TO and SUBJECT.
c
s /range
s /array
I am not a fan of Java - but I think comparting languages like this is plain stupid - because you are not comparing languages but the libraries.
printf is not C - it's a C library function.
OutputStreamWriter is not Java - is's a Java library class.
Shure the standart libraries. But they are library function which you can replace if you don't like them.
What you can't replace is:
unsigned int = -1;
or
char const y[] = "Hello World!";
char x[5];
for (int i = 0; y[i] != '\0'; i++)
{
x[i] = y[i];
}
These are language features. Both show a common bug not detected by the compiler. A library can be replaced by a better one - a bug generating language feature will be with you all the time. No matter how much experience.
When I did C/C++ work I was hunting down bugs based in integer ranges, buffer overuns, dangeling or null pointers all the time.
Now I have an Ada assignment and those kind bugs are all gone. If it compiles it runs. I am a happier man now.
There is more to a programming language then the count of lines for "hello word".
Martin
PS: I did not use strcpy (which does the very same) because I want to show languages features.
PS2: Declaring a variable inside "for" has become valid for C99.
PS3: Hello World in Ada:
http://en.wikibooks.org/wiki/Ada_Programming/Basi
PS4: Integers in Ada:
http://en.wikibooks.org/wiki/Ada_Programming/Type
PS5: Arrays in Ada:
http://en.wikibooks.org/wiki/Ada_Programming/Type