Beautiful Code

Java seems to be going through its mid-life crisis. A year or two ago, there was a massive push to get closures into Java. No doubt this was inspired by the upsurge in interest in functional programming languages and abetted by the rising use of languages like Python and Ruby which show us daily how convenient blocks are. C# keeps marching forward also. C# 3.0 is substantially heavier on syntax than C# 1.0, and much of it has to do with this functional push. There have even been motions to add closures to C++.

So, this is all good, right? People find better ways of developing software, and they extend languages to take advantage of them. It seems like it makes sense. But, have you see the OO extensions to Fortran, Cobol, and Ada? In the best cases, OO looks grafted on. In the worst cases, the extensions are too conservative. It's as if the language designers said "Look, we know that people want OO and we can do it all the way, or we can hit the 80% that people care about." It's hard to fault them for doing that, but you can't say that the result is cohesive or elegant.

The other day, I ran into a blog by Ricky Clarkson on point free style in Java 7. It's a wonderful blog, and it shows that once you have closures there a few more things that you'd like to do next. Whether Java 7 will support them is up in the air.

I have my biases. I like small minimal languages that express a few ideas and allow you to compose them to do anything you'd like to do. I don't think I'm alone in this. History shows us that when languages get too eclectic, people leap to simpler languages, or at least languages that are perceived to be simpler. Java seems to be to right on the edge now.

What would you say if you saw a C# framework that had classes with public fields. No, I'm not talking about const fields. I'm talking about public non-static mutable fields.

If you are like most developers, there are probably a number of things running through your head now. One is that whoever wrote the code must be naive. We all know that public fields are bad. At the very least, fields should be hidden behind properties, or at least getters and setters. It's just bad practice.

But... how do you know?

One answer is: because violates style rules. Another is: it ignores years of experience formulating best practices for programming.

But, again, how do you know it is bad?

I run into this problem frequently now. It seems that we're very good about articulating rules and best practices. If you go onto any newsgroup or mailing list, you'll find a number of people who will argue with you about the right way to do something. However, the saddest experiences I've had with teams are times when I've visited and seen code that applies nearly every "best practice" you can imagine, without thought. You look at a particular situation and you see that, well, in this particular case, the advice of so-and-so in this-or-that book about programming in C++, C#, or Java doesn't apply... that there is some much more contextual way of doing things, but no, the rule is the rule and we have to argue.

Good programming is contextual. Practice is contextual. We can articulate rules about how to use language constructs correctly, but they're just guidelines. Context is king.

This is a reprint of an entry from my use.perl journal. Seemed relevant after Michael talked about how It's All Design.

Whenever I hear the phrase "seems perfectly sensible to me" come from the coder I immediately look for where the coder is allowing the ability to see inside the box influencing their thinking about what is and is not sensible.

----

Coder: Expert programmer with years of experience on the details of web
development and author of the code in question with detailed knowledge
of its inner workings and weeks training yourself to its behaviors.

User: None of the above.

----

Coder: Can see inside the black box of how the site works.

User: Cannot.

----

Coder: Idea of how the site works is influenced by how it actually works.

User: Idea of how the site works is influenced only by the site itself, how similar things work and how they want it to work.

----

Coder: Playing with the site through its evolutionary process for some time now.

User: Seeing it all for the first time.

----

The user does not know what you know.

They do not have the knowledge of how the device works.

They do not have prejudices about how the device is supposed to work based on its internals.

Coders see the inside (how it works) and outside (the interface).

Users only see the outside.

Coders tend to focus on the inside, that's what they work with.

Users can only focus on the interface, that's all they can work with.

The coder's knowledge of the internals influences their expectations and separates their thinking from the user. A coder must actively work against this built in prejudice in order to put themselves into the user's position to learn what is sensible.

Note for the easily offended: I know that these blogs are supposed to be about beautiful code, but I believe that by exploring its opposite – nasty, ugly, horrific code – we will enrich our discussions of, and appreciation for, code beauty. I am also aware that the opposite of beautiful is ugly, not crap; and I realize that the term crap is mildly vulgar. I decided to use the word anyway because that’s the term most programmers use when referring to offensively ugly code. In other words, I heard the expression “This code is crap!” much more often than “This code is ugly!” Besides, Wikipedia says that “… [crap] is considered mild enough that even a child may use it informally.” So there :-).

Hell is other people. - J. P. Sartre

Hell is other people’s code. - T-Shirt seen recently in Mountain View, CA

While writing my chapter for Beautiful Code, I was forced to think beyond code functionality and efficiency. I had to think about beauty in code. And thinking about what makes a particular piece of code beautiful also made me think about the complementary question: What makes a particular piece of code crappy?

In the last few months, this question has led to heated conversations with colleagues, friends in the business, and random software engineers sitting next to me at the local coffee house. It would be naïve to expect programmers to unanimously agree on anything, but on the subject of crappy code most people I talked with agreed on a few of things:

> continue reading

My chapter in Beautiful Code is titled Another Level of Indirection. In it I discuss how the filesystem code in the FreeBSD kernel employs various levels of indirection to structure the features it offers in a coherent way. In a related article, Abstraction and Variation, appearing in this month's IEEE Software Tools of the Trade column I explain how indirection is just one of the many mechanisms at our disposal for abstracting away non-essential complexity from the problem at hand.

I think that some of you will like to known that on August the 16th I managed to deliver a copy of BC to Presidente Lula. Putting aside all the political discussion, from the beginning of his government on, the adoption of Free/Open Software by Federal (Central) Government grew to tens of thousands of workstations, thousands of servers, and dozens of information systems. And still growing. Although BC is not focused on FOS, I felt like giving an exemplar to him anyway, since our work is on top of FOS.
On this day, we had the official operations start of a new CEFET Campos campus, located on a very poor neighborhood, and dedicated to vocational and workers education - in Brazil CEFETs offer high school, vocational, workers, undergraduation, and graduation courses - all levels of technological education in fact.
The link for an official picture of the moment is here.
Unfortunately, the angle is not favorable, but one can see that it is a BC exemplar!