> reads like an ode to Haskell/ML. It may seem like that from the intro, and from how the text is frequently summarised, but a closer reading shows that what

> reads like an ode to Haskell/ML. It may seem like that from the intro, and from how the text is frequently summarised, but a closer reading shows that what Backus proposes is almost as different from modern functional programming as it is from imperative programming. For example, Backus stresses the need for not naming parameters. This is a supported (if not universally liked) coding style in most modern functional languages, but the lambda calculus is fundamentally about naming parameters. The language that Backus proposes, FP, isn't really a lambda calculus-style language. It has more in familiar with APL or stack-based concatenative languages. > maybe FP will be the future, but right now and considering everything is a stack machine that has ASM/C under the hood, things have to change on the hardware level to enable deep change in both our hardware and our curricula You don't really need anything to change at the hardware. The hardware should stick to doing computation as well as physics permit, and then we can always come up with programming models that fit. I myself am working on a functional language (in the lambda calculus tradition) and an optimising compiler that generates pretty efficient GPU code[0]. GPUs are nothing like any reasonable mathematical tradition, but it turns out to be, if not easy, then reasonable to map a subset of functional programming (namely, array programming) to GPUs, and probably other parallel machines. This is because the programming model makes very few requirements of the runtime system, giving the compiler a lot of freedom to bridge the rather large conceptual divide between high-level array programming and massively hardware. Imperative languages don't really grant the compiler this freedom, because they impose very strict ordering requirements on when their component statements are executed. Automatically determining when such ordering can be ignored (to obtain parallelism) is very very hard. At the other extreme, a lazy functional language (like Haskell) requires a lot of flexibility at runtime to deal with thunks and spontaneous allocation, which also inhibits the compiler's ability to bridge the divide and generate efficient code. Related, but not strictly a language issue, is the dirty secret that many of the beloved functional algorithms and data structures are inherently sequential. It has been said (although I sadly don't remember by who) that "the linked list is the GOTO of functional programming". What is meant is that the use of linked lists enforces a strict sequential ordering and fiddling around with cons cells, instead of focusing on the overall structure of the computation. For this reason, parallel functional languages generally do not have linked lists as their primitive type, but use arrays instead, and have map/reduce/scan/etc as language primitives rather than library functions. [0]: https://futhark-lang.org https://futhark-lang.org