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.

Comments

Comparison with perl??

[poeidon1]

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.

Re:Comparison with perl??

[Hercynium]

Before I learned Java, I wrote some pretty large, complex apps in perl. Object-orientation, casting, closures, marshalling... perl made so much of that easy (at least to me)

Now, I work in a department where Java is the canonical language, and other languages are discouraged (except expect - *ugh* - but I understand why)

And guess what? For the most of the applications we write and deploy, Java is a great choice! Looking back on some of my larger perl programs, I wish I could re-write them in Java. They'd be easier to maintain and extend.

But that's not always the case. There are days when I'm parsing a log file, or listening on a socket using Java - only to parse it and correlate to a database table and maybe store it someplace else - and my brain is *screaming* to be writing this in Perl.

Data munging is beautiful in Perl.

Interoperability is terrific in Java.

Each was built for different reasons, and it shows.

*BTW - I think perl interoperates just fine, but not with everything java does.

News flash:

[grasshoppa]

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.

Show me the money!

[boxlight]

I'll probably look at Ruby out of geek curiosity, but Java pays *very* well.

If I'm to dump Java and use Ruby then someone's going to have to show me the money.

boxlight

Perl is not too loose and messy

[truckaxle]

"Perl's too loose and too messy" please provide some meat to that aspersion.

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.

Re:Perl is not too loose and messy

[Tetris Ling]

Regular expressions can replace pages of code, but that doesn't mean they should. In fact, I recently had to change a Python program I'm writing to use regular expressions less, because the implimentation just wasn't clear enough.

And that ends up being the problem with Perl. The language doesn't encourage clean code. Perl is, and probably always will be, useful for small scripts. But any replacement for Java will need to be managable and maintainable on a larger scale than Perl is capable.

Re:Perl is not too loose and messy

[a55clown]

the word you're looking for is "obfuscate".

Dynamic typing

[CastrTroy]

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.

Re:Dynamic typing

[Some Random Username]

It lets you be more flexible at the cost of making it impossible for the compiler to catch certain bugs. As the most basic example, a single function can take either an int or a float with a dynamically typed language, instead of having to write multiple functions to deal with all the combinations of floats and ints.

For a nice tradeoff of static and dynamic typing, check out pike. Its statically typed, but lets you give up just as much of that staticness as you need when you need to. You can declare a function as taking float|int for its args for instance.

Re:Dynamic typing

[margulies]

The following is taken from Andrew Cooke's excellent write-up of issues like this...

http://www.acooke.org/andrew/writing/lang.html#sec -staticdynamic

Static and Dynamic Typing

Types can be static or dynamic. Languages like Lisp or Python have many different types, but when you look at a piece of code there is nothing that forces a variables to "be" (or to "point to") a piece of data of a particular type. In other languages, like ML or Eiffel, a certain variable will always be connected with a value of a certain, fixed type. The first group of languages (where the type of everything is unknown when the program is compiled) has dynamic types, the second group has static types.

Dynamic types are good because the program source can be more flexible and compact (which might be particularly useful for prototyping a system, for example). Static types are good because they allow certain errors in programs to be detected earlier (a compiler for a statically typed language may also be able to make extra optimisations using the extra information available, but this depends on details of particular languages and compilers).

My own view is that at computing projects become larger, static typing becomes more important. I would not like to work on a project with many other programmers using a dynamically typed language, and I choose to use dynamically typed languages, usually, when doing projects of my own.

In some languages (e.g. ML) the interpreter or compiler can often work out the type associated with a variable by itself, which saves the programmer a lot of effort.
Strong and Weak Typing

Types can be weak or strong. The languages mentioned above are all strongly typed, which means that at any point in the program, when it is running, the type of a particular chunk of data is known.

Since a dynamically typed language does not have complete type information at compile time it must, if it strongly typed, keep track of the type of different values as it runs. Typically values are boxed together with information about their type - value and type are then passed around the program together.

It might seem that a strong, statically typed language would not need to do this and so could save some memory (as type information is available when the program is compiled). In practice, however, I believe that they still do so - possibly because of polymorphism (see below).

Unlike the languages mentioned so far, C has weak typing - some variables can point to different types of data, or even random areas of memory, and the program cannot tell what type of object is being referred to. Depending on the context within the program, the variable is assumed to point to some particular type, but it is quite possible - and a common source of confusing bugs - for this assumption to be incorrect (some type checking is done by a C compiler, but not as much as in a language designed to have rigorous compile time checking, like those described as statically typed above).

