Hate COBOL, not Java?

August 13, 2012

Another stinker from jelastic, this time on how Java’s not that bad:

So next week someone will invent another DSL that makes Twitter easier to use, but your bank will be writing new COBOL to more efficiently transfer funds to another Bank. We’re embarrassing ourselves with our petty arguments.

So, because some industries are still using COBOL, we should stop advancing the state of the art, which involves moving onto more modern languages than Java, and go help out these poor billion-dollar industries get into the cloud?

End of Rational Discourse?

August 10, 2012

Steve Yegge has an interesting post up, that classifies programmers along the conservative-to-liberal axis (which is, ironically, completely useless in classifying real people’s political feelings):

I think that my conceptual framework gives us an “out” – a way to avoid being emotional about these subjects. Casting the problem as a clash between Liberalism and Conservatism gives us the ultimate ticket for “agreeing to disagree”.

The way to avoid being emotional is to…avoid being emotional. I think that casting the problem as some unchangeable political “stance” is lazy thinking, and gives use the ultimate ticket for avoiding any real discussion. This way of thinking seems most useful in dismissing arguments one doesn’t feel like thinking too hard about.

Honestly, if you can’t have a real discussion about the pros and cons of e.g. static typing, you either have a lot to learn, or are not a very capable developer. If your best answer to “Can we use Ruby on this project?” is “oh, we’re Conservative, so…no”, then you are either have a lot to learn or you are an asshole. If you refuse to even discuss what the benefits of explicit, yet verbose code are over implicit, but compact code, then you are either have a lot to learn or are an asshole1.

As developers, we’re blessed to work in a field full of objective truths. To avoid seeking them out under the guise of immutable political stances is the epitome of anti-intellectualism.


  1. 1I would make the same conclusion for the opposite: you should be able to discuss the benefits of implicit, terse code over explict, verbose code, too.

Running Stock

August 02, 2012

One of my fellow developers asked me the other day if I had any good dotfiles for bash. I realized I don’t. I don’t even have ll aliased to ls -l like most of the known universe. I realized that I like to run as stock as I can.

Hungry Academy graduates

July 30, 2012

An article in the Washington Post gives a good summary of Hungry Academy, LivingSocial’s experiment to train 24 motivated people to become fully-functional developers in just five months. They worked hard and all graduated last week, starting as official developers over the next week.

The benefit, if all goes according to plan, however, is a fleet of engineers that can be hired en masse with a commitment to work at LivingSocial for at least 18 months. Unlike fresh hires, the academy students are already familiar with the company’s products and culture.

The 2-3-week-long projects they delivered over the course were impressive enough, but given that many of them didn’t have any professional programming skills beforehand, their progress has been amazing to watch. The first half of this grand experiment is over and it was a rousing success. The second half - how well they succeed in the actual work environment - begins now. I’m optimistic.

Six languages to master

July 29, 2012

This post, by Michael O Church is an excellent post on being a better programmer and full of a lot more awesome than the title implies. You need to read the entire thing. After he makes the case for which five programming languages to learn, the best stuff starts when he makes his case for the sixth:

The sixth is one that very few programmers are willing to use in source code: English.

He rightly defends comments and documentation:

Most problems are custom problems that require documentation of what is being solved, why, and how. People need to know, when they read code, what they’re looking at; otherwise, they’re going to waste a massive amount of time focusing on details that aren’t relevant.

And makes very salient points about depending on IDEs to develop. This is one of many, but my personal favorite:

If you’re IDE-dependent, you can’t write code outside of a corporate environment, because when you go home, you don’t have a huge support team to set the damn thing up.

Really great read.

A world without nil

July 25, 2012

Previously, we saw how just using functions in Ruby, we could create a lot of powerful code. Let’s continue the theme of “programming with constraints” and try to solve an actual problem. nil.

Adventures in functional programming with Ruby

July 17, 2012

The following is an aimless journey through a degenerate form of Ruby, in an effort to learn a bit more about functional programming, simplicity, and API design.

Suppose that the only way we have to organize code in Ruby is to make lambdas, and the only way we have to structure data are arrays:

square = ->(x) { x * x }
square.(4) # => 16

person = ["Dave",:male]
print_person = ->((name,gender)) { 
  puts "#{name} is a #{gender}"
}
print_person.(person)

This is the most bare-bones essence of functional programming: all we have is functions. Let’s write some real-ish code this way and see how far we get before it starts becoming painful.

What is 'better' code?

June 27, 2012

We all want better code. Rails creator David Heinemeier Hansson said that the only way to evaluate a code change is if the new code is “better” than the old. Of course, he didn’t define what he meant by “better”. At Scottish Ruby Conf, Dave Thomas said that good code is code that is easy to change. This is a bit more specific, but not really enough to give any real direction.

Let’s see if we can derive a real understanding of code quality.