5 ms·
Does this depend on language? 20k lines of Perl is a different beast from 20k lines of Python, or 20k lines of verbose Java, I would expect. If not, does it sug
by fredley 9y ago
Does this depend on language? 20k lines of Perl is a different beast from 20k lines of Python, or 20k lines of verbose Java, I would expect. If not, does it suggest we should be aiming to use more expressive languages, that can get more done in less lines?
- evincarofautumn 9y agoJust from my own experience, I’d say yes, with qualification—rather like age is only an approximate indicator of maturity, line count isn’t a meaningful metric per se, but a proxy for more important, less tangible things like complexity, navigability, fitting the program in mind, and so on. In Haskell, for example, I can write software that does more things, using less code, with higher confidence that it’s correct, and much higher ability to change it, than I ever could in C++, my previous top language. That’s partly the language, partly the fact that it matches my style of thinking, and partly the culture around it—writing reusable code, heavily encapsulating state, and making as much of your program as possible “correct by construction” so that invalid states and state transitions are inexpressible—or at least harder to express, such that the easy path is also the right one. A 500-line Haskell module tends to feel very large to me, on par with 1–2000 lines or so of C++. I don’t necessarily mean to just evangelise Haskell or functional programming here. Any language & ecosystem with an expressive orthogonal core, which matches your problem space and not only matches but improves your style of thinking, can give you similar benefits if you’re deliberate about taking advantage of it.
- userbinator 9y ago...and 20k lines of APL is... probably not something any APL programmer has ever reached for any single application.
- ryanmarsh 9y ago20k lines of Perl is a different beast from 20k lines of Python, or 20k lines of verbose Java Very good point. We’re all familiar with the “I can do ${lambda} in ${n} lines with ${lang} language”. It seems to take me 10x more lines to do something in Java vs. Python, and 10x lines to do something in Python vs. Perl. Except that the Java is laborious to read, the Python is nicely readable, and the Perl will never be understood by a programmer. I had great fun writing Perl many years ago but I used to joke that Perl was a “write only” language.
- dublin 9y agoI had lunch with Eric Raymond here in Austin a 15-20 years ago, and he was lamenting the fact that he couldn't read his own Perl programs less than a year after writing them, so he was rewriting them all in Python. I never get religious about languages or platforms, but Python, which has been described as "executable pseudocode" does a nice job of balancing power and readbility. Idiomatic Perl is powerful, but opaque enough to be effectively unmaintainable. Since errors are pretty much proportional to LOC, it is best to use languages that offer "high leverage": Python, Tcl, and Lua come to mind. Note that C is still almost the only choice for real embedded work - it's unsurpassed at register bit-banging. (Well, except for assembly, but that requires skills that are no longer taught - interestingly, the same ones that make good embedded C programmers...)
- ryanmarsh 9y agohe couldn't read his own Perl programs less than a year after writing them A year? I often lost a half day trying to understand Perl I’d written less than a week before. I’m not exaggerating. I’m not sure what that says about me as a programmer but I’m terrified to find out.
- lmm 9y ago> Does this depend on language? 20k lines of Perl is a different beast from 20k lines of Python, or 20k lines of verbose Java, I would expect. Evidence is rare in our profession, but IIRC what little we have suggests no. > If not, does it suggest we should be aiming to use more expressive languages, that can get more done in less lines? Yes, it absolutely does. I recommend pursuing that approach.
- dahart 9y agoI suspect there might be a small difference, like 2-3x, but not a big one like 10x or more. Every large project I've ever seen in any language adopts a very different style than small projects. Large projects automatically start modularizing and using namespaces of some flavor, and the code typically becomes more explicit and more verbose, it becomes sparser compared to small programs. I think we should be aiming for more expressive languages that can get more done in less lines, but I don't think that will have any affect on this phenomenon of hitting a wall once the complexity is high enough. The main issue is less about how expressive the language is, and more about whether you can read a section of code and easily understand it's limits and constraints and side effects. In non-functional C, it can be really hard to spot pointer bugs, where a more functional Python program might be easier to debug and maintain.