Tuesday, July 01, 2008

The Problem With Popplers

Today's entry is just a rant about the state of programming in general. That's why the subject line is completely irrelevant. I was going to call it The Problem With Programming, but where's the fun in that? My problem with programming is that we keep having the same endless discussions. These discussions, in my humble opinion, are not really of much consequence. Most of the programming discussions seem to have to do with a) programming language features, b) new and better programming languages, and c) methodology. Hey, this is an "agile" programming blog, right? So I'm already guilty of c. The truth is that none of these things really matters all that much in relation to the giant elephant in the room: Competence. With reasonable exceptions, if you're competent in one programming language, you're competent in them all. Sure, you'll have to take some time to learn the idioms and quirks of another language, but that's fine. Am I really going to be significantly more productive using C# than Java? What about Python? What about Perl or PHP? What about Ruby? Oh, those are boring, eh? Perhaps something like Scala or Lisp would do the trick. Honestly, does it really matter? Sure there are cases where such distinctions do make a difference, but frankly, assuming you've got some kind of reasonable OO language without pointers (I've excluded C and C++ from this discussion), really it comes down to this:

1) Is the inherent performance adequate for your forseeable needs?
2) Is the platform stable?
3) Can you find suitable libraries for what you want to do without re-inventing the wheel?
4) Have you addressed relevant portability issues?
5) Are the available development environments suitable for your needs/preferences?

Really, that's about it. Everything else is just kind of annoying dithering. Sure, with real human languages people have a lot of vested interests, plus there are aesthetic concerns. But programming languages have only been around for decades. Do we really need to have a balkanized landscape in the programming language world to mimic that of regular languages in the real world? Apparently so! As for aesthetics, I suppose poetry written in French can never be perfectly translated into English, or Chinese, or Swahili, and so on. But we're talking about computer programs here. The aesthetics should, in my opinion, be limited to expressing things clearly and economically. Computer programming is much more like technical writing than poetry. If there are real aesthetics to it, then I would say any poetry in programming lives in the realm of algorithms, which are language-agnostic anyway. Then there are the endless debates about changes to programming languages. I had an email discussion recently with a fellow about checked exceptions in Java and how terrible they were. My goodness. If you don't like them, then don't use them. It's easy to dispense with them. It's not a problem. Frankly it's a waste of mental energy to discuss things like this. But that's what people are into these days. Endless onanizing with the latest and coolest language features. Should the language be more dynamic? Less dynamic? Can we write our own specialized Domain Specific Languages? Sigh...

Finally there's the methodology cesspool. I have my own views. The problem is that this issue tends to be at the forefront all the time. Is XP good? Are all XP practices good? Is agile a religion or a con? What's the difference between agile and lean? The simple reality is having competent and motivated programmers is good. Having unmotivated and incompetent programmers is bad. If you have competent and motivated programmers, then a really bad methodology may cripple them, but nothing short of the insanity of the CMM stuff is likely to do that.

CMM level 5, denotes complete paralysis. Levels 2 to 4 indicate various intermediate stages where paralysis is spreading, but you can still ship.
The norm is simply chaos without any form at all: The hack and fix grind. Outside the realm of complete insanity, there are practices that most reasonable people would agree on: Automated tests for regression and quality; using a revision control system; integrating the tests into the revision control system as part of an automated build; planning and designing in some kind of iterative fashion; communicating - you know, like, talking to one another in some way that doesn't involve exchanging 200 page documents. Cooperation - people involved genuinely wanting to help one another reach the goal.

Ok, you get the idea. Beyond that, it's all about refinement. Don't like pair-programming? Fine. Prefer writing automated tests after you write the code for a particular feature? Well, I disagree, but ok, go for it. Find occasions in which some detailed planning and design is necessary? Hey, do it - just don't lose it and end up in in(s)anity land again.

What's my point? Well, it's that the real problem with programming is that developers aren't competent enough. There is not enough understanding of core programming ideas - either that or there isn't enough self-discipline to appy them: Reduce duplication; encapsulate; reduce coupling; increase cohesion; emphasize clarity; resist the urge to obfuscate; no matter how tempting it might be, choose the plain way to do something rather than the really fancy: Avoid the way that uses some new fangled language feature unless you can demonstrate the plain way is going to be a serious problem.Whatever you do, avoid falling in love with object-oriented design for its own sake (or functional programming for its own sake). You should be able to show how everything you do emphasize clarity and reduces duplication and coupling. At the end of the day, a good program written in Python should look almost identical to the same thing written in Java. What are your objects? What are their functions? How have you removed duplication? It's not a sexy problem. Switching to a new programming language or a new methodology won't help. It's just the slow grind of educating people, educating ourselves, and keeping things as simple as possible.


