The World's Most Maintainable Programming Language: Part 5

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 fifth 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 2, The World's Most Maintainable Programming Language: Part 3, The World's Most Maintainable Programming Language: Part 4, and The World's Mode Maintainable Programing Language: Conclusion).


12 Comments

Ben
2006-04-03 06:38:28
For sure, there are a fair few ideas packed into this installment. Very interesting. I agree symbol naming is critical and much overlooked aspect of programming. Best practice in this area should certainly be taught as an integral part of learning to program in CS courses. Wasn't even touched upon back during my degree...
John Flack
2006-04-03 08:23:36
While I welcome suggestions from software, like the grammer suggestions in Word, I HATE software that thinks it knows better than I do. For instance, if I know that I am going to spend 40 hours over two weeks on a project, I HATE it when MS Project keeps insisting that 40 hours is a one week project and keeps changing the end date. Your "ideal" programming language with checking, not just for syntactical correctness but for vocabulary sounds okay in theory, but if it wouldn't compile something because I used a plural when it wants a singular, I'd refuse to use it.
Josh Peters
2006-04-03 11:19:29
I find the idea of spell check and grammar enforcement very interesting. However, one downside to this is internationalization. Essentially, to program, one would have to have a sufficient understanding of English. How would you address the issue of creating a globally useful language? Would internationalization issues be taken care of via compiler plugins?
xyz
2006-04-05 00:41:00
The descent seems to continue. Have you ever read a program in any programming language that was at the same time full of carefully thought out names, AND having an confusing layout in general?


Good programmers write nice programs, slobs will slob away in any environment.


2006-04-05 04:50:12
"""
A well-chosen symbol name may never be as useful as rigorous commenting according to a standard template
"""


heck. A well-chosen symbol name is worth a thousand lines of comment.


2006-04-05 04:56:46
Ok, this is a too-long april's fool article. And it fails to be funny....
grahamsw
2006-04-05 11:01:06
===============
A well-chosen symbol name may never be as useful as rigorous commenting according to a standard template
===============
couldn't agree less. A properly expressive language should need very few comments. (within functions - the public interface should always be commented since it's a contract). You really ought to read Fowler's "Refactoring".
Paddy3118
2006-04-05 14:30:04
I was a novice reader once. The books I read as such a novice are definitely not the books I want available to me now.

2006-04-11 08:01:51
Programming is a complex and often complicated craft. It takes hours, if not days and weeks to produce first steps that are even remotely of some use. It takes years to become good. Mastery is not possible. A good language doesn't force the programmer to use certain concepts and code formatting. The problem at hand is what forces the programmer to use certain concepts (and to a degree even formatting). If the language cant provide a way to express those concepts efficiently and clearly, then the language is not fit to solve that problem. A language that doesn't support recursion can't solve whole classes of problems. But it's not the languages fault when someone with years f programming practice still doesn't understand recursion (and yes, I have seen such people).
Ian McGowan
2006-07-17 07:01:08
"Imagine trying to work in an office where the chair is at the wrong height or the screen is too low"


Doesn't this point argue for *more* customization, not less? Shouldn't my environment fit me, a 5 ft tall emacs user, not my partner, a 7 ft eclipse user? As long as our code conforms to an agreed upon standard, of course.

malaysiadomainname.com
2006-09-19 23:11:45
I have to agree on the Naming section: Clear thinking promotes clarity.
As one of the most overlooked disciplines of writing maintainable code is carefully considered symbol naming.
martin
2007-01-09 09:56:28
Wow... you started out OK... BUT! overly constraining languages don't tend to become terribly popular as programmers will invariably spend a LOT of time having to wrestle with it. The naming suggestion is what caught my eye. There are ways to manage this kind of thing with external tools, but the compiler is the wrong place to do it. For example... one domain in which i am working would have GL1 GL2 and GL3 as perfectly acceptable components of an identifier... It is NOT a bad idea to have lint style programs that generate lists of identifiers, check them against approved identifiers for a project and highlight possible exceptions... The key concept though is that it ISN'T part of the language... it is part of the development environment, just like version control (something that has occasionally been incorporated into programming languages in verious ways as well). Great, so long as you don't need to use a different version control system.


All of your points are certainly valid items for discussion, but your approach to them (make everything part of the compiler/language system) has never worked well at all except in completely closed commercial programming systems.