The Art of Perfection

La perfection est atteinte, non pas lorsqu’il n’y a plus rien à ajouter, mais lorsqu’il n’y a plus rien à retirer.

Antoine de Saint-Exupéry

For those of you impaired by a lack of baguette eating, that quote also works as « perfection is not attained when there is nothing to add, but when there is nothing to take away ».

It’s one of UX’s biggest gotos to justify a lot of its sometimes debatable rules. Android’s « Beyond two clicks is too much » may well have been shielded by this quote more than castle princesses have been by dragons.

Speaking of which, this quote may well be our greatest Dragon.

How does one engineer to the point that there is nothing to take away?

« By taking out every unnecessary processing », says the backend dev.

« By taking out every unnecessary visual » says the UI designer.

« By taking out every unnecessary user operation » says the UX designer.

« By taking out every unnecessary character » says the code golf artist.

« By taking out everything that doesn’t bring extra money » says Finance.

« By perfectly estimating how many features and thus how many lines we’ll need for the program to reach its goals » says the architect.

« By having a programming language that perfectly provides what you need through its syntax, features and objects » says no one ever. Not even me.

And yet, that random brain fuse that made me write that line may not be entirely devoid of some sort of statement to take to heart.

Let’s, for the sake of bumping into the most well-oiled part of all of programming, which is web dev, talk about the Triad of HTML, CSS and JS.

HTML responds, easily and quickly, to the needs of the UX dev.
CSS responds, efficiently and accurately, to the needs of the UI dev.
JS responds to the backend’s needs. Neither efficiently nor accurately, and I’m starting to be convinced that anything with Java in the name is out to ruin all of our lives, but it still carries on its part.
The architect can cut away a chunk for each of his devs. Sure, HTML and CSS aren’t so clear cut, but the principle still stands. We have a « language » of sorts that allows for buttons and text, a « language » of sorts that gives colors and styles, and a «  » » » » » » » » » » » » » » »language » » » » » » » » » » » » » » » » » of sorts that allows actual interaction.

So do we need a little different language for everyone’s satisfaction? Do we need pluggable languages with self-constrained to satisfy everyone’s vision of perfection? Is perfection closer when we each give each other elbow room and admit that our goals, and thus our language, stops here?

Perhaps so. Let’s take a more low-level example: Perl.

Perl is a failure. Historically speaking. It was eaten and gone as a popular programming language long ago. And when I first entered the halls of that failure, I was expecting to see the all-too-common atrocity that had been my first contact with Perl: a language with a natural tendency towards Golfing.
Thank God, it turned out not to be the case. Written with intent to be readable, Perl is a perfectly acceptable, and readable, language.

Despite its failure, I have a certain…appreciation for this old thing. It allowed me to parse server log files that went up to 33GB of machine noise every day, and to do so far faster than anything else could’ve done.

Perl died for a very simple reason: its OOP is not by any stretch acceptable to modern standards. Modern meaning in this case 1990. It would not even be unfair to say that its treatment of subroutines/functions and passing arguments to them is outright shocking. I went under a literal brain death for about 6 hours when I realised that it was not a mistake but a feature to have an entire language that relied on automated argument catching rather than expected named statements. I mean, why would you ever need to declare:

int *add_arrays(int first[], int second[]) { return (first + second); }

When you can simply:

sub add_arrays {
my $arr_one_len, $arr_two_len = $_[0], $_[1];
my @array;
for my $entry (@_[2, 2 + arr_one_len])
 push $entry, @array;
for my $entry (@_[2 + arr_one_len + 1, 2 + arr_one_len + 1 + arr_two_len])
 push $entry, @array;
return @array;

And yes, those lines are quite certainly wrong, but the point is there. Perl died because it did things like that.
Past the shock and trauma of its killer « feature », and the admiration over its brilliant regexes and text treatment (as well as interesting syntax)…I realised that Perl’s only, and yet strikingly brilliant and time-tested quality, is its focus on its strengths.

Let us take a use case: I want a large, options-full, complex program with many use cases. No Perl.
I want a files/networking oriented devops tool with lots of features. No Perl.

I want a fast, text-oriented or Linux-only devops tool that has high speed requirements. I will literally refuse anything else than Perl.

The thing about Perl is that it is not worth learning. Its regexes are so great everyone stole them, and now any language can use them. Its talent at replacing Bash is undeniable, but if we’re going to have to install an extra language in a linux system, it’s going to by Python for Devops, Python for network, Python for anything that doesn’t require speed. Perl is outclassed or equaled in everything.

Yet I would refuse anything else than Perl for regular file operations or text treatment. Not because it is the easiest tool. In that too, I would choose Python any day. Not because it is fast. Of course it is fast, but if we’re talking of a fast text treatment language, then you’ll choose Perl not out of choice but obligation.

I would choose Perl because it was born for this.

Because every bit of its syntax is meant to replace Bash in better. It is cleaner, leaner, more flexible, more powerful, much faster, more readable, less stupid syntax error prone. Because Perl was born to replace grep, sed, awk, rm, mv, env, and every single text oriented Bash/Linux tool you can think of. Because even today, as much as I admire Python or Ruby’s brilliant syntaxes or C++’s absurdly headstrong commitment to covering every use case ever and do so with high performance, I understand that when I need to do more regexing, when I will need to handle my linux ops, when I will have to fly the colors of the linux web server backend dev, with its measly, tattered grey, its leaning mast and its obsession with sanding itself with logs and logs and conf files over conf files, when I will need someone to save me from parsing hundreds of lines straight out of /proc, Perl is going to be the uncomfortable yet perfectly tailored shovel that’ll help me unbeach it. Unless I don’t need performance then I’ll laze with Python again.

Perl is not a good language. But it is what it was born to be, Bash’s slayer.

TPPL must be good, of course. Nobody would use it otherwise. Yet I have this eerie feeling whenever I look at Perl, its bloat, its sillinesses, its bad decisions, and yet its perfect glove-born-for-my-hand feel, that by seeking « good », as in seeking the 3 Goals, syntax, performance and power, we can only end in failure.

Unlike my overengineering habits of always looking at an architecture from the top down, starting with the core construct(syntax) and creeping towards the features one by one, Perl, as well as the CHJSSSTML Trio, feel as if the opposite should be the driving force.
« What do I want my Perfect Programming Language to do » rather than « How do I make a language that satisfies everyone »?

Or better yet, « What should my Perfection Chunks each do to satisfy »?

Votre commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:


Vous commentez à l’aide de votre compte Déconnexion /  Changer )

Photo Google

Vous commentez à l’aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s

Créer un nouveau site sur
%d blogueurs aiment cette page :