Year: 2019

Google: How to do a code review

Google is sharing “How to do a code review” as part of its engineering practices. Unlike many similar guides online, I find this document to be a lot more comprehensive. It covers both the technical bits of the process, as well as suggestions that improve overall team communications and efficiency.

A particular type of complexity is over-engineering, where developers have made the code more generic than it needs to be, or added functionality that isn’t presently needed by the system. Reviewers should be especially vigilant about over-engineering. Encourage developers to solve the problem they know needs to be solved now, not the problem that the developer speculates mightneed to be solved in the future. The future problem should be solved once it arrives and you can see its actual shape and requirements in the physical universe.

Perl 6 re-branding

Curtis “Ovid” Poe, the author of the book “Beginning Perl” and long-time Perl Monk, has this excellent post on the re-branding discussion of Perl 6.

Even though I’m not writing much Perl code these days, I have to admit that the whole Perl 6 thing has been going for years now and I’m one of those many people who were confused by it. In my opinion, Perl 6 is not a continuation of Perl 5 as a version bump (like in Python or PHP), but it is a different language. And as a different language, it should have a different name.

Of the ones mentioned in the blog post, I like the “Raku” the best. But given the negative connotation in some countries, cultures, and languages, “Camelia” seems like a better option.

Regardless of the alternative names, I want the change from “Perl 6” to anything else the sooner, the better.

Ranking The Startup Ecosystems of 1,000 Cities and 100 Countries

CrunchBase links to the StartupBlink’s “Ranking The Startup Ecosystems of 1,000 Cities and 100 Countries“.

The top 3 countries are USA, UK, and Canada. Cyprus takes 68th places out of a 100, climbing 6 places from the 74th place it was at in 2017.

The top 3 cities are San Francisco, New York, and London. Three Cyprus cities made it into the ranking:

  • Nicosia takes place 239, dropping 23 places from 216 in 2017.
  • Paphos takes place 531, climbing 329 places from 860 in 2017.
  • Limassol takes place 613, climbing 234 places from 847 in 2017.

I can find ways to justify Nicosia being so much higher than Paphos and Limassol. But Limassol being below Paphos looks strange to me.

PHP vs P++

If you haven’t heard the news yet and are wondering what the heck P++ is, here’s a quick update for you. There’s been some noise around the idea of creating a separate dialect of PHP, code-named P++. The idea is an attempt to find a compromise between two different schools of thought on the evolution of PHP programming language: maintaining backward-compatibility for as long as possible and cutting historical baggage off to allow for faster development cycle and more of those new shiny features.

Here’s the FAQ with some details and explanations:

Trying to shorten the lengthy email into a couple of points:

* There are two big, substantial schools of thought in the PHP world. The first likes PHP roughly the way it is – dynamic, with strong BC bias and emphasis on simplicity; The other, prefers a stricter language, with reduced baggage and more advanced/complex features.

* There’s no ‘right’ or ‘wrong’ here. Both schools of thought are valid, and have a very substantial following. However, it’s challenging to create a language that caters to both of these crowds at the same time – which is a constant source of contention on internals@.

* The proposal is to create a new dialect of PHP (code named P++) that will live alongside PHP, but won’t be bound by the historical philosophy behind the language. In other words, this new dialect could be inherently more strict, it could be more daring with BC and remove elements that are considered ‘baggage’ (such as short tags), and adding more complex features – especially ones that are a good fit for strictly typed languages – without having to introduce the same complexity to the PHP dialect.

This is not a fork. The code base will be identical, the developers working on that codebase will be the same. The vast majority of the code would be identical. Only the specific points of difference between the two dialects will have different implementations. It is somewhat similar to what was done with strict_types in PHP 7 – only on a larger scale.

And here are a couple of other articles with some thoughts, links, and arguments:

Personally, I understand the challenges that brought up this idea and I applaud every effort that tries to find the solution to these problems.

But…

I don’t like this particular approach. I don’t think it solves the actual problem. Instead it just buys some time until it comes back again. Much like the current arguments of what to drop and what to keep in PHP, we’ll be fighting over what to keep in P++ and what to push into the PHP.

The new versions will keep coming, bringing new features and new backward compatibility issues. If we are to address this, I think a more strategic approach should be used.

I think most people are not compiling custom PHP binaries these days, but rely on some kind of distribution packages, so I will ignore the compilation discussion and focus on distrubtion instead. From this perspective, I would prefer to have additional packages for support of legacy PHP versions. Something along the lines of:

  • php-7.3.0-common.rpm (main PHP 7.3 package)
  • php-7.3.0-legacy-7.2.rpm (legacy features from PHP 7.2)
  • php-7.3.0-legacy-7.1.rpm (legacy features from PHP 7.1)
  • … and so forth.

This allows more control as to what is available on the system. It also falls into the Composer platform paradigm of checking which PHP version and extensions are installed. This will still require quite a bit of work to implement, test, and get people to use. But I think it’s a better approach for the long term, and it is an easier transition for the short term.

This is something to keep an eye on, as I think there will be a lot of insightful discussion all over the web about it.