1% the Code (2001)

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.

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.

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.

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.

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.

Odd complaint, especially to be levied against C.

http://yosefk.com/blog/my-history-with-forth-stack-machines....

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.

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".

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.

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.

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.