Writing code that is concurrent by default is a massive paradigm shift when all I had been exposed to at that point were procedural languages.
Writing code that is concurrent by default is a massive paradigm shift when all I had been exposed to at that point were procedural languages.
(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.)
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.
[0] http://conal.net/blog/posts/haskell-to-hardware-via-cccs
[1] http://conal.net/blog/posts/overloading-lambda
Deleted comment
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).
Or even crabs: http://hackaday.com/2012/09/28/making-logic-gates-out-of-cra...
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.
Say
e.g:
state read_input =>
reg_a <= input
next_state <= multiply_input_by_10
state multiply_input_by_10 => reg_b <= reg_a * 10
next_state <= finish
state send_to_output => finish_reg <= '1'
and then parallel to that you would have finish_wire <= finish_reg
value_wire <= reg_b
or something like that, sorry for the bad example but definitely use state machinesSoftware tools are also way ahead of FPGA tools. I'm not sure how folks that develop FPGA designs professionally retain their sanity after using the tools...