Your comment is currently downvoted, I didn't do that (I don't even have the necessary karma yet). I'm feeling somewhat supported by that, given it seems to be questioning my judgment or my ability to write software, although maybe that's not how you've meant it.
Yes, I've written software, a few hundred Kloc over two decades. That won't look like much. I think most of my code is pretty dense, though, yes, I'm taking my time usually, and I've largely worked alone, which supports that sort of activity. I've always wondered myself how you arrive at those huge code bases. Some people (like Torvalds in earlier projects) are just much more prolific, I don't have any illusions about that. I've written both in low-level languages (C, C++, some assembly) and high-level ones (Scheme, Perl, Python, Bash, some Haskell and JavaScript), more in the latter area.
I've been able to experience that the same code written in C++ is several times (IIRC 3-4x) larger than written in Scheme (both code bases were written by me, first in Scheme to flesh out the algorithm then rewritten in C++ identically except for the memory handling). And takes even rather longer than that to write. I can also see how having a language that's easy to work with will probably lead a developer to spend their time just producing more "meat" in the same time frame, leading to the same or possibly even larger numbers of loc. I can also see how needing to care a lot about how memory is managed might lead to caring a lot about other people's code, hence, to more re-use. Code being costly to create might also give management a sense of urgency to re-use it, or reduce the amount of it being written. But all of those points are just conjectures, I don't have any data on them. But it's interesting conjectures and I'm with you on them.
What I was, or meant to be, saying, is that we need more details and be careful about conclusions. Ranting about bloat is common, it seems fashionable, and there surely is truth about it having real downsides, and it may be right to try to get the world to care, but if one wants to influence anything, one needs to know the details. Already the label bloat itself is up to interpretation: is e.g. embedding a framework to serve ads bloat (a user would likely say yes) or essential (some businesses will say yes)? Is the feeling of drowning in bloat coming from the recent tendency of Windows doing too much undesired activity (again, probably warranted)?
I didn't mean to ridicule you by posting the link to the demo. I was making fun of our often present (shared?) desires of producing beautiful, small code--and the applicability to real-world money-making work. I might be proud if I can produce small code, but the business may very well not care at all (rightly so if it's at such extremes). As you say it takes time to write shorter code, and that has to pay off. Doing it any other way would not be smart. So, there must be a value to reduce code size, and what that is exactly is one of those details we're not talking about. So I've posted the link to say, hey, you could write such code, if you wanted--the question is just, do you want to? Does the business want to? Why, or why not? That's the interesting question, I think. And I was just correcting you on the numbers that you were posting.
Yes, I've written software, a few hundred Kloc over two decades. That won't look like much. I think most of my code is pretty dense, though, yes, I'm taking my time usually, and I've largely worked alone, which supports that sort of activity. I've always wondered myself how you arrive at those huge code bases. Some people (like Torvalds in earlier projects) are just much more prolific, I don't have any illusions about that. I've written both in low-level languages (C, C++, some assembly) and high-level ones (Scheme, Perl, Python, Bash, some Haskell and JavaScript), more in the latter area.
I've been able to experience that the same code written in C++ is several times (IIRC 3-4x) larger than written in Scheme (both code bases were written by me, first in Scheme to flesh out the algorithm then rewritten in C++ identically except for the memory handling). And takes even rather longer than that to write. I can also see how having a language that's easy to work with will probably lead a developer to spend their time just producing more "meat" in the same time frame, leading to the same or possibly even larger numbers of loc. I can also see how needing to care a lot about how memory is managed might lead to caring a lot about other people's code, hence, to more re-use. Code being costly to create might also give management a sense of urgency to re-use it, or reduce the amount of it being written. But all of those points are just conjectures, I don't have any data on them. But it's interesting conjectures and I'm with you on them.
What I was, or meant to be, saying, is that we need more details and be careful about conclusions. Ranting about bloat is common, it seems fashionable, and there surely is truth about it having real downsides, and it may be right to try to get the world to care, but if one wants to influence anything, one needs to know the details. Already the label bloat itself is up to interpretation: is e.g. embedding a framework to serve ads bloat (a user would likely say yes) or essential (some businesses will say yes)? Is the feeling of drowning in bloat coming from the recent tendency of Windows doing too much undesired activity (again, probably warranted)?
I didn't mean to ridicule you by posting the link to the demo. I was making fun of our often present (shared?) desires of producing beautiful, small code--and the applicability to real-world money-making work. I might be proud if I can produce small code, but the business may very well not care at all (rightly so if it's at such extremes). As you say it takes time to write shorter code, and that has to pay off. Doing it any other way would not be smart. So, there must be a value to reduce code size, and what that is exactly is one of those details we're not talking about. So I've posted the link to say, hey, you could write such code, if you wanted--the question is just, do you want to? Does the business want to? Why, or why not? That's the interesting question, I think. And I was just correcting you on the numbers that you were posting.
I hope that made my position clearer.