Programming languages you should learn in 2021

This kind of title appears once in a while in feeds and in search results about languages (I do search for languages trends).

I want to make my own list. I am not going to suggest a language because they can give you a job, high salary, or because it’s what all the buzz is about. These factors mean nothing.

I am not going to explain why you should learn something about all those languages: you will get it once you study them!


Annoying Ubuntu

Ubuntu is getting more annoying. Recently — I can’t remember exactly when — I’ve got a forced update which could not be interrupted. Very microsoftwindowish.

Now, it’s trying to make me upgrade the system to Ubuntu 20.04 LTS. The LTS bit almost got me, so maybe I’ve a little bit of peace.

But it told me it could take several hours. This made me think and check what’s in this 20.04, codenamed Focal fossa.

And I decided to stop the process and well, think to switch again away from this canonical monster — it’s nice and everything, but I can’t stand this microsoftish attitude and, more importantly, the very concept of updating regularly a system experimenting “new” features which smell a little (snaps what?).

Then, the only update I expect is about bug fixes. Moreover, we don’t need to ride the versions-wave of every software, unless we need that very brand new feature it hadn’t or that didn’t work so well in the current version.

I’m starting to believe that the package system and its dependency handling is broken, after all. Not as “technology” per se, but because of how packages were created — I remember vaguely to have stumbled upon a package which wanted its documentation, and so I couldn’t install it without that unnecessary burden. Maybe I don’t remember well and the dependency wasn’t with the doc package… anyway a dependecy oddness of sort happened and pissed me off.

Now, Ubuntu 20.04 LTS, … codenamed Focal Fossa

Please, STOP referring to Ubuntu versions using their code name!

This is one thing which is very annoying. Shame on all authors who like to do so. With a version number, I know what comes first and what comes later. With a silly name, I can’t.

So, please, stop referring to Ubuntu versions using their code name.


Ok, the trend is to use container, and whatever. Snaps look like that to me. Replacing the Debian packaging with these snap scares me. If I need containers, I think I would use docker — in fact I’ve installed it already. Normally, I don’t need snaps and all the new things needed to make them work.

It’s just crap. Moreover it is Canonical behaving like Microsoff, pushing a “new” technology which they made when other solutions already existed.

It is even worse than the introduction of that crappy thing which luckly died away; how did they call it? I think it was upstart. It had been talked about as if it were a great thing. It wasn’t.

Not that I am the “if it works, keep it” kind of guy all the time. But there are stupid attempts at innovation — innovation is the word used to say that there’s a change and to present that change as a good thing, when indeed nobody has really considered if it is good for the average of the users.

If then changes create new problems which need to be solved by experienced people, who are few because the “innovation” is new too, … well. Very few people — i.e., no one — need to have always the last version, the last software, the last innovation.

I think snaps’ destiny is to fail, but it will be harder to go back for adopters, and so that failure will survive longer than it could be.

My suggestion is to drop snaps: do not use them, hence do not use Ubuntu anymore until it will be back on its track.

Let me say it again:

Do not use Ubuntu anymore until they “park” snaps

About me… It is always hard to reinstall everything, to start over with a new distro — not all distro have all the packages, few programs could be missing… After years of “tuning”, it will be very upsetting. I fear the moment when it will be necessary: for now, I will continue to use Ubuntu 19.10 as I have it on my machine.


When I was about to upgrade I had also a list of package the upgrade would have removed. Among these now I remember only coccinelle.

Why they removed it?

Maybe I don’t need Coccinelle in particular, but there where hundreds of packages to be removed. Not supported anymore? Why? I don’t want to go and check what an upgrade will uninstall without a reason, and wonder why they decided to remove the package. If I have it on my system, I want it on my system also after upgrade. Linking problems with new library, nobody cared to recompile something successfully with the library versions? Make a static package with old library version, maybe — no, do not think about snaps to solve this.


