12 ms·

6 years ago, I rewrote 30 000 lines of C++ code in 1000 lines of Ruby. A year ago, I rewrote 424 lines of Java+Spring+Hibernate in 18 lines of bash. This is l

6 years ago, I rewrote 30 000 lines of C++ code in 1000 lines of Ruby. A year ago, I rewrote 424 lines of Java+Spring+Hibernate in 18 lines of bash. This is less glorious, but if you compare the size of the deliverable, it's 39Mb for the J2EE webapp against… 772 bytes for the shell script. At my current job, I maintain an app with 500,000 lines of code that could easily fit in 20,000. Code bloat is indeed a recurrent problem.

brandonbloom 11y ago
My experience mirrors yours. I'd like to also stress that it's not just 30:1 ratios that are worthwhile. Most recently, I just rewrote a decently written ~8 kloc C program in to a ~4 kloc Go program that does 5 times as much, 10 times faster. If I had more time, I could probably shrink the new Go program to about half its size. This new program includes the old, as well as a new simplified interface, both HTTP. Moving clients to the new interface has had cascading C#/Scala code reduction of ~1 kloc each. This is the most important point! Simplicity breads more simplicity.
- grandalf 11y ago
  Exactly. I have recently had a few cases where I've rewritten bloated overly-complex js into 10% to 20% of the LOC. The big benefit is the drastic complexity reduction. Suddenly the junior developers look like superstars because they can understand it and their productivity soars. I'm continually surprised at how otherwise smart engineers end up writing boated spaghetti that is 'correct' at the micro level but ridiculous at the macro level. A few poorly chosen abstractions can increase the cost of development by 10x easily.
throwaway999888 11y ago
Rewriting something like C++ into a higher level language with a heavier runtime wouldn't necessarily be reducing code bloat in the author's eyes. He's talking about "bloat" in the sense of the whole stack, not just how many lines you write on top of the stack.
- deleted 11y ago
  [deleted]
jzd 11y ago
two words: job security
- wmt 11y ago
  You write bloated code for job security? Shame on you. Typically bloated code comes from legacy and years of organic growth. I'd imagine almost any 30k LOC project in any language that has been developed more than just a few years could be rewritten in a small fraction of the original size, now that you actually know what the end result must do, a luxury you don't have on the first go.
  - enraged_camel 11y ago
    >>You write bloated code for job security? Shame on you. Try to give him the benefit of the doubt. There's no indication that that's what he meant. Instead, he probably meant that one possible reason people write bloated code -- or at the very least, do not attempt to refactor it after writing it -- is that it provides them with job security. Which is a fair point.
  - imtringued 11y ago
    Adding feature X instead of refactoring the code base contributes to job security.
mightybyte 11y ago
7 or 8 years ago I had to take over a Java project on the order of ~10k lines. I reduced the code size by 77% by rewriting it in, wait for it...Java.
- gnarbarian 11y ago
  Hindsight is 20-20. The iterative bloat during development can happen for so many reasons. (Numerous changes in requirements late in the project, many developers working on numerous modules, design for flexibility and expansion that are never used, going too far down a path that turns out to be more work than an alternative). Once a program has been in production for a while and its use cases are more well defined it becomes easier for a single person to swoop in and rewrite it in a far more conscice way. In most of these cases I think the language is pretty irrelevant in terms of how much can be culled.
  - deleted 11y ago
    [deleted]
  - alch- 11y ago
    Call me a starry-eyed idealist, but > The iterative bloat during development can happen for so many reasons. (Numerous changes in requirements late in the project, ... and people not cleaning their mess up afterwards; > many developers working on numerous modules, ... without proper coordination, or, without the drive to keep things clean (i.e. proper manners); > design for flexibility and expansion that are never used, ... and never cleaned up, i.e. left there to rot by the people who put them there; > going too far down a path that turns out to be more work than an alternative) ... and not cleaning up. > Once a program has been in production for a while and its use cases are more well defined it becomes easier for a single person to swoop in and rewrite it in a far more conscice way. I think it's always easier for the guy/gal who wrote something to clean it up than for the next guy/gal, who doesn't know the code or its history as well. Really, this is all just people not cleaning up (or being allowed to clean up) after themselves. Now if we could all just be nice to each other and hold hands..
    - 11y ago
