14 ms·

1% the Code (2001)

143 points by mr_tyzic 11y ago

sam_lowry_ 11y ago
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?
modulus1 11y ago
> It's strongly typed, with a bewildering variety of types to keep straight. More errors. Odd complaint, especially to be levied against C.
- brandonbloom 11y ago
  Forth is completely untyped. Traditionally, all values are machine words.
  - david-given 11y ago
    Well... yes and no. Some values are multiple machine words, pushed onto the stack. Some of these (such as double-words) have language-defined representations. (They're always stored with the low word at the lower address, regardless of your machine endianness or, as far as I can tell, whether your stack is growing up or down. Which means that on some platforms the low word is pushed first, and on others the high word first. This shouldn't matter, because you should be using the dword words to manipulate them, except that it's common practice to assemble and disassemble dwords manually.) Some have implementation-defined implementation-defined representations. For example, the various bits of state that the control flow words push onto the return stack. You don't know how big any of these are, so accessing the return stack from inside loops is basically impossible. And some are just weird. Floating-point numbers live on their own stack. Except not necessarily; the implementation is allowed to store them on the data stack. So you can't use NIP TUCK OVER PICK etc because you don't know the layout of your stack. Basically, at every point, you have to know the type of the values on your stack so you can pick the right word (DROP vs 2DROP vs FDROP) to operate on the stack... and if you get it wrong, you get stack corruption and horrible, hard-to-debug crashes. tl;dr: Forth is typed. Forth is very typed. Forth just doesn't check types.
    - brandonbloom 11y ago
      That's one definition of "typed", but not a very useful one. By that definition _everything_ is typed. That's an interesting metaphysics discussion worth having, but not relevant to explaining Forth to a C programmer. Vanilla Forth values do not have runtime type information (such as class pointers or discriminator tags) nor does a traditional forth compiler have compile time type information (such as an abstracted understanding of the state of the stack at any given point of execution). Meanwhile, Factor, a modern stack language has both: SmallTalk-style object-oriented class pointers on every value, and a compile-time stack-effect checker. Factor values have a Lisp-like dynamic typing discipline. That is to say "uni-typed" as "dynamic", or a discriminated union.
chipsy 11y ago
Proclaiming that the syntax only causes problems stands in complete defiance of most people's preferences in programming syntax. We like syntax errors because they mold thoughts more precisely. Going against that is also going against a lot of "productivity enhancers" - we build them because we expect to have a lot of code, and we want to reduce the kinds of errors that it may contain. That doesn't mean that we should abuse them to write as much code as we can, but it does turn out that way in practice. So in an odd way Moore and co are right - we would be more free if we also constrained ourselves more on this point. But the broader thought is that you can apply such constraints at any time, in tandem with what you already like. And that is more likely to produce an innovation than "just Forth".
- Guvante 11y ago
  I think that needless compiler errors is an interesting point that isn't discussed often, so that at least is an interesting point. We have those productivity enhancers because the language makes it easy to make a mistake there. Ideally we would want to eliminate those mistakes without the syntactic headache. Although obviously how to do that is a complex exercise, I do think that saying "code bloat is bad" even against "bugs are worse" can provide interesting insights into what we really want from languages.
  - dietrichepp 11y ago
    It's discussed fairly often with static analyzers. Static analysis is a powerful tool, but false positives erode user confidence in the tool. I've worked with code bases where thousands of warnings (and even several errors) were left in place, which meant that you had to basically ignore all diagnostic messages every time you compiled. At that point, you might as well be 2>/dev/null. Someone even wrote a wrapper script that would diff the stderr against the "known good" stderr. My general impression of that project was that it was dying a slow death unless someone went in and restored developer confidence in the build process, and the most likely person was me :-/
throwaway999888 11y ago
If some C programmers have that scoff at higher level programmers attitude, Chuck Moore is the equivalent but addressed at C programmers (and higher, I guess). I have a feeling he's not the kind of person a C programmer could say things like "C is high-level (obvious one-to-one mapping) assembly" and "C is (blanket) efficient" around, and get away with it.
archgoon 11y ago
>But I'm game. Give me a problem with 1,000,000 lines of C. But don't expect me to read the C, I couldn't. And don't think I'll have to write 10,000 lines of Forth. Just give me the specs of the problem, and documentation of the interface. I could be wrong, but I'd wager that a lot of projects that are 1,000,000 lines of C don't have well defined interfaces or documentation. However, if the author wants to give it a shot, they could try replacing v8 with pure forth. That's a fairly well defined problem, they just have to maintain compatibility with the exposed v8 api.
- kctess5 11y ago
  I'm not sure the stats on this one, but it seems to be that something with 1,000,000 loc would have to have decent documentation, or it would be totally unmaintainable and wouldn't grow to that size without dying a horrible death.
  - protomyth 11y ago
    You would think that, but it can grow without understanding by adding code at the edges which expands then starts the cycle over. A code archeologist[1] would see a central island with bridges to developed islands with more bridges and various ships running between interfaces. Its particularly fun with multiple subsystem teams. Each one builds its own island of code and the bridges are scary. 1) please say that exists
    - TranquilMarmot 11y ago
      I could probably describe my current job as a "code archaeologist"...
    - archgoon 11y ago
      > 1) please say that exists The term 'software archaeology' has been used for a while https://en.wikipedia.org/wiki/Software_archaeology https://en.wikipedia.org/wiki/Software_archaeology And the wiki page suggests there are some consultants in the field. Many programmers trying to understand open source projects will dabble a bit in this.
