Re: Some thoughts around the "is Perl code maintainable" discussion

[chromatic]

It is my impression that languages like Python and Java have much more standard conventions and they therefore seem more maintainable.

But neither Python nor Java has interesting standard conventions that prevent interesting maintainability problems!

You can always, always, always look up syntax in a language reference. Always.

You can't always look up why another coder used a particular algorithm or what a poorly-named variable signifies.

It's time to reject the idea that maintainability has anything to do with syntax (spend $40 on a language reference already!) or formatting (use a pretty printer!) and consider that maybe, just maybe, it's all of the creative work of writing programs that can get us into trouble.

Update: TimToady said s/maintainability programs/maintainability problems/.

[oyse]

But neither Python nor Java has interesting standard conventions that prevent interesting maintainability programs!

Sorry, I did not understand this sentence. Could you elaborate a bit more?

It's time to reject the idea that maintainability has anything to do with syntax [...]

I do agree with you that people should stop focusing on the syntax when discussing languages. As you have pointed out (above and in other posts) there are other things that are far more important when it comes to maintainability. However saying that syntax does not have anything to do with maintainability is too strong in my opinion. In my opinion the syntax of the language does matter. I am fond of the following quote by Alfred N. Whitehead that says this better than I will be able to do:

By relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more advanced problems, and, in effect, increases the mental power of the race. Before the introduction of Arabic notion, multiplication was difficult, and the division even of integers called into play the highest mathematical faculties.

For example would not the creation of domain specific languages be an example of that syntax/notion matters? Take pattern matching for example. We could express pattern matching directly as finite state machines with states and transition, but the notation for doing so is cumbersome. So instead we use regular expression that are much more expressive, but can be automatically translated into an equivalent state machine. This makes our programs easier to read and to maintain.

That being said, I do wish people would stop focusing on syntax when discussing languages. There are far more interesting and important properties to discuss.

[chromatic]

Sorry, I did not understand this sentence. Could you elaborate a bit more?

Suppose someone names all of his variables and functions after the titles of Led Zeppelin songs. How does a language prevent that? Yet it's a maintenance problem.

Suppose someone refuses to use built-in aggregate data types and rolls his own. How does a language prevent that? Yet it's a maintenance problem.

Suppose someone refuses to use built-in string handling functions and rolls his own. How does a language prevent that? Yet it's a maintenance problem.

Suppose someone has a program which watches the commits and reverts all changes to a section of code he feels that he owns. How does a language prevent that? Yet it's a maintenance problem.

Suppose someone has a penchant for writing long, long functions because "the overhead of setting up call frames is too much for this critical path" and you end up with thousand-plus line monsters. How does a language prevent that? Yet it's a maintenance problem.

Suppose someone writes a god object and couples it to the internals of every other object in the system. How does a language prevent that? Yet it's a maintenance problem.

In my mind, all of these problems are much more important than "Wow, I've never seen that particular bit of syntax before", but somehow people get caught up on the idea that syntax and idioms matter more.

[Ven'Tatsu]

For example would not the creation of domain specific languages be an example of that syntax/notion matters? Take pattern matching for example. We could express pattern matching directly as finite state machines with states and transition, but the notation for doing so is cumbersome. So instead we use regular expression that are much more expressive, but can be automatically translated into an equivalent state machine. This makes our programs easier to read and to maintain.

I think maybe you are confusing the abstraction with the syntax of the abstraction.

The presence of lack of an abstraction can have a dramatic effect on maintainability. The syntax used to express the abstraction has a far lesser effect.

In JavaScript you can create a regular expression in a Java like re = new RegExp("\\w+") fashion or a Perl like re = /\w+/ fashion. In Perl6 you will be able to select between Perl5 and Perl6 (and maybe other) syntaxes for the expressions them selves. One form might be easier to write or read than the other, or a programmer might know one form and not the other, but any form existing in a language negates the need to program a state machine to do simple (and possibly complex) string matching.

[paddy3118]

It is _not_ time to reject the idea that syntax affects maintainability. When you buy your language reference note how many ways there are of doing things; how many special cases; how many themes. Too many increases the chance that the other persons code is written with themes and idioms that the maintainer is not familiar with. How much does the community advocate machine generated code? Or elevate code obfuscation? They can lead to a culture of poorly written code being O.K. or even cool. Syntax and community have a lot of influence on maintainability of code! - Paddy.

[chromatic]

Too many increases the chance that the other persons code is written with themes and idioms that the maintainer is not familiar with.

Why does your organization not have coding standards?

Why are you not performing code reviews of some kind?

Why are you hiring maintenance programmers without sufficient language experience or at least sufficient training in your organization's coding standards?

You betrayed your own argument when you said "poorly written code". How can you even identify code quality without these things?

If your maintenance programmers can't handle the style of syntax your organization uses, I can't see how they have any hope of handling the interesting problems of maintainability.

[paddy3118]

Not all your code is your own. In large organisations there can be multiple coding standards at work from internal and external organisations. What you suggest, isn't Perl specific and does not diminish the fact that Culture and syntax do play a part. If code readability is not a major part of the language design and syntax, then those coding standards are more likely to endorse stylistic elements that are difficult to read. If the culture of the users think obfuscation is cool then that too may slip by in code reviews by members of that culture. Perl code is maintainable. I, and many others have had to do it. It's just the language, and culture doesn't make it particularly easy. - Paddy.

[mreece]

If your maintenance programmers can't handle the style of syntax your organization uses ...

is it just me, or is that getting a little harder lately? finding maintenance programmers who are familiar with Perl's vast syntax, i mean.