Why?
Cardano’s plutus is a strictly typed pure functional programming language used for defining smart contracts.
Random:
SnipCart could be the first shopping cart platform that we see supporting Cardano, I’m saying this as logical speculation, devs I know are anxiously waiting for Q2 which just happens to coincide with a hedge fund manager I ran into, expressed the same Q2 view, coincidence?
I believe it is due to Haskell’s type system. You can obviously do a lot with Scala (see shapeless), but it is quite easier to express in Haskell, even when you need to load up a couple of extensions.
The first thing to learn before learning FP is why you want to learn FP. The answer to this question is the best way to guide you to the correct learning material (believe me, you can spend your whole life learning FP and related stuff). If you want to understand what FP (kind of) is, any quick-and-dirty tutorial is mostly likely to do it for you. I usually suggest the mostly adequate guide to functional programming that gets you covered for the basics and a little bit more.
Thanks. Bookmarked that baby too. I mostly want to learn it because I’m “lazy”, meaning, if shifting my thinking paradigm to FP is going to help me be more of a productive programmer, even if it means not necessarily writing the most efficient code that one could crank out in C, I think it’d be useful. I’ve no problem with expressing solutions to problems recursively, my major ‘hangup’ now is how does on deal with side-effects and how does one “think” when designing programs with side-effects… I still struggle with the imperative mind, where you have a sequence of statements … whereas FP leads you to a style of programming - at least in the extreme case- where you have perhaps one top level function in your main(), that just takes input and spits out the output, and that one then calling another function, the one within calling yet another, etc, all passing input and getting output, without any imperative/sequential statements… I know this is unrealistic f(g(h(i(j)))) - but my noob nature is now trying to leap into eliminating ALL imperative code… not even sure if that’s possible. And then you have the side-effects - if you write code like this, which is fine - then are the side-effects basically the last thing that executes (lazily), after all other functions are complete? Meaning, are the side-effects supposed to always sort of come “last” and wrap the computations of pure, referentially transparent functions?
Also another thing that bothers me is large program design - how do you approach it? With OO, you try to identify concepts which then become classes and assign behaviors (apis) to them, hopefully self-contained, and loosely coupled w/other classes… how is this kind of namespace isolation that classes provide achieved in something like Haskell? Is everything “global” in Haskell - I know that’s a dumb question, but OO has its applications too, that I don’t see as exclusive of FP, more like orthogonal to FP…
Anyway, that’s where I’m at … now let’s see if I can get those scala submissions going :).
FWIW: Topic and links presented as “food for thought” - personally not interested in any active involvement with developing and/or testing Cardano. I am, however, very interested in seeing that the project succeeds.
When you tire of the constant breakage, and want to quit publically stepping on your johnson, embrace release testing. The sooner the better…
With FP there are no side effects . It is very programmer intensive because it only allows you to write truths first before running them , you should never get any unexpected outcomes. It is thus very cognitively demanding to write . The imperative way is to get stuff done … the functional way is to find out what can be done and then that is your program … Very labor intense … but A++ uptime and unbreakability are some nice attributes…
The extent of your “side effects” are the extent your expressions are imperfect, and thus it is to Haskell reddit I would send you.
I would recommend a deep dive into the why of the lambda calculus and include Godels point of view , but that is just me .
All fp code should be “perfect” but , as experts say, it’s easy to write more complexity than you need.
One helpful concept to have at heart is abstraction/evaluation … one takes you away from final output and towards concept space , and evaluation takes you to the final output of your functions
Perfect (simplest) FP can be a thonier goal to pursue , because , a lot of coding you spend extra time on and is more verbose, but accomplishes thr goal of the functionality just as perfectly. Then, you can go to a repo and find your exact same program in 90% less code.
The reddit has a lot of subdebates on the “truth” properties of different ways of “doing/writing” the same programs.
Personally , I found that a grasp of combinatorics and lamba background helps me find my way around understanding which modules will do what.
Your actual # of tasks in writing in Haskell, casually, is very limited… you find and express your value functions , then arguably use modules to accomplish the so to speak I/o/db manipulation… Disclaimer, I am a Haskell newcomer, so take my advice with a grain of salt … but as someone from a computing theory and math perspective, I would say Haskell makes complete intuitive sense , but still that the programming with it is hard work, because the onus is on the coder to find a perfect function to use, Whereas in imperative programming , the burden is much more so on the computing architecture, and the coder merely specifies actions to take. The downside of it is that you have a hard time relying on perfectly logical and truthful behavior from your program… Those risks are side effects .
In fp, you should fully expect all outputs. … in imperative, your program has a high inherent and implicit risk of breaking if it receives unexpected or exploitative inputs or input chains .
Hth just my 2 cents as a fellow person in awe of fp’s power
Functional Programming (broadly-defined) does not really care about effects. If you gotta use them, you use them. You can see this approach being taken in most of the so-called functional languages: Scheme, SML, etc. Haskell could have taken this approach too if it was possible. However, in lazy evaluation you don’t have a fixed order of evaluation, so performing effects would be a great mess. Then Phil Wadler came up with this idea of using Monads as a sequencing operator that would make sure an order existed when performing effects (you can verbosely force linearization of some effects with let … in tho). So, effects are always there since they are what makes our programs “useful”. In summary, what Haskell does to you is to make you aware of effects. While such awareness can be transposed into other languages (albeit manually), I don’t think that programming Haskell-style in other languages is fruitful in most cases.
Haskell has the concept of modules where you define your datatypes and functions, and then you can export and import them in other modules. You can relate this model to the way nodejs modules work (albeit the implementation details may vary greatly).