▲ 1 points

Ask HN: How would you compare programming languages?

by deepaksurti·9y ago·1 comments·view on hn ↗

In this day and age of polyglot programming, how would you compare the programming languages you know.

Let the comparison be not restricted to just the properties of the language, but the tooling, the learning curve, the resources to learn and anything you know from experience is useful?

My main motivation in asking this question is: "does a deep knowledge of the differences between the languages you know helps in becoming a better programmer and writing idiomatic code or code with better idioms in that language?" for ex: coming from Lisp and if you know about generic functions, you may immediately feel the pinch where message passing falls short?

Edit:Fix Typos and prefix with Ask HN Thanks.

1 comments

You would compare programming languages semantically. You can characterize each programming language by the semantic constructs provided, and the corresponding syntax (or syntaxes) to invoke the semantics. You can list those semantic constructs in nice tables, and compare the languages by seeing what semantic construct exist in one language and not in the other, or how complex the syntax to invoke the semantic is in one language vs. the other.

Obviously, the syntax complexicity is a bother, but it's nothing compared to the naked absence of a feature.

For example, comparing lisp and bash, in lisp all values are first class objects; in bash, arrays are not first class objects (eg. you cannot pass an array in parameter to a function, you cannot assign an array to another variable [ what you can do is to copy it with a=("${b[@]}") ], etc. On the other hand, variables in bash exhibit dynamic binding: function f(){ echo $foo ;} function g(){ local foo=42; f; } g # echoes 42

so bash has dynamic variables like lisp, but it doesn't have lexical variables and therefore no closure.

etc.

Now how can comparative study of programming language help?

The main problem is that formal semantics is a cheat: they're defined by mapping one formal system to another formal system. But what is the mining of the other formal system? How can you extract sense (semantics) from such a mapping between 2 or N formal systems? It's an ouroboros.

Only, hopefully, the other formal system is simplier, and better understood than the one for which you're trying to define the formal semantics by this mapping. And we have a neural network in our brains, so we can find some meaning after all.

Therefore, knowing a programming language, ie. knowing its semantics, and comparing a new language with it (instead of just perusing the self-centered formal semantics of this new language), you may more easily and better understand the new programming language, if only because you clearly identify what you already know, and what is really new (often not much, if you know lisp).

Finally, generic functions are not message passing, they're function call and multi-method dispatching. A closer model of message passing would be Smalltalk (but since Smalltalk has been implemented originally and trivially on lisp, its message passing is actually implemented as a function call, so people in OO are totally confused and think that OO is about object, when the original intent was to make it about passing messages. You'd get a better image if you only had asynchronous message passing, without result.

In conclusion, if it's taught in university, I would assume that comparative study of programming language should indeed help becoming a better programmer, and at least give you tools to better understand the semantics of the language you have to use, including it's limitations, and how you could extend (more or less easily) to help you perform your task.