What Good Are C, C++, and Java?

Under Python in C++

Under PHP is C++

Under Haskell is a variant of C called C--

Under Lua is C

Under Perl is C

Is this because "the dinosaurs haven't died yet"? No. It's because writing a high-level programming language almost always requires a lower-level language. Under all of your high-level abstractions, there needs to be some compiles-to-assembly language that has access to memory management. Under all of your fancy high-level language debuggers, there needs to be some disassembly and translation of the assembly code to match the symbol databases for your high-level code. Under all of your binaries, there needs to be a kernel that can translate API calls, handle interrupts, dispatch exceptions, manage memory protection, and schedule threads.

Can you do all of this with Haskell? Sure. But the first Haskell compiler written in Haskell needs to be compiled by something. It can be C, C++, C--, or even assembly for all I care, but it has to exist. Even the first C compilers needed to be written in something that wasn't C.

The bottom line is that it has nothing to do with "technical debt". These languages exist because they can work on hardware without heavy frameworks weighing them down. They rely on the bare system, and not on a bunch of abstractions. And that's why they can be used as a layer between hardware and the much-needed abstractions brought to us by high-level languages.

These "old" languages have many strengths, and you're foolish to write them off just because their strengths don't fit your use-cases. Without the programmers that are "lost" to these "old paradigms", you would have nobody to maintain, develop, or secure your new paradigms. And that's a consequence that only considers one of the many strengths of these languages; there's many more consequences that we'd face if nobody new learned how to use them.

> As a final point, consider that your precious C programs and the C compiler can only run because of the CPU, which was not written in C nor in any Von Neumann language - oh no, they were written functionally, with only logic gates, in a dataflow-oriented way, because you know, they really needed this to work. HDL's are not "only" logic gates. Have you developed anything substantial in a HDL? I'd think the lack of recursion alone would cleanly delineate them from anything functional. My own work with FPGA's started without language, literally wiring things together in a GUI. That's the legacy ASIC design descended from, not a functional ivory tower.

> That's why CPUs don't have bugs - they picked a better starting language than C, with a principled approach (logic) that is amenable to mathematical verification. iHDL is not a "better" language than C. Imagine having to specify the exact opcode you wanted the linker to emit for a particular instruction, that's the level of dipping into implementation details that HDL's allow. It's not uncommon to have "behavioral" code that is checked in concert with the rest of the design, "implementation" code representing the actual circuit, and some poor engineer tasked with signing off that the two are equivalent without the ability to simulate all inputs. Formal verification is a specialized technique that is only used on vanishingly small parts of the design. At no point in the consideration of an HDL for a new design is "amenable to mathematical verification" given weight.

Another slight problem with your argument: CPU's DO have bugs. Google up "Intel Errata" and prepare for your stone castle to be torn apart. If you'd like to duck this and say that they're esoteric and don't matter, I'd really like to know what you think about the TSX-killing errata that's essentially set back parallel computing in a measurable way. Why wasn't this subjected to formal verification magic?

> Guess what - functional programming languages are also increasingly more amenable to mathematical verification. Once this is popularized, you'll be delegated to maintaining the old sand castles from dinosaurs while we will be building stone castles over here. Join us. :) You don't understand what you're comparing to with enough fidelity to trust the end result.

The easiest way to imagine a CPU design team is that it's Just Another Software project. The only extra constraints are that you can't run it full speed. You can simulate a 5GHz chip at 5Hz with SW-like visibility. At some point in the alpha, the team will spend a few million dollars to wait 8 weeks to get a few dozen test chips that will run at full speed, with near-zero visibility. So the question is how much extra unit testing would you do, on each of those models, with those kind of timelines.

Formal verification doesn't make a dent on modern CPU design. It's all these extra considerations (read:bodies) taken during the design process that make up the gap. Please, try to educate yourself before going off on half-baked assumptions based on superficial similarities.

I'm trying to imagine what paucity of knowledge about a CPU you can have to say something like "no state." Registers? The program counter? The megabytes of caches? You've got to be stretching the definition of "state" beyond recognition. Each CPU has at least a few dozen, up to a few hundred, fuses covering everything from PLL tuning values to the vendor string.

CPU's are not deterministic, in the sense that given the same inputs it will return the same outputs. Have you never powercycled a system to have it come up when no "state" was changed? A single degree difference can cause transitions to different power states. A PLL might not lock on the same cycle. Electrical systems are ugly nightmares and it's just speaking to the quality of the abstractions that have been presented to you that you think otherwise.

> and even memory access is just a function to set or read from an address and those functions never fail, never throw null pointer exceptions, etc. Do you disagree that a circuit is more an example of data-flow paradigm than an example of the state-machine paradigm?

I'm not sure how to answer this. Everything's built as a series of state machines. Crack open a PRM and see state machines explicitly drawn out with all their transition arcs. If we're talking about generic "circuits," take a look at something like the PCIe LTSSM. PCIe is all about shoveling data from point to point, pretty dataflow-oriented, but it's behavior is specified as a combination of state machines.

> For a CPU to take the next step and decide what work to do at each clock cycle it needs only its inputs - it need not inspect the previous work it did in order to decide what to do next - it simply reads the next opcode the user wants to execute, and does it. That means it is referentially transparent. Which means it's tons more functional than C.

You're not talking about a "CPU" here. You're talking about the abstraction that a CPU provides about how it's assembly instructions will be interpreted. Normally it's not really an issue, people blur that all the time, but you're using statements about the abstraction to talk about the concrete. Map instead of the territory.

If CPU's were implemented in the fashion you describe they'd be incredibly slow. They HAVE to consider what they did before, what they're doing next, and how it all relates to the current instruction. There are prefetch blocks that just watch traffic, completely unaware of the actual instruction stream, just looking for patterns and optimistically pulling things into the cache. There's a ton of state just to keep up the illusion that things are happening sequentially, instruction by instructions, instead of out-of-order as possible to keep execution units humming.

> I will grant you though that I was wrong that CPUs never have bugs, they do and I appreciate your opening my eyes to that. Lots of interesting reading ahead of me. Let me ask you, then. Do you think CPUs have so few bugs just because of more stringent testing, or because of referential transparency and the fact that they a CPU is not a state machine like a C program is?

CPU's have so few bugs because of more stringent testing. There is no functional magic happening. It's just hard work by a lot of talented people. Please respect their effort.