My Programming Language is More Terse Than Yours
My usual retort is: “so what?”
Isn’t brevity a goal for programming? Well, no. Okay, a short program is easier to understand than a long program, right? Yes, your point? Well, that means making a program shorter is also making it easier to understand. Actually, no.
I have been programming in Perl for the last 30 years. Yes, yuck! Not for me though. It is a wonderful language to replace shell scripts. If you don’t write system programs that you run for a couple of times, you don’t know what I mean. But it is okay, still, Perl is the language you want to use if brevity is your be all and end all. I don’t recommend it for any program longer than 1,000 lines. I never deploy a Perl program in production that I have to support. Yup, I said it: Perl is the language that can produce the shortest programs for a given problem.
But you would not understand in a week if you wrote it in the briefest way possible.
So, brevity is obviously not the most important goal. It is always something else. Most people who say they hate boiler plate code don’t know what boiler plate code is, or why it is there in the first place. I completely agree that programming languages should make it less necessary to do that kind of stuff. But it is what it is; when you design a language, you will never know how it is used. If it is used in a non-intended way, some kind of boiler plate code will be needed.
No, functional programming does not mean brevity. Actually, it can make it much harder to understand. Yes, I say it, functional programs can be more difficult to understand than a vanilla procedural program. Functional programs in many ways read like mathematical theorems, which they actually are, in a way. Now, how many people can really understand mathematical theorems more complex than the simplest form? Not many.
I am not knocking functional programming. I love program in functional style. However, for me, it is either pure functional or not, I hate mixing the two as my little brain either thinks in the functional style or not. It does not like to mix the two approaches.
It is the same thing when I was really into XSLT, which has the functional patten matching style that is very addictive for me. But if I worked in it for a few weeks, it would take me a few days to get back to Java. And vice versa.
Anyhow, what I want to say really is something obvious. If you want to maintain a piece of code, get out of your way to make it easy to understand. If that takes 10 lines to do, so be it. If that takes 10,000 lines to do, so be it as well. And what programming language you use for that, well, that usually is out of your control if you write programs professionally.