qwertyuiop924 11y ago
You have got to be kidding me. I mean come on, you're joking, right? If you gave me some qualification, maybe. I know that FORTH is more compact than C, and the code decrease in size might be reasonable in some cases, but the reasons you give are insane! come on! Elaborate Syntax: Your syntax is simple, C's is less simple. If you want elaborate, look at PERL or Haskell. Redundancy and Confusing Types: Fair enough, but the types have to be the ones they are because C's supposed to be close to the metal. Therefore, you need specific bit sized types. It could be better than it is, though. Strong typing causes errors: Um. Take that up with the angry Haskellers lining up behind you. I'll just duck off this way... Honestly, C's type system is pretty awful, but that's not because it's strongly typed. Infix:...Yeah, pretty much, but the mainstream won't except anything else. Parens: Tell that to the lispers. Parens shine for syntax parsing, and the incredibly common editor support makes it even nicer than Python for editing. Unclear how source will be translated: Well, I guess, but more so than anything higher up the stack, like, just to pick a random example, most modern FORTH implementations. Subroutine calls are expensive: Compared to what? 1 mov or push instruction for for each arg, and than a call instruction, at least on x86. Most other processor architectures seem to have similar things going. Those are all pretty fast. Elaborate Compiler, Object Libraries: Yes, compared to FORTH, the compiler is elaborate, but that isn't why object libraries are distributed, seeing as there's a C compiler for every system under the sun. And distributing object libraries isn't exactly hard. Lots and lots of files: Yeah, this sucks. But every other system is going to have the same problem, and a proper module system that associates functions to files is really the only way to fix it, aside from oddly specific introspection utilities. Most other languages, say, for example, FORTH, don't have this, AFAIK. Indentation as an indication of nesting: And you suggest counting braces as an alternative? or just not having nesting? Because most languages, say, for instance, FORTH, have nesting. No Docs: In BAD C code, this is true. As in bad code in any language, like, for instance, FORTH, as any language designer knows that the language cannot make bad programmers good. Names are Hyphenated: "I think hyphens suck" isn't a problem with the language, it's just a personal preference. Constants are named: With my passing familiarity with FORTH, I don't know what he's on about here. Could somebody explain, so I can see if I agree? Preoccupation with Contingencies: Because everybody loves leaky abstractions that fail at critical moments for ill-defined reasons. Conditional Compilation: This feature sucks. It really does. The problem is, I don't see what else they could have done. So my response here is, Do you have any better way to do cross platform compatibility? Because I would honestly love to see it. I'm serious. Hooks: Ahhh, I see. You're from the beautiful-diamond camp of software design. I can recognize you guys by your catchy slogan, "Don't Design With The Future In Mind." Programmers best interest to exaggerate complexity: No language can fix this. It's impossible, because this is a social pressure. Portability: Yeah, basically. Maybe I haven't seen enough C. Maybe I haven't seen enough FORTH. Maybe I just can't get into Chuck's mindset here. But his claims just seem insane. EDIT: I read some more off of Chuck's pages, he seems to be thinking more in terms of embedded architectures and single purpose code. Fair enough, in those situations, some of his reasoning makes sense. But the presentation of this page still makes him look like he's off his rocker.
mwcampbell 11y ago
This post by Yossi Kreinin offers an interesting perspective on Forth and Chuck Moore's general approach to programming: http://yosefk.com/blog/my-history-with-forth-stack-machines.html http://yosefk.com/blog/my-history-with-forth-stack-machines....
- lolc 11y ago
  Interesting take. I remember Forth only from the time I was looking to replace `dc` with a more powerful calculator. I figured Forth could fit the bill because it was a stack language. Whoops we didn't get along immediately. I realized that Forth was not meant to be my calculator, if anything I could have made it my calculator.
