Re: Programming language similarity

Meshach Mitchell <>
Mon, 25 Apr 2022 12:06:02 -0400

          From comp.compilers

Related articles
Programming language similarity (Derek Jones) (2022-04-25)
Re: Programming language similarity (Derek Jones) (2022-04-25)
Re: Programming language similarity (Fernando) (2022-04-25)
Re: Programming language similarity (Jan Ziak) (2022-04-25)
Re: Programming language similarity (Meshach Mitchell) (2022-04-25)
Re: Programming language similarity (Derek Jones) (2022-04-25)
Re: Programming language similarity (Derek Jones) (2022-04-25)
Re: Programming language similarity (gah4) (2022-04-25)
Re: Programming language similarity (Derek Jones) (2022-04-26)
| List of all articles for this month |

From: Meshach Mitchell <>
Newsgroups: comp.compilers
Date: Mon, 25 Apr 2022 12:06:02 -0400
Organization: Compilers Central
References: 22-04-012
Injection-Info:; posting-host=""; logging-data="58444"; mail-complaints-to=""
Keywords: design
Posted-Date: 25 Apr 2022 12:34:48 EDT
In-Reply-To: 22-04-012

I could see how that could be interesting as an academic pursuit, but I
think the dearth of exploration here is most likely because pretty much
anyone in a position to do that already knows that every turing complete
language is equivalent. The comparison, therefore, would be a comparison of
placement of syntactic sugar. I have trouble visualizing a real-world use
for such a comparison, by which I mean, what is the problem that I would be
able to solve by knowing which languages are similar? In the current
environment, anywhere you would work already has a whole tech stack already
mapped out.

I have actually thought about this, and vaguely remember looking up
articles on the subject. The article you linked is interesting, but I agree
with your analysis; semantic similarity has some value but IMO what really
matters is "supported patterns". ie. what a language provides "for free".
Now., TINSTAAFL, so there is no real "free" but there is some optimization
done by a language [compiler, interpreter] to support statements
represented in the grammar. An example that comes to mind is in javascript
(I know, I *know*, but I have a family, and we need to eat.) Early
implementations of async in js used the *Promise* object to implement
asynchronous execution, but newer versions of the language use *async* and
*await* keywords. The former piggy-backs on the existing OO architecture,
while the latter, implemented as keywords, is available to lower level
abstraction and optimization.

We've been doing this long enough that a number of "higher level" patterns
have emerged. The aforementioned asynchronous (threaded, maybe?) execution
is one. *Events* also come to mind, which are generally implemented as good
old-fashioned polling under the hood or function registration and
hash-lookup. What is actually happening in the machine translates to vastly
different computation cost, and seems to me to be non-trivial. I think a
meaningful categorization could be done based on this idea of language
"provisions" over language semantics, and some deeper analysis of how
exactly a language [compiler, interpreter] implements what necessarily
boils down to syntactic sugar.

To answer your actual question, No, I don't know of other attempts, but I
can understand the scarcity. Hope my thoughts have some value.

-- Meshach Mitchell

On Sun, Apr 24, 2022 at 10:49 PM Derek Jones <>

> All,
> There has been remarkably little work that tries to measure
> programming language similarity.
> Yes, there are many multi-language runtime benchmark comparisons, and
> people extract data from Wikipedia to made dubious claims.
> Does anybody know of other kinds of attempts at measuring language
> similarity?

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.