Think about it.

7 comments:

Илья Казначеев said...

"At the end of the day, a good program written in Python should look almost identical to the same thing written in Java."

Nope, it's going to be about 5 times shorter. And no, this isn't due to incompetence, it's due to language grubbing.

And yes, maybe Java program is going to be just 3 times longer, by introducing a fair dose of archeticture astronautics - abstractions which aren't straightforward or required really, but designed to make program shorter.

Marcel said...

"Am I really going to be significantly more productive using C# than Java?"

If you're not, you're doing something wrong. Anything but assembly should be more productive than Java.

Just saying :P

Testosteles said...

I love it! You've pretty much summed up why I haven't been blogging lately; I just came to the realization that none of the stuff I used to post or read about really matters. I've implemented my share of complex shit that isn't clear before, and once I came to the realization that being clever is stupid and being clear is next to godliness and that boring code is where it's at... Well, nothing's really profound enough for me to care enough to blog about anymore.

Vladimir Levin said...

Testosteles, I feel compelled to say that I hope you made your comment in jest or with some sarcasm! I don't think being clear and being boring are the same thing. Also, there are always opportunities to expand the scope of what you're doing if your current work isn't challenging enough. The big problems occur when people apply too much sophistication to problems that don't need it. I found this link awesome and hilarious, and so true!

http://www.yosefk.com/blog/fun-at-the-turing-tar-pit.html

Илья Казначеев said...

"If you're not, you're doing something wrong. Anything but assembly should be more productive than Java."
Well, C# *is* Java (yeah, with some nice additions, but not enough to make it perform differently).
So yes, one would'nt get a sizable perfomance boost from switching to C#.

Dynamic languages are a different concern.

uga said...

Sorry for joining the discussion so late. But I feel that I should respond as, apparently, I played a little inspirational role in this post.

I completely agree that the single most important thing in programming is competence. Every language mentioned in the post has proven itself as an excellent platform for some amazing software, given excellent competence.

That said, that does not make the discussion of languages and their features any less important precisely because we have to deal with less than excellent competence. It is not a waste of time to discuss things like checked exceptions and what good or bad may come out of using or misusing them. In the worst case you will gain more competence by discussing the subject and getting a second opinion.

It is also important how much effort is required to acquire the kind of competence in a particular programming language that would be sufficient to produce good code. This effort will be different for different languages. Every language has its good and bad practices. When we encounter bad practices it is only natural to ask ourselves what inspired them. It is also a valid discussion whether it is possible to create good code with less competence given the reasons for bad practices are eliminated.

Consider a hypothetical situation. Vlad, I have no doubt that you are an excellent programmer. But what if you are asked to work on a project with teammates who are less competent in programming? Would you not ask yourselft what the best tool is to give to your teammates to bring the project to success? What would you base that decision on? Say you don't like checked exceptions, so, as you say, you will not use them, but will your teammates use them?

I think that one programming language is more suitable than another if, for a given problem or situation, the language "invites" you to write correct and clean code. The subject space in programming is so broad that programming languages naturally fall into their own domains for this reason. That's why Java is considered good for middleware and infrastructure, PHP - for the web, C/C++ for high-performance stuff and Erlang for concurrent stuff. It is things like checked vs runtime exceptions, static vs dynamic, functional vs OO, imperative vs declarative that decide where a language will end up.

Vladimir Levin said...

I'd like to clarify something that perhaps I did not state plainly enough: Let's say both Java and Python are suitable for the basic needs of a piece of software.

Perhaps one can get something like a 30% improvement in coding productivity out of Python. I read such a statement on a Google engineer's blog -- need to find the link. Anyway, let's suppose true. Ok, that is all fine and good, but a) actual coding time is not usually a huge part of the time developers spend on a project. Much more time is spent understanding what needs to be done, thinking about how to do it, and testing of various kinds. b) All programming languages have strengths and weaknesses. Python doesn't have much compile time checking so it is likely that at the end of the day that will eat into whatever productivity improvements one thinks one is getting. I am confident it all washes out in the end.

In the end I cam promise you this: Chances are that whatever platform you pick for a project, the time will come when you curse what decision and decide with certainty rhat *the other* platform would have been a much better choice. Of course, the same thing would happen with the other platform too ;)