## 2020-08-30

### Ada 2020 target syntax (at)

I’ve already talked a little bit about Ada++ — just a waste of time, in my opinion.

Somebody once told me that he liked C because you can write

   a++;

where other languages require

   a := a + 1;

I don’t see the problem, but imagine that the variable to be incremented is longer:

   A_Long_Name_For_A_Var := A_Long_Name_For_A_Var + 1;

Well, in Ada 2020 you can write

   A_Long_Name_For_A_Var := @ + 1;

(Yes, Ada 2020, not in Ada 2012… GNAT already support -gnat2020 and this feature, but I suppose you must check what else is supported before embracing anything in Ada 2020.)

## Let’s say it again: Ada++ syntax is a silly idea

Silly to say the least.

Now I’ve stumbled on A Modern Syntax For Ada and had goose bumps and thrills along my spine.

Before spitting on that job of Adacore’s core members, luckly I’ve read that it’s just a April Fool Prank.

Now I feel better.

But let’s compare the idea of this prank with Ada++…

Ada++ embraces part of those ideas scolded in the april fool prank!

• is becomes :
• pointless shortening (here return becomes ret, function becomes fn… Ada++ has priv instead of private…)
• begin becomes { and end }

So, I hope I am not alone when I say that Ada++ is a horrible idea and hopefully I won’t be the only one rage rejecting it.

## 2020-08-29

### Top 10 highest paid programming languages

I don’t think one should learn a programming language just because it is well paid. A programming language is just a tool, you can use it well or bad, to build or destroy, to make life great or miserable to your future self and your collegues — and your employer, I forgot to mention it…

But real life, alas, works like this: you choose your tools not just because they are the best to do what you want to do: you choose them because there’s someone willing to pay you to use them, even if they aren’t the best tools for the job — but, you know, everybody’s using this, or that, or that, or that…

Maybe that explains the success of certain languages and their ecosystems: nobody thinks to ask if they are the right tool anymore… At least, that’s so when the product isn’t, indeed, critically bound to such a technical choice, and hence market- and money-induced blindness don’t waste everything… Apparently…

Anyway, if I were you, I wouldn’t enrich my skillset just looking at boring lists of most paid this or that. It’s a dangerous path (maybe not for the wealth, but for the health of the consultants’ built digital world, it kind of is.)

Articles with titles like “Top N something” are almost click-bait. Be prepared to read BS — which doesn’t mean there isn’t some research and value in those words.

Well, do you really want to become rich programmer? Then, maybe the article Top 10 highest-paying programming languages in 2020 appeals to this secret desire.

Let’s see…

## 2020-08-15

### Absurd dependencies

Writing something in texinfo, it happens that I can’t use @subentry for the index. It seems Ubuntu 19.10 has an old texinfo. So I downloaded the latest and wanted to purge the old one. But:

