Path: csiph.com!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: Meshach Mitchell Newsgroups: comp.compilers Subject: Re: Programming language similarity Date: Mon, 25 Apr 2022 12:06:02 -0400 Organization: Compilers Central Lines: 54 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <22-04-017@comp.compilers> References: <22-04-012@comp.compilers> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="58444"; mail-complaints-to="abuse@iecc.com" Keywords: design Posted-Date: 25 Apr 2022 12:34:48 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com In-Reply-To: <22-04-012@comp.compilers> Xref: csiph.com comp.compilers:2983 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 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?