[Warning: I am not a coder, just interested in the topic. So I don’t really know what I am talking about ]
Recently I stumbled across a presentation about the paradigm of Functional Programming.
Two important aspects of this coding approach are:
Write “clean functions”: You pass an input (or many) into the function and return an output - no calling or writing of global variables from inside the function, no “side-effects”, only the return value
Immutable Data: To avoid data being changed under your nose while running a function, you make all data storage immutable. E.g. instead of changing (overwriting) an element in an array, you create a copy with the updated element. To prevent lots of redundant copies of data, you only write new entries and use some clever tree-structure to reference all the most up-to-date data.
It sounded extremly Ceptr-ly to me. So I wanted to ask:
Is Functional Programming a thing with Holochain developers? And if not, should it be?
Would love to hear your thoughts!
Hi @jakob.winter there is a relationship between Category Theory and Functional Programming.
And I have seen some refer to Ceptr as “…a planetary distributed semantically rich functional reactive programming environment…AKA processing of immutable streams, which reminds me strongly of receptors.”
A great comment from @pospi on Mattermost:
I imagine @pospi @dellams may want to share their thoughts on this topic.
Functional programming is pretty neat, and I’m curious to see how people will uncover the overlaps between it and Ceptr/Holochain. Seems like many threads in the computing world are converging… @jakob.winter which parts seemed particularly Ceptr-ly to you?
Interesting thoughts from @pospi on how functional Rust isn’t, @dhtnetwork My gut feeling is that anyone who learns the basics of functional programming will write more disciplined, bug-free programs, which will put them in good stead even when they’re writing in languages like Rust that don’t make FP style easy. This’ll be especially important in validation functions!
A receptor (in Ceptr) is a little piece of code that accepts some inputs and gives an output, independent of where it is running (could be any device anywhere in the world).
Functional programming treats functions in the same fashion: Functions accept some inputs and give an output.
I dimmly remember reading about Ceptr allowing to nest receptors (please correct me if I am wrong). So designing even the functions inside a receptor as pure input-output machines would make perfect sense… receptors all the way down to the smalles unit…
Hmmmm, it’s been so long since I read about Ceptr that I can’t remember what a receptor is — it may store/change local state or it may not. I do know that @artbrock and @zippy were influenced by both Lisp (which is fairly functional and is echoed in ‘semantic trees’) and Smalltalk (which is more object-oriented, wherein objects can store and change local state). Maybe if the two of them have some free time, they can steer us straight
I believe you are right. A receptor without local state wouldn’t make much sense.
Well, it could be quite useful as a translator or filter between different types of signal — a ‘membrane’, if you will.
My gut feeling is that anyone who learns the basics of functional programming will write more disciplined, bug-free programs
Spot on. Can you mathematically prove that an imperative program is bug-free? No you can’t
Personally I feel as though Rust is more functional than imperative, but there’s room for debate there. The reason I say that is that the compiler uses Hindley-Milner type inference… in contrast to (crap) languages like TypeScript, this means you can get strong typing in Rust without a heap of verbose annotations. Most “proper” functional languages use the same algorithm.
This is also the reason you get better error messages from the Rust compiler than many other languages you’re used to. Its style of compilation isn’t just some dumb thing that chews through symbols mechanically and spits out instructions, oh no. What
rustc does is to solve constraints given by your source code, and then determines whether any program is possible. If so, it builds you one. If not, it shows you the conflicting constraints. I dunno if that is relevant but I think it’s cool.
For the JS devs, I really recommend looking in to https://ramdajs.com/ (if you get good at it, more or less the only dependency you’ll ever need again) and https://flow.org/ (which is like Typescript except far more powerful and it can do FP properly… TS doesn’t handle pure functions, variadic arguments or partial application well… thus my contempt for it forcing every JS app to be written like a much more verbose Java app ><)