You have got to be kidding me. I mean come on, you&#x27;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!<p>Elaborate Syntax: Your syntax is simple, C&#x27;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&#x27;s supposed to be close to the metal. Therefore, you need specific bit sized types. It could be better than it is, though.<p>Strong typing causes errors: Um. Take that up with the angry Haskellers lining up behind you. I&#x27;ll just duck off this way... Honestly, C&#x27;s type system is pretty awful, but that&#x27;s not because it&#x27;s strongly typed.<p>Infix:...Yeah, pretty much, but the mainstream won&#x27;t except anything else.<p>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.<p>Elaborate Compiler, Object Libraries: Yes, compared to FORTH, the compiler is elaborate, but that isn&#x27;t why object libraries are distributed, seeing as there&#x27;s a C compiler for every system under the sun. And distributing object libraries isn&#x27;t exactly hard.<p>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&#x27;t have this, AFAIK.<p>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.<p>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.<p>Names are Hyphenated: &quot;I think hyphens suck&quot; isn&#x27;t a problem with the language, it&#x27;s just a personal preference.
Constants are named: With my passing familiarity with FORTH, I don&#x27;t know what he&#x27;s on about here. Could somebody explain, so I can see if I agree?<p>Preoccupation with Contingencies: Because everybody loves leaky abstractions that fail at critical moments for ill-defined reasons.<p>Conditional Compilation: This feature sucks. It really does. The problem is, I don&#x27;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&#x27;m serious.<p>Hooks: Ahhh, I see. You&#x27;re from the beautiful-diamond camp of software design. I can recognize you guys by your catchy slogan, &quot;Don&#x27;t Design With The Future In Mind.&quot;
Programmers best interest to exaggerate complexity: No language can fix this. It&#x27;s impossible, because this is a social pressure.<p>Portability: Yeah, basically.<p>Maybe I haven&#x27;t seen enough C. Maybe I haven&#x27;t seen enough FORTH. Maybe I just can&#x27;t get into Chuck&#x27;s mindset here. But his claims just seem insane.<p>EDIT: I read some more off of Chuck&#x27;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&#x27;s off his rocker.