5 ms·
From Paul Graham, and one of the best essays on the subject ever written: http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html As long as our
by base698 10y ago
From Paul Graham, and one of the best essays on the subject ever written: http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.
When we switch to the point of view of a programmer using any of the languages higher up the power continuum, however, we find that he in turn looks down upon Blub. How can you get anything done in Blub? It doesn't even have y.
By induction, the only programmers in a position to see all the differences in power between the various languages are those who understand the most powerful one. (This is probably what Eric Raymond meant about Lisp making you a better programmer.) You can't trust the opinions of the others, because of the Blub paradox: they're satisfied with whatever language they happen to use, because it dictates the way they think about programs.
- bborud 10y agoSo when you say a language is "powerful" you are talking about its level of abstraction? Because then we should probably try to call it something else so as not to confuse "power" for technical ability to deliver performance or productivity.
- kuschku 10y agoDefinitely, the measurement of how "powerful" a language is directly corresponding to its level of abstraction. It does not necessarily mean that any dev can code faster – or even similarily fast. But it means that much of refactoring usually is easier (as you’ll have less duplicated code), that you get more guarantees, that you have less boilerplate, etc.
- bborud 10y agoThen I'm not sure if "powerful" is necessarily what I look for in a language. I have three priorities when programming: 1. Correct 2. Understandable 3. Fast Priority 1 is non-negotiable (code should be correct, or the rest is moot). Priority 2 is negotiable in situations where priority 3 isn't, however I've had this happen perhaps a handful of times in the last 25 years. Being able to produce code quickly is nice, but unimportant if the code isn't likely to be correct, understandable or fast. Productivity in production code is measured in how you achieve the above. Likewise it is nice to have code that is easy to refactor and doesn't require duplication, but duplication is more permissible than the dogmatic avoidance of duplication when it is detrimental to understanding or speed. It can also lead to unnecessarily bothersome abstraction or spending too much time creating abstraction where the domain doesn't naturally lend itself to abstraction. (Note that points 2 and 1 tend to dictate that duplication should be avoided: it isn't about the typing saved, it is about correctness.) Priority 3 could be elaborated as "quick response times and avoidance of unnecessary resource use". Any idiot can write code that does X. A craftsperson writes code that does X well. A valuable craftsperson can do X well and quickly. Be a craftsperson. For rapid prototyping you can throw the rules slightly overboard, but when you write production code things count. Abstractions and language mechanisms that can give you static guarantees are good when they help you achieve the above. They are counter-productive when they conflict with any of the above. It is easy to become counter-productive when you try to satisfy some dogma.