entropia

In his latest rant, Steve Yegge asserts that the worst thing that can happen to a codebase is for it to get too big. He uses a lot of words to make his beliefs clear: too much code is bad; most people don’t think too much code is bad; Java, and similar languages, are verbose; refactoring doesn’t help code size. But in all his words, there wasn’t a lot of reasoning behind what he said.

Fortunately, Jeff Atwood condenses and elaborates, and for the most part he agrees. But they both fail to distinquish between bloated code and verbose code.

Bloat is when code is larger than it should be because of repetition, featuritis, or poor organisation. Bloat is the opposite of elegance.

Verbosity is code that is long because the language requires it, or because of design decisions. Verbosity is the opposite of succinctness.

Code can be bloated but succinct. It can be verbose but elegant. And it can be bloated and verbose. Verbosity can be bad, but bloat is always bad.

In Java, and C#, there’s a lot of boilerplate code. A simple property can take up 15 lines on the screen. A map can take 6. Both can be done in a single line in a language like Ruby.

But does that matter? Is that extra code any harder to manage?

One more thing that Steve asserts is that the claim that the IDE can overcome this verbosity is flawed. This is where I don’t necessarily agree. A good IDE can hide a lot of that boilerplate code from you, can do refactorings that would requires managing the code, and, perhaps most importantly, can highlight the code so it’s easier to see the meat.

Steve’s argument is that the power of the IDE promotes even longer code, requiring even more powerful IDEs and creating a vicious circle. This is true, but it’s ultimately up to the programmers and languages designers to keep their code managable. Just because it’s easy, doesn’t mean you should do it.

Yes, less code is better. And being succinct is better than being verbose. But the latter really isn’t that big of an issue.

4 days ago I wrote about parallel processing.

Sun and Microsoft are constantly working on improving the Java and .NET frameworks. And by the time the average programmer needs it, both will have plenty of support for easy threading.

Today, via Public Sector Developer Weblog:

Microsoft is working on a set of Extensions for the .NET Framework 3.5 (Visual Studio 2008) that will make it dramatically easier for Developers to build “managed code” parallel process applications.

The CTP is now available. I hadn’t heard about it before today, but apparently the word has been out for a few months. There’s a Parallel Programming Team blog, an MSDN Magazine article, and a Hanselminutes podcast about the framework.

I haven’t tried it yet (my computer only has a single core), but it looks interesting.

I’ve had this post on the back-burner for a few months. It wasn’t until I read Only Code Has Value? that I decided to finish it.

If you have well-written code, you can easily understand what the code is doing. However, even the best-written code can’t reveal why it is doing it. That’s because the question of “why” is not centered on the code itself, but on the context it operates in and the design decisions made during the development of the system.

I don’t think I can put it any better than that: there’s no way for code to explain the Why. And without the Why, you are powerless.

Our only hope, our only peace is to understand it, to understand the `why.’ ` Why’ is what separates us from them, you from me. `Why’ is the only real social power, without it you are powerless.

As recently as a couple years ago, I didn’t care much about what code looks like. As long as your program does what it’s supposed to, it’s all good. Sure, it’s nice when other people can easily understand how it works, but that’s not as important. Besides, if they’re to understand the Why, they’ll need some form of documentation anyway. You might as well just put the How in there too.

More recently I’ve been reading blogs and books that promote readable, extensible code. One of the quotes that comes up again and again is from The Structure and Interpretation of Computer Programs:

Programs must be written for people to read, and only incidentally for machines to execute.

That’s a fine theory, and definitely something that we should strive for in practice. But when was the last time you came across a non-trivial piece of code that you immediately understood? Even the most well-written code takes time to read - to understand the How. It would help if you already had the power of knowing the Why.

Maybe we should spend a little less time making sure our code is readable, and start spending some time on the documentation.

From Write Me a Small Program at freeshells.ch:

Don’t let me catch you saying anything like `The multi-core future’. Multi-core is not in the future. How many cores do you have in your current computer? How many in the computers being sold _right now_? How many CPUs? If you ever again say `future’ and `multi-core’ in the same paragraph, and I catch you.

Muli-core processors are becoming more popular every day, and that trend won’t end soon. Steam’s survey shows more than 1 in 3 users mave more than one core (this survey covers gamers, who tend to have more powerful computers than “average users”, so real-world usage rates are probably much lower). When I checked a couple months ago, it was about 1 in 4. Computers in the future will have more and more cores, and developers need to be aware of this. But as a developer, do you need to be actively thinking about it?

I say no.

And it’s not because of adoption rates. A user’s future is a developer’s now. Developers need to design their software for hardware that won’t be used for a year or two. But even if every user had multiple cores, most developers wouldn’t need to worry about it.

The reason is because most software doesn’t need multiple cores, and would not benefit from being multi-threaded. Other than game developers, most programmers don’t do anything that’s CPU-intensive. Most desktop- and web-apps run fine in a single process.

But applications are getting more complex, and eventually even “simple” programs will nned multiple threads. Does that mean developers will suddenly flock to Haskell? Again, no. Language designers are well aware of the situation. Sun and Microsoft are constantly working on improving the Java and .NET frameworks. And by the time the average programmer needs it, both will have plenty of support for easy threading.

If you want to stay ahead of the curve, then yes, you should learn all about parallel programming. The same goes if you’re making games or anything that requires a lot of CPU power. But chances are, it won’t help with what you’re working on now, so you don’t have to worry about it.