Well that's an interesting view, functional languages are based on lambda calculus whereas imperative languages are all based on Turing machines. But lambda calculus and Turing machines are provably equivalent ways of describing computations.

One is not a rehash of the other, they are alternative yet equivalent, in the sense they can each model computation but in quite different ways.

Functional languages are much closer to mathematics, have a purity much closer and that's is an appeal - well for me it is!

https://forum.allaboutcircuits.com/threads/why-do-we-use-recursive-function.145874/post-1240875

I agree with you. It's nice to know about them for ways to solve a specific problem but I find that style of programming too abstract for most practical applications.

https://woodridgesoftware.com/advantages-functional-programming/

 

https://forum.allaboutcircuits.com/threads/why-do-we-use-recursive-function.145874/post-1240875

I agree with you. It's nice to know about them for ways to solve a specific problem but I find that style of programming too abstract for most practical applications.

I think it all depends on the problem domain. Some of the claims made about functional languages seemed far fetched to me a few years ago until I started to explore them in earnest.

Some of the claims are "If it compiles it likely works" and "the amount of code is smaller" and "the number of odd, edge case types bugs is much smaller".

These seemed like lofty, over stated but it seems there a great deal of truth, some of financial modeling firms seem to get huge benefits over imperative solutions. Some of the people making these claims turned out to be very experienced team leaders and managers who'd been around the block too, not just newbies playing around.

I do think that these languages are out of reach for MCU systems though, but data manipulation, parsing, etc seem to definitely get benefits.

F# in particular is excellent due to its integration with .Net which is now superb and runs in Mac, Linux etc.

 

Functional programming based on lambda calculus has been around since the 1950s with LISP. Most hardware engineering brain types that also program barf at the sight of this type of hot mess.

 

I've been playing with FPGA's (only just beginning) and they are great devices but the languages (System Verilog) seem artificial, an encumbrance and I've been wondering if a more functional-like language would make any sense.

However I am far to new to the subject to say much, just a feeling I get as I work with the devices.

The hardware structure is a bit like a function, inputs and outputs which parallels a functional language.

 

Functional programming based on lambda calculus has been around since the 1950s with LISP. Most hardware engineering brain types that also program barf at the sight of this type of hot mess.

Did you ever have an opportunity to use APL?

 

Did you ever have an opportunity to use APL?

I might have touched a old Waterloo version ages ago but never really used it.

 

I've been playing with FPGA's (only just beginning) and they are great devices but the languages (System Verilog) seem artificial, an encumbrance and I've been wondering if a more functional-like language would make any sense.

However I am far to new to the subject to say much, just a feeling I get as I work with the devices.

The hardware structure is a bit like a function, inputs and outputs which parallels a functional language.

The big difference between CPU and an FPGA as far as a language is concerned
is
a) An RTL has 9 levels or so , not just 1 and 0
b) An FPGA is inherently parallel, where as CPUs , though they might have the odd multi thread, are effectively single threaded
c) RTL designs, the timing is always important, in CPUs its much more on lines of "lets see what we can get"

I would love to be able to have a language that allows easy abstract concepts in FPGAs , but the tools are decades from being able to do so

The "best" that has been cmoe up with at the moment,
are various versions of "lets write C , and add pragmas to tell the tools what to do "

 

The big difference between CPU and an FPGA as far as a language is concerned
is
a) An RTL has 9 levels or so , not just 1 and 0
b) An FPGA is inherently parallel, where as CPUs , though they might have the odd multi thread, are effectively single threaded
c) RTL designs, the timing is always important, in CPUs its much more on lines of "lets see what we can get"

I would love to be able to have a language that allows easy abstract concepts in FPGAs , but the tools are decades from being able to do so

The "best" that has been cmoe up with at the moment,
are various versions of "lets write C , and add pragmas to tell the tools what to do "

Yes, I was reading about the toolsets recently. Lots of grumbling, SystemVerilog gets a lot of criticism it seems too, based on C++ which itself a problematic idiosyncratic language.

I'm not familiar at all with "RTL" not heard the term before, but as I said I only just started dabbling with an FPGA (I studied electronics for two years back in 1980 which covered a lot of digital (as well as analog) design so I'm at hone with the basics, just not done anything with any of this in the past 30 odd years).

Functional languages are very different to imperative languages like C, C#, C++, Java. No loops, no (explicit) state, no variables and so on.

In a functional language functions always return the same result for the same inputs, always (one can violate that if they want but it's not the done thing). Thus there seems to be a parallel between a bunch of functions like that and a combinatorial digital circuit.

Even just playing with SystemVerilog in Vivado made me think "Why didn't they use the word 'when' instead of 'if'?". The word "if" is so closely associated with on-the-fly branching/decision making whereas in the simple digital circuit I was looking at it was just a possible state of some inputs.