Java is strongly, but not statically, typed - classes can be converted (cast) and, if the types are not compatible (related through inheritance - see below), a run time error will occur. Apart from this (significant) exception the Java type system can be considered static - one description is "compromised strong static typing".

When strong static typing is enforced (even if only partially, as in Java) it can be difficult to write generic algorithms - functions that can act on a range of different types. Polymorphism allows "any" to be included in the type system. For example, the types of a list of items are unimportant if we only want to know the length of the list, so in ML a function can have a type that indicates that it takes lists of "any" type and returns an integer.

Another solution to the problem of over-restrictive types is to use inheritance from OOP (see below) to group data together. Yet another approach, used in C++, is templates - a way of describing generic routines which are then automatically specialised for particular data types (generic programming and parameterised classes).

Re:Dynamic typing

[Coryoth]

Whenever there is a debate about static and dynamic typing people always come out to fight with their blinkers on. They seem to be bound by the mindset of the sort of problems and projects they work on. In practice both have their uses and that's the real reason the debate. I use both, and the choice largely depends on what it is that I am coding. Analogies inevitably fail, but let's try one for this case:

If I'm building a treehouse for my kids* I'm probably not going to bother with the same sort of formal measurement that I would use to build a house for myself - line it up and cut it to fit will do most of the time. That flexibility is beneficial because I'm building around a tree, and being able reshape and redesign things easily makes a whole lot more sense in that environment (the other option being spending several weeks surveying the tree, and a lot of long tedious calculations to deal with its twisting organic structure).

If I'm building a house to live in I'm probably not going to just slap it together: I want to have some sort of design and measure everything against that as I go so I can be sure everything will fit together exactly as I want it to when I'm done. This more rigorous checking saves vast amounts of time over a flexible approach because I know that as long as all my measurements match up, the house will stay up - with a more dynamic approach I'll have to be testing everything every step of the way.

If I'm building a bridge or a bank vault I'm probably going to have another level again of formal requirements and calculations to ensure not just that things fit together, but that I can be certain that it will be safe in all weather conditions, or properly secure from potential thieves. Bothering to have detailed specifications from which extensive calculations and proofs of deep properties can be made is going to save me effort in the long run - it's just another level of formality again, above that used to design and build the house.

Now to my mind these three cases represent dynamic typing, static typing, and full formal specification (for those who think static typing in Haskell is as high as you can go, check out HasCASL). Each has their own place, and it's a matter of what it is that you're doing that determines which is the most suitable approach. If you mostly work on treehouses then someone telling you that you need to be properly measuring everything is going to seem like a pedant who just wants to annoy you and slow down your treehouse building. If you mostly build houses then someone telling you to hold up the 2x4 to where it needs to go and cut it to shape is going to seem reckless and foolhardy. As long as you're looking at everything only through the type of things you build the other point of view will always look silly.

Jedidiah
* (I am not trying to suggest that dynamic typing is for inconsequential or throwaway projects, I just wanted an example that is fairly dynamic and works best with an evolving approach)

Re:Dynamic typing

[CastrTroy]

So, basically dynamic typing is good if you want to whip out small projects really fast, but once your dealing with bigger projects, it helps if everything is staticly typed. Personally i've found that even for smaller projects you can save a lot of time using static typing just in debugging time. For the amount of time that i've lost to define a method twice to deal with 2 different types of objects, i've saved tons of time dealing with bugs that result from dynamic typing.

Re:Dynamic typing

[Jerf]

I don't understand as a developer what dynamic typing does to help a language, and what real world advantages it offers the developer.

Fact: Nothing is free.

Everyone will agree with that in principle, but few people have internalized it.

Static typing is not free. It makes you jump through hoops to type correct code. When you need to change a type, it's even more difficult, especially when it's not something you can search and replace. When changing requirements require you to refactor out some interface, this costs yet more.

The great failure in this debate between static typing people and dynamic typing ethusiasts largely arises from the fact that static typing people can only see the benefits of static typing, and only see the costs of dynamic typing. You particularly made reference to your own inablitity to see the benefits in your post.

