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.
Fortran '08 baby!!
Check out the D programming language, http://www.digitalmars.com/d/, which is a refactoring of C++ to keep the performance benefits but make it much easier to program in.
What does "half-ass" mean? Jumping on the latest language bandwagon? Learning every "language" out there?
I can see it if you mean "use the appropirate tool for the job", but...
If all your job boils down to is learning a new language, then you are in more trouble than you think.
I see this book touches on Ruby a handful of times, but for a beginner who knows a dash of html and php, could someone recommend a Ruby on Rails book for total beginners? ... or should I stick with php :)
I find C# to be far and away the most productive and efficient language I've ever worked with. This is, of course, due in large part to the robustness of the .NET class framework and the top-notch development environment. To me, it was a significant step up from Java (although I understand that that's a subjective statement). As someone who has been working professionally with C# for years, and who has found it to be a much faster way to deliver quality production code, I contend that C# is the true benchmark: Java has already been superceded.
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
So is C++, oh wait...
well, maybe C? no...
Fortran? damn...
lots 'o corpses walking around here...
And no, the Batmobile doesn't count as a "commuter car".
Take it easy? I'll take it anyway I can get it . . .
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.
If this is all we got, Java's going to be around for a long, long time.
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.
AJAX is so passe.
Ooh! Move over Java. The future has never looked brighter for COBOL, FORTRAN, and LISP programmers. They'll soon have Java programmers to rub shoulders, er, uh, walkers with. Of course, I think it was a mistake to move away from paper tapes and punch cards to enter programs. You young programmers can have your Visual Basic, your octothorped C#, and fancy schmancy .NET.
I'm just typing incoherent nonsense today. But I felt I had to take a swipe at something. I thought I'd create a new computer language called UC or Carbide. Programs would compile OK, but when executed would wipe out thousands of files. Calling it Bhopal would be just too tacky.
I used to think the Amiga enthusiasts were a bunch of hyper spazzes, but then the Ruby evangelists disabused me of that notion.
"You'll get nothing, and you'll like it!"
I think it is less about the language and more about the framework. JSP / JSF et. al., are just too bloated with configuration and XML files that leave the new developers scratching their head. If you look at other frameworks such as Echo2 , you can have a developer developing in no time given a familiarity with Java. Frameworks such as Echo have very little configuration to get up and running and provide a very code centric way to deploy web applications they allow a programmer to stay in their domain of expertise and allow for faster production. Lighter frameworks are the key not new languages.
-- ac at work
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? - Noone turned any features off the language, you can still write anything you want in any possible way you like. The message here is different: Understanding Application Servers is harder for beginner programmers than just the language itself. So, what else is new? Even then Application Servers are not taking away your ability to write any Servlet in the old fashion way. So the book is written by some guy who doesn't want to rely on existing frameworks and likes to recreate them on his own. Well, if he can get paid for that, then kudos, most of us are writing applications that solve business problems and we have neither time nor money to write our own app servers.
You can't handle the truth.
News Flash! Rails is not Ruby. It is the current "killer app" (actually a set of libraries) written in Ruby, and you can find similar libraries available for other languages as well.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
I hereby order to author of this book to go read comp.lang.lisp.
The future has been here for a decade or two. Lisp isn't good for everything (system's programming being the biggest thing because it practically requires pointers and inline assembler), but for the sort of things that Java tends to be used for (databases, web applications, handling large amounts of data, portability) you just can't beat Lisp.
This experience leads him to realize that maybe Java is dying - or at least fading in certain areas.
It seems to me that this kind of "opinion leading" is part and parcel of the development game. Someone has to be in front, shedding light on alternative approaches. Granted, sometimes change is sorely needed, but other times I get the impression that it's little more than change for the sake of change. This seems particularly true when a certain market segment gets saturated, and a new direction is needed to help those who were at the forefront, well, *stay* at the forefront.
When I hear/read about stories related to failed projects, projects in trouble, or projects that didn't turn out as well as they might have, I wonder how much if it involves programmers that aren't as well-trained as they maybe should be, and managers and/or organizations that don't have a clue about the dynamics associated with software development. It then leads me to wonder how much certain criticisms like java "bloat" is due to factors that have nothing to do with the language itself.
Fast forward five more years- lather, rinse, repeat - except this time it may very well be Ruby on the chopping block.
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.
$|=1;
In a somewhat related essay, Paul Graham is writing about what he thinks programming languages will be like in 100 years.
When you are sure of something, you probably are wrong (search for "Unskilled and Unaware of It").
FLs like APL2 and J Jsoftware are the best for real computer scientists. You can do some really kewl thangs that I would never attempt in traditional languages. APL and J let you focus on the real problem.
You want a signature? You can't handle a signature!!
May Peace Prevail On Earth
Mods - this is not flamebait. It may be uninformed, or any number of things - but it's not flamebait.
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.
PHP out of the box is, indeed, "too close to the HTML", and PHP and HTML code are often interlarded together in the same file. This is fine for quick & dirty applications, but for anything even a little bit more advanced, Smarty templating -- http://smarty.php.net/ -- is a very elegant solution. Logic and layout can be completely separated. It also simplifies the dev cycle: create simple, interim PHP files that just declare arrays and variables stuffed with fake data and have your HTML/front end coders working with that, then when your dev work and db stuff is done the switchover can be seamless if you've done it right.
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.
A bit surprised to see Smalltalk in the list of languages to use "beyond java", since (unless I'm wrong) the language is a fair bit older than Java...
:p
To the more experienced developers on Slashdot - is Smalltalk still used today? I have a decent idea of where the other languages mentioned in the article are used - but the only times I've heard of Smalltalk is generally connected to learning OO concepts. Has it gone the way of Pascal, or is there still some niche outside of academia where it thrives?
And no, I'm not trolling, it's an honest question
ClutterMe.com - easiest site creation on the Net. Just click and type.
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!
I call shenanigans on you, sir. See the MSDN article for yourself.
http://msdn.microsoft.com/msdnmag/issues/03/02/M ultithreading/
In particular, pay attention to the .BeginInvoke discussion and the meaning of the InvokeRequired boolean. And, if you know of a better way please feel free to add it as a response to this post.
Weaselmancer
rediculous.
Here's what happens with dynamic typing:
In a really small system, it saves you a few bytes of code because you don't have to type "int" or whatever all over the place. But as the system grows, and as other people start working on the same code, you start running into run-time problems of someone passing in values of the wrong type. In the best possible case that throws a run-time exception. In the worse (and more likely) cases the program will simply behave in an unexpected way. For example if I have a function like:
function add(a, b) {
return a + b;
}
Because of dynamic typing, that won't fail, whether I send it two ints, or two strings! And yet the behavior and meaning of the function is totally different whether it's with ints or strings. This is certainly wrong, and can very possibly create security problems too.
So what happens in larger projects of untyped languages like PHP (etc) is that you end up having to write type-checking error-throwing code at the entry to every function! It ends up looking like:
function add($a, $b) { // some error condition
$aInt = intval($a);
if($aInt != $a)
That is idiotic!
A lot of the things that help for very fast prototyping, like flexible typing and syntax, just aren't compatible with larger systems with more programmers working on them.
The answer is to not abandon good programming language design, but rather to come up with toolkits or designers that help automatically generate the right code. Like working with Java Swing is tricky and sometimes unpleasant, so Netbeans has a layout assistant called Matisse that automates the process. Tools like Matisse, Hibernate, etc are the way to go. It sounds like this guy is advocating a return to PHP.
Listen up, Ruby evangelists: You need to get Ruby running natively in the JVM like Jython! Then you'd have the KILLER language.
You mean like JRuby?
Viva la Visual Basic 6.0!
-Tom
Enterprise Integration - PHP Frameworks like WASP (and Zend's own) are on their way there.
Internet Focus - PHP is certainly that.
Interoperability - PHP Frameworks are very abstracted, and PHP has PECL connectivity to Java
Dynamic typing, OO, reflection - PHP 5 has all of those.
PHP itself may be too close to HTML, but that's what frameworks are for... You could say the same things about JSP/ASP. read this for more info on PHP frameworks
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#.
Java is a bad language because servlets are a pain?
Wow, that's like saying C++ is a bad language because Outlook sucks.
That's "Mr. Soulless Automaton" to you, Bub.
Static, dynamic, which is the best? It depends. Sometimes you need more power, sometimes you need more security. With C, you can have the security of strong typing, with the power of dynamic typing, by using casts.
What people who don't like C fail to realize is that C gives you the best of all worlds. You can write Java in C, just don't use pointers, don't use casts, and use the strictest syntax checking options in the compiler settings. You can write Perl in C, just use one of the several string manipulation and regexp libraries available.
Why stay locked forever in a language designed for beginners? You are a beginner only once, after you learn the basics you will need power, more than security. If you want efficiency, you need control, you need to know exactly how your code works.
I use a lot of small, quick, and dirty scripts in other languages, mostly Bash, Perl, PHP, and Python, but for deliverable professional work, there's only one language: 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'.
So, while I'm sympathetic to the frustration you encountered in the sample you posted, my response to your question would be this: Is there a better way to create a new thread from a button click handler and display Hello, world?
Well, of course there is. But rather than post my entire application (which definitely needs threads since they're polling hardware, and they definitely need access to the UI since that's where the status gauges are) I figured a small demonstration program would be more appropriate. Just saying "threads are difficult, do you really need them anyways" is hardly a fix.
Weaselmancer
rediculous.
"I recently got sent a copy of Bruce Tate's newest book Beyond Java - A Glimpse at the Future of Programming Languages.
Shouldn't this read:
"I recently got sent a copy of Bruce Tate's newest book Beyond Java - A Glimpse at the Future of Programming in Ruby.
I see nothing about "future programming languages", I see "Ruby is the next big thing!"
Amazon has it for 16.47
Expert Java EE Consulting
Static typing pretends to eliminate type bugs, but I find myself suspicous that its real effect in most cases is to lull a false sense of security. Consider the zillion bugs in Java from casting to Object and back!
For a full coverage, mathematically provable type system, take a look at SPARK Ada. It has detailed coverage annotations, no dynamic allocation, no recursion, no exceptions, no overloading or polymorphism. Until recently it had no threading. That's what you have to sacrifice to get a type system that works! Ergo, any more flexible language has holes in its armor. If you expected it to be impregnable, you have a nasty surprise coming.
Dynamic typing, at least, is honest about its limitations.
For me, the crapper is always the first thing beyond my first cuppa joe every morning.
If a baby duck is a "duckling," why would anyone want to eat "dumplings?"
Function overloading doesn't exist everywhere, and where it does, you are still writing two functions. Just because they have the same name doesn't mean its not a waste of time.
I didn't advocate dynamic typing, if you read the post you'll see I advocated a static language that gives you the best of both worlds:
int|float do_foo(int|float x) {...}
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.
The entire Java platform is a mess, it's so complex that most of the Java applications out there are solutions to problems caused by the platform itself.
XDoclet is a great example. Here is a program that reads JavaDoc headers in your EJB source files and looks for special comments. Then, together with Ant and Ant build files, it creates the server XML files that your J2EE app server needs to deploy the EJB. This saves you from writing the XML yourself. What's wrong with this picture?
And XDoclet itself is so complex that there's an entire book from Manning about it!
www.lucernesys.comHorizon: Calendar-based personal finance
Any language that claims (as Python does) that it allows programming in a functional way but lacks closures isn't anything but a con.
Just though to post a small insight to matter. My opinion is that a good programmer can almost anything with any language.
Yes certainly there are diffrences how long something can take and how easy/difficult it is. There are some limitations of course what are ready libraries etc.
But honestly, put your palmas to your chest near your heart, how much real life problems in programming have much to do with any specific languages and it's features?
I've done in 3 month in a J2EE course my first real 3-tier and J2EE application in two weeks. A bit over week went to planning, rest to coding.
I've done much less with PHP in few weeks because customer doesn't know what he wants and there isn't documentation to begin with.
I don't care about language, give me people who know what they want and somebody who can organize well it's coding!
I'd argue most of waste in effiency and speed in programming isn't lost to weaknesses of some language, but weakness of organization communication and generally people not being up to the job.
Is it PHP, JAVA, Python, or Ruby on Rails are just a seconday issues.
Nobody knows the trouble I've seen, nobody knows has the trouble seen me, even I sometimes wonder why I write these line
Python (Ruby, Perl etc) is a nice scripting language/small scale application development language.
Java is a great large scale application development language.
Comparing the two is like comparing a Cirrus aircraft with an Airbus.... It really does not make sense. Use the Cirrus to zip around quickly and with little cost. Use the Airbus to do work of shuttling hundreds of people at a time. Yes - the Cirrus will cost less and be more flexible (dynamic) but hey - that's the point. The Airbus is not supposed to be dynamic - its safe.
Ok - we have been doing serious Python large scale applications since 2000. We are switching to Java - especially with 1.5 and Eclipse. I will not bank at a bank that uses Python for their back end. Java will do.
Cheerio. Hardy
Save yourself $8.48 by buying the book here: Beyond Java. And if you use the "secret" A9.com discount, you can save an extra 1.57%!
Just a quick comment, Ruby does have regular expressions built into the language.
I think it is less about the language and more about the framework. JSP / JSF et. al., are just too bloated with configuration and XML files that leave the new developers scratching their head.
Bingo. This is exactly what's wrong with Java today and right about Ruby on Rails. The same kind of configuration that Hibernate uses XML for is done with simple methods in Ruby. Java is still far more powerful than Ruby... it has far more available for it, it's a very fast language whereas Ruby is not, and has more knowledge out there. But these XML configuration files are a beast to get around when you're just trying to learn how to do Hello World or simple CRUD.
http://www.mathdogs.com/people/mkc/perl-puzzles.ht ml
"Not an actor, but he plays one on TV."
The measure of a language is not just about the technical characteristics: there is always a language with some better technical gadgets than the one that you are using at the moment. (And some drawbacks.)
No, you have to judge a language by the package of features that are important to your project.
By that I don't mean the technical aspects alone, although they form a part; here are some non-technical aspects that are critical to whether you adopt a particular language for a particular task:
And lastly, what technical characteristics does the language have that will make the job easier?
For ages it's been on my todo list to write something about this on my blog; I've got to make a decision about what language to use for a project that will last a few years.
Sadly, it's true.
It's true, but the people that are held back by that are the same people who wouldn't try Python because of the indentation, Perl because of the "line noise", C++ for its odd streams / template syntax, etc etc. One shudders to think what they would think of actually fundamentally different languages, like Haskell or Prolog, but luckily they probably won't ever be exposed to them.
In short, those are the people who don't want to switch to something that's not exactly like what they already know. And if there's ever going to be a move in this industry to actually better ways to do development, these sheep who are scared by mere parens will not be the ones to initiate the move. So why cater to them? They'll follow the hype once it's there, or more likely be left behind because they didn't want to learn anything new.
I believe posters are recognized by their sig. So I made one.
This is the only extant book on Ruby on Rails: Agile Web Development with Ruby on Rails . There are about a half dozen others that will be available later this year, but the Agile book is quite good and sufficent to get you started.
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.
What if I still prefer to program in C?
That same example now requires deployment descriptors, packaging into WAR files, configuration files, etc, etc. For Java developers, this is the norm
I looked into Java several times as a potential replacement for PHP, and I honestly never really made it past this part. Thanks, but I'd rather just put my file in the docroot and be done with it. The only explanation I've ever been able to figure out for this madness is that somewhere along the line, Sun realized that they were pushing to hard on the "Java is easy to program" button. When developers started feeling like their fat paychecks were being threatened, they had to figure out a way to make it more confusing and make the whole process just as complicated as it would be with a "less efficient" language.
If I don't put anything here, will anyone recognize me anymore?
The author says that PHP is "too close to the HTML". But it's also really close to the XML. That makes PHP a perfect fit for SOA and its conclusion, the Semantic Web.
random underscore blankspace at ya know hoo dot comedy.
Standard ML has an even better feature than static or dynamic typing -- automatic type inference. It is both very powerful (catch all typing errors at compile time) yet does not make you jump through hoops to declare or change types. I recommend you check it out sometime.
http://smlnj.org/
It does turn java to binary. Real binarys.
Not bytecode platform dependant binarys. Java in this form is faster than C#.
Now we need a C# to platform dependant binary and end the problems.
Fastest code is platform dependant.
No Implicit Function Template Instantiation, useless! :)
I've not done java. C for a lot of years, and other things before.
Lately, while waiting for work, I've been reading the docs for J2EE, and a java textbook.
Lessee, what I've decided: java is an advertising name. It's real name should actually be Pascal++ (the println's a dead giveaway).
Oh, and J2EE, and java beans? It's a reimplementation, much messier, and rebuzzworded version... of IBM mainframe CICS (yes, I *have* done that, too).
mark "everything old is new again"
There doesn't have to be a trade off.
Static typing allows you to catch 'compile-time' errors. The earlier you catch errors in the development cycle, the quicker they are to fix. Also static typed languages generally perform better.
Where as Dynamic languages like Ruby have the benefits of being quicker to develop as you can can skip the 'compile step' and lets you do more with less code.
Although there exists languages like Boo (http://boo.codehaus.org/ that lets you have both.
Advanced features like Type Inferencing lets the compiler 'infer the type' so you don't have to write it each time.
While built-in support for lists, hashtables, regular expressions, Extension methods, closures and callables (Functions as first class citizens) allows you to write code as terse and easy as Ruby, Javascript and PHP.
You can run in interactive mode on the fly 'without needing to compile', yet also be able to compile to byte code which gives you the performance benefits of C# and Java.
Boo also has coding conventions that are actually useful as it allows you to type code that you mean. e.g.
#Example in Boo
class Example:
_privateIntList = [1,2]
publicStringField = "String"
[Property(Name)]
_privateString as string
def ToString():
return "Hello, ${_privateString}!"
examples = [Example(Name:"Foo"),Example(Name:"Bar")]
examples.Add(Example(Name:"Joe"))
for example in examples:
print example
#Equivalent example in Java
import java.util.*;
class Example
{
private List _privateIntList;
public String publicStringField = "String"
private String _privateString;
public Example()
{
_privateIntList = new ArrayList();
_privateIntList.Add(1);
_privateIntList.Add(2);
}
public String getName()
{
return _privateString;
}
public String setName(name)
{
_privateString = name;
}
public toString()
{
return "Hello, " + name + "!";
}
public static void Main()
{
List examples = new ArrayList;
Example fooExample = new Example();
fooExample.setName("Foo");
Example barExample = new Example();
barExample.setName("Bar");
Example joeExample = new Example();
joeExample.setName("Joe");
examples.Add(fooExample);
examples.Add(barExample);
examples.Add(joeExample);
for (Example example : examples)
{
System.out.println(example);
}
}
}
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
Lisp is a wonderful and beautiful language. Common Lisp macros are probably the most powerful language constructs we could ever have.
... and everything that couldn't be readily implemented in Common Lisp.
However, back in the day it needed more computing power than what was available. 8 whole megabytes of memory for a runtime! A complex program could need 40MB! Outrageous! I remember the first computer in school with 4MB of RAM, dawn expensive.
So lisp was abandoned, and let to just rust there. Thanks to Paul Graham, everybody turned their eyes to lisp again.
Time was pretty hard with lisp, and available Common Lisp implementations doesn't have real standards for:
- Threads
- GUI
- C library access
- Network stuff
In contrast, if something is implementable directly in Common Lisp, like regular expressions, or aspect oriented programming, it tends to be even faster and more powerful than their counterparts.
It doesn't mean that there is nothing like a GUI, network libraries and threads in Lisp. The Big and Expensive CommonLisps sure have it. But is non portable between implementations, and TheBigCommonLisps(tm) sometimes ask you for a runtime license fee for every copy you sell of your software. Hey, the greed of commercial lisps is the trauma inflicted in RMS and the underlying cause of the GNU project!
And the fact that there is no hard dividing line between a DLL and a embedded piece of code in a running lisp image, means that the GPL is probably not a good idea for lisp implementations and libraries.
So? Well, lisp is good. It surely can be the most powerful language in earth. But Open Common Lisp implementations have to play a little catch up in features and libraries, just about the 15 years everybody forgot about lisp and dreamed of java.
We are Turing O-Machines. The Oracle is out there.
D has been featured here on slashdot a number of times before. And for anyone who hasn't checked in a while, D has made tremendous progress since it was last reviewed. I think that anyone with use for a systems programming language would do well to look into it.
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
If you want a language with Python like Beauty, that is statically typed, uses the mono or .NET framework and is as fast as Java then you should check out Boo:
http://boo.codehaus.org/
The answer is quite simple, lua. Powerful language who's best feature is its own lack of bloat.
The language itself doesn't really matter.
.NET house, you'll land like a dead fish.
When it comes down to it, there are two reasons to write code:
1. For fun.
2. For money.
Most people tend towards reason 2, as do I.
You can be a super wizard at D and be able to write outstanding applications that blow everything else out of the water, but try to get a client to understand why you're using a language that nobody else in the world will be able to maintain for lack of knowledge, and you'll soon be short of a contract.
You may be the god of Python, but if you're pitching to a
There's more than one way to write a program, no matter what language you use, but if you're not following where the mindshare is going, you're taking a huge risk on your career.
Clients and managers don't want to hear about how language X kicks ass on language Y. They want to hear buzz words. They want to hear how you can synergize your idea with their existing code and knowledge (there exceptions, of course, but I wouldn't bet my future on it!)
I don't use Java for any love of the language. I use Java because it generates for me a six figure income.
In a recent interview, Bruce Tate commented "Keep in mind that I'm suggesting Java will be dead like COBOL, not dead like Elvis. For the hardest enterprise problems, Java is safe for at least three to five years--things like sophisticated and scalable object relational mapping, two phased commit, and the like. Java is being threatened in a much more common, and I think important space: how do you build a simple web application that fronts a relational database? Especially a database schema that you control? This industry solves this particular problem over and over, and Java's not very good at it. I think we'll see some significant movement to Ruby on Rails this year."
a stJava.htm
http://www.webservicessummit.com/Articles/MovingP
Truly, once GNUStep gets known, building applications using Ruby as the prototype layer (or Python for that matter) you can build some sweet and very high performance applications for desktop and server and embeded systems.
If Java does not get with the times and start supporting """ identifiers, object and array literals (JSON) and cleaner iterative constructs foreach r in l {, it will get left behind.
Less lines == improved readability == less scary == maintainable code
JsD
One thing to keep in mind with List.size(), that method is not limited to Lists (something similar to arrays), but rather any type of Collection. The 'length' of a Set doesn't make much sense, but size tends to.
It is a little odd at first, but mathematically and logically, I find it appealing: length of a vector and the size of some generic collection.
No question that the typical web app can be written 5 times faster with rails, but ruby *replace* java? That's just silly. Would you want to implement a programming language in ruby? Build a 3D animation library? Display vector graphics? Simulate weather? Dude. One of these languages is very high level and one of them is relatively low level. They have very different strengths and weaknesses.
Java really is a bloated beast. Let's take a few specific examples from your post, shall we?
That may be, but it still has huge amounts of duplicated functionality in its standard library: it pretty much has two complete GUI frameworks, for a start! Of course you can't remove either without breaking any code. That's what happens when you throw not-so-great stuff straight into a standard library with little consideration for the maintenance issues, and then you have to play catch up. Such problems are ridiculously common in the Java world, and practically define "bloated".
And yet, somehow countless properly compiled languages manage neither to preload their entire standard library nor to have extensive start-up times. As you say, it's difficult for Java to win this one, but that's because Java has a fundamental architectural disadvantage. Other languages don't.
That's pretty much an admission that Java is "guilty as charged"... Why should any even moderately efficient programming language need OS support just to gain acceptable performance?!
But really, I'm not sure the library issues are even the major bloat problem in Java. Just take a look at the code. "Hello, world" takes something like four lines of actual code, ignoring punctuation. And before anyone pipes up that you can't compare languages used to develop large-scale applications based on such a trivial example, let me just say: like hell I can't. Everything that's weighing down "hello, world" weighs down the whole language: pointless use of classes, this.that.the.other.do.something(), qualifiers all over the place, etc. Don't even mention the repetitive SomeClass object = new SomeClass() everywhere, even where there's no need to use polymorphism where the types might actually be different for a good reason.
Compared even to something like C++, Java's syntax is cumbersome and full of unnecessary repetition. Compared to a neat language -- whether your interpretation of that is Python or Haskell or Ruby or whatever -- Java's syntax is almost prehistoric. If it were more powerful to compensate, that would be one thing, but the simpler, more elegant languages are almost universally far more expressive than Java as well. Again, the syntax is bloated, pure and simple.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
You made a common mistake. You made the mistake of correlating popularity to quality.
Java has been hyped enough that people have been forced to use it by their bosses. This necessitated the creation of many different libraries for different purposes.
"I want our cellphones to use Java, I've heard Java is good." says the PHB.
Face it, if quality was the only deciding factor in programming language support then Lisp would already have dominated and wiped out other languages long ago. Java was hyped into star-dom. End of story.
See, I think, you are presenting too much scrutiny and missing an important point. Yes, maybe VS is functionally powerful, but WHO CARES?
..... It's about Free Software vs proprietary. Freedom vs slavery. Ethics vs complete absence thereof. Trust vs antitrust. (I hope you realize why I use the capital 'f' in Free).
It's not Java vs C# vs Python vs Ruby vs
Allow the user to decide how they want java to work might be a good idea.
I personally don't need java to compile anything. It's pure unnecessary overhead for a game or a website. I don't need high speed computations. Python or Ruby speed is acceptable. For a scientist that needs it , I would understand.
Java should be able to start and work immediately like Python and Ruby . Java implementation was faster perception-wise in previous releases. It's trying to do to much for too many people.
Java is still growing. The only competitor is .Net, which eventually will take more market shares, but probably never will outgun Java. Like in the MS-world, Java's biggest competitor is the prior version.
Keep in mind that C and C++ are still the most used languages in their environments. (Parallel computing, OS etc.)
SSIA
(%i1) factor(777353);
(%o1) 777353
It is about fashion. Count "Ruby" in replies, > 100. Count "Smalltalk" ~ 5. A cleaner language with better library is talked about so much less
try Squeak Smalltalk
try 3D Croquet
At the POPL 2006 (Symposium on Principles of Programming Languages, an academic conference) last month, Tim Sweeney (of Epic Games and Unreal Engine fame) gave an invited talk on the future of programming languages. You can read his slides online.
It is worth noting that he seems to think that static types, particularly an expressive dependent type system, is the way to go for the future of game development.
This has nothing to do with trying something new or not being open to certain programming languages. Perl, Python, Prolog, Haskell and C++ each have there benefits. The Lisp parenthesis syntax has no benefits other than arcane insanity and a simularity to Grok and Ork tongue. Molbolge and Befunge are better than Lisp. A Pan Galactic Gargo Blaster would feel better than Lisp because although your smashing your head between two lemon peals with a sledge hammer at least it gives you a good buzz.
Lisp needs a more modern control structure not something that is 30 years old. Parenthesis notation is for the birds. A modern list oriented language would look more like C with list processing not RPN Algebra and that is why Lisp hasn't caught on. Lisp has a Lisp and is one of the few languages that has a defective vocabulary. All the Lisps including Scheme ect. need a modern structured approach. Just because it is list processing doesn't mean it needs parenthesis. Come up with a better structure at least.
This is some Lisp Code:
(null (= 1 (* 2 3)))
(and 1 (cons 'c '(b)) (rest '(c)) (setf y 'ThislanguageSucks))
This would be a C version of lisp. It shows that Lisp in it's present form sucks. Not to mention that some versions of lisp don't have for loops.
list x, y, z, u;
display(x.size);
x.add("a", "b", "c");
z.add("a", "e", "qsdlfjks");
display(x.first);
if(cmp(x.first, y.first)) display("true");
u = first(x.rest + z.last + y.middle);
Each of the Languages except Lisp has some advantage to go with it's paradigm. With Python the tabbed spacing at least makes things more readable. With Perl the complexity gives lots of power and with C++ it gives some additional features beyond pure C. Haskell and Prolog also give some benefits concerning logic and functional programming. But Lisp has severe issues with it's parenthesis programming structure that hampers it from becoming more mainstream.
Ruby has made some important OO design contributions
It has ?! Like what ?! What's in Ruby that wasn't in other languages ?!!
For patience's sake, this is the problem...All I see are ideas that were in other languages, thrown together in a learn-as-you-go experiment. People think continuations are cool? Then look at Scheme and look at Smalltalk. You can't compare years of development to that experiment. Ruby is rubbish. Compare it to any Smalltalk implementation. Download a Common Lisp IDE (LispWorks, Franz) and tell me how cool Ruby is...When people diss Java, remember to also diss HotSpot. Can your little language optimize code statistically like that? I thought not...
You want new stuff? Look at Factor, Joy, the Mozart/Oz system, or Slate.
Wanna compile at gcc performance? Try Scheme with the Bigloo implementation, or Objective Caml. Bechmarks for Ocaml here (and for SML with MLTon compiler here.- The bechmarks for Bigloo were reomved some time ago).
I'll just post the buzzwords for Factor:
Continuations, exception handling.
Powerful and logical meta-programming facilities. Introspection, code generation and extension of both syntax and semantics is very easy.
Higher-order programming allows code blocks to be treated as data and used as parameters.
Highly minimalist, very consistent design. No layers upon layers of indirection, no confusing corner-cases, no poorly-thought-out features.
Postfix syntax with an extensible parser; values are passed on the stack.
Higher-order programming allows code blocks to be treated as data and used as parameters.
A powerful and very generic collections library allows many algorithms to be expressed in terms of bulk operations without micro-management of elements, recursion, or loops.
A very consistent object model based on generic predicate dispatch.
Arithmetic operations that closely model mathematical concepts, rather than just being a thin abstraction over underlying machine arithmetic. All integer operations are done in arbitrary precision, and exact fractions are supported. Complex numbers and complex-valued elementary functions are integrated.
Damn, that Slava Pestov is one smart dude.
When you see those languages, you kinda get sad that Ruby is such an attention-grabber, but I can see clearly that this is just because of disinformation. With the exception of Joy and Slate (for now, I hope), all the others I cited have pretty workable environments.
And by the way, you don't write LISP anymore, it's Lisp.
Main difference between the BSD license and the GPL license: one is from California and the other is from Massachusetts
That above comment was quite inciteful!
:= Array new: 10. "creates new Array with 10 nil entries"
:= 'Hello World'.
;) { }
For those who haven't programming in a dynamic language such as Smalltalk: Dynamic type doesn't equal no type. Nor does it mean non-declared variables
for example in Smalltalk:
|ar | "Mandatory declaration of ar"
ar
ar at: 1 put: 20. "puts 20 at position 1"
ar then has class of Array.
This can be verified by displaying:
ar class will return Array
Running in a debugger will also verify it.
Later could do:
ar
ar class will return String.
(The array would be garbage collected if nothing else pointed to it.
And with languages as dynamic as Smalltalk or Ruby you can also add methods to any class. Even add to Array and String.
You can even add them at runtime if you are so inclined. (personally never had to do it).
Want to re-define a loop? Go ahead it isn't a fundamental keyword a'la C like for ( ;
Want to stuff different types into a collection? Go ahead, as long as particular function you want to traverse collection with is supported.
The other critical component of using a dynamic language, as has been pointed out, is unit testing. For example, I can run a test on all methods starting with 'test'. Like 'testString'. Just add method and it will be added to test suite. And will check as many diabolical edge cases as you like. Pick your level of paranoia: Run test suite every day, every hour, or every time you commit a method.
Unit tests let you take bigger risks. The reason codebases stagnate is not due to fear of creating bugs: every developer does it. The better ones probably create more. The reason is fear of NOT KNOWING if you created a bug. That is why unit testing encourages experimentation and ultimately better code. Static type checking simply 'falls out' of unit testing, but it is a minor win compared to the edge case exercising of each method that has unit test coverage. That is the major win.
If interested, you might tryout the Community Edition of Dolphin Smalltalk.
http://www.object-arts.com/content/mydolphin/d6Dow nloads.html
For windows environment it it hard to find a more comfortable environment. And you will find it is quite fast execution speed as well. They do a lot of clever optimizations (without breaking simple language) to get good speed.
Other languages:
Personally I like a lot about Ruby (especially current popularity), but Smalltalk syntax is way cleaner. I worry the reported execution speed of Ruby apps will prejudice folks against dynamic languages.
"IO" is by far the cleanest language syntax of anything I seen, just fairly new at this point. If it had kept the self-documenting keyword: key method: met syntax: syn of smalltalk, it would be that much cooler.
Of course ObjectiveC might be the cleverest compromise ever: Ansi C plus embedded smalltalk like coding... I believe this is a key reason Apple appears to be more nimble than MS.
And going yet further out on this unsupported limb (it goes without saying someone will shoot me down). Google does quite a bit with Python. I think that being a good dynamic language is a strength and allows them to market quickly with new ideas. However, Python is not AS dynamic as Ruby or Smalltalk (weaker reflection I understand). And in some tiny way, I think this has made it harder for Google to really hone their projects. To me at least Google does a really nice job on initial release of a product (gmail, maps, picasa) but then kind of doesn't fill in some obvious missing functionality. (like saving thumbtacks or waypoints on maps for example). Kind of 1/2 baked theory I suppose.
Actually if you look at history of programming languages after smalltalk, they are ALL re-converging toward Smalltal
I am just starting out with Java now (I've been forced to) and I really like Python! Damn the 'hype'rs !!
Sent from my desktop computer
Save yourself $0.99 by buying the book here: Beyond Java. And if you use the "secret" A9.com Instant Reward discount, you can save an extra 1.57%! That's a total savings of $1.25, or 7.24%!
Boo Version:
print "Hello World!"
How about a comparison of Code that does a little more?
import System
April1st = DateTime(DateTime.Now.Year,4,1)
CountDown = April1st - DateTime.Now
print "There are ${CountDown.Days} days left for a release of Java that is productive!"
Java version Anyone?
Sat down at the local Borders and read it in about an hour after it caused a big stink over at javalobby.org and theserverside.com a couple months ago. Ruby's a real nice language and I'd personally choose it over Java for many projects, but it's just falling into it's niche with the Ruby on Rails hype, just like PHP, Perl, and Python fell into their niches a while back.
The thing is that a pure dynamically typed language is never going to be the language "Beyond Java". But it doesn't have to be an either/or situation, as is already the case with languages like Boo and Dylan. Look at languages that do type inference with type declarations for method arguments and return types as "the future". Take a look at http://lambda-the-ultimate.org/node/1253 for what Microsoft is doing with the next version of C#. That seems to be a more reasonable approach to the whole dynamic vs static typing debate. In fact, I would recommend searching http://lambda-the-ultimate.org/ to see what some of the "deep thinkers" about these issues say about the whole debate.
Ruby is nice, but Beyond Java seems more of a book to shake up the Java community and promote consulting services than any real insight onto what's "Beyond Java". I think Guido is even going to be pure some sort of type declarations in Python 3000 - whenever that comes out.
Nice troll.
Lisp has macros. They're extremely powerful, and one of the most important features of the language, and as far as I know not available in any other. And they would hardly be possible with a C like syntax.
I believe posters are recognized by their sig. So I made one.
There are several points I consider important for a programming language
- Available under various operating systems.
- Operating system independend (no access to proprietary functions).
- An open source implementation of the compiler/interpreter + librarys.
- Usable to write applications and skripts (Not only an internet language).
- Possibility of compilation (some optimizations are not possible just in time).
- Typesafety for containers, etc. (the compiler can find typing errors)
- Object oriented but simple types should also be there.
- Possibility for extension (new Datatypes, Functions, Operators, Statements).
- For simple problems simple programs should be the solution.
- Take load from the shoulders of programmers.
Because I am biased, I do not suggest a successor for Java
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net/
Wikipedia: http://en.wikipedia.org/wiki/Seed7
Project page: http://sourceforge.net/projects/seed7
Performance might sometimes be a concern, depending on the nature of the app. Probably a bigger problem with any interpreted language is security. Maybe, just maybe, I don't want everybody out there picking over my source code and making changes to the program. I don't know if Ruby or Python have any way to tokenize or obfuscate source code -- but with a compiled language, it's clearly not something I need to worry about.
The future is multiparadigm programming.
This book was an eye-opener for me.
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
I read a quote somewhere: "Technology is something that isn't finished yet". These frameworks are bloating because people aren't creating the correct kinds of tools; their developers haven't yet identified what they want the frameworks to do, or else they're just solving the wrong problems. Hopefully, this bloat won't lead to Java being abandoned in favour of the next half-baked set of ideas. Java is simple to work with and its object model is easily applied to real-world problems (i.e. whatever you want your program to represent, bar interfaces with external systems, including end users). I firmly believe that once the corrrect objects/interfaces are defined in "problem" areas (such as User Interfaces - or "presentation layer" as some might call it), then programming as a whole will benefit. This is where "patterns" are leading us. Some will fall by the wayside, just like some frameworks.
Hibernate looks pretty cool.
I like the look of Echo 2, will be looking at it again...
... and Spring. Hear people are raving about it, saying that it's saving them days' worth of meaningless coding ...