5 ms·
> 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 clea
by Sandman 12y ago
> 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.
- lmm 12y ago> 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.
- yummyfajitas 12y agoI 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.
- brianwawok 12y agoThe 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.
- lmm 12y agoIn 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.
- kasey_junk 12y ago"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.
- lmm 12y agoGithub highlights code; so do many popular blog engines.