You can't complete the debate until you admit to yourself that there are costs to static typing, and benefits to dynamic typing. Only then can you intelligently weigh the costs and benefits of each approach.

I think dynamic typing wins in the vast majority of cases not because "static typing has no advantages", but because static typing charges you through the nose for very, very dubious benefits. Yes, static type correctness catches bugs. But what kind of bugs does it catch? Type bugs. All in all, as someone working in dynamically typed languages exclusively for years now, that's just not the kind of bug I deal with very often. I have logic bugs, architecture bugs, library bugs (bleh! and no these aren't type bugs), comprehension bugs, specification bugs, but I just don't run into type bugs that often. Thus, "paying through the nose" to avoid this particular type of bug is not a compelling bargain.

You're almost always better off taking the development-speed gains of a dynamically-typed language, and learning the discipline to write good tests (which, incidentally, tend to be easier in those languages). Static type correctness has very little overlap with program correctness. (Neither is even a subset of one another; it's perfectly possible to have a completely correct program that does not meet some definition of "static type correctness".) (Elaboration by somebody else.)

There are rare calls for static type languages, where it is so important not to make any type errors, ever, that's it's worth the pain of using them. But it's pretty rare for most programmers. (Of course there are programmers who deal in that exclusively.)

One of the things that could conceivably tip the balance back in favor of static type correctness is if static type correctness becomes more cheap, perhaps with such things like better type inference. But few things are worth the unbelievably staggering price you pay in Java for static type correctness. If you've never used a dynamic language for long enough to see the benefits, you have no idea just how much you are paying.

Until someone shows me that all the code that I've written in dynamic languages that have served tens or hundreds of thousands of people are somehow riddled with type bugs that have somehow failed to cause my code to come crashing down, I'm going to continue to use dynamically-typed languages. The predictions of doom if you let go of static typing have so far shown themselves to just be fear-mongering, quite a lot of it (as far as I can tell) from people who learned in school that static typing was important and have never even tried anything else.

Re:Dynamic typing

[radish]

Or you could just use overloading:

public foo doFoo(float) {..}
public foo doFoo(int) {..}

or inheritence:

public foo doFoo(number) {..}

rather than dynamic typing:

public foo doFoo(your_guess_is_as_good_as_mine) {..}

I'm firmly in the static typing camp. Not only does it make things more reliable (due to compilers catching errors) it also prevents those errors in the first place by allowing IDEs to be smart and suggest appropriate parameters. Going back to dynamic typing also means going back to vi as the ultimate editor, and I really am not ready to give up my IntelliJ thanks.

Re:Dynamic typing

[0xABADC0DA]

The comparison of bug rates is false, because it assume the same programmers are doing work in both types of languages. They aren't.

Fundamentally, what you perceive as "power" or "expressibility" in a dynamically typed language is due to lack of structure. For example, in Smalltalk one can add a new method onto Object and then one can call this method on any instance of any type. This means you can solve some requirements in such a dynamically typed language in a very small amount of code, by tweaking how the system works.

But there is no free lunch. This "power" means that you cannot take an arbitrary program and know what it does without considering then entire system it resides in. Or in the dynamically-typed languages that do not allow modification of the common classes, you cannot usually take a subset of the program and know what it does without considering the entire whole. Static typing acts as a barrier, allowing code to be isolated from the rest.

You have to realize that, for the vast majority of programmers, that the structure is necessary. Those programmers working in dynamically-typed languages fail; they produce spaghetti. Sure, you *can* maintain structure in a dynamically typed language such as Smalltalk or Ruby. But programming is a constant struggle to keep the code from descending into chaos.... and the harder the language makes this the fewer that will be able to use it effectively. That's why these languages typically are used for scripting or for projects only done by an elite few of highly competent developers (fyi most web development work is basically scripting).

Re:Dynamic typing

[mad.frog]

static typing charges you through the nose for very, very dubious benefits

Well, as they say, "your mileage may vary".

From my development perspective, static typing isn't a cost, it's a dividend.

