4 ms·
How is it not an obvious oxymoron to call a language "too powerful"? Imagine a physicist or a mathematician calling a theory "too powerful". It explains too muc
by gruseom 15y ago
How is it not an obvious oxymoron to call a language "too powerful"? Imagine a physicist or a mathematician calling a theory "too powerful". It explains too much! You can prove too much with it!
We're not even close to understanding how to reliably make good programs, so naturally we don't understand how to do that with Lisp either. Lisp is just a particularly pure medium for programming. Most of the things people are saying about Lisp ("it allows people to invent their own little worlds") are really just statements about programming.
Oh and one other thing. A pox on the terms "readable" and "unreadable" floating around as free variables. They are hopelessly relative and their prominence in any discussion of programming (or should I say every discussion of programming) renders said discussion pointless. We literally don't know what we're talking about.
As pnathan brilliantly put it in another thread (http://news.ycombinator.com/item?id=3387432 http://news.ycombinator.com/item?id=3387432): "Intuitive is just what you've seen before." Bravo, pnathan.
- j_baker 15y agoEven worse than "readable" and "unreadable" are "maintainable" and "unmaintainable". At least I know what "readable" means at some level. But "maintainable" usually turns into a generic catch-all term for "this doesn't scare me too much".
- wpietri 15y agoIt's not an oxymoron because programming languages are tools for accomplishing specific purposes, and power is not the only thing that makes a tool good. For what it's worth, one can easily call a theory "too powerful" for practical purposes. E.g., one often uses Newtonian mechanics to analyze something rather than Einstein's more powerful approach. Human brainpower is a sadly limited resource, so "easy" often trumps "powerful".
- gruseom 15y agoIt's funny you should cite limited cognitive capacity, because the same starting point leads me in exactly the opposite direction. "Human brainpower is limited, so we should use weaker languages" seems a strange argument. The whole point of using more powerful languages is that they can express more with less, allowing us to fit more into limited human RAM. It's because our brains can't manage millions of details that we don't build systems directly out of machine instructions in the first place and resort to cleverer strategies like higher-level languages. At what point along the way does that process stop being valid?
- wpietri 15y agoIt's for the same reason that we sometimes favor Newton's tools over Einstein's: RAM isn't the only cognitive limit. "Powerful" in the sense you're using is similar to compression. The deeper the compression, the more effort it takes to unpack fully. Deeper abstractions are only useful in coding to the extent that you don't have to understand the details. But abstractions leak: http://www.joelonsoftware.com/articles/LeakyAbstractions.html http://www.joelonsoftware.com/articles/LeakyAbstractions.htm... As Martin Fowler writes, "Any fool can write code that a computer can understand. Good programmers write code that humans can understand." You might be able to turn 100 lines of Java into 1 line of Lisp, but if it takes your colleague more time to understand and modify the 1 line of Lisp than the 100 lines of Java, then you've made things worse.
- gruseom 15y agoThe deeper the compression, the more effort it takes to unpack fully. That implies that humans must mentally compile the code. By definition that's not true of a higher-level language. Ditto for your invocation of leaky abstraction: by definition, a program written in a language can be understood by learning the language and reading the program. If that's not true, then the program must not really be (fully) written in that language. The whole reason why we prefer a program in, say, C to a 100x larger program written in assembly language is that it's easier to understand. Given that available evidence points to source code size as the best measure of complexity and best predictor of errors -- there was a recent thread on HN about this with links to several papers -- I think the burden is on you to explain how the benefit of writing smaller programs in more powerful languages holds good up to, say, Java, but breaks down when you move to, say, Lisp or K.
- wpietri 15y agoIn theory, theory and practice are the same. In practice, they're different. The higher the language, the more abstract the abstractions. Each symbol represents more, and therefore hides more. There are manipulations on the symbols that are plausible in context but idiotic when one looks at the hidden details. I see that regularly with developers who have only worked in higher-level languages. From their perspective, they will see two approaches to the problem that will be equivalent. However, there will be 3 orders of magnitude difference in performance. By definition (well, your definition) that doesn't matter in a higher level language. In practice, it does. I don't think I've said that Java is some sort of magic universal middle point in languages (and indeed, I don't think that exists), so I don't accept the burden you're pushing on me. You asked how a language could be too powerful, and I tried to answer your question. If you have more questions, feel free to ask.
- ezyang 15y ago'Imagine a physicist or a mathematician calling a theory "too powerful". It explains too much! You can prove too much with it!' Actually, I can perfectly reasonably imagine a physicist complaining that a theory is too powerful. If a theory has the capability to explain any possible observation, it similarly does not have the capability of being falsified...
- gruseom 15y agoThat seems like a degenerate trivial case. A better objection would be Occam, that a simpler theory is preferable where adequate. But even that breaks down here, because we don't have any adequate "theories", only the hard problem of how to build complex software systems. I can see refusing an approach on the grounds that it doesn't work, but to refuse it on the grounds that it works too well?