nickpsecurity 11y ago
1% the code, 0.01% the reader comprehension. I'll stick with a good ALGOL or LISP language anyday. Especially with macros plus support for real HW rather than 18-bit etc.
necessity 11y ago
People like to blame programming languages for programmer's faults.
superuser2 11y ago
>Code is scattered in a vast heirarchy of files. You can't find a definition unless you already know where it is. Not if you're using a proper IDE (or the right emacs/vim plugins, which are effectively an IDE). >Code is indented to indicate nesting. As code is edited and processed, this cue is often lost or incorrect. Not if you're using a proper IDE configured for the project's chosen style. My engineering org also has linters in pre-commit hooks and automatically commenting on code reviews. >Sometimes a line of code contains only a parenthesis, or semicolon. This reduces the density of the code, and the difficulty of reading it. Depends on the style guide you choose. Also, some people find this more readable. >There's no documentation. Except for the ubiquitous comments. These interrupt the code, further reducing density, but rarely conveying useful insight. The only documentation I've ever found useful (aside from comments) was automatically generated from comments, explaining the signatures of methods and what they do.
- seanwilson 11y ago
  Not commenting on any language in particular, but you can make any language's issues easier with a combination of a better IDE, commit hooks, linters etc. However, it would require less effort if the language itself enforced these constraints so everyone using it is writing code the same way.
fffrad 11y ago
When you look at code you wrote in the past, whether it is 1000 lines, 3000 or 100,000 you could always think of a way to remove the redundancies and such and turn it into a smaller number of lines. But the first time you write it, the first time you are solving the problem, it is much harder to focus on that part. This is not to say that it's ok to have unmaintainable million lines of code application, but more that it is not something we willingly do to make ourselves look more important in a company.
benbenolson 11y ago
I think that the author of this article is mistaking LOC for readability. Despite colorForth being wonderfully concise and independent of any operating system, that doesn't make it convenient or readable for future programmers. Just because something is a number of lines longer than another something, doesn't mean that it's less readable. Take Perl, for example. I often write Perl scripts, and they're very few lines, but nobody can read them, which is really what matters. So, I'll expand it to be more C-like (calling functions with parentheses, using less implied arguments and scalar/vector contexts, etc.), thus making it very easily readable by people that don't even know Perl. I regard this revised version much better than the more Perl-like and obfuscated (although shorter!) version.
- HillaryBriss 11y ago
  Absolutely. LOC isn't the only measure of code quality.
- nchelluri 11y ago
  I do think readability is key, and found the article intriguing so I took a very brief look at some colorForth sample code: http://colorforth.com/ide.html http://colorforth.com/ide.html . It may be that I'm just extremely new to a very foreign programming language, but I did not understand it at all.
  - djsumdog 11y ago
    I thought I was reading a satire article. That was the first source I found when looking through the site. I still wasn't sure if it was satire or not.
- sklogic 11y ago
  Smaller code does not necessarily guarantee better readability, but there is a strong correlation. What is more readable, a TCP stack from the Linux kernel, or this [1] 200 lines of code? [1] http://www.moserware.com/2008/04/towards-moores-law-software-part-3-of-3.html http://www.moserware.com/2008/04/towards-moores-law-software...
overgard 11y ago
I agree with how verbose some of these languages are, but this is a bogus argument. You can shorten almost any design on a rewrite, regardless of language. Not to mention the "density" metric is ridiculous. Minified javascript is certainly more dense than regular javascript, but nobody would argue it's simpler.
Procrastes 11y ago
Chuck Moore came out and spoke to us at work not long ago, and I have to admit I had a total fanboy moment. There are very few people in the world with as clear a view of how to make an entire system, hardware and software, directly reflect the problem to be solved with no cruft. There's alot to learn just from the way he decomposes a problem.
- otakucode 11y ago
  As things have been developing, first with virtualization becoming widespread, and then with things like Docker continuing the trend of packing things off into 'separated' containers, I have wondered at what point we will get to the place where a tool is developed which provides a highly modular kernel along with the tools to quickly spin up a whole system which has exactly and only the resources a particular subsystem needs. And, of course, a basic system that spins these things up when needed. Not just microservices, but atto-scale services. It sounds like this is the sort of thing Forth promoters could help us realize.
