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


Perl6 appetizer

Perl5 is a nice useful language, I've always liked it, though sometimes it felt a little bit clumsy. I had some metaphorical headache managing arrays and hashes in few circumstances, for instance, and I've never get really accustomed to the lack of a signature in subroutines. I've barely seen the “new” OO features, and when I tried them, they didn't felt totally right to me. On the other hand, Perl regular expressions are a variant which has spread outside Perl world, likely because they gave something which was missing in basic or extended POSIX regexes.

Perl6 is a totally new language, despite some syntactical and superficial resemblance with Perl5. With respect to the regular expression story, it takes it to a whole new level using a different syntax and introducing grammars which really make easy to write parsers.

Perl6 has many other features, of course: it looks like a very interesting language.

Here I'm going to show something.


For your and the others' safety

I use gmail and I was doing some cleaning to get rid of past things I don't need anymore, until I saw this message:

I am sure that this file (which is a password protected rar archive) is safe and doesn't contain anything dangerous. And by the way I was able to download it in the past. But why is it now blocked? Because now gmail isn't happy with password protected archives. For your safety, of course…

I wanted to check my attachments, too: sometimes I use gmail to send to myself archives of things both in order to transfer them from a computer to another and to keep them in (another) “cloudy” place.

Some of them can't be downloaded neither. Most of them aren't password protected. They are just archives, but it happens they contain other (not password protected) archives. And this is another category now Google isn't happy with. Always for your safety…


Java and its silly war against unsigned integers

Short story: Java hasn't (primitive) unsigned integers because Gosling thinks that too many programmers don't get what goes on with unsigned, what unsigned arithmetic is. Good solution: teach and make them aware, fix the problems of the education system which hasn't taught them, and so on. Bad solution: treat everybody as a stupid unable to learn, remove the feature and disappoint programmers who understand what goes on with unsigned, what unsigned arithmetic is, and those who think they can still learn. End of the story.

Not only zip bombs

Crawling around few corners of the net I've found a file named something like do not uncompress me unless you're a bot dot gz. It is, as per extension, a small gzipped file (26 kBytes), but — and this explains the suggestion — it expands into a 10 GBytes long files.

A sort of modest zip bomb, but for gzip.

You can find more on

Public domain image of an explosive device

Beware, those files can be dangerous if not handled properly! Do whatever you want at your own risk. Be safe.


Exceptions will rule the world… and “all” goes lazy.

Python has an odd tolerance for try - except controlling the flow. They have also an ancronym to justify it: EAFP, which is Easier to ask for forgiveness than permission.


One size doesn't fit it all

Lord Byron

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.


To be fair with Haskell

Fairy Tales

In Java 8, functional style and efficiency I have shown how bad Haskell performs at the silly task I was using as test.

But there's a detail which makes the test unfair: the problem with the given code is that the factorial function I've written isn't tail recursive.