Hacker News Reader

Comment by jodrellblank | Hacker News Reader

His suggestion is that the cure for code bloat is, basically, codegolf?

So... is bloat extra features, extra code, or extra resource usage? Is it bloated if you have the same features in fewer lines, or fewer lines with more resource usage?

It's almost as if bloat is a meaningless snarl term with a mostly illusory definition beyond "bad".

Meaningless snarl? How DRY is your code, and have any refactoring attempts been made to dry up the code. Do you have unused functions, methods, classes that are there because you think you might need them in the future. Does every binary have all the code for other architectures that are not specific to the current platform of execution. Etc... I could go on with several more examples, but it's the exact opposite of illusionary.

If everyone has a different definition, the term has no real definition. That's my point.

Those aren't different definitions, they're all examples of artifact waste. If something has multiple examples, it doesn't mean it has multiple definitions.

Except your example of "extra" is my example of "just enough".

I didn't use the word extra.

If they're "extra" then they are unnecessary; I define code bloat strictly as redundant code inside the source tree.

Redundant code has performance and resource ramifications: Programs that are bigger load slower (more bytes to pull from disk) and run slower (more trips in and out of cache memory).

Redundant code also has other ramifications: Two modules in the same source tree may attempt similar (or identical) algorithms and miss an opportunity to consolidate. One of them might hide a bug, where the other code path was executed more frequently and the bug fixed.

I have seen this on a grand scale - 72MM LOC over multiple versions (10 year span) of multiple products by the same well-known software company. The occurrence of nearly identical code was the most surprising find.

One product had minimal redundancy. It used a plug-in architecture for the entire application - not just for extensions.

Your idea of "superfluous" is my idea of "just enough", and vice-versa.

For example, why have Bentley when we already have Ford? Multiple car manufacturers is surplus, waste, and bloat.

I didn't use the word "superfluous". I define code bloat strictly as redundant code inside the source tree.

Car manufacturers do not exist inside the source tree.

They aren't even obviously unnecessary; After all, people have different tastes about whether they like a Bentley or they like a Ford.

The computer (however) does not have taste, and it doesn't care whether you like your strcmp or my strcmp.

I was thinking the same thing myself. Like your code may be 1/10th the length but you need to find someone with a seemingly rare skill set to maintain it.

But what skill is this?

Is it something we can develop in people? Teach? Practice?

It may be rare that people will do it and invent it on their own, but I know there was a point in my life that I did not want to write code this way, so I know at least one person can change.

Yes people can change that is true, and I don't think anyone goes into a CS or IT program thinking this will be the type of code they write. The skills really are to think differently about code, and functional programming. Two things that are not taught in American universities(Or companies for that matter). So I feel like if I were to choose K as the language for my project which I expect to hire others to work on, I would have to build a K community in my area just to have the talent to work on my project.

I'm not (yet) advocating we all program in K, but we start with the simpler problem of trying to talk about programming like scientists: To try to define things only in terms of what we can measure.

The speed at which code runs? The size that the binary is? The size of the source file? How long it takes to build software that runs correctly?

These are things we can measure, and while I suspect once we optimise programming languages for these things we will end up with something that looks like K, I do not think that it will be K because I have noticed that K is very bad at some things that I like to do.

That's an interesting way to put it.

Yes. It might be.

Reply on news.ycombinator.com