HillaryBriss 11y ago
It has elaborate sytnax
RodgerTheGreat 11y ago
The most important idea in Forth is factoring. Breaking complex tasks into small pieces. In an ideal Forth codebase, most definitions are about a line long, contain at most one control structure and reference no named variables. Forth's stack-oriented semantics make function calls very cheap- a function call and return is literally two instructions, whereas languages which use activation records will turn a function call into dozens of instructions- copying arguments around, backing up registers, etc. Since it's computationally inexpensive, you don't need to sweat over whether your optimizing compiler will manage to inline a function. Short, simple and mostly pure functions are easy to test in isolation- there aren't deeply nested code paths to exercise. Lots of short functions allow your codebase to reuse more of those functions- any redundancy can be collapsed together, both shrinking the codebase and improving test coverage. This effect is magnified in more complex programs. You can do this sort of thing in other languages, but forth's syntax and semantics for function definition and invocation are both very lightweight, and this makes it much easier to apply.
- tehwalrus 11y ago
  It sounds like what Clean Code[1] really wanted. I still think it's a great shame that all his examples are in Java (although, in fairness, they are very pseudocode-ish). [1] https://books.google.co.uk/books/about/Clean_Code.html?id=dwSfGQAACAAJ https://books.google.co.uk/books/about/Clean_Code.html?id=dw...
mhd 11y ago
As someone who's still doing a lot of Perl: Can't we just ease up on the line count fetish? Some languages are really bloated, but I'd still say that more often than not, the sheer amount of lines isn't the most major factor of a program's cognitive load.
smartmic 11y ago
I just started to learn the Factor programming language. I think of it as a modern implementation of a stack based language like Forth (similar what Clojure is for Lisp). I admit, the first step were a bit brain-twisting, but after getting hands dirty, programming feels relieving. Like a rain shower on a steamy hot day. No worrying about syntax and punctation, elegantly shuffling the stack is fun. For me a perfect demonstration of KISS.

1% the Code (2001)

143 points by mr_tyzic 11y ago

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?

modulus1 11y ago

> It's strongly typed, with a bewildering variety of types to keep straight. More errors. Odd complaint, especially to be levied against C.

