
Ask HN: How would you compare programming languages? - deepaksurti
In this day and age of polyglot programming, how would you compare the programming languages you know.<p>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?<p>My main motivation in asking this question is: &quot;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?&quot; for ex: coming from Lisp and if you know about generic functions, you may immediately feel the pinch where message passing falls short?<p>Edit:Fix Typos and prefix with Ask HN
Thanks.
======
informatimago
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.

