It looks like I've got another "old fart" programmer rant here. Josh On Design has an open letter to language designers in which he urges them to kill a few of what he feels are sacred cows of programming language design.
Some of his points are ones that I can't disagree with (type systems, garbage collection, extending the syntax), but his points 1, 2 and 4 stick in my craw
Cow #1 is "stop storing source code as ASCII files on disk".
Cow #2 is "use an IDE that is more than a text editor"
Cow #4 is "stop using whitespace or indention or braces styles"
For #1 he suggests storing code in XML/JSON or a database, and storing the code structure, along with any metadata, and non-text resources together. This is not a bad idea, but it seems to gloss over one detail - a programmer will need to read the code to understand it, so it will end up being displayed as text in the end, even assuming it's not XML. His point is that once the structure of the code is set, having a compiler/interpreter extract that structure every time is wasteful. It is, but it gives the programmer great flexibility. The only thing like what he suggests that I can imagine is something like the visual programming languages that represent the constructs as icons with slots for the details, like a loop is an arrowed circle with the start, end, and increment values inside the circle. But what if you need to change from a loop to a recursive call? You would need to somehow remove the loop icon and replace it with another icon (drag&drop? emacs-like ctrl-meta-bucky keys?) and fill in the recursion endpoint and recursive calls. And you'd have to find a set of symbols that would be clear to all programmers, which is not an easy task. The great benefit of written languages is that they can carry a lot of meaning in a compact form.
For #2, he promotes requiring an IDE, since the source code would not be in a pure text format. IDEs are great tools - I was reminded of this recent;y in a class where Eclipse was being used, and the auto-import feature for Java code was really useful. But if the code requires an IDE to even look at it, you are adding complications - the language structure is now tied to the IDE understanding it, or you get incorrect rendering. Then you must wait for the IDE developers to update their code before you can safely work on your code. This seems a bad idea, especially if the IDEs are commercial tools, where corporate interests will have undue influence on the process. I was distressed to hear, years ago, that a C++ feature was misimplemented in the official version because one of the corporate members of the standards committee did not want to be forced to fix their broken extension of C++, and ramrodded their version into the language. Now imagine something similar, but where a good feature is rejected because a corporate member doesn't want to update their toolset!
Point #4 is superficially on target. Arguments over brace style and how many spaces a tab should be are probably the least useful, and most heated, disagreements in software. However, they are underlaid with a critical point - we need to understand the code to work on it, and different people find different layouts more suited to their mental models. But the point is a bit of a strawman - there are already tools to adjust the layout to suit - store the code in one format, and have the repository filter it to your favorite style on checkout so you see it in the style you prefer.
Basically, the point of source code is to provide the programmer with an easy-to-understand format. We have lots of computing power now, so why not use that to deduce the details, instead of making the human do the drudgework - compilation/interpretation can be done from the text much faster then understanding the code intent from a complex layout.
Now, it is still a good idea to perhaps save an intermediate step in a non-human-readable form, like Java class files or Python .pyc files, and there is always room for better ways to organize the source code of a project and its libraries, but assuming that one-size-fits-all is almost certainly going to fail.
Some of his points are ones that I can't disagree with (type systems, garbage collection, extending the syntax), but his points 1, 2 and 4 stick in my craw
Cow #1 is "stop storing source code as ASCII files on disk".
Cow #2 is "use an IDE that is more than a text editor"
Cow #4 is "stop using whitespace or indention or braces styles"
For #1 he suggests storing code in XML/JSON or a database, and storing the code structure, along with any metadata, and non-text resources together. This is not a bad idea, but it seems to gloss over one detail - a programmer will need to read the code to understand it, so it will end up being displayed as text in the end, even assuming it's not XML. His point is that once the structure of the code is set, having a compiler/interpreter extract that structure every time is wasteful. It is, but it gives the programmer great flexibility. The only thing like what he suggests that I can imagine is something like the visual programming languages that represent the constructs as icons with slots for the details, like a loop is an arrowed circle with the start, end, and increment values inside the circle. But what if you need to change from a loop to a recursive call? You would need to somehow remove the loop icon and replace it with another icon (drag&drop? emacs-like ctrl-meta-bucky keys?) and fill in the recursion endpoint and recursive calls. And you'd have to find a set of symbols that would be clear to all programmers, which is not an easy task. The great benefit of written languages is that they can carry a lot of meaning in a compact form.
For #2, he promotes requiring an IDE, since the source code would not be in a pure text format. IDEs are great tools - I was reminded of this recent;y in a class where Eclipse was being used, and the auto-import feature for Java code was really useful. But if the code requires an IDE to even look at it, you are adding complications - the language structure is now tied to the IDE understanding it, or you get incorrect rendering. Then you must wait for the IDE developers to update their code before you can safely work on your code. This seems a bad idea, especially if the IDEs are commercial tools, where corporate interests will have undue influence on the process. I was distressed to hear, years ago, that a C++ feature was misimplemented in the official version because one of the corporate members of the standards committee did not want to be forced to fix their broken extension of C++, and ramrodded their version into the language. Now imagine something similar, but where a good feature is rejected because a corporate member doesn't want to update their toolset!
Point #4 is superficially on target. Arguments over brace style and how many spaces a tab should be are probably the least useful, and most heated, disagreements in software. However, they are underlaid with a critical point - we need to understand the code to work on it, and different people find different layouts more suited to their mental models. But the point is a bit of a strawman - there are already tools to adjust the layout to suit - store the code in one format, and have the repository filter it to your favorite style on checkout so you see it in the style you prefer.
Basically, the point of source code is to provide the programmer with an easy-to-understand format. We have lots of computing power now, so why not use that to deduce the details, instead of making the human do the drudgework - compilation/interpretation can be done from the text much faster then understanding the code intent from a complex layout.
Now, it is still a good idea to perhaps save an intermediate step in a non-human-readable form, like Java class files or Python .pyc files, and there is always room for better ways to organize the source code of a project and its libraries, but assuming that one-size-fits-all is almost certainly going to fail.
1 comment:
http://joshondesign.com/2012/03/14/sacred-cows-2
I've posted an update that clarifies things a bit.
Post a Comment