Code with explicit typing, to me, is MORE readable, more clear, and easier to deal with, because type expectations are spelled out explicitly; I *can't* avoid specifying them, because the language won't let me. Maybe you find it to be annoying, irrelevant dreck that drowns out the meat of the program, but for me, types are inextricably part of the meat -- removing them makes me wonder, "what are the expectations for this again? I hope someone commented it properly..." (And yes, I've done enough work in dynamic languages to have valid opinion of both sides.)

You're almost always better off taking the development-speed gains of a dynamically-typed language, and learning the discipline to write good tests

Yeah, yeah, yeah, I've heard this argument. I happen to agree that improved testing is a good thing, and that testing frameworks tend to be harder than necessary in most current static-typed languages. But IMHO this argument is rather like saying that seat belts are unnecessary if you have air bags (or vice versa); I'll take *both*, thanks.

Until someone shows me that all the code that I've written in dynamic languages that have served tens or hundreds of thousands of people are somehow riddled with type bugs

Whoa, slow down, no one's saying that dynamic languages are impossible to write proper code in. My assertion is that static typing is a tool to help programmer's avoid dumb mistakes, and to make the meaning of the code more clear. Can I get by without this tool? Yeah. But I don't see a good reason to, in general.

Re:Dynamic typing

[Anonymous Coward]

Fact: Nothing is free.

Yup.

But what kind of bugs does it catch? Type bugs.

Type bugs are almost always logic bugs or comprehension bugs. If you understood the requirement and implemented it correctly, the type should be correct.

In fact, when I was taking chemistry in school, I would often guess at the correct formula for something based on the units. Nearly always worked. And if you ever end up with the wrong units, you KNOW the answer is wrong.

Static type correctness has very little overlap with program correctness.

Try writing some stuff in Haskell and see what you think. Many people have commented that code either fails to compile or works correctly.

Of course type annotations are mostly optional in Haskell due to type inference, but adding it or checking the type later helps a lot. (I'll often add annotation by asking what the type is, saying "yup, that looks right" and copy-pasting it.)

Re:Dynamic typing

[sproketboy]

Here in a nutshell is what's wrong with dynamic typing.

// Proto language dynamic typed
// This function trims a string from the 2nd param
FUNCTION trimString(a, b)
   IF typeOf a <> "String" OR TypeOf b <> "Number"
     // er, not sure what I should do here.
     // Maybe the caller passed the wrong params OR
     // maybe I was passed the wrong number of params OR
     // maybe I was passed NO params
     // I "guess" that maybe I cuold throw an error OR
     // maybe I should just pop up a message box OR
     // Is this a web application? If it is I really can pop a message box
     // I "guess" that really I should just throw an ugly runtime error
     // at the user even though this realy should be a "compile" time error.

     throw new WTFError()
   ENDIF
   // Code goes here....
RETURN

In other words. It's *impossible* to write any kind of generic code without having to deal with these kinds of runtime issues.  Much better code:

// Proto language static typed
// This function trims a string from the 2nd param
String FUNCTION trimString(String a, Number b)
  // code goes here....
RETURN

Re:Dynamic typing

[Eivind Eklund]

The elite programmers I know tend to choose which language is appropriate for which project. I can't think of any I'd consider "elite" that program less than 3 languages.

And I've seen much more chaotic code in Java than in Ruby; chaos isn't a function of static or dynamic typing. It is mostly a function of programmer and manager competence, though also a function of the surrounding culture and what the language makes easy. Perl, for instance, tend to encourage halfassed programming.

Eivind.

Re:Ruby's Quite Nice, Really

[PopCulture]

Where do you think Ruby will be in 10 years? My guess is either:

1) extinct, or,
2) 'bloated'

Re:Ruby's Quite Nice, Really

[AKAImBatman]

Java, on the other hand, is much too bloated.

People keep repeating this, but it just isn't true. What Java has is an extensive set of libraries that provide all kinds of common functionality. If I were asked to trim it down, I'd have a hard time nixing anything that wouldn't get me in trouble with a LOT of people.