brandonbloom 11y ago
Forth is completely untyped. Traditionally, all values are machine words.
- david-given 11y ago
  Well... yes and no. Some values are multiple machine words, pushed onto the stack. Some of these (such as double-words) have language-defined representations. (They're always stored with the low word at the lower address, regardless of your machine endianness or, as far as I can tell, whether your stack is growing up or down. Which means that on some platforms the low word is pushed first, and on others the high word first. This shouldn't matter, because you should be using the dword words to manipulate them, except that it's common practice to assemble and disassemble dwords manually.) Some have implementation-defined implementation-defined representations. For example, the various bits of state that the control flow words push onto the return stack. You don't know how big any of these are, so accessing the return stack from inside loops is basically impossible. And some are just weird. Floating-point numbers live on their own stack. Except not necessarily; the implementation is allowed to store them on the data stack. So you can't use NIP TUCK OVER PICK etc because you don't know the layout of your stack. Basically, at every point, you have to know the type of the values on your stack so you can pick the right word (DROP vs 2DROP vs FDROP) to operate on the stack... and if you get it wrong, you get stack corruption and horrible, hard-to-debug crashes. tl;dr: Forth is typed. Forth is very typed. Forth just doesn't check types.
  - brandonbloom 11y ago
    That's one definition of "typed", but not a very useful one. By that definition _everything_ is typed. That's an interesting metaphysics discussion worth having, but not relevant to explaining Forth to a C programmer. Vanilla Forth values do not have runtime type information (such as class pointers or discriminator tags) nor does a traditional forth compiler have compile time type information (such as an abstracted understanding of the state of the stack at any given point of execution). Meanwhile, Factor, a modern stack language has both: SmallTalk-style object-oriented class pointers on every value, and a compile-time stack-effect checker. Factor values have a Lisp-like dynamic typing discipline. That is to say "uni-typed" as "dynamic", or a discriminated union.

chipsy 11y ago

Proclaiming that the syntax only causes problems stands in complete defiance of most people's preferences in programming syntax. We like syntax errors because they mold thoughts more precisely. Going against that is also going against a lot of "productivity enhancers" - we build them because we expect to have a lot of code, and we want to reduce the kinds of errors that it may contain. That doesn't mean that we should abuse them to write as much code as we can, but it does turn out that way in practice. So in an odd way Moore and co are right - we would be more free if we also constrained ourselves more on this point. But the broader thought is that you can apply such constraints at any time, in tandem with what you already like. And that is more likely to produce an innovation than "just Forth".

Guvante 11y ago
I think that needless compiler errors is an interesting point that isn't discussed often, so that at least is an interesting point. We have those productivity enhancers because the language makes it easy to make a mistake there. Ideally we would want to eliminate those mistakes without the syntactic headache. Although obviously how to do that is a complex exercise, I do think that saying "code bloat is bad" even against "bugs are worse" can provide interesting insights into what we really want from languages.
- dietrichepp 11y ago
  It's discussed fairly often with static analyzers. Static analysis is a powerful tool, but false positives erode user confidence in the tool. I've worked with code bases where thousands of warnings (and even several errors) were left in place, which meant that you had to basically ignore all diagnostic messages every time you compiled. At that point, you might as well be 2>/dev/null. Someone even wrote a wrapper script that would diff the stderr against the "known good" stderr. My general impression of that project was that it was dying a slow death unless someone went in and restored developer confidence in the build process, and the most likely person was me :-/

throwaway999888 11y ago

If some C programmers have that scoff at higher level programmers attitude, Chuck Moore is the equivalent but addressed at C programmers (and higher, I guess). I have a feeling he's not the kind of person a C programmer could say things like "C is high-level (obvious one-to-one mapping) assembly" and "C is (blanket) efficient" around, and get away with it.

archgoon 11y ago

>But I'm game. Give me a problem with 1,000,000 lines of C. But don't expect me to read the C, I couldn't. And don't think I'll have to write 10,000 lines of Forth. Just give me the specs of the problem, and documentation of the interface. I could be wrong, but I'd wager that a lot of projects that are 1,000,000 lines of C don't have well defined interfaces or documentation. However, if the author wants to give it a shot, they could try replacing v8 with pure forth. That's a fairly well defined problem, they just have to maintain compatibility with the exposed v8 api.

kctess5 11y ago
I'm not sure the stats on this one, but it seems to be that something with 1,000,000 loc would have to have decent documentation, or it would be totally unmaintainable and wouldn't grow to that size without dying a horrible death.
- protomyth 11y ago
  You would think that, but it can grow without understanding by adding code at the edges which expands then starts the cycle over. A code archeologist[1] would see a central island with bridges to developed islands with more bridges and various ships running between interfaces. Its particularly fun with multiple subsystem teams. Each one builds its own island of code and the bridges are scary. 1) please say that exists
  - TranquilMarmot 11y ago
    I could probably describe my current job as a "code archaeologist"...
  - archgoon 11y ago
    > 1) please say that exists The term 'software archaeology' has been used for a while https://en.wikipedia.org/wiki/Software_archaeology https://en.wikipedia.org/wiki/Software_archaeology And the wiki page suggests there are some consultants in the field. Many programmers trying to understand open source projects will dabble a bit in this.

qwertyuiop924 11y ago

