Code Inflation [pdf]
computer.org
Code Inflation [pdf]
1–10 of 30 posts
Re: Code Inflation [pdf]
#2Here's a link to the coreutils source for true if anyone's interested:
http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/true...
I think the argument can be made that command lines tools shouldn't provide versioning and help text at all - leave it up to the manual pages.
Re: Code Inflation [pdf]
#3A good and informative read. While I'm new to programming, I have began to judge my productivity in terms of lines of code I remove, not add to a project.
Re: Code Inflation [pdf]
#4The same is true for standards. There are often so many non-features that make the standard harder to implement yet bring no real advantage. With standards the problem is that you have to implement everything to be standard-compliant.
And then you have a reluctance to remove the cruft that nobody uses in newer versions of the standard.
I'm currently working a bit with SVG paths. There are some features that aren't really used that much in the wild. For instance quadratic bezier curves, arcs, a shorthand syntax for successive horizontal/vertical lines in a subpath. Those things could be debated but they are okay.
Then we also have things that are really just unneeded. You can also write numbers in xxEyy or xx.yyEzz way. Scientific notation has limited uses, computer graphics is not one of them. You can use a comma in addition to optional whitespace, but only at specific locations and at most one. Also there's exactly one place in the grammar where the whitespace is not marked optional.
Re: Code Inflation [pdf]
#5A good and informative read. While I'm new to programming, I have began to judge my productivity in terms of lines of code I remove, not add to a project.
If all programmers did what you are doing, we would not have the problems we do.
I hope someone gives you a medal and merit badge and a cookie.
[1] have begun
Re: Code Inflation [pdf]
#6"OMG, /bin/sh increased in size by 191x from 1974 to 2015!" seems like the byte-counting equivalent of people who lose their minds about "YOUR FOOD HAS CHEMICALS IN IT WITH COMPLICATED NAMES!". Both sound impressive and might make you worry - and both omit important facts that would greatly reduce that effect.
For instance, 191x growth since 1974 seems steep until you realize that the corresponding storage has grown from, say, 10.5MB (capacity of an RL02 for the PDP11) to ~1TB; a scaling of 100000x over the same period. That's not even really comparing apples-to-apples; the RL02 was not the sort of thing you'd have on your desk.
Re: Code Inflation [pdf]
#7A good and informative read. While I'm new to programming, I have began to judge my productivity in terms of lines of code I remove, not add to a project.
Awesome. You're following in some big footsteps: http://akkartik.name/post/28672493
Re: Code Inflation [pdf]
#8A good and informative read. While I'm new to programming, I have began to judge my productivity in terms of lines of code I remove, not add to a project.
If all programmers did what you are doing, we would not have the problems we do. I hope someone gives you a medal and merit badge and a cookie. [1] have begun
Agreed; I now always run a minifier before committing.
Re: Code Inflation [pdf]
#9"OMG, /bin/sh increased in size by 191x from 1974 to 2015!" seems like the byte-counting equivalent of people who lose their minds about "YOUR FOOD HAS CHEMICALS IN IT WITH COMPLICATED NAMES!". Both sound impressive and might make you worry - and both omit important facts that would greatly reduce that effect. For instance, 191x growth since 1974 seems steep until you realize that the corresponding storage has grown…
If we'd gotten 191 times better at avoiding bugs and security issues (and those problems scaled linearly with code size), this would be to the point.
Re: Code Inflation [pdf]
#10The problem with code inflation is not the the space needed on disk or in memory. The real problem lies in the quality assurance area. With every byte a program grows (in source code), the complexity of the system also grows with it. It is not only inherent complexity, but also extrinsic complexity -- for example dependencies from dynamic libraries and also the dependencies from the operating system.
With the growing complexity, the systems become more and more fragile and difficult to maintain. You can see that, when software just fails on one computer and runs on an other computer with the same operating system, but some little, weird dependency (e.g. with the graphics card) just makes the program misbehave on that particular computer.
Some times I am just worried, that all the computer scientists of the world make the world of computers more and more complex and on one day, the software becomes unmanageable. Even today, as normal computer user, I some times get the impression, that computers take more time (for installing updates and updates of the updates, worrying about threats, getting the best virus scanner ...) as they save us.