My final year project was a hardware implementation of this. My group made an 8 core coprocessor and an OpenCL-like implementation complete with an LLVM IR to SUBLEQ translator. We actually got performance better than the proprietary NIOS II e soft processor on our image processing demo (Y colorspace conversion).
That's because hardware description languages are not programming languages. This point was constantly emphasized in my digital systems courses. You do not describe a sequence of instructions using an HDL, you describe the layout of a circuit with registers, wires, and logic blocks. You have to consider the physics of the device to avoid violating timing constraints or driving a signal from two different sources, etc.
Hardware description languages are not imperative programming languages (even if they might superficially resemble them). That doesn't mean they aren't programming languages at all -- they just belong to a different category of language.
(I suspect that there's a connection between hardware design and functional programming, but I don't have enough hardware design experience to know how closely the two are related.)
Conal Elliott, Haskeller of FRP fame, was recently working for a company where he was developing a compiler of functional programming into categorical semantics which is actually quite neatly similar to the layout of a circuit. The company went under, unfortunately, so I'm not sure of the status of his research, but some remarks are available on his blog [0] [1] [2].
Further, there is a notion of a Generalized Arrow [3] which is a useful, advanced functional programming technique which is quite nice for implementing FRP. These are somewhat obviously "wiring diagrams" but are shown to be in correspondence with a more normal "lambda calculus"-like syntax.
They are programming language, but you don't program the FPGA device with them. Your program a generator that runs on your CPU and creates the physical layout for the FPGA device as its output.
(Apologies for deletion. I moved my comment to parent. Won't try that again.)
It is, but on a different level. I think the analogy would be that in VHDL/Verliog you are dealing with a template or macro language (which is executed to generate code) as opposed to a low-level language (which translates almost directly to machine instructions).
I'm not sure a presence of a stream of instructions or anything comparable is a requirement for a definition of a "programming". You can program a DNA, or a slime mold: http://www.wired.com/2013/06/slime-mold-computers/
Anything which can be used to implement any kind of computing in a broad sense is a programming, as long as it's done using a well-defined formal language.
> (Aside: I am intentionally sticking with U. S. customary units of pounds, miles, etc., to be consistent with much of the related literature.)
From the article, it sounds like dietary science in the US is done with imperial units. It was written by an American for a primarily American audience. Americans track their weight in pounds. Those seem like pretty good reasons to not use metric to me.