JustSomeNobody 11y ago
How many LOC is the ruby runtime?
- Jach 11y ago
  How many LOC is GCC?
  - hamiltonkibbe 11y ago
    Or the OS it's running on?
    - agumonkey 11y ago
      And in Forth, you write the OS.
      - hamiltonkibbe 11y ago
        But the real question is how many lines of HDL went into the design of the processor?
        agumonkey 11y ago
        We have a bigger problem, nobody found electron source code yet.
        hamiltonkibbe 11y ago
        https://github.com/atom/electron https://github.com/atom/electron
        sklogic 11y ago
        It is proprierary, but yet pretty cheap and it comes with a comprehensive datasheet without an NDA: http://pdglive.lbl.gov/Particle.action?node=S003 http://pdglive.lbl.gov/Particle.action?node=S003
        11y ago
aplorbust 11y ago
"...424 lines of Java+Spring+Hibernate in 18 lines of bash." Curious. Were you paid to write the Java? If yes, how much did your employer spend to license that software? Is it possible that bloat supports livelihoods?
- logn 11y ago
  I'm not the GP, but speculating... The Java code itself probably took less than a few days to write. Java/Spring/Hibernate have no licensing fees (in most cases) and is an industry-standard stack. I'm guessing the original author didn't write it in Bash because either (1) they didn't know Bash, (2) they didn't know if/when requirements would expand beyond what Bash can easily do, (3) they wanted platform independence, or (4) their team wrote everything else on the Java/Spring/Hibernate stack. You can argue the merits of all those reasons, but I don't see bloat being profitable as a factor. The difference in lines and executable size is likely due to an apples-to-oranges situation. Bash scripts seem really light weight if you're not counting all of their system dependencies and if you're writing a program that Bash excels at (such as moving data around).
  - jack9 11y ago
    When they say "wrote in Bash" more than likely they used Bash to script together existing unix tools, than used Bash to do some algorithm that couldn't be done as code-efficiently in java.
  - aplorbust 11y ago
    You're speculating no fees paid to Oracle? "J2EE" does not suggest Oracle in any way? My understanding is that companies that license proprietary software are heavily involved in writing these open standards. Incorrect? Please forgive my ignorance re: Java. I think Moore was writing about drivers written in C. Is the GP's story about programmers at a hardware company? Does it matter that most of the comments are about high-level programming, not writing drivers? Just wondering...
    - logn 11y ago
underwater 11y ago
In my experience there are two main causes of code bloat. One is that people use abstractions that are more verbose than necessary. The fact this is bad is pretty uncontroversial. Though very few people go out of their way to write bad code, it's just that everyone's view on the right amount of abstraction is different. What's fine to you might look like gibberish to me. I've radically simplified code by converting complex regexes to multiple steps, for example. The other cause of bloat in mature code is the inevitable bug fixes, feature requests, and edge cases that accumulate over time. Having the attitude that a system is unnecessary complex is dangerous because you don't know which of these edge cases could doom your rewrite. Even if you do manage to ship a simplified version of the system it's incredibly difficult to maintain the pristine state of the system. Unless you devote all your time to playing code police then cruft will creep back in when others touch the code. This is where having more abstractions can actually help, because good abstractions limit the impact a bad piece of code can have.
- jandrese 11y ago
  Excessive abstraction might otherwise be called Enterprise Class Code Syndrome.
  - paulddraper 11y ago
    Your post begs for a definition of too little abstraction.
    - EvanPlaice 11y ago
      'The Unix way' would be an example of too little abstraction. Sure it's great to have lots of little single purpose applications that can be mixed/matched in a variety of different ways. But... If everything in a system is built based on that premise, eventually the OS just becomes a lousy abstraction for a global namespace. I think it's important to strike a middle ground. Build tools that work well for solving a 'class' of problems, then include public interfaces so they can be re-used for the higher level composition of systems.
- 11y ago
nly 11y ago
Most of this is probably due to better libraries and forfeiting the static type system. There's very little that Ruby can offer that imho should allow a program to become shorter than the equivalent C++ by more than, say, a factor of 2. Bash and Perl might be the only exceptions to this due to their incredibly terse syntax for a certain subset of tasks.
- SomeCallMeTim 11y ago
  Umm...Ruby inherited most of Perl's terse syntax, or at least it did originally? I haven't followed recent versions of Ruby very closely. (And by "recent" I mean post-Rails.)