The main problem that Java still has is a large memory footprint. This is due to loading all those libraries into memory at startup. Why is this done? To reduce startup time. (i.e. It doesn't have to keep hitting the disk every time a new class is instantiated.) Thus Java appears "bloated". Yet if they remove the "bloat", people complain about the startup time. It's really difficult for Java to win this one.

The only real solution to this dichotomy is to make Java an operating system component. As a system-wide component, it could keep all the info in memory ONCE (including the pre-compiled versions of the classes) and make effective use of the system resources. This is very similar to what most OSes do with their libraries. Sun has taken steps toward this design with new code that preloads the classes into a shared memory area, but it's only partially complete. Given Microsoft's stance on Java, it's doubtful that they'll ever be able to completely solve the issue on Windows.

Thankfully, systems today have tons of memory and disk space. Since the unused classes will just be swapped out to disk anyway, there's no real concern. So quit whining, and enjoy what the Java platform has to offer. :-)

Ruby on Rails

[ukpyr]

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?

Rails

[jkauzlar]

Although I cringe at the name "Ruby on Rails," I'm assuming I'll get past that. I've been writing Java for years and, afraid of falling behind, I decided to try out rails to see if I really could, as the books all say, become more productive. I certainly think it's something to look into. The language's lack of type safety (or even 'my'!) sets off a continual internal alarm and nags at me to no end, but I find I can just set the vars to zero to get past that.

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).

Re:Rails

[sulam]

Rails (not Ruby) is faster than Java because it's a RAD framework. R = Rapid. If you used a Java RAD framework (there are a couple), it'd be just as fast. Ruby _can_ be faster (to develop) than Java due to things like collections semantics, but there's no guarantee it will be. As far as MVC separation goes, the two languages are functionally equivalent with the right framework. People conflate Rails with Ruby, but that's a mistake. Java was popular long before any great web frameworks existed for it, but now that they're there, people don't conflate WebWork (for instance) with Java. They do with Rails and Ruby because the two are getting popular together. With Rails, you have .rhtml files as your view, with scripting possibilities available there. You have your controller obviously, and your model bound to a db via ActiveRecord. This is no different from something like WebWork where you have a .jsp file as your view with JSTL scripting available within it, a controller class that provides objects to the view to manipulate, and model objects that use Hibernate to bind to a db. Ruby will get additional libraries and third party support over time. Heck, it may even get another web dev framework besides Rails (would be nice, people might quit conflating them). So I think over time Ruby will become a more compelling replacement for Java, and of course people who like to do original development for the sake of getting their name out there or just pride have a lot more to do in Ruby than they do in Java. That's true for books too, imagine trying to write a Java book today covering almost any topic, it's guaranteed to be a "me too" book. But with Ruby you can be the first guy to write the classic ActiveRecord book, or whatever it is you become an expert in. So yeah, it doesn't surprise me that people who create libraries or right books are excited about Ruby, there's more left to do. But that doesn't mean I'm gonna start using it in production code. :)

Re:Ruby's Quite Nice, Really

[AuMatar]

AN OS component? Dear fucking god no.

The REAL solution is not to put everything and the kitchen sink in the language itself. The language should be a syntax specification, not an implementation of every obscure library you could ever think of. Outside methods similar to CPAN and BOOST do a far better job of being library repositories. The resulting interfaces tend to be better designed to boot.

Lisp

[fionbio]

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.

Re:Lisp

[JanneM]

Well, thousand page standard may not be always a good thing, but IMO it's better than having to rewrite your program from scratch every time you switch implementations.

One major problem is that when a language defines a very large environment - and especially when the designers have been 'clever' about the design - it will frequently be several times faster to implement some functionality yourself than to find out if, and how, to do it with the standard framework.

Yes, you can depend on the library to be debugged, optimized and correct (to a larger extent than your own attempt, at least), and yes, taking the pain of learning it now will pay off in years to come. But when the deadline is looming, and you are faced with a two to four hour programming task, or an all-day look through documentation and example code to determine if and how you can do what you need (that may in the end result in you writing it yourself anyway) it's very easy to just do it yorself, and put off learning about the 'right' way to do it to later (ie. never).

OK, this is not a dig against LISP - this issue of having very large piles of functionality is common to many languages, from C++ to LISP to Java, to Perl. How many people actually use even all the nifty goddness of glibc, for example?

Re:D programming

[Coryoth]

D is nice, and I certainly appreciate it's addition of design by Contract (even if it is a little kludgy), but I will be surprised if it actually takes off as the next "in" language. It doesn't have the right sort of hype engine behind it. I think you'll see Java and C# duking it out, and growing focus on dynamic languages, particularly when Parrot gets finished. The other developing area for "in" languages is probably functional languages - I think eventually there will be a functional language that, by dint of being different, manages to garner suitable hype and attention.

Jedidiah.

It's Too Much.

