Funny, some Rubyists are stupider than a piece of wood

“My language can beat up your language” is a game played by school kids. Adults are busy putting bread on the table, and will gladly reach for whichever language does that best today. If it’s Ruby, fine. If it’s Java, that’s fine, too. And if it’s not Java, but the boss is paying better for Java today, then… well… I like bread on the table. Because it’s a grown-up world out there, full of Turing complete languages that are mostly good enough to do the job, and that all pretty-much suck in varying ways and are pretty-much great in other ways. I do have my preference, as we all do, but that preference doesn’t make my favorite language necessarily better. It makes it comfortable and broken in, like a favorite pair of shoes. It doesn’t give me blisters anymore.

The most important thing about a language and a platform is that you know it well. Because the language that you know very well is mighty and powerful, no matter how much it sucks compared to the much better one you don’t know at all.

Chuck Yeager said, of pilots and planes, “It’s the man, not the machine.” It’s just as true of programmers and languages.

Stephan,

It was meant to be a joke, I was not expecting anyone to get angry ‘cos it’s a really stupid argument to begin with. That’s why I wrote it, to people to have a laugh. Laugh at the examples, laugh at me or laugh at the inherent stupidity of it.

As you say, on the readability issue, let’s agree to disagree on that one :-)

@Chintana: Ah, didn’t sound like a joke. And reading your post again – well it still doesn’t sound like a joke.

“From time to time, if you feel the need to piss someone off for their own good, let me assure you that it’s a perfectly natural thing. [...] if the pissee uses a big stupid language and actually LIKE it. [...] Because there’s a very high probability that the other person, yes, the one who’s using a big stupid language, will get so angry and beat you up.”

I agree with Wayne. Somehow this reminds me of the movie “Ronin”:

Spence: They [weapons] tend to settle the argument. So what do you favor?
Sam: Well, you know. lt’s a toolbox. You put the tools in for the job.

Chintana: Languages tend to settle the argument. So what do you favor?

It’s a toolbox…

I thought someone would react to this like “right, he talks about pissing people off, particularly Java programmers, and then goes on to describe how to piss off by making the argument “my language is better than your language” ha?! how stupid is that??” So, at this point you either stop reading, laugh at my stupidity and carry on with your life. That’s what I thought would happen.

The paragraph you quoted was me building up the story, it’s meant to invalidate as soon as one read the argument about *how* to piss off. It was not written in a sadistic kind of way you know. BTW, who would go on as far as to beat someone up about a stupid non issue like this?

So Stephan, I apologize if I’ve mislead you. It was not intentional. Also, I do use Java from time to time.

Yeah agreed. If java was rebuilt from the ground up today by engineers who had worked with nicer apis it would be much, much easier to program in.

That said, theres something most rubyists get angry over: renaming a class! Or better, renaming a method. Lets time a java developer refactoring a method name vs a ruby developer and see who wins.
Thats why I left ruby behind and didn’t miss it at all.

Since the majority of programming isn’t writing but maintaining, I think you have a clear winner! :)

@ben: Yes, refactoring is a problem. That together with mostly bad documentation and immature code completion and runtime errors is the reason I don’t do Python or Ruby any more (and I did a lot and was a strong proponent).

IDEA might change this and solve some of the problems. Refactoring and IDE error checking will be better in the future with Ruby when the IDE listens to the runtime VM for clues on method calls etc.

But who knows, Java might get closures and Scala like type inference, or even move to Groovy style references on the other side.

Rewriting the Java API? Yes it would be easier. Java was mostly build with a 1995 understanding of APIs. That shows in a lot of ways (especially with I/O, Collections, String). Looking at JMockit and Google Collections, the idea what a good API for Java is has changed today. For now it’s best to write some small wrappers for your project to make the JDK usage easier.

“Since the majority of programming isn’t writing but maintaining, I think you have a clear winner! :)”

I think this is a huge argument that gets often neglected. I know some Ruby CTOs who have a maintenance problem with their code, now after 5 years and > 20 developers.

A line of code is usually written once but maintained dozens of time. As said above, integration an IDE with the runtime VM for information gathering could solve the maintenance problem in dynamic languages.

Ruby development is best done with automated full coverage testing of the code. That’s how you are able to maintain a large code base over time, have ownerless code, and do all these other things that make money flow into a company.

Why is Ruby (as are other dynamically typed languages) so dependent upon testing? A language with dynamic typing is giving up something over a language with strict static type such as Java. Static typing is actually a type of unit test specified by the programmer in the code and executed by the compiler every time you compile. You lose that in a dynamically typed language. It’s the price you pay for the flexibility of a dynamically typed language. If you don’t build a framework of tests to make up for having given up the safety of static typing, you’ll find yourself afraid to refactor, paralyzed by the fear of introducing bugs. Each refactoring must be tested manually by the programmer. That becomes too tedious to keep up as the code grows, so programmers either aren’t able to keep up the testing, and refactor without testing all of the things they’ve changed (introducing bugs), or knowing that they won’t be able to keep up with manually testing the changes, they don’t refactor (and the code grows crufty).

