So, the responses are coming in on my rant about Real Programmers, and I have to say the responses are disappointing. But what was surprising was what people latched on to, in order to prove that I was, in fact, a “Real Programmer” myself- my aside on my interview question.

There was a reason I picked that as my first interview question. If I’m interviewing you, it’s for a programming position. And the first, and most important, qualification for any programming position is the ability to actually program. I picked a problem that a) everyone who has had any training what so ever has been given a solution to, b) can be implemented in any language, and c) is fairly short. If my walking into the room and going “OK, so you’re applying for a position a programmer- write some code” causes you to panic and freeze up, I’m sorry. But the purpose of the interview is not to make you feel all warm and fuzzy about yourself, it’s to determine whether you’re worthwhile hiring.

And yeah, every once in a while this will cause me to toss back a programmer that should be hired. Guess what? I’ve blown interviews as well. It happens. There are other fish in the sea- on both sides of the table (both other good programmers to hire, and other good jobs to get).

But what really struck me about the responses to this was how unfair it was. It favored people freshly out of college, as one commenter on the original article said. Bwuh? You can’t even remember something as simple as bubble sort? But this was the clue to the heart of the problem, I think.

Those objecting to my post were packers. I’m thinking like a mapper. I want to quote the original Programmers Stone here:

As software engineers, we might describe learning as forming associations between referents. The sky is blue. The rain in Spain falls mainly on the plain. We might call these learned facts `knowledge packets’: little bits of truth (or errors) that we possess.

One can go a long way on knowledge packets. Early learning (as directed by adults) for most children focuses almost entirely on the acquisition of knowledge packets. Things that one should or should not do. Methods for performing tasks. Data to be retained and later recovered on demand.

This is exactly how the respondents were treating the sorting question: as a information packet. A method for performing a task, to be recovered and regurgitated upon demand. This is what made the question favor the newly graduated: they had memorized the prepared answer more recently.

If you believe this- that the reason they taught you sorting back in college was just give you a knowledge packet, you missed the point. What they were trying to teach you was generalized problem solving techniques, and they were just using the specific example of sorting and searching to do it.

Take, for example, divide and conquer- take a complicated part, split it into two smaller parts, solve the smaller parts, and then recombine. This is an incredibly powerful technique, and not only for algorithms. It’s also a real good design pattern- split the big, complicated, unsolvable problem into two smaller problems, and then solve them. This is a principle every programmer should be aware of. Now, apply it to the problem of sorting a linked list: OK, we’re splitting the list into two, and then recombining the two parts, sorting the sub-parts, and recombining. On what basis should we split the lists? If we split the list into the first n/2 elements, and the rest of the elements, then we’ve reinvented merge sort. If we split the list into those elements above or below some given element, we’ve reinvented quick sort. If we split the list into the first element and all the rest, we’ve reinvented insertion sort. You don’t even need to remember the algorithms in particular, if you remember the general principle you can reinvent/rediscover them at speed.

But, of course, if you treat the whole exercise as just a question of storing and retrieving the right knowledge packets, it’s a trick question. Either you’ve memorized the right answer, or not. And that by asking the question, I’m just trying to prove I’m a better programmer than you, on the basis that I know the answer to the trick question and you don’t. When what I’m really trying to do is just see if you have any understanding of programming. And, as of this writing, whether you’re a mapper or a packer.

Popularity: 5% [?]

So, when Robert started talking about his April Fools joke post, I immediately thought of the classic essay “Real Programmers Don’t Use Pascal”. It was a take off of a book that was a seven day wonder at the time, entitled “Real Men Don’t Eat Quiche”, which was a funny-once sort of book.

Parts of the “Real Programmers” article didn’t age well- most of the languages discussed (Pascal, Fortran, Cobol, Assembler) are, by and large, irrelevant and unknown to most professional programmers today. Most programmers today don’t know flow-charts, and don’t hang out at beaches doing anything, because most beaches don’t have wireless.

I would, however, argue that the Real Programmer is alive and well- indeed, he (and it is almost always a he) is even more prevalent today than he was in 83. Aspects of being a real programmer have changed, but the core attitude and nature of the Real Programmer remains. Indeed, in many ways the modern Real Programmer is worse than the original. The original breed still remains, mainly doing C++ these days. Meanwhile, a new breed of Real Programmer has arisen, and found a home in languages like Ruby. Some of the aspects changed, but the attitude DNA remains the same.

By the way, the date as I write this is April 3rd, and I’m being deadly serious.

Continue Reading »

Popularity: 12% [?]

Wow. Continue Reading »

Popularity: 6% [?]

Just like last year (cite), I’m cataloging some of my favorite April Fool’s jokes.

Google has triggered the singularity by giving the internet sentience: this is its home page. The technical specifications include a picture of Descartes and other fun stuff.

Help Save the Best Browser Around: Save IE6.

Popularity: 4% [?]

After a whole lifetime of ranting against it (cite, cite, cite, cite), I finally have to eat my words, come out, and say it: Ruby is the language of the future.

Now, I don’t specifically mean Ruby itself will be the most used language in the future, but I believe Ruby is the future now like C++ was the future in the 80s — all mainstream production languages that come next will be, at their heart, a Ruby derivative. And it’s easy to see why.
Continue Reading »

Popularity: 18% [?]

I wanted to share this tidbit n how to do salted and hashed passwords in Grails. If you don’t know why you want to do this, read Never store passwords in a database!. More on salting is available at Wikipedia’s article on Password Cracking.

To be smarter about passwords than the Reddit developers, first install the Crypto plugin via: grails install-plugin crypto. More information on the Crypto plugin is available on the Grails website: Grails Crypto Plugin Documentation.

I tend to then structure the password part of my application user class to look something like this:

import static cr.co.arquetipos.password.PasswordTools.*
 
class AppUser {
 
  static transients = ['password']
 
  String passwordHash
 
  boolean checkPassword(String password) {
    checkDigestBase64(password, passwordHash)
  }
 
  void setPassword(String password) {
    passwordHash = saltPasswordBase64(password)
  }
 
}

Once that’s done, you can execute code like this:

def user = new AppUser()
user.password = "foo"
assertTrue user.checkPassword("foo")

Note that this won’t work:

   assertEquals "foo", user.password // Fails because the 'password' property can't be found

Using this approach, the password is not stored in the database, or even in a transient property in the domain object. This minimizes the tendency to do something stupid (like e-mail the password in cleartext).

Popularity: 5% [?]

Most anonymous inner classes are really closures at heart, the same way inversion of control is really monadic handling at heart.

Groovy, recognizing this synchronicity, allows you to coerce a closure into an interface implementation via the as keyword. For instance:

// Groovy way of expressing the natural comparator
def c = {a,b -> a <=> b} as Comparator

Interfaces with multiple requirements can be implemented by constructing a map of string names to closure implementations, and then coercing the map via the as keyword.

So there’s really no need for anonymous inner classes. They’re theoretically coming in Groovy 1.7 in order to appease the Groovy-as-superset-of-Java sales pitch, but I wish Groovy would stick to its guns — the coercion is a lot nicer, and reveals what’s actually going on in the code: a function or two is being defined and passed around.

(Since it was noted that there’s no Google hook for this trick, I’ve decided to share it in the hopes that it will be picked up. “Anonymous inner class” or “inner class” for “Groovy” and “Grails” should really link to this stunt.)

Popularity: 8% [?]

Back in My Fundamental Issue with Ruby, I complained about Ruby’s types without the ability to work with/understand types.

Just had another example of the issue. I’ve got this code:

path = ['foo', 'bar', 'baz']
msg.step = path.shift
if msg.step == 'foo'
   # Do something smart
end

The problem was that the “do something smart” line was working just fine, and then strangely wasn’t ever being hit later on. WTF?

Turns out the issue is that “msg” is an ActiveRecord instance, and “step” changed from a string type to an integer type in the database, so when I assigned a string to “step”, it silently stored it as 0.

Seriously, either be typed or don’t be typed. It hurts to sit on the fence like this.

(In more positive news, I note that Rails is really a slick system these days, with the exception of its ORM. I’m taking notes for a Grails vs. Rails blog post coming up, which I hope to be more constructive than my previous forays into the area.)

Popularity: 8% [?]

So Lawrence Lessig, who I have a huge amount of admiration for, is advocating that we, the small time internet-centric donors, go on strike, and refuse to donate any more money to any candidate who doesn’t support public financing of campaigns. For Lessig’s side of the issue, see here.

I’m not joining the strike- in fact, I think it’s a terrible idea and one that is liable to backfire on it’s proponents. Follow me below for why.

Continue Reading »

Popularity: 3% [?]

So, two different posts crossed my transom recently, that I felt I had to respond to. First, and most egregiously, there’s The Daily WTF’s Programming Sucks! Or At Least, It Ought To. Then there is this blog post on Why Functional Programming Doesn’t Catch On.

I am of the opinion, having covered much of the computer industry one way or another, that there are no non-trivial, uninteresting problems. The reason is just this- any problem that is boring, trivial, and/or mechanical should be done by the computer. I mean, come on, people! We’re programmers. If anyone anywhere should be able to harness the power of computers to make our work easier, it should be us programmers- the ones harnessing the power of computers to make everyone else’s work easier!

If programming sucks, it’s because we’re being incredible stupid. Five lines of code duplicated over and over again, just to set some UI properties? Dear gods, people. Hasn’t any heard of subroutines? Abstraction? How about straight up code generation, or maybe implementing a DSL? OK, maybe if you’re only replicating those five lines a couple of times it’s not worth the bother. But if you’re replicating (with minor variations) those same lines of code over and over again, it’s probably worth it to step back and consider how to abstract things.

Abstraction helps up the percentage of interesting code vr.s boring grunt work code, by minimizing the amount of boring grunt work code. If you can turn five lines of code, replicated ten thousand times, into one line of code, replicated ten thousand times, you’ve just turned a 50 KLOC project into a 10KLOC project, doable at least 5 times faster (and probably more like 25 times faster). Get the crap work out of the way fast, so you can get on to the more interesting stuff.

I’m not even talking about leaving your language of choice, I’m talking about thinking outside the box, or even just thinking. But learning new languages is an advantage in making programming not suck, because if nothing else, it gives you new tools for your tool box, new ways to consider abstracting the code. And some languages are better than others, and the more you know, the more likely you are to know a good one. And if you don’t know the better language, you can’t use it.

My initial response to the DailyWTF post was that it was another classic example of the starving child in Africa syndrome. You’ve seen the pictures. A child in some hell-hole of a third world, generally Africa but parts of Asia and South America qualify as well. The child is hungry, maybe starving, disease ridden, bug infested, and destined for a life that was nasty, brutish, and short. But they’re smiling away, happy as can be, simply because they don’t know any better. Everyone they’ve ever known, seen, or even heard of has been in exactly the same boat they are. That’s just what life is like. I often times think that many programmers are just like that staving child. They put up with, indeed don’t even see anything wrong with, having to write half a dozen lines of code just to set some UI properties, because they’ve never known any better. Bug ridden, virus invested, bloated, slow, impossible to maintain, that’s just what programming is.

The second post is convincing me that the situation is much, much worse than that. That it’s not just ignorance is the problem. It’s not just that many programmers don’t know any better, it’s that many programmers don’t want to know any better, and are looking for an excuse, any excuse, to stay ignorant. It’s as if that starving child doesn’t want food, and would reject food if offered.

The reason that post is causing to me think this is because I’ve heard this argument before. All of them. See, I lived through the last great paradigm shift, when the industry moved from Procedural to Object Oriented- and heard the dying remnants of the one before that, from unstructured to procedural programming. I’ve heard all these arguments, or should I say excuses, before- from people trying to avoid learning C++ and Java.

And excuses are what they are, because it impossible to jump through the hoops. For example:

• Any example of less than several thousand lines of code is a toy or a trick, and thus irrelevant. Real programs are tens or hundreds of thousands of lines long, and saving a line to two here or there is pointless. Any example more than a dozen lines long won’t be read, and thus is irrelevant.


• Any example that uses the advanced idioms and features of a language simply proves that the language is too weird, complex, and hard to learn. Any example that doesn’t use the advanced idioms and features of a language is irrelevant because that’s not how programmers competent in that language would write the code.


• Any example that is not directly applicable to what the programmer is doing right now is irrelevant, because that’s not what real programmers do. 3D rendering to games developers, server programming and database access to business logic programmers, GUI interactions to the desktop applications developer- if you’re not writing my code for me, what good are you?


• Comparing the productivity of different teams of developers is irrelevant because different programmers are differently capable. Comparing the productivity of the same team of developers in different languages is irrelevant because the the same programmer will be differently capable in different languages. Solving the same problem(s) in the same way(s) is irrelevant because the nature of the solution will favor one language, and that’s not how you’d solve the problem in the other language. Unless you solve the problems in different ways, in which case you’re comparing apples to oranges. Not having a ready made comparison simply means there is no proof of your biased claims.


• The object code produced by my compiler for my language (which has had thousands of man years of effort put into it’s optimizer) is much faster than the object code produced by your compiler for your language (the optimizer for which was written by some guy in his basement over a long weekend). And this is the way it will always be.


• The only way for a language to become popular is to have shelves full of books on it at your local bookstore, glossy magazines for your boss to read, thousands of programmers in the language lining up for the thousands of jobs in the language, etc. I.e. the only way for a program to become popular is to already be popular. And since your language isn’t already popular, it’ll never become popular.


• Your language is hard to learn. My language is easy to learn, because I already know it. People won’t learn what they don’t already know.

I heard every single one of these argument used against C++ and Java back in the day. Every single one. If these arguments were valid, then we’d still be programming in Fortran and Cobol. In fact, I’d argue that we still are. What made Cobol suck so bad wasn’t the language. It was the fact that it took five lines of code to set up some UI parameters- and even more so, because the Cobol programmers didn’t abstract, did look for the general case (which is, in general, interesting), but simply replicated the five lines over and over again.

I’ve done the “boring” data processing job. Turns out there’s a deep and interesting problem in the middle of that “boring” code. When I sing the praises of this language or that paradigm, I’m not trying to sell you a bill of goods, I’m offering you a way out of sucky programming. Come with me, if you dare- to a magical land full of interesting and deep problems, where drudge work is rare and quickly disposed of. A land of mystery- where the game is always afoot, Watson! Can it be done, how can it be done, can it be done better? Come with me to where programming doesn’t suck, but achieves it’s place as one of the great art forms and engineering miracles of the age.

What’s the first step, you ask? Well, first you need to learn a new language…

Popularity: 6% [?]