You would compare programming languages semantically. You can characterize each programming language by the semantic constructs provided, and the corresponding

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.