Hacker News Reader

> Does the syntactic diabetes really bother people? Like, yes, these are different sequences of characters that mean the same thing, but visually it's very clear that they are the same thing; it's not the perl "there is more than one way to do it" where the ways of doing it are conceptually very different.

Oh yes, this is one of the things that bother me the most about Scala, actually. I don't mind if there are conceptually different ways of achieving the same goal, as you put it, because those different ways usually have different trade-offs; if you're doing things one way instead of the other, you know why you're doing it, there's a certain benefit in doing it this way.

But syntactic diabetes is bad because it ultimately provides no real benefit. Different people will write different code based simply on their tastes and preferences and pretty soon you'll have a mess in your project codebase, unless you enforce strict rules and conventions about writing code. Furthermore, people who work in a team that enforces one set of conventions may have trouble when joining another team that uses a different set of conventions. In Java, for example, this is not the case. Yes, there are things that the language itself doesn't enforce, and conventions are used, but these conventions are well known, and there's probably no Java developer on Earth who wouldn't adhere to them. When a totally new Java developer joins the team, she can usually read code right away, because there are no surprises with regards to the syntax. Sure, she'll need to spend some time perhaps to really get what's going on, because the code might be complex, but the syntax itself won't stand in her way.

> But syntactic diabetes is bad because it ultimately provides no real benefit. Different people will write different code based simply on their tastes and preferences and pretty soon you'll have a mess in your project codebase, unless you enforce strict rules and conventions about writing code. Furthermore, people who work in a team that enforces one set of conventions may have trouble when joining another team that uses a different set of conventions. In Java, for example, this is not the case. Yes, there are things that the language itself doesn't enforce, and conventions are used, but these conventions are well known, and there's probably no Java developer on Earth who wouldn't adhere to them. When a totally new Java developer joins the team, she can usually read code right away, because there are no surprises with regards to the syntax. Sure, she'll need to spend some time perhaps to really get what's going on, because the code might be complex, but the syntax itself won't stand in her way.

But the brackets, braces and dots are just such a trivial part of the syntax. Is anyone really getting confused about the difference between

    opt.foreach{s => println(s)}
    opt.foreach(s => println(s))
    opt.foreach(println)
    opt foreach println

? I really can't imagine a developer who's learnt one having trouble reading the other.

I find the latter one confusing.

    opt foo bar baz buz bif baf

Quick - is buz the method or argument? You have to count to figure it out. Not so hard with java style opt.foo(bar).baz(buz).bif(baf).

In my view dropping the . should only be done for non-alphanumeric operators, e.g. foo |+| bar |> baz.

The ONLY time it makes sense for me to drop . is for some DSL stuff and some math operator stuff...

But really - this is why you have a style guide. Make your style guide say "Always use . unless a math operator". Then the guy that does

foo map x + y filter < 2 foreach println

gets bonked in the head and told to rewrite it.

You would do the same in Java to the guy who wrote a 600 line method, right? Should the JVM enforce the no 600 line method rule, or can we deal with it in style guides? Because the 1 time I need to write a 900 line method, I am sure glad the JVM doesn't limit me.

In my IDE I'd have no trouble - they show up in different colours.

I kind of agree with you, but I think the flexibility over delimiters actually makes it easier to keep code like this clear - you can write something like

    opt.foo{ bar.baz(buz bif baf) }

And it's very obvious which brackets go together and what's at which level of nesting.

"In my IDE I'd have no trouble"

But if you were reading the code on github, on a blog post, or in a chat you wouldn't have that advantage.

Github highlights code; so do many popular blog engines.

It won't be able to figure out the non-delimited version in the parents example. That's the point. By allowing that you've made it harder to read unless the reader has exactly the capabilities of a heavy weight IDE. This may or not be an ok trade-off, but you have to accept that there are cases where people may be reading your code without that benefit.

> It won't be able to figure out the non-delimited version in the parents example. That's the point. By allowing that you've made it harder to read unless the reader has exactly the capabilities of a heavy weight IDE.

Yes it will. This is not Haskell where different functions have arbitrary precedence; Scala functions are evaluated left to right (except a very short list of mathematical operators) unless they end in ':'. The only possible meaning of "a b c d e f g" is the one where b, d and f are methods and c, e and g are arguments. You don't need a heavyweight IDE to work that one out.

1) you are wrong:

https://gist.github.com/kaseyjunk/d58f00a4b1865feb94cc

No highlighting that helps.

2) You've moved the goalposts. The original parent said that he found the call syntax confusing, you responded by saying your heavyweight IDE prevents that confusion from happening, and I pointed out the tradeoff required for that. Now you've gone back and just said it isn't confusing and that it is something you have "to work out".

