3 ms·

Or you have to keep the codebase small. I'm not convinced an OS or programming language or database needs millions of lines of code. I'm not alone in this scep

Or you have to keep the codebase small. I'm not convinced an OS or programming language or database needs millions of lines of code. I'm not alone in this scepticism. Check out Alan Kay's STEPS project from a few years ago. The goal was to create a complete computing stack in 20k LoC. My current project has a similar goal: https://github.com/akkartik/mu#readme https://github.com/akkartik/mu#readme You mentioned tech debt. I think I have a more aggressive definition of tech debt than most: any dependency you rely on that you don't understand the internals of is tech debt. It's fine to take on in the short term, but you should be planning to pay it off in the long term. The approach modern software takes, of continually adding dependencies (each of which is itself growing monotonically complex) faster than anyone can internalize them, this approach feels utterly insane. Under this definition, my tiny tool is the least of someone's problems if say they depend on 60 Ruby Gems. Look at my definition of x86 instructions: http://akkartik.github.io/mu/html/013direct_addressing.cc.html http://akkartik.github.io/mu/html/013direct_addressing.cc.ht... If this is tech debt, I'll stay in debtors' prison, because it's safer inside than outside.

jopsen 7y ago
So if I use HTTPS to fetch resources from the internet, I must understand the internals of TCP, TLS, HTTP 1.1, HTTP/2, UDP, QUIC, HTTP/3 and the implementations of these protocols in the library I depend on for HTTP I/O. IMO, if you understand HTTP verbs, headers, response codes, body and the basics of REST. The beauty is that you don't need to understand the internals of every layer on the stack. In fact you can be unconcerned with whether libcurl does HTTP 1.1 or HTTP/2 on your behalf.
- akkartik 7y ago
  Sure. Protocols are like air. And I'll even give you a pass on your OS kernel. Can you think of any examples where my idea may be more useful? How about we measure mean time between security incidents. Spend time understanding your dependencies in order of their security records. And you just have to learn enough to go noping away from it. Once you delete a dependency you don't have to waste your time on it anymore. Does that seem useful? If it just gets you thinking about the full cost of ownership of your dependencies, I think chatting with me has paid for itself :) (None of this applies if you aren't providing a service to others, of course. If you're just learning, use whatever you want!)
scroot 7y ago
> I'm not convinced an OS or programming language or database needs millions of lines of code. I think this (implicit in most cases) belief that OSes are inherently complex and therefore require mounds of code is a result of our current computing culture and the expectations set by the open source movement. OSS/FOSS is great, but has kind of frozen things at Unix. We have sacrificed simplicity and comprehensibility in the name of platform compatibility. It's not just STEPS that shows another way, as compelling and underappreciated as that project is. Older systems like Oberon, Smalltalk, and even the Lisp Machines were examples of systems that had a different idea of what "simplicity" means. Unix principles, Posix architecture, x86 -- these things are not natural laws. They are artifacts with immense historical and cultural inertia. What's worse is that today we have widely accepted and utilized standards (for communication and data formats) that we didn't have back in the days of greater computing platform diversity. If anything this should be leading us to create exotic systems once again, now that they can better inter-communicate and translate data. But we aren't -- and not for technical reasons. We should make a rule that if the full computing system cannot be reasonably described in a book, then it isn't simple enough.
cryptonector 7y ago
Once you ship it gets very difficult to keep the codebase small because your customers will want you to stay backwards-compatible. This is a problem you want to have, of course, because you want to ship because you want to have revenue because you want to have earnings -- or just because you want to ship open source and keep a user community happy even if you make no money from it.
- akkartik 7y ago
  Making breaking changes and pushing them to your customers without warning is bad, no question. Staying compatible with everything forever is equally bad, but we only realize that over relatively long timescales. I think there's a middle-ground between these two extremes that hasn't been explored: when you make an incompatible change, fork. Patch only the worst bugfixes and security fixes on old forks (but continue these indefinitely). Point new users at the latest fork in each point in time. Support switching forks on your users' schedule. This approach adds some overhead for authors and maintainers. But I think it's not as much as we fear. And it can be automated over time. There's a selfish reason this never happens, but we don't talk about it in polite company: if you start forking yourself you make it more acceptable for others to fork you. I think that's a good thing. We should all stop playing shallow politics and encourage being forked by others.
  - cryptonector 7y ago
    Sure, you tell your customers that in so much time you'll be removing some feature. If you've got a large enough and popular enough OS, say, even so your codebase will get very large.
    - akkartik 7y ago
      No, you didn't understand what I meant. There is no single codebase serving all users. Some users are on v1, and they use its codebase. Some users are on v2, and they use its codebase. And on and on. There is no notion of removing features. All forks live forever. They just get updated less and less frequently over time. No single fork grows larger and larger over time.

