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.

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++…?

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!

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.

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.

Harmful go to (heck)

One size doesn't fit it all

Just to remember that OOP does not fit all. Cited from this document, emphases added by me.

Ada 83 was object-based, allowing the partitioning of a system into modules corresponding to abstract data types or abstract objects. Full OOP support was not provided since, first, it seemed not to be required in the real time domain that was Ada's primary target, and, second, the apparent need for automatic garbage collection in an OO language would have interfered with predictable and efficient performance.

You can argue that C++ hasn't automatic garbage collection, hence the second point doesn't seem a good reason at all. I think there were other concerns too, e.g., more requirements about “safety”.

However, large real time systems often have components such as GUIs that do not have real time constraints and that could be most effectively developed using OOP features. In part for this reason, Ada 95 supplies comprehensive support for OOP, through its “tagged type” facility: classes, polymorphism, inheritance, and dynamic binding. Ada 95 does not require automatic garbage collection but rather supplies definitional features allowing the developer to supply type specific storage reclamation operations (“finalization”). Ada 2005 provided additional OOP features including Java-like interfaces and traditional operation invocation notation.

Final remark:

Ada is methologically neutral and does not impose a “distributed overhead” for OOP. If an application does not need OOP, then the OOP features do not have to be used, and there is no run-time penalty.

Java threads and exceptions

Talking about tasks and exceptions in Ada, what about Java?

Just another Schiaparelli

Performance-impacting postconditions

Declaring preconditions, postconditions, and invariants, and actually checking them at runtime are two different things.

Hamming numbers

Tasks and exceptions in Ada

Ada's concurrency facility (tasks) reminds me of Erlang's concurrency facility. I am not fluent in any of these two languages but I like them — Ada is a fresh new entry in the list: seen a bit of it ages ago and I thought to dislike it. Now I'm looking into it again and a litte bit deeper, and I started to like it…

Overloading so much

I suppose that my average readers know what overloading is, but let me give a quick definition: overloading is a feature which allows to reuse (overload) a function name provided that each signature makes each function distinguishable. According to the signature the compiler can pick the right actual code to execute.