You have got to be kidding me. I mean come on, you're joking, right? If you gave me some qualification, maybe. I know that FORTH is more compact than C, and the code decrease in size might be reasonable in some cases, but the reasons you give are insane! come on! Elaborate Syntax: Your syntax is simple, C's is less simple. If you want elaborate, look at PERL or Haskell. Redundancy and Confusing Types: Fair enough, but the types have to be the ones they are because C's supposed to be close to the metal. Therefore, you need specific bit sized types. It could be better than it is, though. Strong typing causes errors: Um. Take that up with the angry Haskellers lining up behind you. I'll just duck off this way... Honestly, C's type system is pretty awful, but that's not because it's strongly typed. Infix:...Yeah, pretty much, but the mainstream won't except anything else. Parens: Tell that to the lispers. Parens shine for syntax parsing, and the incredibly common editor support makes it even nicer than Python for editing. Unclear how source will be translated: Well, I guess, but more so than anything higher up the stack, like, just to pick a random example, most modern FORTH implementations. Subroutine calls are expensive: Compared to what? 1 mov or push instruction for for each arg, and than a call instruction, at least on x86. Most other processor architectures seem to have similar things going. Those are all pretty fast. Elaborate Compiler, Object Libraries: Yes, compared to FORTH, the compiler is elaborate, but that isn't why object libraries are distributed, seeing as there's a C compiler for every system under the sun. And distributing object libraries isn't exactly hard. Lots and lots of files: Yeah, this sucks. But every other system is going to have the same problem, and a proper module system that associates functions to files is really the only way to fix it, aside from oddly specific introspection utilities. Most other languages, say, for example, FORTH, don't have this, AFAIK. Indentation as an indication of nesting: And you suggest counting braces as an alternative? or just not having nesting? Because most languages, say, for instance, FORTH, have nesting. No Docs: In BAD C code, this is true. As in bad code in any language, like, for instance, FORTH, as any language designer knows that the language cannot make bad programmers good. Names are Hyphenated: "I think hyphens suck" isn't a problem with the language, it's just a personal preference. Constants are named: With my passing familiarity with FORTH, I don't know what he's on about here. Could somebody explain, so I can see if I agree? Preoccupation with Contingencies: Because everybody loves leaky abstractions that fail at critical moments for ill-defined reasons. Conditional Compilation: This feature sucks. It really does. The problem is, I don't see what else they could have done. So my response here is, Do you have any better way to do cross platform compatibility? Because I would honestly love to see it. I'm serious. Hooks: Ahhh, I see. You're from the beautiful-diamond camp of software design. I can recognize you guys by your catchy slogan, "Don't Design With The Future In Mind." Programmers best interest to exaggerate complexity: No language can fix this. It's impossible, because this is a social pressure. Portability: Yeah, basically. Maybe I haven't seen enough C. Maybe I haven't seen enough FORTH. Maybe I just can't get into Chuck's mindset here. But his claims just seem insane. EDIT: I read some more off of Chuck's pages, he seems to be thinking more in terms of embedded architectures and single purpose code. Fair enough, in those situations, some of his reasoning makes sense. But the presentation of this page still makes him look like he's off his rocker.

mwcampbell 11y ago

This post by Yossi Kreinin offers an interesting perspective on Forth and Chuck Moore's general approach to programming: http://yosefk.com/blog/my-history-with-forth-stack-machines.html http://yosefk.com/blog/my-history-with-forth-stack-machines....

lolc 11y ago
Interesting take. I remember Forth only from the time I was looking to replace `dc` with a more powerful calculator. I figured Forth could fit the bill because it was a stack language. Whoops we didn't get along immediately. I realized that Forth was not meant to be my calculator, if anything I could have made it my calculator.

nickpsecurity 11y ago

1% the code, 0.01% the reader comprehension. I'll stick with a good ALGOL or LISP language anyday. Especially with macros plus support for real HW rather than 18-bit etc.

necessity 11y ago

People like to blame programming languages for programmer's faults.

superuser2 11y ago

>Code is scattered in a vast heirarchy of files. You can't find a definition unless you already know where it is. Not if you're using a proper IDE (or the right emacs/vim plugins, which are effectively an IDE). >Code is indented to indicate nesting. As code is edited and processed, this cue is often lost or incorrect. Not if you're using a proper IDE configured for the project's chosen style. My engineering org also has linters in pre-commit hooks and automatically commenting on code reviews. >Sometimes a line of code contains only a parenthesis, or semicolon. This reduces the density of the code, and the difficulty of reading it. Depends on the style guide you choose. Also, some people find this more readable. >There's no documentation. Except for the ubiquitous comments. These interrupt the code, further reducing density, but rarely conveying useful insight. The only documentation I've ever found useful (aside from comments) was automatically generated from comments, explaining the signatures of methods and what they do.

seanwilson 11y ago
Not commenting on any language in particular, but you can make any language's issues easier with a combination of a better IDE, commit hooks, linters etc. However, it would require less effort if the language itself enforced these constraints so everyone using it is writing code the same way.

fffrad 11y ago

When you look at code you wrote in the past, whether it is 1000 lines, 3000 or 100,000 you could always think of a way to remove the redundancies and such and turn it into a smaller number of lines. But the first time you write it, the first time you are solving the problem, it is much harder to focus on that part. This is not to say that it's ok to have unmaintainable million lines of code application, but more that it is not something we willingly do to make ourselves look more important in a company.

benbenolson 11y ago

