3 ms·
>I agree, but that's where the many caveats come in. First, my argument is more one of diminishing returns (following Brooks's theory). I.e., languages make an
by fauigerzigerk 7y ago
>I agree, but that's where the many caveats come in. First, my argument is more one of diminishing returns (following Brooks's theory). I.e., languages make an increasingly small difference. C may have been a big improvement over assemby, and Java may have been a smaller but still quite big improvement over C, but now differences are quite small.
I don't necessarily disagree, but I'm a bit skeptical about the way in which you use the concept of diminishing returns. If I'm not mistaken then Brooks used diminishing returns in relation to headcount. And this is in fact how economists use the term as well - adding quantitatively more of one production factor.
But that doesn't apply to qualitative changes like introducing new production methods and tools, which is what programming languages are. New programming languages are not simply "more programming language".
If we agree that there have been observable effects of new programming languages in the past, then we cannot exclude the possibility of the same happening in the future.
>First, the difference in LOC is not as big as PL fans claim
What PL fans claim is a bit of a fluffy benchmark, but there are undoubtedly significant differences in LOC, certainly significant enough to make an economic difference.
>I've been programming for about 30 years now...
Shockingly, me too :)
- pron 7y ago> If I'm not mistaken then Brooks used diminishing returns in relation to headcount. Oh, I'm referring to "No Silver Bullet" and diminishing returns in the sense that languages at best help with "accidental complexity", so the less of it there is, the less languages can help. > New programming languages are not simply "more programming language". But there are inflexible theoretical limitations on their utility (even without Brooks). We know the effect of different programming constructs on expressive compression and reasoning costs. The closer we get to the limit, the less benefit we can have. > then we cannot exclude the possibility of the same happening in the future. I'm mostly pointing out that it's not happening at present. I'm less sanguine about future advances because of various limitations (and, BTW, Brooks's predictions were called overly pessimistic by PL fans at the time and it turned out they were too optimistic), but I won't rule out another major breakthrough, or possibly two. > but there are undoubtedly significant differences in LOC, certainly significant enough to make an economic difference. I don't think I agree with your first assertion (although that depends on what we mean by "significant" here), and I certainly disagree with your second. We simply have not been able to detect or induce such an effect. Here, too, there are theoretical results showing that increased expressiveness cannot lead to cheaper reasoning, which is not an obvious result even in the worst case (because there are far fewer "compressible" programs than non compressible ones).
- fauigerzigerk 7y ago>We know the effect of different programming constructs on expressive compression and reasoning costs. The closer we get to the limit, the less benefit we can have. >Here, too, there are theoretical results showing that increased expressiveness cannot lead to cheaper reasoning, which is not an obvious result even in the worst case (because there are far fewer "compressible" programs than non compressible ones). I find that very interesting. Do you have a source for it?
- pron 7y agoYes. Some interesting papers are: * http://www.lsv.fr/Publis/PAPERS/PDF/Sch-aiml02.pdf http://www.lsv.fr/Publis/PAPERS/PDF/Sch-aiml02.pdf * http://www.lsv.fr/Publis/PAPERS/PDF/DLS-jcss-param.pdf http://www.lsv.fr/Publis/PAPERS/PDF/DLS-jcss-param.pdf * https://www.cis.upenn.edu/~alur/Zohar03.pdf https://www.cis.upenn.edu/~alur/Zohar03.pdf What's important to put those results in context for those who are not familiar with the subject is that, in the context of complexity theory, the "model checking problem" does not refer to the complexity of a particular model checker algorithm, but to the inherent complexity of the problem of deciding whether a program M satisfies some property 𝜑 (i.e. whether M is a model of 𝜑 in the formal logic sense). The "model checking problem" is the closest to a mathematical description of what we usually mean when we talk of "reasoning about a program." I've summarized these results and more here: https://pron.github.io/posts/correctness-and-complexity https://pron.github.io/posts/correctness-and-complexity
- fauigerzigerk 7y agoThanks!