It was 2015 when I attended my first Scala Italy conference. I was freshly landed in the functional programming magic world and I was tasked by my boss to asses whether Scala was a technology with a future or just a fade. I sat there, as proved by the picture used over the years as a background for the conference website, and enjoyed the show.
The conference was well organized, with a bunch of sponsors and some hundred people attending. My report, reinforced by attending Scala Days 2016 in Berlin, was that Scala was viable with quite a strong interest and support from the industry.
Over the years the conference grew, I missed the Venice edition in 2016, but I was in Rome in 2017, Florence in 2018, and eventually Bologna in 2019. Both Florence and Bologna were two-day events.
Starting the post with “When I was a kid…” sounded proper until I realized this is the typical incipit of elder people talking about something that wasn’t around when they were youngsters. So I convinced myself to find an alternative incipit, but yeah, when I was young no one ever dreamed of working at home, the cave was where rocks and pebbles were and you had to fight your way with saber tooth tigers, wild mammoths, and velociraptors to get there.
The idea of remote working is not new. It gained popularity during the pandemic in the years 2020-2021, but it was already widespread in the technologically advanced industry. Once all your work is done on a computer, thanks to the innovative (but now more than 60 years old) idea of connecting a computer together at a distance – you may do your job anywhere a computer and an Internet connection are available.
TIL what Catamorphism and Anamorphism, and about a new useful function. Functional programmers are not shy to use mathematical terms that could frighten the casual programmer listening. Functor, monoid, applicative just to name the first that comes to mind. Usually, they turn out to be relatively simple concepts (which get combined together until they are no longer simple).
Jung’s Synchronicity theory is as fascinating as unscientific. It is “unscientific” because it can’t be proven false by its very own definition – two events appear to be related even if the causal relation is missing. Someone talks about dreaming of a Golden Scarab and suddenly a Golden Scarab hits your window. There is no apparent causal relationship, yet the event pair is so unlikely that the Synchronicity idea has been developed around this. My rational mind is more inclined in thinking of this as a selection bias (countless times it happens something like – you spend a few days away in a city and suddenly the news is filled with stories about this city). Nonetheless, when it happens I always feel uneasy, like the Universe would like to have a word with me.
So when I read the tweet below, by Mario Fusco, in a quite specific job timeframe, I felt called out
In my whole professional career, I always tried to push the boundaries of the language(s) I was using, from assembly to C++, to achieve better engineering, more robust and safer code, fewer bug opportunities, simpler development, and improved collaboration. This meant sometimes introducing the latest C++ standard, sometimes introducing concepts from other languages and sometimes defining DSL with the help of the preprocessor. So I am not new to some raise of eyebrows when people look at my code.
I’m reading “The Art of Functional Programming” by Ming Quan Tran. The book is short (200+ pages) and well-written, offering a rationale for all functional programming constructs and techniques, often comparing FP solutions with imperative / OO approaches.
It all starts in schools. When they teach you how to program a computer. You get plenty of code that just works in the happy path scenario. So happy path that there are no other paths at all.
And then it is easy to grow, line of code after line of code, with the idea that error handling is not really part of the code. Elegant code has nothing to do with errors. Could be a sort of brainwashing.
And then language designers, present you the ultimate error-handling solution – lo and behold the Exceptions!
You can still write the code the way you were taught and then when something bad happens, throw an exception. A flare fired in the sky, in the hope that some alert patrol on guard could spot and come to the rescue.
In my previous post, I described how I devised a programming problem for an internal company contest with the help of the ubiquitous ChatGPT. Also, ChatGPT provided a solution for the problem as part of the development process. Even more interestingly the language model provided a fictional context for justifying the problem.
The task was to write a function removeVowels( string text ) which takes an arbitrary text (arbitrary as long as it contains no uppercase letters) and returns the same string where vowels have been removed. Given the string “hello world”, the result should be “hll wrld”.
The implementation must not have:
If you want to give it a try before reading the solution, stop here. Otherwise, follow me.
As a winner of the last programmer contest at Schindler MIL, I had to devise a new compelling and intriguing puzzle to propose to my colleagues. The first two puzzles were in the form “Implement X without using Y“, an interesting pattern that allowed for multiple solutions.
But I ran short of (X,Y) pairs, and staring at my blank page I decided to resort to … ChatGPT. Yes, nowadays it is like the uber-solution to everything. Don’t you know how to partially specialize your templates? Ask ChatGPT; don’t you know how to present a topic? Ask ChatGPT; don’t you know how much a brick weighs? Ask ChatGPT; don’t you know how to devise a programming puzzle? Ask ChatGPT.
Back in another era, when I worked for UbiSoft, my then-boss Alain, started a wonderful initiative – the Technical Meeting. Every Friday afternoon, one of us should present a technical argument to the whole team. A good number of Technical Meetings were held, but when the project entered some frantic period. I have fond memories of these meetings.
So I was very happy when I heard that a similar initiative was going to happen at Schindler – the biweekly Technical Session. The idea is very similar – every two weeks one of the colleagues volunteers to make a short technical presentation and give it to the team. Topics are diverse, mainly related to C++. The goal is to have compact presentations limited to 10-15 minutes, ideally including some hands-on parts.
I volunteer for the second topic, which in turn I’ll present here.