$sudo apt-get remove texinfo [sudo] password for user: Reading package lists... Done Building dependency tree Reading state information... Done ... The following packages will be REMOVED: cantor-backend-octave dynare liboctave-dev lilypond lilypond-data matlab2tikz octave octave-bim octave-biosig octave-bsltl octave-cgi octave-communications octave-communications-common octave-control octave-data-smoothing octave-dataframe octave-dicom octave-divand octave-doctest octave-econometrics octave-financial octave-fits octave-fpl octave-fuzzy-logic-toolkit octave-ga octave-gdf octave-general octave-geometry octave-gsl octave-image octave-image-acquisition octave-instrument-control octave-interval octave-io octave-level-set octave-linear-algebra octave-lssa octave-ltfat octave-ltfat-common octave-mapping octave-miscellaneous octave-missing-functions octave-mpi octave-msh octave-mvn octave-nan octave-ncarray octave-netcdf octave-nlopt octave-nurbs octave-octclip octave-octproj octave-openems octave-optics octave-optim octave-optiminterp octave-parallel octave-pfstools octave-plplot octave-psychtoolbox-3 octave-quaternion octave-queueing octave-secs1d octave-secs2d octave-secs3d octave-signal octave-sockets octave-sparsersb octave-specfun octave-splines octave-statistics octave-stk octave-strings octave-struct octave-symbolic octave-tsa octave-vibes octave-vlfeat octave-vrml octave-zenity octave-zeromq texinfo texlive-full Why? Why removing texinfo should bring down the whole texlive-full and whole pieces of octave and… WTF. Idiotic, nonsense dependencies. So I will keep that old texinfo. And Ubuntu has one more angle to push me towards their personal nightmare (I mean, snaps). ## 2020-08-09 ### Old times news Weeks ago I digged into one of my dad’s hard drive on his Microsoft Windows office machine, searching for interesting stuffs he could have left there. Since I hadn’t the time to cope with all the amount of data found there, I did a simple dir /s ... >a_file.txt (or something like this) to have a list to check against the content of other hard drives at home. Likely what’s there was already copied here. ## 2020-07-31 ### Ada++ what? Not very much time ago I commented on a post on LinkedIn. The post promoted the “Ada++” language as some sort of better Ada. As an Ada hobby newcomer who began to like the language very much (and who started to consider C++ acceptable in its modern revisions, and yet continues to think not very much of that really important and powerful language), I felt horrified. Ada isn’t perfect, nothing is perfect, but the comment made me think it was almost all because of the syntax. What’s wrong with Ada’s syntax? According to me, nothing; and on the other side there’s C++, which to me is a syntax nightmare. One month later or so, I stumbled on that comment again and took a look (again!) to the Ada++ website. Looking around… again… I confirmed my first impression that the idea is horrorful, even if it would about syntax only. Do we want a C++-syntax-like language? What’s the value in this? Will C++ developer feel more comfortable? Why not a C++ada language where C++ imitates Ada’s syntax, just to make Ada developers more comfortable with C++…? ## 2020-06-21 ### Golfrun reloaded in lisp? Currently I’m mainly trying to learn more about electronics and hardware, beyond the basic things I already knew (also opened a new Italian blog to dump whatever related — everything indeed begins from my dad’s death and his stuffs). But I never stop to try and learn other things, especially in the software field where I feel more comfortable. ## 2020-06-20 ### Snap the back of those snaps I’ve already said how annoying Ubuntu is getting. Already said something about that crappy things they call snaps, that idiotic insane attempt to replace the honorable and mostly working and easy enough (from the users’ point of view) usual package system used by Debian and other “.deb” distros, with the “.rpm” as competing school (and few others in other distros). Leaving apart the fact that snaps are old (already) ideas rebranded, likely modified a little in details the common users don’t care about… but anyway… And leaving apart the fact that if I want something like that, I can AppImage or flatpack, and even docker at last. So, nobody needed snaps. Let’s fake I forget the fact that this change is pushed in a microsofterish way, and let’s fake there could be some kind of merit in whatever snaps do and how they do it… No wait, I really can’t fake this. And for some reasons. There are several ways this CRAPPY CANONICAL THING called snaps is polluting my system with unwanted, annoying artifacts. • A new folder, snap, in my home; because it seems I’ve already 4 snaps which needed that: gnome-calculator, gnome-characters, gnome-system-monitor and shotcut • 2.9 Gbyte taken in /var/lib/snapd — I guess apt would get as much for the same amount of software installed…? Ok, you can leave with those, can’t you? And what about the pollution of mount points? It’s unbearable. $ mount |grep -c snap
26

And the whole system isn’t converted to snaps yet. What would it be when almost everything will be a snap? Moreover, a single snap produces several mount points; e.g. gnome-characters has two, and also gnome-calculator has two. Then there are mount points taken for snapcraft (part of the snap system, I suppose); and core appears 4 times.

var/lib/snapd/snaps/core18_1705.snap on /snap/core18/1705 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/core18_1754.snap on /snap/core18/1754 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/core_9289.snap on /snap/core/9289 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/core_9066.snap on /snap/core/9066 type squashfs (ro,nodev,relatime,x-gdu.hide)

Nice, isn’t it? So, once I did mount to take a look at few more interesting things; now I have to filter those shit out.

There’s still more noise I used to remember, and it can be also because of that shit, again. For instance1,

When hardware is assigned to the snap, a device cgroup is set up with default devices

and that can explain partly the explosion of cgroup lines when I do mount.

Ok, it’s nice that for your security they are polluting that too. No big deal. (It’s shit but who cares?)

Then the other day I was playing with loop devices; it’s hard I didn’t find one available at the second try… This time, no luck. Why? And so I’ve found another by-product of that shit:

