Idiomatically written Red is largerly data-driven, composed out of mini languages and micro formats (dialects), with huge emphasis on homoiconicity and rich set of available datatypes.
Functions indeed are mostly used to guide the flow of program and stack dialects on top of one another, so the resulting app is like a dedicated toolchain (or even a VM), where each component is a small interpreter or compiler.
> I used to point out to people that functional programming can be imperative and nobody (I do mean nobody I spoke to about this) would believe me on this.
Interesting. Monadic Haskell can be quite imperative if you want it to be, as can SML or OCaml. Scheme and Lisp have imperative parts too.
Re:Red Programming Language: Plans for 2019
by grenadier21 on Monday January 07, 2019 @07:56AM
(#18844753)
Haskell's IO is literally the idea of sequencing commands reified, though, so the comparison is a bit apples-to-oranges.
Re:Red Programming Language: Plans for 2019
by macintux on Monday January 07, 2019 @07:55AM
(#18844750)
Ditto Erlang.
Re:Red Programming Language: Plans for 2019
by lerpa on Monday January 07, 2019 @09:35AM
(#18845379)
What's the different between that and plain old structured programming subroutines?
> the nesting of functions defines both the stacked structure and the resulting control flow
That's called not being functional. What distinction are you drawing between "functional imperative" and regular imperative languages?
Even the Wikipedia article gets this wrong: https://en.wikipedia.org/wiki/Functional_programming
Functional imperative is the idea of using functions to define the shape of an application, which is to say the nesting of functions defines both the stacked structure and the resulting control flow opposed to describing units of logic or any sort of reflection.
https://en.wikipedia.org/wiki/Function_model#Functional_deco...