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 Raku 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 Raky has many other features, of course: it looks like a very interesting language.

Here I’m going to show something about it.

The language was renamed to Raku. I have edited this article consequently, except where file names are involved (that is, .p6 stays as .p6 instead of .raku.

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

• Bomb codes

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.

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.

To be fair with Haskell

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.

Eat the apple

Reading Why you should totally switch to Kotlin

I don't believe in titles like Why you should totally switch to Kotlin or Ten Reasons Why I Don't Like Golang (subtitle: why “I wouldn’t use it for a new project”), but being curious about languages, I always like to read this kind of articles, and eventually criticise them — though I neither advocate for nor oppose to any language in particular.

So…

Exceptions to control the flow

Using exceptions to control the flow of your program is an anti-pattern. Don't take too seriously whoever believes in exceptions as an indispensable feature of a language. Better no exception than misused exceptions!

Java 8, functional style and efficiency

Java 8, released in 2014, introduced lambdas and the possibility to write code in a functional style through streams of elements. C++11 standard was published in 2011, and it introduced lambdas too, which altogether with old and new functions in algorithm (e.g. accumulate(), for_each(), count(), transform()) allow for a functional style in C++.

Don't Go, let's Go

My few encounters with Go were pleasant and I stick to the idea that it is a good language.

Java threads and exceptions

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

Sather's iterators

Sather's way for loops is interesting: you have iterators which yield giving the control back to the caller, very much like coroutines do.

Sather reloaded

Once upon a time, there was Sather… I've briefly said it exists in a previous old article, Languages, OOP, Sather et al..

Eiffel

The first language which put emphasis on design by contract was Eiffel. It seems that the term is born with/for it.

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…