Featured image vector created by brgfx – www.freepik.com
Although functional programming can be done in a dynamically typed language (Lisp, the functional programming language forerunner, had no types), strong static type adds a very natural complement to functional programming.
From a mathematical point of view, a function sets a relationship between the set defined by the function argument (domain in math speaking) and the corresponding results (co-domain). Algebra studies exactly these relationships and may help the programmer in proving certain properties of the functions composing the programs.
Algebraic Data Types (ADT) are aggregated types in the algebra context. Two ADTs are of particular interest – sum types and product types. With sum and product referring to the resulting number of possible values (i.e. cardinality of sets).
Continue reading “Is C++ Ready for Functional Programming? – Types”
Time to take a closer look to the standard library from the functional programming point of view.
In the first installment of this series, I stated that using a library to implement functional programming structures would not be an ideal solution, but as C language pioneered in the 70s, part of the language finds its proper location in a library.
C++ standard library has grown disorderly oversize during the years, so let’s have a look at what kind of support is available for those that want to use C++ with the functional paradigm.
Continue reading “Is C++ Ready for Functional Programming? – Standard Library”
In this second installment, I’ll look closer to the core of functional programming – functions. When I started programming, BASIC was the language of choice… the only available choice. And no, it wasn’t the quite convoluted Visual Basic, but the old plain, primitive BASIC with line numbers and poor syntax.
In those days I just used
Continue reading “Is C++ Ready for Functional Programming? – Functions, Functions for Everyone!”
GOTOs and looked with suspicion at the
RETURN wondering why in the world I would need to automatically return when I could
GOTO everywhere I needed… But I’m digressing. It is just for saying that (besides yours truly could be not the best authority on this matter), programming languages have come a long way and the poor BASIC programmer had to spin the evolution wheel for quite a while to reach to concept of function as presented in this post.
Design by committee (DbC) was never meant to be a compliment. In DbC, every decision has to go through a debate and be subjected to a political process. Because of the needed compromise among the parts, the resulting artifact usually tends to be clunky and patchy, lacking elegance, homogeneity, and vision.
C++ is quite an old language, not as old as its parent C, or other veterans of the computer language arena, but the first standard is now 23 years old and the language was quite well-formed and aged to mature its dose of quirks, long before that.
Continue reading “Is C++ Ready for Functional Programming? – Intro”
Well, I’m running out of anti-patterns and oddly looking code from the legacy of my job-ancestors. I thinks that there are a few that are worth mentioning but don’t build up to a stand-alone post, and then its space for questions and discussions and whether exists or not a way out.
Continue reading “Our Father’s Faults – Wrapping it up”
When I started this job and faced the joyful world of Scala and Akka I remember I was told that thanks to the Actor model you don’t have to worry about concurrency, since every issue was handled by the acting magic.
Some months later we discovered, to our dismay that this wasn’t true. Or better, it was true most of the time if you behave properly, but there are notable exceptions.
Continue reading “Out Fathers’ Faults – Actors and Concurrency”
This post is not really specific to Scala/Akka, since I’ve seen Finite-State Machine (AKA FSM – not this FSM) abuse in every code base regardless of the language. I’ll try to stick with the specificities of my code base, but considerations and thoughts are quite general.
FSM is an elegant and concise formal construct that helps in designing and encoding and understanding simple computational agents.
Continue reading “Our Fathers’ Faults – Actors – Explicit State”
This was intended to be a single comprehensive post about what’s wrong in mixing the Actor model with OOP. After a while I was writing this I discovered that there is a lot of stuff to be told, so I split the post in two. This is the first and talks about why you would like to add typing to Actors and then why you would like to get back. The next one (that I would likely publish in 2020) is about why you would like to add inheritance among actors and why guess what… you would refrain to do it. Let’s start.
Once that the concept of Actor as implemented by the Akka framework is clear, we can proceed to the first issue in mixing Actors and OOP, that is brilliantly depicted by the sentence “No good deed goes unpunished”.
Continue reading “Our Fathers’ Faults – Mixing Actors and OOP 1, Actors with methods”
After the first four posts of “Our Fathers’ Faults” it’s time to turn a specific aspect of the application – the Akka framework. The code I’m managing is strongly based on this framework offering endless inspiration for misuse and abuse. Before going straight to the sins parade, I think it is proper a brief introduction to the Akka framework actors and their usage. Half of my two readers are ludicrously proficient in Akka and Scala that they might think of skipping this post wouldn’t it be for my witty ranting prose style, the rest of you two may actually be interested in the content as well.
BTW, actors, as most innovations in programming, are no longer that innovative. The actor model dates back to 1973 (geez, I was 5! I couldn’t even spell “actor”!), but it has been largely popularized by the reactive manifesto as a viable model for reliable concurrent programming.
Continue reading “Our Fathers’ Faults – Akktors and Ekkstras”
Scala tries to help the programmer in many ways. Verbose and repetitive code can be often syntactic-sugarized into concise statements. This is very convenient but encourages the programmer to produce write-only code. Let’s talk about types. In many contexts, you can is very good at inferring types. Consider
val n = 1
This Is the most obvious case, you don’t need to specify
Continue reading “Our Fathers’ Faults – Scantly Typed Language”
Int because the language manages to infer the type of the variable from the type of the expression to the right of the equal sign.