\$ losetup -l
NAME        SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE                                          DIO LOG-SEC
/dev/loop1          0      0         1  1 /var/lib/snapd/snaps/gtk-common-themes_1474.snap     0     512
/dev/loop19         0      0         1  1 /var/lib/snapd/snaps/gnome-characters_539.snap       0     512
/dev/loop17         0      0         1  1 /var/lib/snapd/snaps/shotcut_64.snap                 0     512
/dev/loop8          0      0         1  1 /var/lib/snapd/snaps/gnome-3-28-1804_116.snap        0     512
/dev/loop25         0      0         1  1 /var/lib/snapd/snaps/gnome-logs_93.snap              0     512
/dev/loop15         0      0         1  1 /var/lib/snapd/snaps/gnome-characters_550.snap       0     512
/dev/loop6          0      0         1  1 /var/lib/snapd/snaps/gnome-system-monitor_145.snap   0     512
/dev/loop23         0      0         1  1 /var/lib/snapd/snaps/gnome-3-34-1804_33.snap         0     512
/dev/loop13         0      0         1  1 /var/lib/snapd/snaps/kotlin_43.snap                  0     512
/dev/loop4          0      0         1  1 /var/lib/snapd/snaps/gnome-system-monitor_148.snap   0     512
/dev/loop21         0      0         1  1 /var/lib/snapd/snaps/gtk-common-themes_1506.snap     0     512
/dev/loop11         0      0         1  1 /var/lib/snapd/snaps/core18_1754.snap                0     512
/dev/loop2          0      0         1  1 /var/lib/snapd/snaps/snapcraft_4892.snap             0     512
/dev/loop0          0      0         1  1 /var/lib/snapd/snaps/snapcraft_4862.snap             0     512
/dev/loop18         0      0         1  1 /var/lib/snapd/snaps/gnome-calculator_748.snap       0     512
/dev/loop9          0      0         1  1 /var/lib/snapd/snaps/gnome-calculator_730.snap       0     512
/dev/loop16         0      0         1  1 /var/lib/snapd/snaps/core_9066.snap                  0     512
/dev/loop7          0      0         1  1 /var/lib/snapd/snaps/shotcut_61.snap                 0     512
/dev/loop24         0      0         1  1 /var/lib/snapd/snaps/gnome-3-26-1604_100.snap        0     512
/dev/loop14         0      0         1  1 /var/lib/snapd/snaps/gnome-3-34-1804_36.snap         0     512
/dev/loop5          0      0         1  1 /var/lib/snapd/snaps/gnome-logs_100.snap             0     512
/dev/loop22         0      0         1  1 /var/lib/snapd/snaps/kotlin_42.snap                  0     512
/dev/loop12         0      0         1  1 /var/lib/snapd/snaps/gnome-3-28-1804_128.snap        0     512
/dev/loop3          0      0         1  1 /var/lib/snapd/snaps/core18_1705.snap                0     512
/dev/loop20         0      0         1  1 /var/lib/snapd/snaps/gnome-3-26-1604_98.snap         0     512
/dev/loop10         0      0         1  1 /var/lib/snapd/snaps/core_9289.snap                  0     512

Really. Are you all serious about appreciating this shit on your daily desktop system?

Let’s say it again and loud:

Snap sucks

I’m going to leave Ubuntu because of this new level of shiny shit, hoping other distros won’t follow it. This is a strage world: the other day I’ve also read that new version of Nautilus removed the ability to split the view in two panes. This means that it once could do it. Why would you remove such a feature? Maybe because a bunch of developer of Nautilus didn’t use it… So, let’s remove it?

Other things disappeared long time ago, because GNOME is going crap too (slightly better now but still, not so good as it used to be). For example in GNOME Terminal I was used to set the tab title. No more of this. And there are other small things missing because of the “progress” of the GNOME desktop. Each time one has to adapt to a new level of silliness: apps are stripped of features they once had, and the real reason of this is… I don’t know, but I call idiots programmers responsible for some of those crappy changes.

It’s still kind of a shocking memory the “feature” a programmer decided for the move to trash behaviour — too dangerous… if you moved your files in the trashcan by error, it’d have been really a problem! (Already insulted that programmer; luckly the change was later reverted and GNOME’s file manager now behave normally)

1. Ok, it’s about the core product; but I suspect the song is almost the same for usual desktop.↩︎

## 2020-05-23

### 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!

## 2020-05-10

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

## Snaps?

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.

## P.S.:

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.

# Conclusion

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.

## 2019-10-05

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