3 ms·
I think we should distinguish between notations that allow users to write incomprehensibly terse code and those that force them to. Only the latter are a probl
by pg 17y ago
I think we should distinguish between notations that allow users to write incomprehensibly terse code and those that force them to. Only the latter are a problem, unless you're taking the protect-users-from-themselves approach to language design.
It's an interesting question whether there are any existing language constructs that force one to write unreadable code. I ended
http://www.paulgraham.com/power.html http://www.paulgraham.com/power.html
by asking for examples, and I don't think I ever got any.
- sayrer 17y ago"Are there languages that force you to write code in a way that is crabbed and incomprehensible?" How about TECO?
- eru 17y ago> It's an interesting question whether there are any existing language constructs that force one to write unreadable code. Depends. Suppose we added GoTo, ComeFrom, and assignment to the Haskell specification, to be implemented by all conforming implementations. The language has become strictly more powerful. But compiler writers will have a much harder time proving certain properties about your program e.g. constancy of variables. The implementation and optimisation techniques that depend on those properties no longer work. Thus the purely functional parts of your programmes will become slower, and you will be forced to switch to imperative style if you want any performance. (To make the compiler writers job even more difficult, add some of Python's dynamic capabilities that make it so hard to compile. Plus an eval that works in the current environment on strings and can change arbitrary variables or cause other side-effects.) Of course the language itself does not force you to write unreadable code. But it may make it harder for the implementors to allow you to write readable code.