[jaredklewis]

I would say that’s just another trade off though, in that extensibility and portability are invariably in tension.

The article simultaneously complains that the SQL standard is not universally implemented (fair) and that SQL is not easily extensible (also fair). But taken together it seems odd to me in that if you make SQL very extensible, then not only will it vary between databases, it will vary between every single application.

Also, the line between SQL and database feels a little fuzzy to me, but don’t a lot of postgresql extensions effectively add new functionality to SQL?

[jampekka]

The point is that with a more expressive language new features could be added as libraries instead of changing the language itself. This is right before the paragraph I quoted:

"In modern programming languages, the language itself consists of a small number of carefully chosen primitives. Programmers combine these to build up the rest of the functionality, which can be shared in the form of libraries. This lowers the burden on the language designers to foresee every possible need and allows new implementations to reuse existing functionality. Eg if you implement a new javascript interpreter, you get the whole javascript ecosystem for free."

[jaredklewis]

Yea I know, I was addressing that in my comment?

You have languages like JavaScript which are very “expressive” in that it comes with very little functionality but there are a wealth of libraries you can use to augment this. And this tradeoff is often lamented on HN since it’s never enough to just know JS; you have to know the particular libraries being used by the project.

Contrast that with batteries included languages like python or go.

And like I said above, Postgres extensions add features to the language, usually without any syntax changes (just new functions or operators). Isn’t this like a “library” in another language?

[xigoi]

Expressiveness and standard library size are unrelated. Python is just as expressive as JavaScript.