[nickpsecurity]

"Take away all C/C++ code and we have nothing or almost nothing."

In that meaning, it's true but only as an accident of history that has little to nothing to do with C's design itself.

"If by economic you mean "pragmatic" and "engineering considerations", then yes."

BCPL was whatever compiled on a machine from the 1960's. C was what compiled on a machine from the 1970's. ALGOL was engineered. C was what compiled and ran fast on old hardware. That's it.

http://pastebin.com/UAQaWuWG

The rest was social factors. Even when alternative languages did better, most people didn't adopt them. Most buyers also paid for performance per dollar totally ignoring reliability, security, maintenance, and so on. Unless you argue these don't matter, then the dominance of C and UNIX is once again due to something other than their technical merits. Plus, the fact that their problems stayed in... intentionally... once better hardware came online while other players fixed them in various ways.

[coldtea]

>In that meaning, it's true but only as an accident of history that has little to nothing to do with C's design itself.

I don't believe that for a second. C had very specific performance and memory characteristics that alternatives didn't have.

>C was what compiled and ran fast on old hardware. That's it.

That's a HUGE pragmatic benefit, not a "historical accident".

[nickpsecurity]

If C was made a decade later, we'd have been using Pascal or BCPL or something. Other stuff could do the job. Example: Hansen later put a Pascal variant, Edison, on the same machine thst was simpler, safer, and faster to compile. Pascal itself was ported to 70+ architectures from mainframes to 8-bitters.

Nah, we didn't need C. Thompson just really liked BCPL. It was crap. So they tweaked it into C. It still couldn't write UNIX. Ritchie added structs and that version finally did the job. All in the papers I cited. It's facts in their own writings and predecessor papers (eg BCPL) why each decision was made.

[coldtea]

>Nah, we didn't need C. Thompson just really liked BCPL. It was crap. So they tweaked it into C. It still couldn't write UNIX. Ritchie added structs and that version finally did the job.

Well, Pascal was also inspired by languages that were crap compared to modern (70s/80s needs), and early Pascal's also had tons of missing features -- so I'm not sure what this "C wasn't good enough from the start" is supposed to mean, especially since C already had structs and all by the time it caught on.

[nickpsecurity]

You should read the history. Compare it to how ALGOL68 was made and what it offered. One looked at all the needs and common situations programmers ran into then engineered a solution to that in the form of a language. It balanced maintenance, efficiency, and safety.

One group tried to implement a version of it, CPL, on horrific hardware in batches on punchcards. Not best way to do state-of-the-art language compilers. Upon failing, they applied this method to CPL: chop off a feature, try to finish compiler, repeat. Result was easiest features to implement on a 1960's EDSAC in form of BCPL. Thompson preferred it over alternatives and tweaked it to his preferences, including assignments from := to =. Admits he just liked that better. That's the amount of science that went into his modifications.

Eventually, Ritchie tweaking it a bit, they got their toy OS to run on a toy machine. Many design decisions they made were due to its own design and limitations. Then, after UNIX spread everywhere and many apps were made, they just kept all that because fixing it would break something. That's the opposite of engineering a good system language. It's an acceptable, but not ideal, hack to make their crappy computers work. After they got better ones, they should've started migrating toward something better incrementally. They didn't and many defended the language as if it was designed well upfront instead of what compiled on an EDSAC and PDP. Facts don't lie.

Plenty of better stuff and techniques. For example, MULTICS project that gave them OS and BCPL experience had critical stuff in PL/0. In MULTICS, a microkernel, prefixed strings, and a reverse-flowing stack would've prevented tons of data loss and hacks that happened in UNIX. Why didn't they use those? Hardware expected a bad stack and other two techniques were too slow on it. Once hardware sped up, they kept the bad techniques to not rewrite stuff. I mean, this shows up over and over in UNIX/C. Its history really defines it.

Now, stop and go look at Modula-3 on Wikipedia. A few of us think it was one of best compromises between a safe, C alternative like Modula-2 and a heavyweight, ALGOL or C++ alternative. It was the product of professionals engineering, as done for ALGOL, an industrial language based on Wirth's prior work. Simple syntax that compiles fast as Go, a Wirth-style language. Has safety by default with off button where necessary, has basic OOP, has GC by default with off button for specific variables, built-in concurrency, mathematically verified stdlib (partially), runs efficient code, and was used for an OS (SPIN) w/ type-safe linking of 3rd-party code into kernel.

So, we know it could've been done better if it was engineered or addressed more programming needs than runs fast on 1960's hardware. Unfortunately, that's basically all BCPL and C did while ignoring good techniques then and later. Fortunately, we can learn from their mistakes for use in new languages or projects. :)