Conjecture: There are a set of languages, call these Import Normal Languages, where any program expressible in the language can be written in the form,

EXPRESSION

or

IMPORT PACKAGE
IMPORT PACKAGE

Therefore the length of any program in an Import Normal Language is either 1 or 2.

---

I wrote this “joke” post a long time ago when learning about context-free grammars, but with all of the npm drama this week it seemed apt to publish.

Projects don’t go long, estimates come up short. There is a distinction to be made between the immovable and the movable.

How many piano tuners are there in Chicago? — more/less — so did the number of piano tuners increase/decrease, or was the guess wrong.

At some point we must look up from the map we have constructed and survey the territory before us: the discrepancy between the two is not the fault of the Earth.

I was thinking about why Go doesn’t, and shouldn’t, have generics. Then it dawned on me: there are two styles of polymorphism.

The first would be that associated with languages such as Java, C#, Haskell, etc. These are languages with generics or something similar which allow you to define types such as List<int>, Dictionary<string, Thing> and so on, with methods/functions that act on a genericList<T>. This I think of as structural polymorphism since it is determining what to do based on the structure of a value.

The other style would instead be associated with Go, Ruby, Smalltalk, etc. These are languages with a way of determining whether an object has a particular behaviour, either by querying its methods (Ruby respond_to?, Smalltalk respondsTo) or by defining an implicit interface as in Go. This would be behavioural polymorphism since it determines what to do based on the behaviour of a value.

Each style is suited to solving different problems, but neither could be argued to be more powerful than the other.

I can’t think of a language that supports both styles, but there is a theme. The dynamic languages favour a behavioural approach, since they have no good way to represent the type information required for a structural approach; and the statically typed languages favour a structural approach for the inverse reason, they are tied to the idea of types as structure.

Go then is the outlier. It is statically typed, yet has a behavioural style of polymorphism. Perhaps this is the reason the Go authors haven’t shown any enthusiasm to including something like generics, they have already chosen their preferred polymorphism.

I emailed the title to myself Friday night with the intention of fleshing it out into a think-piece. Googling the term returned nothing, so I’m claiming this as the canonical definition.

It is best to contrast with the idea of the Full Stack Developer, which when Googled gives me the following from Laurence Gellert:

To me, a Full Stack Developer is someone with familiarity in each layer, if not mastery in many and a genuine interest in all software technology.

Layers in this case range from the hosting through to logic through to user experience and finally customer/business need. So familiarity with the technology used throughout the systems you use/write and why these are valuable.

The Horizontal Developer on the other hand is familiar with the range of processes required in the business. Their “stack” consists of being able to:

• Propose a range of solutions to business/customer problems, including pros and cons for each approach.
• Plan out work required in a sustainable way.
• Write the software (though they aren’t necessarily full stack, if so “square developer”? Or is that just too many words…)
• Test software at all levels, from high level acceptance tests to unit tests, to manual tests, finding edge cases, bugs. They are the tester, QA team, etc.
• Communicate with stakeholders.
• Push forward the processes used by the business and advocate better ways of working.

I have two questions:

1. Could a company theoretically replace the whole set of [Product Owner, Product Manager, Team Lead, Technical Lead, Developer, …] roles with just Horizontal Developers.

2. Is this just “being agile”, or is it more?

This is a technique I haven’t seen anywhere else, so here it is…

Say you have a list of items that you want to be able to filter. Items that don’t match should fade out and be pushed below matching items. Here’s a list to start with,

<input type="text" placeholder="Filter..." />
<ul>
  <li>Apple</li>
  <li>Apricot</li>
  <li>Banana</li>
  <li>Bilberry</li>
  <li>Blackberry</li>
  <li>Blackcurrant</li>
  <li>Blueberry</li>
  <li>Boysenberry</li>
  <li>Cantaloupe</li>
  <li>Currant</li>
</ul>

The first step is to make it a flex list:

ul {
  display: flex;
  flex-direction: column;
}

Then add a class which represents the “hidden” elements, these are made transparent and pushed to the bottom with order: 1,

.hidden {
  opacity: .3;
  order: 1;
}

Finally add a little javascript to apply/remove the class

function filter(val) {
  for (var li of document.querySelectorAll("li")) {
    if (li.innerHTML.contains(val)) {
      li.classList.remove("fade");
    } else {
      li.classList.add("fade");
    }
  }
}

document.querySelector("input").onkeyup = function() {
  filter(this.value);
}

And it is done. No sorting the list with javascript or anything complex, just simple class manipulation with flexbox. An example should be below to play with: