The World's Most Maintainable Programming Language: Part 2

by chromatic

Have modern programming languages failed? From the point of view of learnability and maintainability, yes! What would a truly maintainable and learnable programming language look like? This is the second of a six-part series exploring the future of programming languages (read The World's Most Maintainable Programming Language: Part 1, The World's Most Maintainable Programming Language: Part 3, The World's Most Maintainable Programming Language: Part 4, The World's Most Maintainable Programming Language: Part 5, and The World's Most Maintainable Programing Language: Conclusion).


7 Comments


2006-04-05 04:02:05
"""
To solve this problem at least, while respecting the principle of learnability and avoiding false cognates, a maintainable programming language should name all invocants after the name of their classes. That is, within a class named AlienInvader, all methods will automatically have access to the invocant through the symbol named alien_invader.
"""


Very bad idea - this introduces a too thight coupling between classes and methods.

Paddy3118
2006-04-05 11:22:58
Naming consistency within a library is good but this should not<\b> be enforced on the user of a library. The mark of a good library is that it can be used in ways the original writer never thought of.
A small, (lame), example: A complex number library might be written with i and j used consistantly for the eal and imiginary part of the number. Someone wanting to use the libraries complex number representation to represent points on a plane may rightly prefer to use x and y instead of i and j in his code.
ooze
2006-04-11 07:39:00
Here you are already leaving your path of the "natural language". Even natural languages have shorthands for "objects". We call them pronouns. You say "I" and "he". And at almost all times the meaning of this alias is very clear. And it is very well defined in a programming language too, so that there never is a confusion about it's meaning. If you don't know what the pronouns are in a language, you don't know the language, and using it for something important will lead to desaster. If you don't know what a pronoun is "aliased" to in certain context, you don't know enough about the domain, and saying something situation can easily lead to (social/programming) desaster. Removing (predefined) aliases won't help the beginner (actually can confuse them), and cripples the the ones in the know and makes certain concepts (as generic programming) ridiculously cumbersome.
Jessemon
2006-10-02 19:04:01

Let me simplify the problem I think you are trying to address:


People can name their variables anything they want.


In the real world, it is OK to name your cat Dog, but in source code, it is so bad for someone to be able to name a File object f, asdf, file, or config. A good name would be configFile. Certainly the others are easier to type, but they are very bad for readability. Oh and I have seen lots of code with variables like qaz, asdf, bob, etc. If it is a small method, then it might be OK, but not if it is used throughout a complex many line block of code.


So I agree that bad variable names are bad and hamper readability.

Akshat
2006-10-22 23:11:09
I will not have a dumb compiler telling me what I may or may not name my variables, or handles if you will. Good naming is a convention, and a courtesy to be extended, but making it a requirement is like communising the programming.


"Number 943, you may only name your dog fifi or fufu, but not dudu. It is against the best intsrest of Oceania"

does it matter?
2006-11-04 03:24:34
Jessemon wrote:"Oh and I have seen lots of code with variables like qaz, asdf, bob, etc. If it is a small method, then it might be OK..."
If it's a small method, surely the language would provide pronouns (eg, Python's underscore: _ ), just as human languages do.

2007-01-26 16:59:42
Good naming is certainly important. But why? It is important to know what kind of object it is (a file, an int, a string), which I equate to structure. However, using generic names for specific instances wouldn't solve the real problem. The more important question for maintainable code is, "how hard is it to figure out what is going on?" So even more important to the reader than the structure is the data it contains. If every file was named File1 and File2, the program would be totally unreadable and considerably more difficult to maintain. The kinds of names you want the programmer to use are ConfigFile and LogFile.


I also agree with the other comments that removing pronouns and replacing them with some convention is not going to clarify things to a beginner programmer, or create something closer to natural language.