3 ms·

I'm open to the possibility that this is true, but experience with regular expressions seems to indicate that terse and complex DSLs are resented for their lack

I'm open to the possibility that this is true, but experience with regular expressions seems to indicate that terse and complex DSLs are resented for their lack of maintainability. The analogy to music notation is good, but how much editing is done on music in musical notation? The top priority is conveying music to the performer. I'm glad to see an open source APL implementation that isn't a derivative like J, because it's good that these things should have reasonably canonical implementations out there for people to use. I don't think J's popularity is much higher for relying on ASCII, but I also don't think it suffers much because its syntax isn't APL's. Realistically, these options are not presented or noticed by the vast majority.

robomartin 13y ago
> experience with regular expressions seems to indicate that terse and complex DSLs are resented for their lack of maintainability The problem with regular expressions is the "regular expressions gone wild" effect. Also, the lack of a mechanism for documenting intent is a serious hindrance. One such example are the various forms of email validity regex strings floating around out there. I'll also say that there's somewhat of a lack of "topology" with regex expressions. What I mean is probably best explained with an analog. If you look at a page full of cleanly written mathematical notation you will quickly identify what I am calling a "topology" of sorts. You'll see the equal sign creating a demarcation between sides. You might see integral signs providing further grouping. The same is true of division lines, parenthesis, exponents and radicals. Now, a page full of equations can be insanely opaque. Alone they mean very little to most people. However, properly inserted comments and guidance can take something that was impenetrable and turn it into a more approachable problem. Of course, all of it assumes that you know both the notation and the mathematics behind it. Hard to understand differential equations if you never studied them. A language like APL can be very similar to this. I can write an ugly impenetrable hunk of code in one line and good luck figuring out what it does. On that point you are absolutely correct. If one starts to work with APL on a daily basis one invariably develops "idioms" --short chunks of reusable code-- that are applied with some regularity. Perhaps the most famous library of APL idioms is the Finn APL Idiom Library [0]. Here you have a set of expressions that do very useful stuff that can be plugged into any program. Generally speaking, a good programmer would include a comment identifying the idiom any time it is used. These little chunks of code, again, if APL is your daily 8 to 12 hour focus, become like words that you use in your code. You learn to recognize them very quickly. Unlike regex, the symbols in APL, similarly to the mathematical example I gave above, create a topology of sorts that helps you read and understand the code. The programmer has to be sensitive to the fact that, very much like regex, APL can easily become impenetrable, particularly to the casual observer. It is important to recognize this and both format and comment code appropriately. My general rule for programming, regardless of the language I use, is that I need to leave myself enough information, breadcrumbs and documentation to be able to understand what I was doing after five years of not having looked at the code or used the language it was written with. This approach has saved my butt multiple times to the point that I can say, at least to my satisfaction, that it is the only way to create code --regardless of language-- that can survive the test of time and is easy to maintain. The short answer to your observation, then, is that a good programmer should easily eliminate the impenetrability issues the language might have. [0] http://aplwiki.com/FinnAplIdiomLibrary http://aplwiki.com/FinnAplIdiomLibrary

robomartin 13y ago

> experience with regular expressions seems to indicate that terse and complex DSLs are resented for their lack of maintainability The problem with regular expressions is the "regular expressions gone wild" effect. Also, the lack of a mechanism for documenting intent is a serious hindrance. One such example are the various forms of email validity regex strings floating around out there. I'll also say that there's somewhat of a lack of "topology" with regex expressions. What I mean is probably best explained with an analog. If you look at a page full of cleanly written mathematical notation you will quickly identify what I am calling a "topology" of sorts. You'll see the equal sign creating a demarcation between sides. You might see integral signs providing further grouping. The same is true of division lines, parenthesis, exponents and radicals. Now, a page full of equations can be insanely opaque. Alone they mean very little to most people. However, properly inserted comments and guidance can take something that was impenetrable and turn it into a more approachable problem. Of course, all of it assumes that you know both the notation and the mathematics behind it. Hard to understand differential equations if you never studied them. A language like APL can be very similar to this. I can write an ugly impenetrable hunk of code in one line and good luck figuring out what it does. On that point you are absolutely correct. If one starts to work with APL on a daily basis one invariably develops "idioms" --short chunks of reusable code-- that are applied with some regularity. Perhaps the most famous library of APL idioms is the Finn APL Idiom Library [0]. Here you have a set of expressions that do very useful stuff that can be plugged into any program. Generally speaking, a good programmer would include a comment identifying the idiom any time it is used. These little chunks of code, again, if APL is your daily 8 to 12 hour focus, become like words that you use in your code. You learn to recognize them very quickly. Unlike regex, the symbols in APL, similarly to the mathematical example I gave above, create a topology of sorts that helps you read and understand the code. The programmer has to be sensitive to the fact that, very much like regex, APL can easily become impenetrable, particularly to the casual observer. It is important to recognize this and both format and comment code appropriately. My general rule for programming, regardless of the language I use, is that I need to leave myself enough information, breadcrumbs and documentation to be able to understand what I was doing after five years of not having looked at the code or used the language it was written with. This approach has saved my butt multiple times to the point that I can say, at least to my satisfaction, that it is the only way to create code --regardless of language-- that can survive the test of time and is easy to maintain. The short answer to your observation, then, is that a good programmer should easily eliminate the impenetrability issues the language might have. [0] http://aplwiki.com/FinnAplIdiomLibrary http://aplwiki.com/FinnAplIdiomLibrary