Comment by lmm | Hacker News Reader

Comment by lmm | Hacker News Reader

Parent Full thread

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

Reply on news.ycombinator.com