[Cranky Weasel]

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.

Re:Ah. Dynamic typing. Again.

[the eric conspiracy]

I agree with pretty much everything you say, especially with the frequent abuse of reflection. Runtime errors that occur in production at a client's site are a real heartache, and are often very expensive to debug and fix. Any language model that increases the likelihood of this is a bad design IMHO.

I've been using Python for prototypes, and have come to like the concise and clear nature of the syntax compared to Java and Perl. However I don't like the thread handling, the lack of quality compared to Java in the libraries, and the lack of some libraries that enterprise applications commonly use. Some performance measurements I've made also show Java is 4-10 times faster.

Re:Ruby's Quite Nice, Really

[Teilo]

Every time one of these RoR vs. Java flamewars erupts, this claim is repeated. The scaffolding scripts, for whatever reason, are a stumbling block to long time Java devs who are looking into RoR for the first time. The moment they see the scaffolding script used, they head for the door.

But had they stayed, and taken the time, they would very quickly realise that no Rails developer actually uses the Scaffolding script to develop an application unless all they really care about is a down and dirty CRUD. Scaffolding is for prototyping, and nothing else. However, scaffolding does a good job of teaching you how the underlying data objects work. Where you go with it from there is up to you.

Take a look at the underlying Rails libraries. Learn how they work. Then come back and see if you still can legitimately make the claim that Rails gives one very little conrol over the internals.

Author: cheerleader for Ruby but has good points!

[scottsk]

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.

Re:Ruby's Quite Nice, Really

[Jason Hood]

You completely missed the point. Making it an Operating System Component has nothing to do with a repository.

Essentially Operating Systems would startup a JRE when they startup. The actual memory footprint would be around 16MB for Java5. That way when apps loaded, they could reuse the existing JVM, sharing common classes with other applications. Think of dynamic libraries on steroids. It wouldnt just be a shared library but possibly instatiated objects.

As for a repository system for libraries, this uneeded. Applications ship with the libraries that they need rather than a perl application that forces the user to download them. Java applications can thus force exact version of libraries on the user without the user having to make decisions. Its a different way to do things, and in my opinion far better. For the desktop, Java has the ideal model. Let users run apps, without having to install libraries (and thus depend on an internet connection or other medium) just to get them to run.

Re:Ah. Dynamic typing. Again.

[Ian Bicking]

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.

The only time Python segfaults is when you have some really crazy code, or far far more commonly when you have C code in your system and that code is bad. Most dynamic languages also are not fully interpreted -- Python is not, and Ruby is interpreted, but won't raise syntax errors at runtime. The exception is if you are doing source code generation, which Rails does a fair amount of, but is not very common in Python code.

Now, the null pointer exceptions don't happen in these languages because there are no pointers, but similar things do happen. And they happen in Java too. Java not statically typed enough? Well, whatever, you get back to me when you have that awesome statically typed language with no slop that anyone actually does useful things with.

I don't think experience has shown us that statically typed languages are more reliable than dynamic. Programs that are developed with obsessive attention to detail, extensive review, and formalized practices and standards are reliable. None of those has anything to do with static typing; static typing is the absurd notion that the computer can be disciplined for you. If you look at something like programming by contract, it has nothing to do with static typing -- it's all about the programmers writing the system spending time indicating the exact needs and promises of the API, and language gives those programmers a structure in which to describe and automatically confirm those promises.

Re:Ruby's Quite Nice, Really

[juancn]

The Java language is just a language (and a very small language).

The mixup comes from the "Java Platform Specification" (which includes the APIs and comes in several editions).

The "Java Language Specification" only requires a few classes (Thread, Object, Class and String) and that's about it.

But the usefulness of the language comes from the standard APIs, which let your programs run without modifications in almost every known OS.

Application Programming

[Zobeid]

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.

What about C# on Mono

[mythz]

C# runs just on well on Mono.

>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 .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).

>and owned by Microsoft.

Mono unlike Java, is 'open source'.

Java is a mess

[tb3]

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!

Re:News flash!

[RetroGeek]

I don't know. I have had training (or self taught) in:

Basic/ GW-Basic
Visual Basic/ VBA/ VBS
REXX
Perl
Fortran
COBOL
Pascal
Assembler
SQL
Java
JavaScript
C
C++
JCL
DOS/WinXP batch commands
WordPerfect PerfectScript
dBase/ FoxPro
PHP
HTML/ XHTML/ DHTML/ CSS
XML/ DTD