Suggestion to abandon Ubuntu towards… Debian again? I installed Ubuntu in this new laptop of mine hoping for a better hardware support, in particular for the graphics card… but I could just hope in the latest nvidia driver, and that’s all — also considering that for most of the time I don’t use the nvidia card — also, last time I messed with prime, bublebee, and whatever, and now I can’t even remember if I can switch to the nvidia card successfully…

Another anti-snaps detail

Those shitty idiotic snaps are polluting the mount points, so that when I do mount, I get a list loger than it should be, in my case, even if I hadn’t upgrade, 26 snaps

26 snaps!

26 snaps were pushed in my throat without even being notified. There are gnome components, gtk-common, and few more thing, e.g. “core” which appears four times.

/var/lib/snapd/snaps/core18_1754.snap on /snap/core18/1754 ...
/var/lib/snapd/snaps/core_9066.snap on /snap/core/9066 ...
/var/lib/snapd/snaps/core_8935.snap on /snap/core/8935 ...
/var/lib/snapd/snaps/core18_1705.snap on /snap/core18/1705 ...

And those are polluting my mount result. And they are using /dev/loopN more than usual. And they appear also when I do df -h, so that I need to filter them out. This is more than simply annoying… I feel like I need to metaphorically head-bang the Canonical guys responsible for this.

Please, please, don’t tell me you like this. It also looks very microsofterish to me, again. They are ruining things, and to push a technology which already existed — thinking of flatpak, AppImage, and alike.

Snaps, go to heck.


Enumeration (enum) in Perl6

Perl6 has enum. Now I have acquired a little bit of the Ada mindset, so I expected something similar. But Perl6 isn’t Ada, of course, hence I was disappointed. Should I retune my expectations taking into account this fact?

Yes, but also no. Because Perl6 enumeration doesn’t feel completely right.


Snippet/ Prolog in the Java documentation

Just spotted this:
The type checker enforces type rules that are specified by means of Prolog clauses.
from here.


Dynamic dispatching reloaded

In previous posts I was exploring a feature I am interested in, and which I have called in many different ways — here I will call it dynamic dispatching.

The previous articles:

Conclusion of those posts: out of the box only Perl6 has it.

The story went on like this: I stirred the net for a solution in C++. And I obtained it.


Nested functions

Some languages allow nested functions (or procedures, or subroutines, or whatever you prefer to call them), others don't.

I think those can be useful and I wonder why they aren't embraced by all living programming languages.


Changing input validation in an established API

Let's suppose that your server S exposes an API and that this API is used by many clients, or maybe just one — it doesn't really matter.

Let's focus on a client only, let's call it C. Documents were exchanged between S and C, so to agree on the interface.

After that, tests were done and none raised issues or, if they did, they were fixed.

The tests stated that S and C can talk, that they can understand each other, that C calls S correctly, that S acts properly according to the request, that C parses server's answer correctly, and so on.

Everything works fine, or mostly fine, since the beginning.


This is google

I am not going to do anything about it. If there are interesting comments, they'll be lost. Hopefully I haven't relied on comments very much — thankfully no one, or few, cared to comment! There are maybe a couple of exceptions in this very same blog. As already written, I am not going to do anything about those, sorry.

But remember: Google can take away from you everything it's given before, and you haven't a say (of course). Hence don't forget that things you can touch in the world are, and always will be, better than anything digital.


“Dynamic overloading” in other languages (not C++)

In a previous post I've imagined that future C++ could dynamically dispatch a call to a proper function/method according to the derived types of its arguments — that is, dynamic overloading, whereas notoriously in C++ overloading is a compile time feature.

Now the question is: what about other languages?


Dynamic overloading

I have always stated that I dislike C++. “Modern C++” (from C++11 on) changed a lot, but the language still has plenty of dark corners. And limits when you would like to achieve easily some goals, but the language reminds you it doesn't work that way, so things can become more complicated than you would like to think.