3 ms·
> We also use programming languages to communicate to other programmers (which includes our future selves). Communication using natural language is fundamental
by catnaroek 13y ago
> We also use programming languages to communicate to other programmers (which includes our future selves).
Communication using natural language is fundamentally different from communication using programming languages. The ability to be vague, redundant and even wrong - all of these are features in natural languages, but bugs in programming languages.
> Perl has many, many nuances. This is often derided by people that prefer more rigid languages. I like to think that it helps me see the programmer intent and thought process more clearly through the code.
Nuances obscure intent, because they require you to be actively aware of the possibility of their existence in order to understand code.
> Obviously there are downsides to this, just as there are downsides to overly rigid languages.
I see no downsides whatsoever to reducing the extent to which one can be wrong.
- Mithaldu 13y ago> I see no downsides whatsoever to reducing the extent to which one can be wrong. Then you need more creativity. :) Nuances make it possible to express extremely complicated (yet often used) concepts in a very concise manner that is still extremely clear. See for example Python Decorators [1]. Very rigid languages take less effort in learning, but at the same time can require the developer to spend a lot more time and effort expressing certain things. See Java. [1] http://simeonfranklin.com/blog/2012/jul/1/python-decorators-in-12-steps/ http://simeonfranklin.com/blog/2012/jul/1/python-decorators-... (Only 12, imagine that!)
- catnaroek 13y ago> Very rigid languages take less effort in learning, but at the same time can require the developer to spend a lot more time and effort expressing certain things. See Java. I do not think of Java as a language with few nuances. Null references, broken covariance for arrays, two non-orthogonal notions of modularity (class-based: public, protected and private; package-based: default visibility), value semantics for primitives vs. reference semantics for everything else... it is all very nuanced! Plus, for all the supposed rigidity, you can break type safety via reflection. On the other hand, Haskell and Standard ML (especially the latter!) strike me as very simple languages, with a far more rigid notion of safety than Java programmers could ever dream of, but which nevertheless afford lots of expressivity. Far more than either Python or Java.
- Mithaldu 13y agoGood answer. :) I'd like to point out that nuance density is dependant not only on the language as a whole, but also on the area of a language you're looking at. Compared with Perl's Moo/se Java's object system is ridiculously small and simple, which is corroborated by things that are extremely simple in Perl OO taking pages upon pages of code in Java. As for Haskell, do consider that while the base of it is quite simple, just like Lisp; it also has the massive ball-of-wax that is monads, which people have been trying for years to explain simply. [1] [1] (Though this is mostly because most people trying either don't have the required humbleness to admit they're a hotfix to a core failing of Haskell, or don't dare explain it in those terms.)
- catnaroek 13y ago> As for Haskell, do consider that while the base of it is quite simple, just like Lisp Lisp is only syntactically simple. (Admittedly, it is syntactically the simplest.) Semantically, it is still a mess. > it also has the massive ball-of-wax that is monads, which people have been trying for years to explain simply. [1] That is a weird thing to say. Monads are simple: an endofunctor "T : C -> C" with two natural transformations "pure : 1_C -> T" and "join : T^2 -> T", satisfying three coherence laws that basically say "the Kleisli construction yields a category". Of course, explaining monads in terms of "bind" instead of "join" is bound (pun not intended) to result in a huge amount of fail. > [1] (Though this is mostly because most people trying either don't have the required humbleness to admit they're a hotfix to a core failing of Haskell, or don't dare explain it in those terms.) It is not a hotfix. It is a feature. Haskell's segregation of effects makes it possible to reason about effects in a compositional manner, using equational reasoning.