- njharman 11y ago
  Better libraries and loosing static boilerplate is 90% of what dynamic languages offer. Kind of like saying other than the higher horsepower and aerodynamics Porshe Boxter has very little in the way of speed over a Ford Taurus.
SomeCallMeTim 11y ago
Not to argue that code bloat is a problem, but the concept of writing things in any dialect of Forth makes me cringe. I played with Forth. Sure you can do complex things without parenthesis, but if you squeeze something complicated into a single line equation, it will be harder for a human to follow than if you use parenthesis. The original article also says "It's never clear how efficiently source will be translated into machine language," which is complete garbage: Most modern processors were designed precisely to optimize for the kinds of control and data structures that C creates, and C (though NOT C++) has close to a one-to-one mapping from code you write to assembly language output. A key exception is those infix equations, which C can reorder in ways that are more optimal than a naive developer writing Forth would create, so this hardly seems like a recommendation for Forth. This is all orthogonal to whether bloat exists or is a bad thing. I think that bloat exists and is a bad thing primarily because developers are some combination of lazy, unskilled, or pressured to complete features on constant deadline. And honestly, in most cases it's probably all three, though I would guess anyone reading HN is mostly afflicted with the last.
- sklogic 11y ago
  > it will be harder for a human to follow than if you use parenthesis Not any harder than following Master Yoda speech. OTOH, following something (say, an English text) (which is heavily parenthesised) may be (I'm sure there is a lot of references to back this notion) exceptionally hard (even if there is just one nested level (and more levels certainly add more confusion)). Choosing flat over structured often makes a lot sense.
  - SomeCallMeTim 11y ago
    Valid Forth syntax: 6 8 7 5 4 + * - + . -49 ok Tell me that's easier to read than 8+6-(4+5)*7 Parenthesis can make things harder to understand if poorly used. RPN can make things harder to understand if poorly used. The reverse is also true for both. Forth does not prevent bad code.
    - sklogic 11y ago
agumonkey 11y ago
From the bsd init / systemd blog article of today: https://github.com/freebsd/freebsd/blob/master/etc/rc https://github.com/freebsd/freebsd/blob/master/etc/rc (standing on https://github.com/freebsd/freebsd/blob/master/etc/rc.subr https://github.com/freebsd/freebsd/blob/master/etc/rc.subr) made me feel the same.
jclulow 11y ago
I tend to find that shorter, putatively simpler bash scripts are often shorter because they don't do adequate (or, at times, any) checking of error conditions. It is deceptively easy to write a terse shell script when you assume that every command, or pipeline of commands, will work exactly as you expect every time. In practice, even simple operations like "rm", or "mkdir", or even "cd" can fail in new and exciting ways. The blanket use of "errexit" and "pipefail" is really only the bare minimum of error handling; scripts that simply _stop_ as soon as a command exits non-zero are not generally an operable product that somebody unfamiliar with the innards of the system can be expected to work with. It is also unfortunately easy to miss out on putting quotes around expansions, or to get caught out by the somewhat peculiar behaviour of variable scoping in functions. Some improved constructs are available in more recent versions of bash, but if the goal is to be _portable_ (without also shipping your target bash binary) you may not be able to use some or any of them. The bash "language" (such as it is) is antiquated and clunky, because it seeks to be backwards compatible with the rich tapestry of history that is the Bourne shell. A truly robust, operable program written in this environment often does not come out a whole lot shorter (if it is shorter at all) than a program written in another language with better facilities.
e12e 11y ago
> 6 years ago, I rewrote 30 000 lines of C++ code in 1000 lines of Ruby. (...) > Code bloat is indeed a recurrent problem. But in your example, you're still depending on thousands (millions?) of lines of BIOS, OS, library, runtime code. It's so many orders of magnitude different than the point Moore is making -- and also, more subtly different: it's not like Forth system don't have library/OS code -- but eg. fitting a rich editor/IDE and OS on a floppy is quite different from eg: Ruby. It's a completely different mindset. Even if something like Ruby does a lot of things out of the box, if you were to strip it down to a subset that only allowed to be used as a caluclator repl, it'd still be quite complex compared to a Forth system (just think about all the code need to handle keyboard input, and talking to the monitor over VGA/HDMI etc). None of that invalidates your point, that code bloat is a problem, I just think it highlights that there are different kinds of bloat. Somewhere between colorForth and developing in in a "traditional" language with a "traditional" IDE on a "traditional" OS, we find things like Project Oberon and Smalltalk-80. Or VPRI's recent effort to create a full drivers-through-gui-up-to-and-including-applications system in 50kcloc total, making aggressive use of DSLs to manage the complexity.
72deluxe 11y ago
What were you doing wrong/differently in C++ that required much more code? Would you write it in C++ differently if you did it again?

brandonbloom 11y ago

My experience mirrors yours. I'd like to also stress that it's not just 30:1 ratios that are worthwhile. Most recently, I just rewrote a decently written ~8 kloc C program in to a ~4 kloc Go program that does 5 times as much, 10 times faster. If I had more time, I could probably shrink the new Go program to about half its size. This new program includes the old, as well as a new simplified interface, both HTTP. Moving clients to the new interface has had cascading C#/Scala code reduction of ~1 kloc each. This is the most important point! Simplicity breads more simplicity.

grandalf 11y ago
Exactly. I have recently had a few cases where I've rewritten bloated overly-complex js into 10% to 20% of the LOC. The big benefit is the drastic complexity reduction. Suddenly the junior developers look like superstars because they can understand it and their productivity soars. I'm continually surprised at how otherwise smart engineers end up writing boated spaghetti that is 'correct' at the micro level but ridiculous at the macro level. A few poorly chosen abstractions can increase the cost of development by 10x easily.

throwaway999888 11y ago

Rewriting something like C++ into a higher level language with a heavier runtime wouldn't necessarily be reducing code bloat in the author's eyes. He's talking about "bloat" in the sense of the whole stack, not just how many lines you write on top of the stack.

deleted 11y ago
[deleted]

jzd 11y ago

two words: job security

wmt 11y ago
You write bloated code for job security? Shame on you. Typically bloated code comes from legacy and years of organic growth. I'd imagine almost any 30k LOC project in any language that has been developed more than just a few years could be rewritten in a small fraction of the original size, now that you actually know what the end result must do, a luxury you don't have on the first go.
- enraged_camel 11y ago
  >>You write bloated code for job security? Shame on you. Try to give him the benefit of the doubt. There's no indication that that's what he meant. Instead, he probably meant that one possible reason people write bloated code -- or at the very least, do not attempt to refactor it after writing it -- is that it provides them with job security. Which is a fair point.
- imtringued 11y ago
  Adding feature X instead of refactoring the code base contributes to job security.

mightybyte 11y ago

7 or 8 years ago I had to take over a Java project on the order of ~10k lines. I reduced the code size by 77% by rewriting it in, wait for it...Java.

gnarbarian 11y ago
Hindsight is 20-20. The iterative bloat during development can happen for so many reasons. (Numerous changes in requirements late in the project, many developers working on numerous modules, design for flexibility and expansion that are never used, going too far down a path that turns out to be more work than an alternative). Once a program has been in production for a while and its use cases are more well defined it becomes easier for a single person to swoop in and rewrite it in a far more conscice way. In most of these cases I think the language is pretty irrelevant in terms of how much can be culled.
- deleted 11y ago
  [deleted]
- alch- 11y ago
  Call me a starry-eyed idealist, but > The iterative bloat during development can happen for so many reasons. (Numerous changes in requirements late in the project, ... and people not cleaning their mess up afterwards; > many developers working on numerous modules, ... without proper coordination, or, without the drive to keep things clean (i.e. proper manners); > design for flexibility and expansion that are never used, ... and never cleaned up, i.e. left there to rot by the people who put them there; > going too far down a path that turns out to be more work than an alternative) ... and not cleaning up. > Once a program has been in production for a while and its use cases are more well defined it becomes easier for a single person to swoop in and rewrite it in a far more conscice way. I think it's always easier for the guy/gal who wrote something to clean it up than for the next guy/gal, who doesn't know the code or its history as well. Really, this is all just people not cleaning up (or being allowed to clean up) after themselves. Now if we could all just be nice to each other and hold hands..
  - 11y ago

JustSomeNobody 11y ago

How many LOC is the ruby runtime?

Jach 11y ago
How many LOC is GCC?
- hamiltonkibbe 11y ago
  Or the OS it's running on?
  - agumonkey 11y ago
    And in Forth, you write the OS.
    - hamiltonkibbe 11y ago
      But the real question is how many lines of HDL went into the design of the processor?
      - agumonkey 11y ago
        We have a bigger problem, nobody found electron source code yet.
        hamiltonkibbe 11y ago
        https://github.com/atom/electron https://github.com/atom/electron
        sklogic 11y ago
        It is proprierary, but yet pretty cheap and it comes with a comprehensive datasheet without an NDA: http://pdglive.lbl.gov/Particle.action?node=S003 http://pdglive.lbl.gov/Particle.action?node=S003
      - 11y ago

aplorbust 11y ago

"...424 lines of Java+Spring+Hibernate in 18 lines of bash." Curious. Were you paid to write the Java? If yes, how much did your employer spend to license that software? Is it possible that bloat supports livelihoods?

logn 11y ago
I'm not the GP, but speculating... The Java code itself probably took less than a few days to write. Java/Spring/Hibernate have no licensing fees (in most cases) and is an industry-standard stack. I'm guessing the original author didn't write it in Bash because either (1) they didn't know Bash, (2) they didn't know if/when requirements would expand beyond what Bash can easily do, (3) they wanted platform independence, or (4) their team wrote everything else on the Java/Spring/Hibernate stack. You can argue the merits of all those reasons, but I don't see bloat being profitable as a factor. The difference in lines and executable size is likely due to an apples-to-oranges situation. Bash scripts seem really light weight if you're not counting all of their system dependencies and if you're writing a program that Bash excels at (such as moving data around).
- jack9 11y ago
  When they say "wrote in Bash" more than likely they used Bash to script together existing unix tools, than used Bash to do some algorithm that couldn't be done as code-efficiently in java.
- aplorbust 11y ago
  You're speculating no fees paid to Oracle? "J2EE" does not suggest Oracle in any way? My understanding is that companies that license proprietary software are heavily involved in writing these open standards. Incorrect? Please forgive my ignorance re: Java. I think Moore was writing about drivers written in C. Is the GP's story about programmers at a hardware company? Does it matter that most of the comments are about high-level programming, not writing drivers? Just wondering...
  - logn 11y ago

underwater 11y ago

In my experience there are two main causes of code bloat. One is that people use abstractions that are more verbose than necessary. The fact this is bad is pretty uncontroversial. Though very few people go out of their way to write bad code, it's just that everyone's view on the right amount of abstraction is different. What's fine to you might look like gibberish to me. I've radically simplified code by converting complex regexes to multiple steps, for example. The other cause of bloat in mature code is the inevitable bug fixes, feature requests, and edge cases that accumulate over time. Having the attitude that a system is unnecessary complex is dangerous because you don't know which of these edge cases could doom your rewrite. Even if you do manage to ship a simplified version of the system it's incredibly difficult to maintain the pristine state of the system. Unless you devote all your time to playing code police then cruft will creep back in when others touch the code. This is where having more abstractions can actually help, because good abstractions limit the impact a bad piece of code can have.

jandrese 11y ago
Excessive abstraction might otherwise be called Enterprise Class Code Syndrome.
- paulddraper 11y ago
  Your post begs for a definition of too little abstraction.
  - EvanPlaice 11y ago
    'The Unix way' would be an example of too little abstraction. Sure it's great to have lots of little single purpose applications that can be mixed/matched in a variety of different ways. But... If everything in a system is built based on that premise, eventually the OS just becomes a lousy abstraction for a global namespace. I think it's important to strike a middle ground. Build tools that work well for solving a 'class' of problems, then include public interfaces so they can be re-used for the higher level composition of systems.
11y ago

nly 11y ago

Most of this is probably due to better libraries and forfeiting the static type system. There's very little that Ruby can offer that imho should allow a program to become shorter than the equivalent C++ by more than, say, a factor of 2. Bash and Perl might be the only exceptions to this due to their incredibly terse syntax for a certain subset of tasks.

SomeCallMeTim 11y ago
Umm...Ruby inherited most of Perl's terse syntax, or at least it did originally? I haven't followed recent versions of Ruby very closely. (And by "recent" I mean post-Rails.)
njharman 11y ago
Better libraries and loosing static boilerplate is 90% of what dynamic languages offer. Kind of like saying other than the higher horsepower and aerodynamics Porshe Boxter has very little in the way of speed over a Ford Taurus.

SomeCallMeTim 11y ago

Not to argue that code bloat is a problem, but the concept of writing things in any dialect of Forth makes me cringe. I played with Forth. Sure you can do complex things without parenthesis, but if you squeeze something complicated into a single line equation, it will be harder for a human to follow than if you use parenthesis. The original article also says "It's never clear how efficiently source will be translated into machine language," which is complete garbage: Most modern processors were designed precisely to optimize for the kinds of control and data structures that C creates, and C (though NOT C++) has close to a one-to-one mapping from code you write to assembly language output. A key exception is those infix equations, which C can reorder in ways that are more optimal than a naive developer writing Forth would create, so this hardly seems like a recommendation for Forth. This is all orthogonal to whether bloat exists or is a bad thing. I think that bloat exists and is a bad thing primarily because developers are some combination of lazy, unskilled, or pressured to complete features on constant deadline. And honestly, in most cases it's probably all three, though I would guess anyone reading HN is mostly afflicted with the last.

sklogic 11y ago
> it will be harder for a human to follow than if you use parenthesis Not any harder than following Master Yoda speech. OTOH, following something (say, an English text) (which is heavily parenthesised) may be (I'm sure there is a lot of references to back this notion) exceptionally hard (even if there is just one nested level (and more levels certainly add more confusion)). Choosing flat over structured often makes a lot sense.
- SomeCallMeTim 11y ago
  Valid Forth syntax: 6 8 7 5 4 + * - + . -49 ok Tell me that's easier to read than 8+6-(4+5)*7 Parenthesis can make things harder to understand if poorly used. RPN can make things harder to understand if poorly used. The reverse is also true for both. Forth does not prevent bad code.
  - sklogic 11y ago

agumonkey 11y ago

From the bsd init / systemd blog article of today: https://github.com/freebsd/freebsd/blob/master/etc/rc https://github.com/freebsd/freebsd/blob/master/etc/rc (standing on https://github.com/freebsd/freebsd/blob/master/etc/rc.subr https://github.com/freebsd/freebsd/blob/master/etc/rc.subr) made me feel the same.

jclulow 11y ago

I tend to find that shorter, putatively simpler bash scripts are often shorter because they don't do adequate (or, at times, any) checking of error conditions. It is deceptively easy to write a terse shell script when you assume that every command, or pipeline of commands, will work exactly as you expect every time. In practice, even simple operations like "rm", or "mkdir", or even "cd" can fail in new and exciting ways. The blanket use of "errexit" and "pipefail" is really only the bare minimum of error handling; scripts that simply _stop_ as soon as a command exits non-zero are not generally an operable product that somebody unfamiliar with the innards of the system can be expected to work with. It is also unfortunately easy to miss out on putting quotes around expansions, or to get caught out by the somewhat peculiar behaviour of variable scoping in functions. Some improved constructs are available in more recent versions of bash, but if the goal is to be _portable_ (without also shipping your target bash binary) you may not be able to use some or any of them. The bash "language" (such as it is) is antiquated and clunky, because it seeks to be backwards compatible with the rich tapestry of history that is the Bourne shell. A truly robust, operable program written in this environment often does not come out a whole lot shorter (if it is shorter at all) than a program written in another language with better facilities.

e12e 11y ago

> 6 years ago, I rewrote 30 000 lines of C++ code in 1000 lines of Ruby. (...) > Code bloat is indeed a recurrent problem. But in your example, you're still depending on thousands (millions?) of lines of BIOS, OS, library, runtime code. It's so many orders of magnitude different than the point Moore is making -- and also, more subtly different: it's not like Forth system don't have library/OS code -- but eg. fitting a rich editor/IDE and OS on a floppy is quite different from eg: Ruby. It's a completely different mindset. Even if something like Ruby does a lot of things out of the box, if you were to strip it down to a subset that only allowed to be used as a caluclator repl, it'd still be quite complex compared to a Forth system (just think about all the code need to handle keyboard input, and talking to the monitor over VGA/HDMI etc). None of that invalidates your point, that code bloat is a problem, I just think it highlights that there are different kinds of bloat. Somewhere between colorForth and developing in in a "traditional" language with a "traditional" IDE on a "traditional" OS, we find things like Project Oberon and Smalltalk-80. Or VPRI's recent effort to create a full drivers-through-gui-up-to-and-including-applications system in 50kcloc total, making aggressive use of DSLs to manage the complexity.

72deluxe 11y ago

What were you doing wrong/differently in C++ that required much more code? Would you write it in C++ differently if you did it again?