## The World's Most Maintainable Programming Language

Oâ€™Reilly author chromatic has a string of blog posts describing his maintainable language. Possibly interesting even while it might be an Avril joke? (Didn't notice this posted on LTU yet.)

## Comment viewing options

### Interesting series...

...even if the punchline takes too long. :-)

Just to have the list in one place, instead of scattered about:

• Learnability: There is nothing more important that you can do with a language than to learn it.
• Consistency: The most important feature of a language is that it is completely consistent. There should be no inconsistency or nuance or shade of meaning.
• Simplicity: Simple things are easier to learn, so the language will optimize for simplicity, having as few commands as possible.
• Comprehensiveness: A language with support for different platforms and paradigms and tools is better than a language without, so the standard distribution will include support for everything useful.
• Power: Programmers should be able to accomplish anything they envision with ease.
• Enforcing Good Programming Practices: Maintainability requires developer support.
• Invariant Code Formatting: Inconsistency breeds unfamiliarity.
• Naming: Clear thinking promotes clarity.
• DRY: Repetition is hazardous and troublesome. Eliminating repetition eliminates dangers.
• Static Analysis: Finding and fixing errors before running a program is easier than finding and fixing them after deployment.
• No Compiler or Platform-Specific Code: Portability prevents strange bugs.
• A Powerful Type System: Forbidding incorrect operations as early as possible prevents bugs.
• Provability: Correct code has fewer bugs.
• A Single Development Environment: Foolish inconsistency is the hobgoblin of lazy minds.

My personal pet peeve is that Type Systems have much more purpose than simply finding errors, but at least he includes it in the list.

### Eclipse + Perl = garbage collection??

From part 4 of the article:

Using the Eclipse IDE improves the Perl programming language by use of garbage collection, freeing programmers from manual memory management.

This is an odd statement, to say the least. Was "Perl" meant to be some other language or has the author just completely flubbed it?

### Avril fool's

A fair bit of what was written was tongue-in-cheek so one can't take it too literally. It is perhaps more of a Rorsach test / tea leaves kind of article that generates discussion :-)

### While I like the idea of

While I like the idea of talking about program maintainability, I don't think the author's ideas were clear or well thought out.

### Static Analysis vs Code Reuse

"Finding and fixing errors before running a program is easier than finding and fixing them after deployment."

While this is obviously true; I would argue that it is also true that it is faster to fix errors for code that you didn't have to write (ie. time=0) than it is to fix static errors in code that you did. What I mean by this is that overly strict static languages often force you to write new code where a more flexible language would let you reuse existing code. Maybe you can debug static code 's' times faster, but if you have to write 'd' times more code, then you only benefit if s > d. The actual values for 'd' and 's' will depend on the project (potential for reuse) and the developer(s) (ability to reuse).

### No code is better

The idea makes sense. I've always liked static analysis, and normally I've found "duck typing" to be a rather abhorrent idea. However, after reading some O'Caml stuff etc., I sorta see the usefulness and pragmatism and power. In the end, personally, I'd still like to have static analysis, but stuff that is at a high enough level and/or is flexible enough that it doesn't cause too many road blocks for the developer yet can still do very powerful, detailed checks.

### The Most Reliable Component...

Is the one that doesn't exist.

-- anonymous NASA engineer

In a similiar way, languages with large high-quality debugged libraries (standard or extension), like PERL and Java (and others), are going to lead to fewer bugs in your code because you aren't going to have to introduce as much new untested code. Languages with less library support force developers to write more code (all other things being equal), and therefore, to produce more bugs.

### Re: Reliability via standard libraries

Everybody probably has a personal trade-off they are willing to make, or judgement call, between super tested libraries that might be founded on lame theory (concurrency in Java) vs. great theoretical underpinnings that haven't been fully implemented (concurrency in E)?

### Some important points are missing

I think a maintainable language should also be: 1. easy to read, 2. easy to modify, 3. easy to refactor.

1. Readability is VERY important. I think it is well known and not necessary to explain anymore.

2. Maintaining a program is somehow modifying it, adding functions, or changing its behavior. Therefore, a maintainable programming language should allow maintainers change the programmes easily.

3. Refactoring is a kind of modification of program, but only the structure of the program is changed and the functions and the behavior are kept unchanged. Refactoring is also important in maintenance, so the ability of refactoring should also be concidered.

### In case you were wondering

For those who were left wondering where exactly the punchline is: based on my previous discussions with chromatic on other forums my understanding is that the entire essay is supposed to be the punchline. From chromatic's point of view, Perl represents an ideal language, and does everything that a language needs to do to be very maintainable - thus all the various restrictions cited in the article (you'll note largely things that Perl doesn't have, or doesn't do well) are, from chromatic's point of view, silly superfluous things that should rightly be laughed at. Those of us who feel that things like powerful type systems, strong static checking, clear learnable syntax, and consistency, are good things... well we're all just left a little puzzled as to what the joke was supposed to be. The thing to keep in mind while reading the article is that it is written from the point of view of people who think Perl is the world's most maintainable language.

### it is written from the point

it is written from the point of view of people who think Perl is the world's most maintainable language

That's of course the funniest joke of them all...

### That's what I said to

That's what I said to chromatic, but he didn't seem to get the joke.

### That's Not the Joke

The joke is that people think programming language features are more important with regard to maintainability than programmer discipline. As a Perl programmer, I like to think I have a pretty good idea how much discipline (or its absence) contributes to unmaintainable code.

### I didn't know

I didn't know I had to choose between the two.

Honestly, I think you would have to look pretty hard to find somebody amongst the group promoting language features such as stronger type systems and static analysis with the opinion that programmer discipline isn't at least as important as language features.

In fact, one of the touted benefits of a language like Perl is that it doesnâ€™t put the programmer in a box. Ideas can be quickly thrown together into a program. But this behavior is often exactly the undisciplined behavior that has so many of us worried about the use of Perl.

Now I have to confess, I happen to like Lisp. Now, Lisp isnâ€™t quite like Perl in the maintainability market, but it is more permissive than other more static languages. That said, I see the benefit of using a language with a stronger type system (such as ML), and that benefit is it introduces a system of discipline that allows me to reason about my code better than I could in a more dynamic language (like Perl).

### My Goal

My ultimate goal was to mock the superficial arguments about maintainability by mushing them all together, especially the mutually contradictory and computationally unsolvable ones. It's not surprising that a regular LtU reader can find all of the holes in the argument -- there are certainly plenty of them, by design.

I just wish that comparisons of programming langauges would include more talk about programmer discipline and less about the hideous awful world-threatening dangers of dynamic typing; I appreciate a lot of things about Haskell for example, especially pattern matching and the compile-time type inference, but using variable names of f and T reduce the maintainability of a program, in my mind.

You can reason about your code all you want, but without decent symbol names and well-factored behavior, I think any program in any language will have maintainability problems. That was my main point.

### IMHO, You Got Trapped...

...by the fact that oftentimes that mushing together of the contradictory and computationally unsolvable is, in fact, advanced without ironic intent. :-)

### My favorite one is "Power:

My favorite one is "Power: Programmers should be able to accomplish anything they envision with ease." Yes, that is definately on my wish list!