maxpagani.org

Is C++ Ready for Functional Programming? – Intro

Posted on 2021-02-222021-02-23 by max Leave a Comment

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.

Comprehensive For in C++

Posted on 2020-11-302020-11-30 by max Leave a Comment

Switching back and forth between Scala and C++ tends to shuffle ideas in my brain. Some ideas from Scala and the functional world are so good that is just a pity that can’t be applied directly and simply in C++.

If you carefully look into idiomatic C code for error handling, it is easy to find a lousy approach even in industrial code. I’ve seen a lot of code where not every return value was examined for an error, or not everything was thoroughly validated, or some code was executed even when it was not needed because an error occurred but was too cumbersome to provide the escape path.

In C++ things are a bit better, thanks to the exception mechanism, but exceptions are such a pain in the neck to get right and to handle properly that error management could soon turn into a nightmare.

Error handling in C and C++ is so boring and problematic that the examples in most textbooks just skip it.

(featured image by Nadine Shaabana)

From C to C++ and back, but not for the reason you may think

Posted on 2020-10-312020-10-31 by max Leave a Comment

After six years of writing firmware in C++, I nearly forgot what it is like to develop in plain C.

In fact, I remember I wrote quite convoluted C macros to implement template-like containers, therefore when I was handed a prototype firmware to contribute, I thought I was quite fine. After all, I needed just to dust off my old library to be up and running.

Well in the past six years not only I wrote C++ firmware, but also I have been dangerously exposed to high doses of functional programming. Therefore my last C++ code looked a lot like (at least in my intentions) Scala code, just more verbose.

C Strings, a C++ View

Posted on 2020-09-252020-09-25 by max Leave a Comment

The worst form of inequality is to try to make unequal things equal – at least according to Aristotle. On the other hand, software engineering tries quite hard to deal with unequal things in the same way. Think for example to the file system concept, it is very handy to deal with data in your hard disk in the same way you deal with data stored on a server across a network connection. As Joel suggests pushing abstractions too hard may hurt, but I think it is hard to disagree that it is very convenient to produce video output regardless of the screen resolution or manufacturer.

So, wouldn’t it be nice to deal with strings regardless they are null-terminated C strings or C++ iterable string? Yes of course, but what does the compiler think about this? Would it generates comparable, if not equal, machine code?

Our Father’s Faults – Wrapping it up

Posted on 2020-01-232020-01-23 by max Leave a Comment

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.

Out Fathers’ Faults – Actors and Concurrency

Posted on 2020-01-162020-05-06 by max Leave a Comment

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.

Our Fathers’ Faults – Actors – Explicit State

Posted on 2020-01-092020-01-09 by max Leave a Comment

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.

Our Fathers’ Faults – Mixing Actors and OOP 2 – Acting is not an inherited trait

Posted on 2019-12-292020-01-01 by max Leave a Comment

This is the second part of the post on why Actors and OOP are really a bad match. In the last post we have seen how adding types and methods to actors could turn into a bad idea, now we look at another aspect of OOP – actors and inheritance.

Once you have wrapped an actor inside an object as our fathers did, you can hardly resist the temptation of composing by inheritance. On paper this is also a good idea, think for example to some sort of service that has some housekeeping to do (registering/unregistering clients, notify clients), what’s wrong in having a base class Service from which LedService can be inherited?

Our Fathers’ Faults – Mixing Actors and OOP 1, Actors with methods

Posted on 2019-12-192019-12-19 by max Leave a Comment

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”.

Our Fathers’ Faults – Akktors and Ekkstras

Posted on 2019-12-132020-01-01 by max Leave a Comment

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.

Blog