I think that the author of this article is mistaking LOC for readability. Despite colorForth being wonderfully concise and independent of any operating system, that doesn't make it convenient or readable for future programmers. Just because something is a number of lines longer than another something, doesn't mean that it's less readable. Take Perl, for example. I often write Perl scripts, and they're very few lines, but nobody can read them, which is really what matters. So, I'll expand it to be more C-like (calling functions with parentheses, using less implied arguments and scalar/vector contexts, etc.), thus making it very easily readable by people that don't even know Perl. I regard this revised version much better than the more Perl-like and obfuscated (although shorter!) version.

HillaryBriss 11y ago
Absolutely. LOC isn't the only measure of code quality.
nchelluri 11y ago
I do think readability is key, and found the article intriguing so I took a very brief look at some colorForth sample code: http://colorforth.com/ide.html http://colorforth.com/ide.html . It may be that I'm just extremely new to a very foreign programming language, but I did not understand it at all.
- djsumdog 11y ago
  I thought I was reading a satire article. That was the first source I found when looking through the site. I still wasn't sure if it was satire or not.
sklogic 11y ago
Smaller code does not necessarily guarantee better readability, but there is a strong correlation. What is more readable, a TCP stack from the Linux kernel, or this [1] 200 lines of code? [1] http://www.moserware.com/2008/04/towards-moores-law-software-part-3-of-3.html http://www.moserware.com/2008/04/towards-moores-law-software...

overgard 11y ago

I agree with how verbose some of these languages are, but this is a bogus argument. You can shorten almost any design on a rewrite, regardless of language. Not to mention the "density" metric is ridiculous. Minified javascript is certainly more dense than regular javascript, but nobody would argue it's simpler.

Procrastes 11y ago

Chuck Moore came out and spoke to us at work not long ago, and I have to admit I had a total fanboy moment. There are very few people in the world with as clear a view of how to make an entire system, hardware and software, directly reflect the problem to be solved with no cruft. There's alot to learn just from the way he decomposes a problem.

otakucode 11y ago
As things have been developing, first with virtualization becoming widespread, and then with things like Docker continuing the trend of packing things off into 'separated' containers, I have wondered at what point we will get to the place where a tool is developed which provides a highly modular kernel along with the tools to quickly spin up a whole system which has exactly and only the resources a particular subsystem needs. And, of course, a basic system that spins these things up when needed. Not just microservices, but atto-scale services. It sounds like this is the sort of thing Forth promoters could help us realize.

HillaryBriss 11y ago

It has elaborate sytnax

RodgerTheGreat 11y ago

The most important idea in Forth is factoring. Breaking complex tasks into small pieces. In an ideal Forth codebase, most definitions are about a line long, contain at most one control structure and reference no named variables. Forth's stack-oriented semantics make function calls very cheap- a function call and return is literally two instructions, whereas languages which use activation records will turn a function call into dozens of instructions- copying arguments around, backing up registers, etc. Since it's computationally inexpensive, you don't need to sweat over whether your optimizing compiler will manage to inline a function. Short, simple and mostly pure functions are easy to test in isolation- there aren't deeply nested code paths to exercise. Lots of short functions allow your codebase to reuse more of those functions- any redundancy can be collapsed together, both shrinking the codebase and improving test coverage. This effect is magnified in more complex programs. You can do this sort of thing in other languages, but forth's syntax and semantics for function definition and invocation are both very lightweight, and this makes it much easier to apply.

tehwalrus 11y ago
It sounds like what Clean Code[1] really wanted. I still think it's a great shame that all his examples are in Java (although, in fairness, they are very pseudocode-ish). [1] https://books.google.co.uk/books/about/Clean_Code.html?id=dwSfGQAACAAJ https://books.google.co.uk/books/about/Clean_Code.html?id=dw...

mhd 11y ago

As someone who's still doing a lot of Perl: Can't we just ease up on the line count fetish? Some languages are really bloated, but I'd still say that more often than not, the sheer amount of lines isn't the most major factor of a program's cognitive load.

smartmic 11y ago

I just started to learn the Factor programming language. I think of it as a modern implementation of a stack based language like Forth (similar what Clojure is for Lisp). I admit, the first step were a bit brain-twisting, but after getting hands dirty, programming feels relieving. Like a rain shower on a steamy hot day. No worrying about syntax and punctation, elegantly shuffling the stack is fun. For me a perfect demonstration of KISS.