Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #2983

Re: Programming language similarity

Show all headers | View raw

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 <derek@nospam-knosof.co.uk>
wrote:

> 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?

Back to comp.compilers | Previous | Next — Previous in thread | Find similar

Thread

Programming language similarity Derek Jones <derek@NOSPAM-knosof.co.uk> - 2022-04-25 00:00 +0100
  Re: Programming language similarity Derek Jones <derek@NOSPAM-knosof.co.uk> - 2022-04-25 08:59 +0100
  Re: Programming language similarity Fernando <pronesto@gmail.com> - 2022-04-25 04:24 -0700
    Re: Programming language similarity Derek Jones <derek@NOSPAM-knosof.co.uk> - 2022-04-25 19:35 +0100
  Re: Programming language similarity Jan Ziak <0xe2.0x9a.0x9b@gmail.com> - 2022-04-25 06:00 -0700
    Re: Programming language similarity Derek Jones <derek@NOSPAM-knosof.co.uk> - 2022-04-25 20:51 +0100
      Re: Programming language similarity gah4 <gah4@u.washington.edu> - 2022-04-25 14:58 -0700
        Re: Programming language similarity Derek Jones <derek@NOSPAM-knosof.co.uk> - 2022-04-26 00:50 +0100
  Re: Programming language similarity Meshach Mitchell <meshach.mitchell@gmail.com> - 2022-04-25 12:06 -0400

csiph-web