jopsen 7y ago

So if I use HTTPS to fetch resources from the internet, I must understand the internals of TCP, TLS, HTTP 1.1, HTTP/2, UDP, QUIC, HTTP/3 and the implementations of these protocols in the library I depend on for HTTP I/O. IMO, if you understand HTTP verbs, headers, response codes, body and the basics of REST. The beauty is that you don't need to understand the internals of every layer on the stack. In fact you can be unconcerned with whether libcurl does HTTP 1.1 or HTTP/2 on your behalf.

akkartik 7y ago
Sure. Protocols are like air. And I'll even give you a pass on your OS kernel. Can you think of any examples where my idea may be more useful? How about we measure mean time between security incidents. Spend time understanding your dependencies in order of their security records. And you just have to learn enough to go noping away from it. Once you delete a dependency you don't have to waste your time on it anymore. Does that seem useful? If it just gets you thinking about the full cost of ownership of your dependencies, I think chatting with me has paid for itself :) (None of this applies if you aren't providing a service to others, of course. If you're just learning, use whatever you want!)

scroot 7y ago

> I'm not convinced an OS or programming language or database needs millions of lines of code. I think this (implicit in most cases) belief that OSes are inherently complex and therefore require mounds of code is a result of our current computing culture and the expectations set by the open source movement. OSS/FOSS is great, but has kind of frozen things at Unix. We have sacrificed simplicity and comprehensibility in the name of platform compatibility. It's not just STEPS that shows another way, as compelling and underappreciated as that project is. Older systems like Oberon, Smalltalk, and even the Lisp Machines were examples of systems that had a different idea of what "simplicity" means. Unix principles, Posix architecture, x86 -- these things are not natural laws. They are artifacts with immense historical and cultural inertia. What's worse is that today we have widely accepted and utilized standards (for communication and data formats) that we didn't have back in the days of greater computing platform diversity. If anything this should be leading us to create exotic systems once again, now that they can better inter-communicate and translate data. But we aren't -- and not for technical reasons. We should make a rule that if the full computing system cannot be reasonably described in a book, then it isn't simple enough.

cryptonector 7y ago

Once you ship it gets very difficult to keep the codebase small because your customers will want you to stay backwards-compatible. This is a problem you want to have, of course, because you want to ship because you want to have revenue because you want to have earnings -- or just because you want to ship open source and keep a user community happy even if you make no money from it.

akkartik 7y ago
Making breaking changes and pushing them to your customers without warning is bad, no question. Staying compatible with everything forever is equally bad, but we only realize that over relatively long timescales. I think there's a middle-ground between these two extremes that hasn't been explored: when you make an incompatible change, fork. Patch only the worst bugfixes and security fixes on old forks (but continue these indefinitely). Point new users at the latest fork in each point in time. Support switching forks on your users' schedule. This approach adds some overhead for authors and maintainers. But I think it's not as much as we fear. And it can be automated over time. There's a selfish reason this never happens, but we don't talk about it in polite company: if you start forking yourself you make it more acceptable for others to fork you. I think that's a good thing. We should all stop playing shallow politics and encourage being forked by others.
- cryptonector 7y ago
  Sure, you tell your customers that in so much time you'll be removing some feature. If you've got a large enough and popular enough OS, say, even so your codebase will get very large.
  - akkartik 7y ago
    No, you didn't understand what I meant. There is no single codebase serving all users. Some users are on v1, and they use its codebase. Some users are on v2, and they use its codebase. And on and on. There is no notion of removing features. All forks live forever. They just get updated less and less frequently over time. No single fork grows larger and larger over time.