8 ms·

The notion of programming languages being “too powerful” rests on fallacious assumptions. The faulty reasoning is this: If Hacker Hortense does something with

The notion of programming languages being “too powerful” rests on fallacious assumptions. The faulty reasoning is this: If Hacker Hortense does something with powerful language L that Newbie Nathan finds confusing, we assume that language J won’t permit Hortense to do that, and therefore if we standardize on language J, fewer bad things will happen. This reasoning is faulty. First off, if Hortense and Nathan don’t see eye to eye on how to write programs, no language will solve the problem, because you have a disparity of experience and/or education. If what you want is code Nathan will like, and you don’t want to raise Nathan to Hortense’s level, you have to drag Hortense down to Nathan’s level with coding standards. And you could have done that in Language L just as easily as J. If you ban L, what will you do when Hortense implements Parser Combinators and Monads in J? The first flaw is the assumption that language features introduce complexity, when in reality it isn’t the features, it’s the solution to the problem that confuses. This indirectly leads into the second fault with the reasoning. There is a hidden assumption that Hortense is going to write so much code, and there will be so many “problems” Nathan will have with his code, and every problem we eliminate is one fewer problem in the result. This is not how software works. Let’s say Hortense writes some code in L, and Nathan complains that there are seventeen things he doesn’t understand. Ten of them rely on features of L, seven are independent of the language. If we tell Hortense to rewrite things in J, we cannot assume that the result will have seven things Nathan doesn’t understand. It might have even more as Hortsense works around J’s deficiencies. For a demonstration of this, look at any modern Java Dependency Injection Framework. These complex and opaque software machines are made up of of XML, interfaces, and classes. They exist in no little part because Java lacks the reflection and meta-programming of languages like Lisp or even Ruby. Are these thing simple by virtue of being written in Java instead of Lisp? Imagine for a moment that DI frameworks don’t exist, and that Hortense had built something in Lisp with macros for dependency injection. Nathan is nonplussed, so Hortense rewrites it in Java and rolls her own DI infrastructure. Will the result really have fewer things that Nathan doesn’t understand? Or will it be even more inscrutable thanks to the accidental complexity of working around Java's limits?? The “problem” is not that some languages are too powerful, it is that people imagine that teams of programmers can work together on complex problems without communicating, and some people assume that when there is a disparity of experience of knowledge, that people can work together without educating or learning from each other.

sirclueless 15y ago
I'm not so sure I agree with you, because there is something to be said against your counterexample. In java, I can reason as follows: the Java Dependency Injection Framework is gigantic and convoluted, therefore it is going to be complex and difficult to manage. In Java there is a sort of ceiling, one might call it an upper bound on the mindfuckery per square inch of code. In 100 dense lines of lisp, there is no a priori reason to assume that no one has written a recursive descent macro-expanding s-expression handler for arbitrary routing of network packets in a rules-based DSL. In the same amount of dense java code there are rarely more than 200 method calls, all statically checked, and rarely more than 100 variables, typed and scoped. From John Carmack's recent article on static checking: "If you have a large enough codebase, any class of error that is syntactically legal probably exists there." Now, he is concerned with actual defects, but the same rules apply even more strongly for stylistic rules. As the size of a codebase increases, the probability that any particular language feature is absent approaches zero. And in a language like lisp, where you can write your own language features, this is moderately horrifying. The fact that you can replicate java's dependency injection in a few orders of magnitude less code in lisp is not a comfort to me. Because the 10,000 lines of code in Java's Dependency Injection Framework is a red flag to me. The chances that someone who writes the same thing in lisp has drastically simplified the implementation are not so high.
- j_baker 15y ago
  Perhaps I'm missing something here. Argument 1 seems to basically be that Java code is bigger than Lisp code. Argument 2 is that big code bases tend to use all of a language's features. Why couldn't you solve the second problem with the first? As you've already pointed out, Lisp code is smaller. Thus, you don't have to worry about the "large code base" problem like you would with java.
  - richardw 15y ago
    A couple lines of particularly dense Perl can make life pretty terrible, e.g. compared to many thousands of lines of getter-setter Java. You can pack more language features into a smaller area with a more expressive language. It follows that a smaller area might hold more complexity and likely more opportunities for errors, and therefore bugs. At the very least, we can say "the LOC-bug relationship doesn't necessarily hold across languages". It's a useful rule-of-thumb, not a universal law.

sirclueless 15y ago

I'm not so sure I agree with you, because there is something to be said against your counterexample. In java, I can reason as follows: the Java Dependency Injection Framework is gigantic and convoluted, therefore it is going to be complex and difficult to manage. In Java there is a sort of ceiling, one might call it an upper bound on the mindfuckery per square inch of code. In 100 dense lines of lisp, there is no a priori reason to assume that no one has written a recursive descent macro-expanding s-expression handler for arbitrary routing of network packets in a rules-based DSL. In the same amount of dense java code there are rarely more than 200 method calls, all statically checked, and rarely more than 100 variables, typed and scoped. From John Carmack's recent article on static checking: "If you have a large enough codebase, any class of error that is syntactically legal probably exists there." Now, he is concerned with actual defects, but the same rules apply even more strongly for stylistic rules. As the size of a codebase increases, the probability that any particular language feature is absent approaches zero. And in a language like lisp, where you can write your own language features, this is moderately horrifying. The fact that you can replicate java's dependency injection in a few orders of magnitude less code in lisp is not a comfort to me. Because the 10,000 lines of code in Java's Dependency Injection Framework is a red flag to me. The chances that someone who writes the same thing in lisp has drastically simplified the implementation are not so high.

j_baker 15y ago
Perhaps I'm missing something here. Argument 1 seems to basically be that Java code is bigger than Lisp code. Argument 2 is that big code bases tend to use all of a language's features. Why couldn't you solve the second problem with the first? As you've already pointed out, Lisp code is smaller. Thus, you don't have to worry about the "large code base" problem like you would with java.
- richardw 15y ago
  A couple lines of particularly dense Perl can make life pretty terrible, e.g. compared to many thousands of lines of getter-setter Java. You can pack more language features into a smaller area with a more expressive language. It follows that a smaller area might hold more complexity and likely more opportunities for errors, and therefore bugs. At the very least, we can say "the LOC-bug relationship doesn't necessarily hold across languages". It's a useful rule-of-thumb, not a universal law.