| Excellent question! The reason has to do with the fundamental differences between software and hardware. Think of software as fundamentally sequential and hardware as fundamentally parallel: Software source code can't run directly on hardware and has to be either interpreted by an interpreter, or compiled by a compiler. In both cases the source code is transformed into machine instructions. As the term implies these are instructions to the hardware, more specifically a processor, or a processing unit. Hardware is the physical manifestation of the computer. Most components of a modern computer - CPU, GPU, RAM, SSD drive, USB controller - consist of vast networks of interconnected transistors. By connecting a few transistors together the right way they can express the electrical equivalent of a boolean logic gate (AND, OR, XOR, NOT etc). By connecting logic gates together they can express logic blocks of various types (multiplexers, adders etc). "Zoom out" a few more levels of abstraction and we call the logic blocks "CPU", "RAM", "USB controller" etc. Many different types of physical objects have been invented that all behave functionally equivalent to a transistor. The first computers were mechanical. For practical and performance reasons, essentially all modern computers use electrical transistors that express boolean logic where logical 0 and logical 1 are represented by different voltage levels. Going back to machine instructions, these are interpreted by the hardware / boolean logic network / transistors one at a time through the fetch-decode-execute instruction cycle. We call this fundamental interface between hardware and software the Instruction Set Architecture. Some ISAs have variable-length instructions, such as x86, others have only one length, such as RISC-V RV32I. In RV32I all instructions are 32-bit wide. An RV32I CPU fetches one instruction at a time. Each of the instruction's 32 bits are transmitted on a separate wire from memory to the CPU decoder logic block. The decoder logic block in turn is connected to other wires that constitute control signals to other parts of the CPU. From this perspective let's rephrase your question a few different ways: Why not use machine instructions to express transistors? Why not use a sequence of instructions to express the behavior of a billion parts that all move at the same time? Haskell's syntax and interpreter/compiler tool chain, or any other programming language for that matter is designed to be transformed into machine intructions. Why not use the same syntax and tools to design the hardware that executes those instructions? Because software design is an abstraction of something inherently sequential, and hardware design is an abstraction of something inherently parallel, massively parallel. Software is "simply" varying voltage levels that represent 0s and 1s, flowing through a labyrinth of billions of transistors in rhythm, all at the same time. The rhythm they are flowing to is the clock frequency. The massively parallel labyrinth is the hardware. This answer is getting a bit long, but it doesn't even begin to uncover the complexities of hardware. Hardware designers of state-of-the-art chips have to consider things like running different parts of a chip at different clock frequencies, turning parts of for microseconds at a time when they are not used so the chip doesn't burn up, account for the fact that 0s and 1s won't arrive at the intended destination at the same time due to wire length and how "deep" the logic gate network is, and taking these things into consideration when they decide where to physically place parts of a chip. Nah, you didn't miss anything obvious. To miss something obvious is either subjective, a contradiction in terms or context-dependent. The differences between a programming language and a hardware description language wasn't obvious to you. It is to me. Does the context of HN assume knowledge of this difference? I sure hope the answer is No! Don't apologize for asking "dumb" questions. I do it frequently, because I learned long ago that I'll likely learn something. More often than not it also turns out that I wasn't the only one confused. The others just didn't know it, or were too afraid to admit it. Embrace your inner n00b. Ask "dumb" questions. :) (note: You may very well know some of this already, but it wasn't obvious to me. I seized the opportunity to write an extensive explanation that I hope will help others as well.) |