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

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.

Comment on Re^2: Some thoughts around the "is Perl code maintainable" discussion

Replies are listed 'Best First'.
Re^3: Some thoughts around the "is Perl code maintainable" discussion by chromatic (Archbishop) on Aug 11, 2007 at 18:11 UTC
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.	[reply]
Re^3: Some thoughts around the "is Perl code maintainable" discussion by Ven'Tatsu (Deacon) on Aug 14, 2007 at 18:59 UTC
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.	[reply] [d/l] [select]