The fact is, some Scala developers find the call syntax confusing and some Scala developers read Scala code in editors that do not have the power to help them suss that out. That is a cost to the flexibility in call syntax. Is that cost worth it? For some people yes, for some no, but don't deny the cost.

1) Fair enough; I'm very surprised, and will take a look at fixing that. 2) I didn't mean for the user to work it out, I meant that a simplistic highlighting script should be capable of it.

> This is not Haskell where different functions have arbitrary precedence

If this were true, how would ghc know how to compile Haskell programs?

ghc can look up the precedence for every function on the line. (So can you, but it's a lot more effort than just reading left-to-right).

> You have to count to figure it out.

It's actually worse than that because one method application that takes an argument can return either an object that can have a method called on it, or a function which can be immediately applied, or some object that doesn't have the appropriate method but can be implicitly converted to one that does - so without knowing the implementation, there is no unique translation of that string into method calls and objects. Your IDE will probably italicise random words in your DSL code for no obvious reason.

A separate issue is that without knowing the implementation you can write code and not know when or how many times it will be evaluated, because if you pass it into an argument that argument may be call by name.

What it all adds up to is that you can look at a piece of code and have very little clue about what it is actually doing underneath. And what is much much worse - it's usually a leaky abstraction so you actually need to know what it's doing underneath and this happens all the time in common libraries in the name of providing a nice DSL.

I don't think anyone's getting confused but I do think that having four different ways to write essentially the same thing can lead to inconsistent code. And when you have a large project with lots of people working on the same code and with people coming and going all the time, consistency matters.

Scala has some great ideas, but it's so easy to abuse it. I know, I know, you can shoot yourself in the foot with any language. But there are languages that have several safety mechanisms you need to circumvent in order to be able to shoot yourself in the foot, and then there are those that give you a gun and a book called "How to shoot yourself in the foot".

So which ones would you remove, and why?

Additionally, you could just define which style you want let the IDE enforce it (or on check in).

Syntactic diabetes is to me the best warning sign. It means the focus on orthogonality has been lost somewhere in the evolution of the language.

There should be only one way to express a given language operation, and this way should be the simplest and most elegant. Not just because of aesthetic (which is crucial when speaking about readability), but also because it would combine the most harmoniously with other parts of the language.

It seems to me that at this point scala should deprecate all non-essential syntactic sugar and features and reduce the language to its "core". Or, at the very least, people should start a fork with that goal. Hell, it could even be just a compilation option.

I don't see how it's a loss of orthogonality; just like a whitespace-insensitive language, it's saying that the choices of bracket and dot are syntactically equivalent. And that syntactic freedom means the precedence of a Scala line is often much clearer than the equivalent in other languages:

    a b {c d (e f g.h(i))}

In Haskell you'd have to write that as something like:

    a b (c d (e f (g h i)))
    //or alternatively
    a b $ c d $ e f $ g h $ i

I don't understand what you're trying to argue here. At least in this example, I cannot see how the Haskell version is not much more clear.

I find it much easier to visually tell what the tree structure (AST) is in the Scala version, because of the different possible delimiters -the fact that a '(' must match a ')' and not a '}' makes it much easier to visually parse.

> There should be only one way to express a given language operation

This is not possible in general, because concepts rarely coincide cleanly with syntax. For example, you can't have both currying and closures if you insist on this.

Most of the "syntactic diabetes" examples in the talk are of this kind: They are actually separate, general concepts that happen to overlap. And some don't even overlap, but the author does not seem to fully understand the language.

For example, that you can write both f(x) and f{x} is simply because f{x} is essentially the same as f({x}) and the parser allows you to drop the parentheses if they directly surround braces. But `{x}` and `x` are not the same: the first is a scoped block, the latter is a variable. You cannot use a variable to express a scoped block and you cannot use a scoped block to express a variable.

There IS unnecessary conceptual overlap in Scala, but you can find that elsewhere: For example, there's quite a bit of conceptual overlap between view bounds and type classes. But it's difficult to blame the language for it: much of this conceptual overlap exists to make the Java interoperability story less painful (of course, you could argue that Scala shouldn't try so hard to be interoperable with Java at the cost of language simplicity, but there are tradeoffs either way).

The author seems to think that java 8 lambdas are faster than scala lambdas. This isn't strictly true. Java 8 spins the inner classes for lambdas at first use, this gives them a performance boost at startup (loading tons of tiny classes from a jar is painfull for the jvm) but at runtime they perform the same (it's just invokevirtual). Another optimization that java 8 has is that lambdas that don't capture are cached & reused, scala does the same if you use the -optimize flag.