Hacker News Reader

Comment by crypt1d | Hacker News Reader

I find it a bit amusing that we used to build systems like this in the first place. There was no unused code because there was no _shared code_ , no libraries ,etc. You only used what you needed. Then we worked our way up to the 'common code' idea and generated enormous amount of libraries that systems come with by default and make programmer's life much easier. But now we realize that this is not very efficient after all, so we want to be able to write a program and then strip it of all the unnecessary code that we introduced(historically) in the first place. What is the lesson learned here? Is it that common code is not always a good idea, or is it that we need to write it in a way that is more _modular_ and easier to take apart and remove the blocks we dont need? Would such a change be even possible now?

View on HN

I think that there's a strong case for starting over, and doing it with your second suggestion in mind.

Much of our fundamental design is a whole generation (20-30 years) old in architecture, and has various modifications tacked on top of that original design. However, we've learned a substantial amount about what we're doing since then and are working with systems that are only poorly represented in those architectures. Many times we find that it's not possible to tack on the latest innovations to these legacy cores in a meaningful way, and that the only way to incorporate them properly would be a substantial rewrite, so we just sort of hack them on top and pretend.

I think it's a fairly normal process in most engineering fields to every few decades, reimagine some core technologies in light of new production methods and materials.

I honestly think it might be worth experimenting with fundamentally green field designs on various core technologies (like operating systems), in the sense of putting a serious development effort behind them (5-10 years of development work to reach parity with current ones) rather than purely as doctoral experiments that clearly aren't production ready.

There are lots of interesting approaches that aren't ever going to make it to market because no one wants to put in the time before the current approach completely fails, rather than just become an increasingly large stack of kludges.

Starting over is incredibly expensive, the more so when done at a deep level. Either you reimplement an existing API on top of it (quite a bit of work, doesn't pass through all the benefits of a redesign) or you also have to port or rewrite all your applications.

Well, the idea here is that with libraries in pure source form, a partial evaluator could be able to specialize and shrink down the program automatically, as you describe. So you'd get the best of both worlds.

I'm not aware of any systems that actually do this on a global level, but I have a feeling I may be surprised if I start looking around.

MirageOS is one such system that has been making the rounds here recently. (Also mentioned at the end of this Regehr posting)

I think the MLton SML compiler does this.

Well, link time optimization does this for C code in principle. It is fairly new in gcc and clang so it is not clear what it buys you in real world cases. A lot of code cant be compiled out because it is hard to prove it cannot be called. I plan to experiment with LTO and compiling a kernel and an application together at some point to see how it goes.

The increasingly higher-level languages that are being used now certainly contribute too, as back when Asm and C were the only popular languages, there was little or no unused code because the amount of effort required was great enough that adding any "superfluous abstractions" would mean basically no advantage to neither developer nor user since someone would have to expend effort to write that code, and at runtime it would also add overhead. Efficient, minimal code - often because of simple design - was encouraged more than it is today.

Now, thanks to all these libraries, frameworks, languages, etc., someone can in a single line of code summon dozens or more layers of abstraction - and be quite unaware of the actual amount of resources being used - until something breaks or feels too slow or runs out of memory. We are increasingly creating systems that are so complex and difficult to comprehend as a whole that they have nonobvious failure modes, and when they do fail, it's even more difficult to figure out why.

A more extreme and somewhat philosophical viewpoint on this: http://countercomplex.blogspot.ca/2014/08/the-resource-leak-...

Of course it's possible. Dead code stripping is pretty easy to do provided that you're also doing static linking. Proguard does this for Android apps and GWT does it when outputting JavaScript.

Server-side programmers haven't had to care as much but maybe we should.

This way you get all the advantages of shared code (all the libraries are still available when you're building the server), and most of the advantages of specialized code like lack of bloat.

"Would such a change be even possible now?"

Yes. I know it's possible because this is how I work.

It is unfortunate that avoiding "common code" sometimes involves more effort than just accepting it, but in my experience, once you have invested the time to free yourself from the "common code", it is gone forever. I find this to be a very liberating feeling.

The idea of "common code" that the user or developer "must" accept is, I think, seen on many levels.

From CPU's where I get dozens of instructions no program will ever use, to computers of all sizes that are pre-loaded with crapware I will never use, to operating systems that come with numerous drivers, libraries and programs I will never use, where the libraries themselves include dozens of functions never used, to IDE's where that would give me heaps of code that I will never use, to programs themselves, often loaded with features I will never use. I'm sure there is more but you get the idea.

Are there costs to "common code"?

For example, I have seen gratuitous features increase attack surface and make programs less secure. At the least these gratuitous features make the programs more complex.

One cost I would argue is time, which I would also argue the world's most valuable asset. But then I also have to invest time to avoid "common code".

I also see the "common code" problem in documentation. Manuals running in the hundreds or thousands of pages where the needed information could be conveyed succinctly and concisely in a few paragraphs.

What is behind this decision to always deliver "the kitchen sink"? Or maybe there is nothing behind it? As crypt1d says, it is amusing.

I recall many years ago various attempts at obtaining small command line utilities from Microsoft for working with Windows. In each case the utility was only a few KB. Yet obtaining the program always involved downloading a "kit" of several hundred MB or, in more recent years, several GB. Is this intentional? Mere oversight? What do you think?

Interestingly, the "common code" problem does not appear to have gained a foothold in the context of information retrieval. Even though users today have ample storage space and processing power to handle bulk data, in fact as much data as they will ever access in their lifetime, they are not usually presented with an option to download "the kitchen sink".

For example, I can download the entire Wikipedia, load it into a database using my database software of choice, wherein all my queries become local.

Or I can make each query across the open internet into a third party's database software of choice.

Obviously, the later approach might be more desirable to the third party as they can record all the queries. But the former "kitchen sink" approach is more appealing to me since the querying is faster and more reliable.

Reply on news.ycombinator.com