Java

This side-by-side comparison of Java and Python shows why I prefer working in languages like Python and Ruby: the “yak shaving” that Java requires drives me crazy.

Tagged as: comparisons, Java, language wars, Python

{ 0 comments }

The blogger at willcode4beer says in 17 Thousand Reasons I’m not a Ruby on Rails Developer that the median salary of Rails developers is on average $17K less than that for J2EE developers. I’m not worried — the pay at TSOT for RoR development is on par with the J2EE rates cited.

The article also suggests that “to bring salaries up, they need to drop the ‘easy’ part. Development is hard, and no language or platform is going to change that. We solve complex problems. Complex problems are hard to solve. period. They should focus on the productivity gains in the areas where Rails shines, and try to avoid the areas where it doesn’t.”

Tagged as: comparison, J2EE, Java, money, Rails, Ruby, salary

{ 0 comments }

One lesson that Nathan Weizenbaum learned from Java that makes him a better Ruby programmer: “I learned what I was abstracting. I learned what blocks are, why dynamic typing is useful, what it means to redefine an operator. And I learned it from Java, by doing without.”

Tagged as: being well-rounded, interdisciplinary, Java, learning

{ 0 comments }

Java’s nickname, “The New COBOL”, as a badge of honour: “…considering COBOL’s standing in the industry: It’s not clear that being the ‘new COBOL’ is actually a bad thing. It may not be glamorous, because people see COBOL programmers as being outmoded and uninventive, but COBOL is far from dead.”

Tagged as: Java

{ 0 comments }

Tim “Ongoing” Bray’s Take

Tim Bray posted a blog entry on what drives adoption of a language in which he included some tables such as the only below:

	Flawed Founders	Polished Successors
Procedural	FORTRAN, COBOL, PL/1	C
Object-Oriented	C++	Java
Higher-Level	Perl, TCL	Python, Ruby

This table of his should inspire a monkey knife fight on a number of blogs:

	Flawed Founders	Polished Successors
Web-Centric	WebObjects, ColdFusion, ASP.Net, Struts, etc., etc., etc., PHP	Rails

Here’s an interesting one. What will JavaScript’s successor be? My guess for the short-term (by that, I mean “the next half-dozen or so years”) is “the next version of JavaScript”.

	Flawed Founders	Polished Successors
Mobile-Code	JavaScript	?

The one about concurrent programming is a little more up in the air. Although there are other languages designed with concurrent programming in mind (either from the ground up or with concurrency retrofitted onto an existing language) and there have been for a while (I used Concurrent C in a course back at Crazy Go Nuts University in the early ’90s), Erlang is getting a lot of the attention these days since it has both a success story at Ericsson under its belt as well the clout of a Pragmatic Programmers book behind it. There is a feeling among some programmers (Bray included) that it isn’t going to be the language to turn concurrent programming from arcane art into mainstream practice:

	Flawed Founders	Polished Successors
Concurrent	Erlang	?

Shelley “BurningBird” Powers’ Take

Shelley Powers disagreed with Tim’s assessments in her posts Flaws are in the Eye of the Beholder:

I find it fascinating when a person marks as ‘flawed’ the languages that have, literally, defined not only the web but application development of all forms. Perhaps the metric shouldn’t be on syntax, form, or function, but on usability.

Here’s her own table on languages:

	'Perfect', but barely used	'Flawed', but simple, approachable, powerful, popular
Higher-Level	*Ruby (every time I see 'Ruby' I mentally add, Mama's precious little…) *I’m giving Python a slide because Python has fairly widespread use today.	Perl
Client side code	(The to-be-created scripting language that will take a nice, clean, easy to use language and morph it until it satisfies the purists, while breaking faith with the millions of users just trying to do a job)	JavaScript
Object Oriented	Java (bloated beyond recognition with senseless additions and overly complex infrastructures)	C++ (which can kick Java's ass performance and resource wise)
Web-Centric	Rails (you know that thing they used for the one application?)	Cold Fusion, ASP and ASP.NET, PHP

Those of you who recall Bjarne “C++” Stroustrup’s line “There are just two kinds of languages: the ones everybody complains about and the ones nobody uses” or the essay Worse is Better (or the essay that led to it or Jamie Zawinski’s commentary on it) should be feeling deja vu now.

As for Shelley’s table, I’d probably have put “PHP” where “Perl” is right now.

My Own Take

I think that right now, the “scripting languages” are stuck in something akin to “Three Stooges Syndrome”. That’s the disease where Mr. Burns from The Simpsons, being so old and frail, has so many diseases trying to get at him at the same time that they’re all “stuck in the door”. The doctors illustrated the syndrome with a model, shown below:

And since Tim and Shelley have their tables, I thought I’d make one too:

Tagged as: Java, JavaScript, PHP, Python

{ 0 comments }

Seems Like Old Times

Back in December 2005, I wrote a blog article talking about the blog shooting war between Java and Ruby advocates that erupted over which approach was better: the one taken by Java with java.util.list or the one taken by Ruby with the Array class.

It’s interesting to see that nearly two years later, not much has changed — now we have a shooting war over Obie Fernandez’ blog entry, Top 10 Reasons Why Java Sucks Ass. I’ll write about this shooting war in a future article — in the meantime, for the sake of reference (and because the blog in which the article originally appeared in about to disappear), here’s my “Monkey Knife Fight” article from December 9, 2005.

The Original Article

Of late, I have been applying the term “Monkey Knife Fight” to language and architure wars among programmers. There’s something about them that reminds me of having two monkeys, each armed with a stilletto knife, squaring off while cheered on by a rabid crowd. I suppose that the major difference is that unlike monkey knife fights, you can glean some knowledge, understanding and even cooperation in the aftermath of a language war.

The particular monkey knife fight I am referring to starts in an entry on Martin Fowler’s bliki (bliki being a blog and a wiki), where he talks about two schools of thought about programming interface design:

• What he calls the minimalist approach: just provide the basic building blocks and leave it to the programmer to build what is needed. “Minimalists tend to focus on the minimal set of necessary methods to support these behaviors,” he says.
• What he calls the humane approach: design the interface so that the most common-case uses are easiest. He writes: “humane designers try to add methods that are needed. Often these extra methods are referred to as convenience methods, a term that minimalists do not consider to be a complement.”

He compares two similar structures: Java’s java.util.List with its 25 instance methods and Ruby’s Array, which has a hefty 78. He then shows us what it takes to fetch the last element of a Java List:

myList.get(myList.size - 1)

While in Ruby, getting the last element of a list is simpler:

myList.last

Elliotte Rusty Harold, author of a lot of books on Java and XML, disagrees with Fowler. He’s of the “less is more” school and wrote:

A 78 method List class is about three times as bad as a 25 method List class, not three times as good. A 12 method List class would be about twice as good.

…

Java’s List class does not lack any of the functionality in Ruby’s. Java just factors it out into a few more classes, especially the Collections class, and skips a couple of rarely used “convenience” methods. The result is a simpler, easier-to-understand, easier-to-use, more humane API.

And thus the monkey knife fight began, with a much excitement from the spectators:

• Martin Fowler’s original post
• Elliotte Harold’s response
• James Robertson, a Smalltalk guy, chimes in: “We are far more interested in solving application problems than we are in the production of extra code to support sparseness.”
• Cees deGroot: “My favorite analogy here: the difference between a human and a donkey is maybe 5% in genes. I like to think that a good object system works the same - the difference in behaviour between my classes, if you count everything they inherit, is typically 1-5%. Just a handful of methods, with usually a couple of lines of code because the base classes are so rich. Now, that is where simplicity rules.”
• Antonio Vieiro: “Each programming language has its idioms, and an API that follows those idioms is a simple API. An API that tends to be ’simpler’ and make things against the idioms is an API that makes things more difficult. As Elliotte says the more the buttons the bigger the difficulty. So that’s just my opinion: I like simple things, but not ’simpler’ things (because those are more complex to maintain).”
• James Higgs: “All of this makes it more frustrating that System.String does not have convenience methods like .Right(int length) or .Left(int length). It’s easy enough to do using .Substring(int startIndex, int length) - it’s just that reading that code takes a little longer, as indeed does writing it. And, of course, string is sealed, so we can’t subclass it.”
• Peter Williams: “Each of those decisions [to keep an interface minimal and let developers write a little extra code] are reasonable in isolation but put together pretty soon you and your community are stuck with a lot more code to maintain than if that behavior had been included in the core library to start with.”
• Cedric Beust: “Humane Interfaces clearly violate both YAGNI and the “do the simplest thing that could possibly work” principle, so I’m quite happy to see them gaining traction. For these same reasons, you can expect XP advocates to come out strongly against the idea of Humane Interfaces (and Elliote is leading the charge), which probably guarantees that they will become mainstream in no time :-)”

  [I rather like the graphic he included, shown below.]

  

• John D. Mitchell: “Alas, arguing back and forth over those sorts of details makes it easy to miss a fundamental, crucial point: no software (library, application, language, operating system, or whatever) can be all things to all people. Fighting that war is not only pointless but is one of my definitions of insanity. The point of a chunk of good software is to enable the effective and efficient creation of more good software and to help inhibit the creation of bad software.”
• Stuart Roebuck: “Finally, if I’m going to agree with Elliotte at all, I guess I should express doubt in the value of method aliases. One of the values of Java over C is that it provides fewer ways of expressing the same thing. I can’t see any great value in having two methods with different names that do exactly the same thing. In a collaborative project it would inevitably lead to situations where code confusing uses of both method names for no apparent reason. On the other hand, aliases in the method documentation would be good, e.g. you look for a method length() and it says ’see method size()‘.”
• Elliotte Harold: Which remote would you rather use?

  

• John Tirsen: “If your requirements on that class library is to have a ‘humane interface’ then that is what should control how you implement that class library. So you implement each feature of the ‘humane interface’ in a YAGNI style. YAGNI doesn’t dictate what features you implement rather it dictates how you implement these features. The principle of ‘humane interfaces’ is what dictates what to implement.”
• Hitesh Jasani: “Perhaps the notion is that Java’s interface looks simple if all you do is look at Javadocs, but it is not simple if you actually try to use it. Ruby’s interface looks more difficult looking at the documentation, but turns out to be much easier when in use.”
• Blaine Buxton: “I like having a minimal set of methods to implement because I make sure duplication and cognitive friction is reduced. But, the users of the class wind up with terse code that’s harder to read than with a richer interface. It seems both sides of the argument will always be at odds. This is where I think concepts of object composition from prototype languages can help. Organizing Programs Without Classes is worth a study for it shows the way that we can have our cake and eat it too.”
• James Robertson: “Smalltalkers - and I think Rubyists - look at this problem very differently from Java folks. The Java people seem to like sparse classes, but they don’t seem to realize that sparse classes combined with an inability to extend leads to everyone creating their own set of utility classes. In Smalltalk, the useful protocol that people add tends to migrate up to the vendor over time…What we seem to have a two very different approaches to the class design problem. I think the Smalltalk/Ruby one is better, because it favors putting code where it belongs. The Java approach implicitly favors lots of utility classes.”
• James Robertson, again: “I like the way [Elliotte] baldly asserts that 78 methods [in Ruby's Array class] is "an atrocity". So what's the magic number? Is 22 methods ok, but 23 - heck no, that gets into atrocity range? There's absolutely no way to look at the raw number of methods and make that statement. He's assuming that there must be fluff in there - but that's an assumption, not evidence."
• Elliotte Harold: “I suspect there’s more middle ground between Fowler and me than perhaps some people realize. His essential point is “The essence of the humane interface is to find out what people want to do and design the interface so that it’s really easy to do the common case.” I don’t disagree with the principle. However we part ways on the practical application of that theory to class design.”

  [Be sure to read his examinations of what he considers to be extraneous methods for the Array class.]

• Charles Miller: “In Java, List is an Interface. In Ruby, Array is a class. The distinction may seem to be hair-splitting, but it’s important…java.util.List isn’t really a shining example of good interface design either.”
• Rob Lally: “Harold is wrong. Plain and simple. And I can prove it. The Ruby Array class is probably the most useful class I’ve ever had the pleasure of using. If it offends his aesthetic senses, then his senses are mis-attuned…He talks about the 80/20 rule in his posting. For me the 80/20 rule is about minimising the amount of work done. Minimal interfaces are great on objects that are only going to be used a few times. If a class is going to be used (in the case of lists/arrays ) 10s or 100s of millions of times then giving it a broader interface is by far the best choice.”
• Bernard Notarianni: “I think that Object Oriented programmers may look at the situation a little bit differently. 78 public methods are 78 different way to talk to an object. Actually, we don’t care what is behind the object, but a large set of methods is an opportunity to find the best one for the programmer purpose.”
• David Crow: He points to John Maeda’s “Rules of Simplicity”, a set of good ideas that programmers should take to heart.
• Ian Bicking: “But I think the Java guy has a point: 78 methods on your list objects isn’t good. Less methods is good. Unless the result is stupid. Now, let’s be honest here, Java is stupid. Dumb, idiotic, maybe written by people who aren’t programmers; I just don’t know how else to make sense of it. list.get(list.size() - 1) should be embarrassing. list.last or list[-1]? I think [-1] reads well enough, and fits into a very elegant set of functionality involving slices and whatnot. But I also think list.last is entirely justifiable. OTOH, list.get(0) isn’t embarrassing, so list.first isn’t as compelling. And the nitems method he points to really seems overboard.”

As for me, I fall closer to the Martin Fowler camp rather than the Elliotte Harold camp, largely based on gut instinct. All the setup you have to do to get Java to do anything of consequence drives me bonkers. Classes with a pared-down interface may be simpler, but not when I have to start linking them to all manner of utility classes to get them to do what I want. It’s not so much simplicity as it is sweeping complexity under the rug, where you’ll have to eventually deal with it. Working with Java, I feel that I’m always thinking “How do I get Java to perform task X?”, while with Ruby, it feels more like “How do I get this result?” With Ruby, I feel that I’m wrestling only with the problem, not the language.

I do have one complaint about the Ruby approach — method aliases. While it’s convenient for luring in programmers from other languages, I think it actually detracts from code readability to have two method names mean the same thing.

Tagged as: Java

{ 0 comments }

Possibly inspired by articles like Tim O’Reilly’s State of the Computer Book Market (here are parts one, two, three and four of the Q1 2007 edition of this series) posts on the O’Reilly Radar blog, Antonio Cangiano decided to do a little research of his own:

Technical books are a topic that interest me a lot. From book sale figures and trends we can attempt to better understand where developers are putting their money, not only their mouths. For this article I decided to perform a small experiment, by collecting some interesting data. I considered 23 fairly well known programming languages, and searched for the top selling book (according to Amazon) for each of them. The Amazon sales rank allows us to compare the success of books representative of each language, and indirectly compare the popularity of the languages themselves.

The Top Ranking Languages

According to Antonio’s research, here are the best-selling programming language books are for these languages, listed starting with the best seller:

1. JavaScript (JavaScript: The Definitive Guide, Amazon rank 1,227)
2. Java (Head First Java, Amazon rank 1,799)
3. Ruby (Programming Ruby: The Pragmatic Programmers’ Guide, Amazon rank 1,881)
4. SQL (Sams Teach Yourself SQL in 10 Minutes, Amazon rank 1,929)

To see the top 23 programming languages based on Amazon ranking, go visit Antonio’s blog entry.

A commenter on the article wrote:

Actionscript would rank even higher than JavaScript, since the book Essential ActionScript 3.0 by Colin Moock currently is at sales rank #346.

Interesting Languages

There are some interesting languages on this list. Although they get mentioned on Reddit and a number of developer blogs, they’re not quite mainstream yet. In spite of that, they’ve placed quite well based on Amazon’s ranking system:

• Erlang (Programming Erlang: Software for a Concurrent World, #12 on the list, Amazon rank 8,609)
• F# (Foundations of F#, #15 on the list, Amazon rank 21,273)
• Lua (Programming in Lua, #16 on the list, Amazon rank 23,052)
• Haskell (The Haskell Road to Logic, Maths and Programming, #18 on the list, Amazon rank 1,929)

[Cross-posted to the Tucows Developer Blog]

Tagged as: Java, JavaScript, SQL

{ 0 comments }

John Maeda at The Laws of Simplicity has an interesting photo of a lightswitch at Sun Labs:

Click the photo to see the original.

He writes:

I gave a talk at Sun Labs where I encountered a special light switch in one of their conference rooms. At first I thought it was some kind of silly “engineer” joke. But the light switch functions as stated for real. Does it win the award for the most confusing light switch? I bet there are other ones out there that are equally complex to use.

The lightswitch design philosophy at Sun is quite clearly reflected in Java.

Tagged as: Java, Sun, User Interface / Usability

{ 0 comments }

It hasn’t even been a year since Sun hired JRuby contributors Charles Nutter and Thomas Enebo to work on it full-time. It’s been an even shorter period since Ola Bini (whom I had the pleasure of meeting at RailsConf 2007) got hired to do the same by Thoughtworks.

In that short span of time, they’ve done something impressive: they (and all the other contributors involved) have brought JRuby to version 1.0.

According to InfoQ:

The release is being termed as “Ruby compatible” with all known JRuby bugs causing incompatibilities with Matz’s Ruby (MRI) resolved. Applications should “just work” out of the box.

Here’s InfoQ’s summary of Charles Nutter’s roadmap for JRuby post version 1.0:

• Performance:
  In the last year speed has been increased by an order of magnitude and a JIT compiler has been enabled. The team will continue to work on improving the JRuby speed and performance.
• Java Integration: Today libraries can be called, interfaces implemented, and classes extended. Edge cases exist however. A redesigned integration API is targeted for 1.1.
• Ruby 2.0 and Rubinius: The goal is to support Ruby 2.0 and Rubinius byte code execution soon.

We at Global Nerdy would like to congratulate the JRuby (and NetBeans) teams on a job well done. We salute you with a filet mignon on a flaming sword!

Tagged as: Java

{ 0 comments }