I am current in Java, *ML, JavaScript, Visual Basic

Not all computer languages, but hey, markup languages also have syntax and quirks.

As for all the (probably hundreds) of choices, each was created for some reason or other (heck I created my own interpreted language). Most of them are fringe, but the main stream ones were carefully designed (hmmm, maybe not PHP) to be the next generation.

Each new language builds on the work of others and hopefully does not inherit the bad things. Old ones fall by the waysside. Everyone has their favourite. The more languages you know, the more you can do in any language.

Take for instance Java vs PHP. Both do web pages. If I was creating a small hobby level site, I would probably use PHP with MySQL. But for a large site which must scale, which has hundreds of pages, which must have a common look and feel, it is Java every time with one of the big databases (MSSQL, Oracle, DB/2).

Its the old adage: If all you have is a hammer, everything looks like a nail. I prefer to have a full toolkit.

Re:Ah. Dynamic typing. Again.

[AT]

I used to think the same way: static typing catches bugs. However, in the past few years, most of the projects I've worked on (largish server side Java systems, primarily) have used some form of dynamic typing anyway. This is usually accomplished by using java.lang.Objects in interfaces or passing around name/value pairs as HashMaps. In some cases, it has been a programmer taking shortcuts, in others, it's been a deliberate design decision.

What's notable though, is how few bugs it has caused. And the bugs that did occur usually were trivial to find and fix.

I've also been investigating some dynamic language frameworks (Ruby on Rails, Django), and although the scope of the projects has been small, I haven't seen a huge cost due to the use of dynamic typing. Although more type-related bugs occur, as above, they are easy to catch and fix.

From an academic perspective, the guarantees of type correctness sound nice, but in my experience, they don't provide much practical benefit. Systems like pike with dynamic typing with optional constraints has the best balance, IMHO.

Heard it all before....

[kaffiene]

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.

Java is omnnipresent in the marketplace and contra the usual /. 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.

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 /. editors' own bias against the language.

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 /. will be the language to do it.

Re:Heard it all before....

[kaffiene]

"Although I would say it is 'dying'. In some domains of programming, it is not even a contender:
- Java Applets are being replaced with Flash, Ajax applications.
- The flood of new Ajax applications are being built with productive agile languages.
- Windows Applications are being built with Native toolkits, i.e. COM+/MFC,.NET Windows.Forms, QT, GTK, Obj C, etc."

(1) Um. No-one uses Java Applets. They were a 'neat idea' a decade ago - they're not "being replaced" - they're long gone. Java went on and made new ground after applets were dead and buried.

(2) Ajax is not an opposed-to-Java-technology - Java works fine with Ajax. You still have servers with Ajax, servers is a space that Java owns. Jeez, even Sun's Java Studio Creator 2 tool (free) supports Ajax directly.

(3) Native windows apps? When has that *ever* been a space that Java owned?
If anything, the Java desktop story is improving - it's gone from non existant to a small presence.

I mean, you raise Web2.0 like somehow that's opposed to Java? What the hell? A language which has been designed to work on the web from the get-go is hardly going to suffer because of Web BUZZWORD two dot oh.

Re:java growing old....

[kaffiene]

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.

Re:Python

[kaffiene]

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.

For christ's sake - would people stop making these STUPID comparisons?

Java is not designed to write "hello world" in one line or less, it's designed to solve big, complex problems quickly, safely and maintainably. Look at something like checked exceptions - that's a PITA if all you are concerned with is a quick scripted hack, but it's important when you're writing huge systems that need to be resilient in the face of the unexpected.

Java IS NOT A SCRIPTING LANGUAGE. Stop comparing it to one. Java properly contrasts with C, ADA or C++

Re:Ruby's Quite Nice, Really

[hepwori]

Java's BNF has 64 productions, Ruby's has 44.

And you conclude that from those buggy BNFs you linked to? Or something else?

The import statement BNF you linked to gives the OK to

import foo.bar.*;;
import foo.baz.*;;

but not

import foo.bar.*;
import foo.baz.*;

Nice.

I'm not disagreeing or agreeing with your assertion about language complexity, but linking to crap like that isn't going to bolster your case.