Hacker News Reader

The nuances of a given spoken language take years to master even with regular use. They are used for brevity, cultural identification, conveying meanings that are often different from the dictionary definitions, many other things that programmers don't need to do. Much lawyer and engineering jargon is motivated behind removing these nuances.

You don't need nuances for a language to be expressive. Haskell is a formally rigid language that can express many things in a billion ways. Python is a simple language that accomplishes the same effect. Clojure has almost no syntax but is more expressive than almost any language I've seen. I don't want nuance in my programming languages. Nuance is how you get write-once source files and migrane-inducing bugs.

I don't want nuance in my programming languages.

Does your programming language distinguish between period, semicolon, and colon? Are = and == separate operators? Is whitespace sometimes insignificant and other times significant?

Distinctness isn't a synonym for nuance. All programming languages that I'm aware of also distinguish between "toast" and "taste", or "4567" and "4587."

Maybe so, but some programming languages have case insensitive keywords or identifiers, or take into account only the first several letters of a keyword or identifier. Distinctness is nuanced too.

Distinguishing lexical tokens is a red herring. Nuance has more to do with giving multiple meanings to tokens, depending on context, like maybe if the colon also worked as a statement terminator, but with slightly different semantics.

So, you're saying:

> Is whitespace sometimes insignificant and other times significant?

(Yes, there are languages where whitespace is ALWAYS insiginificant. Well, that is unless you tell the parser to treat it as significant. Or a construct in the parser temporarily enables significance of whitespace.)

> 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.

> 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-... (Only 12, imagine that!)

> 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.

Good 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.)

> 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.

That's a simple description, not a simple explanation, and yes there's a difference. An explanation has the additional burden of being easy to understand, which your "simple" explanation is not unless you already have a background in category theory or other relevant experience. What's an endofunctor? What's a "natural" transformation? Is it something more specific than "just a transformation"? What in tarnation is a Kliesli construction? I'm sure you can give good answers to all these questions, but at that point your explanation is neither simple nor easy.

I'm not saying they're bad, I'm saying they're hard, and your pitch needs to be that they're worth the effort, not "come on, they're not that hard". Until I saw your reply to your other reply, I truly thought this was a joke. In fact, the "monoid in the category of endofunctors" "explanation" is a classic joke about haskellites.

edit: typo

Do not conflate objective mathematical simplicity, https://news.ycombinator.com/item?id=6972986, with subjective easiness, which depends on your prior experience.

I'm not. That's the distinction I spent my whole post making.

> Monads are simple: ...

Ahahaha, please tell me that was meant to be comedy and that you're actually aware of the simple explanation. :D

My understanding of the notion of "simple" is based on the following principles:

1. Short definitions are preferable to long ones.

2. Reusable generic definitions are preferable to overspecific ones.

3. Case analysis should be kept to the bare minimum necessary.

The notion of "monad" fits these principles perfectly:

1. "A monad is a monoid in the category of endofunctors." Short and to the point.

2. You cannot possibly get anything more reusable and generic than category theory. (Contrast with "instanceof" and reflection breaking type safety, and essentially depending on luck and the stars being aligned in order to work.)

3. There is no case analysis whatsoever in the definition. (Contrast with: "if a pointer is invalid, dereferencing it is undefined behavior, otherwise...", "if a downcast is invalid, performing it will result in a ClassCastException being thrown, otherwise...")

Note that my understanding of "simple" actually encourages abstraction (for the benefit of genericity), rather than dissuade it. Abstraction might make things less "easy" (this is subjective, though), but in no way does it make things less "simple" (this is objective).

I literally cannot tell whether you're still being funny or serious. Poe's law is in full effect. (It's still pretty funny to me either way.)

That said, try:

Haskell tries to be a language where all code only does this: Take input, produce output from it; whenever input is the same, output needs to be the same, nothing else may happen, no exceptions whatsoever. Since this forbids things like printing to the screen, reading from a network connections and other useful things, there needed to be a single construct that is excempt from these rules, so Haskell can be useful. Monads are these constructs.

Monads are the house rules you bring to your Monopoly game to make it fun.

(Yes, that means Haskell is not a fully functional language, it's just more functional than most.)

> I literally cannot tell whether you're still being funny or serious. Poe's law is in full effect. (It's still pretty funny to me either way.)

I am dead serious.

> Haskell tries to be a language where all code only does this: Take input, produce output from it; whenever input is the same, output needs to be the same, nothing else may happen, no exceptions whatsoever. Since this forbids things like printing to the screen, reading from a network connections and other useful things, there needed to be a single construct that is excempt from these rules, so Haskell can be useful. Monads are these constructs.

Stop conflating monads with IO. Monads just happen to be usable for modeling IO, but they can model other things as well.

> Monads are the house rules you bring to your Monopoly game to make it fun.

Ironically, when I program in Haskell, I try to keep as much stuff outside of IO as possible. The reason is precisely that IO is usually not fun.

> (Yes, that means Haskell is not a fully functional language, it's just more functional than most.)

No, it just means that IO is a DSL for constructing imperative programs functionally.

===

Anyway, I have no desire for being trolled, so this discussion ends here.

>> things like printing

> Stop conflating monads with IO.

> I have no desire for being trolled

Wow, that was a clever troll, didn't catch on until the end. Would've been better if you hadn't ended it on an obvious declaration of intent though. :)

--

Edit: In retrospect and for later readers i guess i should point out that i forgot one house rule Haskell brings along: Any function can only ever take one single argument. Some monads make it possible to bunch multiple values into one. So the monopoly analogy above is still perfectly accurate.

Taking multiple arguments has nothing to do with Monads. You can either take in a tuple of arguments

    f (x,y,z) = x*y + z

or take them in curried form

    f x y z = x*y + z

where f 3 is a single argument function that returns another function. This ends up being the same as functions having multiple arguments, in practice.

As someone who has a passing knowledge of perl, what do you mean by nuances? It always seemed that perl the language is pretty minimal.

No. Perl has a lot of syntax. There is a lot of language containing a lot of nuance. Python is an example of a language with moderate syntax, probably several times smaller than Perl 5's, assuming Perl is about the same size as Ruby, which is a good assumption, given that they both depend on complex interactions between lexer, parser, and runtime to fully parse. Smalltalk is several times smaller than Python, and actual Lisp implementations have syntaxes that are 1/3rd to 1/2 the size of Smalltalk's.

The above is all objective. You can reduce a language to a formal grammar and count the number of terminals and nonterminals in that grammar.

Not all linguistic nuance is syntactic. For example, the semantics of object models can contain a lot of nuances, as can the lifetimes of variables, visibility of identifiers, etc. While there are ways of encoding semantics (denotational, axiomatic, etc.), the size of the encoding will depend a lot on how closely the language's semantics resemble the semantics of the encoding you choose.

Okay, then. Single letters in regular expression statements.

An interesting nuance, which many early Perl teaching books up until Modern Perl [1] failed to address properly is "context". Perl allows both single and multi-value function return. In return the function can ask whether the calling statement expects a single or multiple values. Additionally, this request for expectation propagates through the call stack from the first statement where this can be correctly determined, to the place where the question was asked.

This makes it possible to do things like this:

   my $first = max( 1, 2, 3, 4, 5 );

   my ( $first, $second, $third ) = max( 1, 2, 3, 4, 5 );

[1] http://onyxneon.com/books/modern_perl/