Written by: malisapusonja

Product-Abstractness Continuum Fit

What are the languages that lie near the end of Paul Graham’s “abstractness continuum”, as defined in his “Blub paradox” essay? Chances are you have heard about Blob paradox. But, in case you haven’t I’ll briefly describe it for you here. What follows is what I hope a well-explained version of it. In case you need a better one go and read Beating the averages article.

Abstractness continuum

Paul Graham says:

Languages fall along a continuum [4] of abstractness, from the most powerful all the way down to machine languages, which themselves vary in power.

In that note #4, he explains:

All languages are equally powerful in the sense of being Turing equivalent, but that’s not the sense of the word programmers care about. (No one wants to program a Turing machine.) The kind of power programmers care about may not be formally definable, but one way to explain it would be to say that it refers to features you could only get in the less powerful language by writing an interpreter for the more powerful language in it. If language A has an operator for removing spaces from strings and language B doesn’t, that probably doesn’t make A more powerful, because you can probably write a subroutine to do it in B. But if A supports, say, recursion, and B doesn’t, that’s not likely to be something you can fix by writing library functions.

And then he goes on to say

… I’m going to use a hypothetical language called Blub. Blub falls right in the middle of the abstractness continuum. It is not the most powerful language, but it is more powerful than Cobol or machine language.

So, let’s make picture out of this


Blub is imaginary programming language which is in the middle of the abstractness continuum.


How does it look like for Blub programmer to look along this continuum?

Looking Down

Looking down this continuum a programmer can say that these ‘lower’ programming languages  lack this and that. Furthermore if he or she is opinionated, she can say they suck. And she does have a point. They do lack, not just syntactic sugar and salt, but something more – abstraction levels, like for example, closure. We all love closures, don’t we? PHP, Java,…, C++ until recently didn’t have them. We did code in those languages, and thought it was the best work ever. All of a sudden a random functional programmer starts screaming at us; something like: “No closure? Really??? It sucks!”

When Blub programmer looks down the continuum, he is in the same place as this functional programmer. Nobody from down there understands him.

Looking up

We’ll not be using a closure for this example, because you are probably familiar with this concept. Let’s use a concept of unoseth instead. Take a look at this piece of code:

H(j), S(s) —>  I(8)

That’s unoseth. I assume you are not familiar with this concept. The question is when you look at this, what do you make out of it? Paul Graham guesses that you’ll think this is the same stuff you write in your code but with different syntax. (Or as king Solomon said “there is nothing new under the sun”). But, Graham also said, it’s not just that. It’s not just different syntax. It’s in my own words – evolutionary step in abstraction and “you the monkey now”.

Looking up the abstractness continuum is much softer, but still something similar to this scene.

Looking up the abstractness continuum is much softer, but still something similar to this scene.

To generalize from this example: when a programmer tries to think about a language on the upside of continuum it is all mumbo-jumbo to him. A different syntax nothing more and nothing less, but at the same time he sees all the bad stuff when he looks down. However, when he looks down the line he seems like a prophet, but when he looks up he looks like a monkey. That is the Blub paradox.

So, what does all this stuff about Blub paradox have to do with MVP development? Before I answer this keep in mind I will concentrate just on one case – choosing the MVP tech stack. For further reasoning as to why it’s important, read Graham’s original article.

Choosing the MVP technology stack

When you go to WordPress sweatshop with your MVP idea what will be a tech solution? You guessed it – WordPress! When you go to Drupal team, the solution is Drupal. Other teams have their own ‘best in the world’ custom CMS written in, for example, Laravel. Then again, others say Laravel sucks, use Symfony. Few people stated they have their own framework, and its the state of the art cutting edge stuff. Finally, you meet the guys who claim that not just those before suck but that the whole PHP language sucks. Use Python!

It is safe to say those guys code in Python, right? There are abstractions that PHP doesn’t have that exist in Python, like for example, threading. But then, while having a cup of coffee in a local cafe, you bump into this guy who knows Lisp, and he says (I think you know by now) that your app should be written in Lisp because no other language has macros the way Lisp has them, and that they are essential for fast and proper development. Ad infinitum.

What is all this?

Walking up and down the abstractness continuum.

If somebody knew only machine code abstractions, what do you think in what code would he write your app? In the machine code of course. Same goes with C, C++, JavaScript, PHP, Java, Swift, Python, Clojure, and all the way to the, as Paul Graham claims, the most abstract language of them all – Lisp. It just depends on whom are you talking to along this abstractness line.

Now that you know what is abstractness continuum, what to do with it?

If you are a programmer it’s obvious, learn Lisp. I think… But, if you are a person interested in making an MVP-product this means that you need to talk to a lot of different teams and try to figure out where along abstractness continuum does your minimum viable product fit. You need to figure out what I call Product-Abstractness Fit. This sounds like I just made a whole new concept. Let me say it again:

Product-Abstractness Fit

or longer.

Product-Abstractness Continuum Fit

It is not always the case that the language with the most abstractions is the best one for your product. Why? For example, you are writing a new mail system, and for some reason, you need to rewrite IMAP server, because Dovecot sucks and it doesn’t have labels, which is a crucial feature for your MVP project. You won’t be doing that in Java or something similar to it but in C. (Maybe you should talk to Java guys first just to check out if you are missing something crucial) Or, let’s say you’re writing yet another website. Why would you use most abstract language for this? It would be like using the smartphone just for calling and SMS, and nothing else. Use PHP, even better write custom WordPress theme.

You need to decide where is that fit – when a language is to abstract for your app, and when is insufficiently abstract to be the best choice for the MVP app.

This can be difficult, and it’s a process. I sincerely hope that now, as we introduced this concept of P-A Fit, you are equipped with this idea in thinking about MVP development phase.

P.S. One more thing before I finish; unoseth doesn’t exist. That’s just my imaginary concept, just like Blub language is Paul Graham’s. I wanted to be sure that you are not familiar with a concept and cannot google it.

Hope you are not disappointed!?

Guides, articles, and news

RWA Marketplace Validation Use Case – Tokenized RWAs are yet to take off

As the bull market kicks off, we are seeing exciting new trends taking over the market from DePINs, tokenized RWA,


ZKSIM – Revolutionizing ZK Circuit Testing

The development of zero-knowledge (ZK) circuits is an intricate process, with testing posing a considerable challenge that often extends timelines


FHE Project comparison

As the adoption of this transformative technology continues to grow, so does the emergence of innovative projects harnessing its capabilities.

get in touch