But if you’ve got a test framework, you’ve got much better than knowing that the types match, which is what strict typing gets you. You know that the functionality is correct, too. You’ve got what you should have had all along back when you were working in Java. Go ask the Java guys. The smart ones do unit and functional testing, too, and although the tests take whats seems like a horrendous amount of time to maintain, their productivity shoots through the roof because the amount of time spent chasing bugs goes way down. And the code gets clean because nobody is afraid to refactor anymore.

So, again, it’s not really about the language. It’s about what you do with it. If you’re using Ruby, testing becomes very important for anything bigger than a “git-er-done” script. But you wouldn’t be sorry to be doing testing no matter what language you’re using.

Stephan,

While you are trying to make a point, you are being incredibly disingenuous. that line… the one you wrote in java. it is not a java program and will not run.

1) you need a main,
2) you need to import File from the java.io package.
3) There is no open method on java.io.File.

I don’t know what you are playing at, but it is really kind of sad.

Ruby can act as a scripting language and therefore you can do things in one line. There is no one line program in Java. You need a main, etc. to do anything. It’s really a scripting language issue.

The other thing I am curious about is why you are trying writing code that is not Java (e.g. File.open). Are there no Java programmers who read your blog?

Cheers,
Jeff

@Jeff:

“1) you need a main,”

Of course you need a main, but if you want scripting in Java, it’s 10 lines of code to write a shell starter which wraps your java code into a main method.

“2) you need to import File from the java.io package.”

Most scripting languages need some way of import too. The imports weren’t the linked post point.

“3) There is no open method on java.io.File.”

This is“my 20min Java version”. Of course this is new code, otherwise it wouldn’t have take 20 minutes, just 10 seconds to write this line.

As I’ve also written “And because someone asked: No this cannot be done with the JDK, therefor it’s an API problem. You need to write some code on your own to fluently wrap JDK classes.” So no, the example File is not from the JDK, it’s my own code. That was the main point. The oneline is Java, but cannot be written with the JDK because it’s an API design issue, not a language issue. If only the JDK is legal ground to use, then Ruby couldn’t do database or web access, it’s not part of the Ruby core.

Before calling me “incredibly disingenuous” it would be better to read a blog post one comments on.

The point of the blog post I’ve linked was that you cannot write this line in Java. Well you can. The code is Java and runs and works as advertised.

hahaha.

So, because you wrote some code to:
(a) create a shell
(b) create a File Object (that behaves NOTHING like a java.io.File object – this is not clever at all. This would fail code review everywhere I have worked – you don’t do this)
(c) the File Object also swallows all exceptions (poor java form)
(d) You really have to admit that no Java Programmer would recognize that “one line” as Java code. That is completely orthogonal to the patterns in all Java I/O.

So, this ONE line of Java code that you have written needs ~ 50 lines to run on someone elses JVM…

THAT is the point. That one line of Ruby code from the stupid ruby developer actually *does* run on every ruby implementation without anything extra.

You are kind of proving that bloggers point – to get to the “one line solutions” it takes a good ruby developer about 14 seconds to type that. Took you (or any other Java developer) the 20 minutes to create the extra stuff to run the one line. So, you can spend the 20 minutes to do this, or the 5 minutes to do it in straight java code. Either way, orders of magnitude more time – that was the point of the other blogger.

@Jeff: [cut a lot which has nothing to do with the point at hand that the code cannot be written in Java]

c.) Well, the File object could return Eithers or Options instead of Exceptions, thought about that?

d.) Well I would. Lots of others would too. All JMockit users for example. All people who use method chaining in Java.

[cut another 10 lines of code which are a straw men attack and have nothing to do with the topic]

Perhaps it would be best to read the linked blog post again. The point was: The oneliner cannot be written in Java. It was written in Java by me. QED. All lamenting doesn’t change the fact.

20 minutes? Where is the problem? I’m working on projects for months. What’s 20 minutes to write a custom DSL if you need to often deal with File operations? Perhaps there is an open source framework which already does this? Every argument in your comment has nothing to do with the point at hand – that the one line couldn’t be written in Java.

What’s 20 minutes to write code? A line of code which is written once, will be read a thousand times in the next 10 years.

How long it takes to write code does not matter when it’s 20 minutes once. The problem is not only productivity when writing code, but also when reading and fixing the code a thousand times.

[...] Productivity in software development « Funny, some Rubyists are stupider than a piece of wood [...]

Jeff,
I am a “Java” developer and i totally understood what Stephen was doing and how it worked. I actually did the same sort of thing in VB (wrapped their code in objects) before they came out with their file objects. Why would his code fail all code reviews? Because he made a better File object?

What Stephen did is EXACTLY how Hibernate Criteria queries work.

Stephen could very easily open source this and share with others.

And no, his code does not have to swallow exceptions. He can convert them to runtime exceptions just like a lot of other API’s do.

It seems to me that most Rubyists are incredibly disingenuous by using silly examples to prove how much “productive” Ruby is and totally ignoring the full development lifecycle.

FYI the method “gsub” would fail most code reviews.