I agree, feels like people don’t understand the word optional. Braces are optional, not forbidden. If you are a developer insisting on not using braces when it obviously would make code more readable … makes no sense to me.
Yes. Maybe it helps to not think of braceless and braces as two syntaxes but as braces being inferred, like types. Sometimes, you add an explicit type for clarity and sometimes you don’t. And when to do it or not do it varies from person to person.
2 Likes
Exactly how I think about it. Most of my coding style works really well without braces, but whenever I need a few more lines, an inner function, nested scope or similar, I add braces. It’s as simple as that 
1 Like
Sure, but what I wanted to get across is that I hope -no-indent sticks around for the long haul even if some people are really sold on SIP-44.
Clearly this feature is controversial, so being able to turn it off is nice for teams (like mine) that don’t see the value.
2 Likes
That’s exactly how I think about it too. If there are any cases where this isn’t true–where I can’t add braces and the syntax will still work–then I think I object to it. (One colon → two braces is a fair change.)
I hope so too, for those people. I also hope that the ability to turn off infix warnings sticks around for people who like infix when consuming Java code (or other libraries), that warning on value discard can be turned on, and so on. People are different, and when you gather teams that work well together and have the same outlook as each other, it’s nice to be able to have barriers where you want them and flexibility where you want it. Not so much that the code is as incomprehensible as another language, though. I guess that’s where significant whitespace gets iffy–it feels more difficult than other things.
I don’t see why these are different conceptually, honestly. The lexical tokens for identical whitespace are different–you can’t see them, and you can see ←, but you have a little lexical work in either case, and then an identical AST after a little reshaping. They’re very much the same flavor. Lambdas depending on the details may or may not count; I agree there.
I don’t like for comprehensions. I would use a flag to disable them if I could–but I wouldn’t take them away from anyone else. I wouldn’t argue that they shouldn’t be added if they weren’t already there. (Not very hard anyway–just hard enough to verify that, yes, it really is a big help to people who like them.)
That’s fair. Nobody seems to like semicolons. Well, the Rust people do, actually. I do also, to an extent. I see the value in having comma inference too, so you can write [sin(x) cos(x) 1.0], and in not having semicolon inference like in Rust so that sequencing is unambiguous.
But anyway, I agree that it doesn’t evoke the strength of feeling that this one does.
(Indeed, I personally still feel pretty irritated that : is the block opening character! So, yeah, I get that it is more different than most.)
I don’t think I can make a very compelling case that it was clearly the right decision for the community, only that it has big advantages in allowing code styles that were awkward before (much like brief lambdas do). Something can have a big advantage and still not be worth it on a community level because there are aspects that people dislike too much.
4 Likes
Yeah, this is the reason I’ve gone mostly-quiet on this debate. I dislike a lot about the new syntax – use in small cases is a good thing, but when you wind up needing colons and end markers I think the whole thing has jumped the shark.
And my big concern (which doesn’t come up nearly enough) is retraining – I’m spending enough effort getting people up to speed on 2.13, having to retrain them for Scala 3 is going to make my Board of Directors look askance at the decision to stick with Scala in the first place.
But provided we can migrate to Scala 3 while sticking with the old syntax, and establish that we’re sticking with a mostly-braceful style going forward, there isn’t a really big problem here.
I do have one serious problem, which really does matter in the real world: the fact that the team has gone completely whole-hog on only showing examples in braceless style, period. That’s a very serious training problem for real-world companies with legacy codebases, and is likely to keep perpetuating this argument forever. It would be Much Better if we could do what many technical ecosystems do, and have documentation with tabs, allowing you to see the same code examples in braceful and braceless style: that would make it easier for everyone to understand, and drive home the point that this is just surface syntax. But I can probably survive without that…
13 Likes
could be worth exploring with automation - I mean most of the doc site now has “scala 2 (i.e. braces) vs scala 3” in tabs - possibly a rework could offer this brace vs braceless
3 Likes
Many senior programmers prefer the syntax. Languages which select for high skill programmers like Haskell, OCaml, F# use this syntax. I maintain large codebases without braces and find the syntax lovely. I want even more whitespace in the language.
So, you should consider alternative hypotheses that explain why you and others like you struggle with the syntax. Perhaps:
- You have strong familiarity bias from previous mainstream languages and feel grumpy from being forced to use a notation you find strange.
- You have other coding habits that don’t work well with whitespace based notation, such as writing long functions, files that span hundreds or thousands of lines. My typical functions are between 1-10 lines long, I write lots and lots of subfunctions, and I dedicate each class to their own file usually, so most files are between 10-100 lines long. Maybe you hate that, but that would just be a fact about your own preferences and psychology, I hate the opposite. Google “Lumpers vs Splitters” in software.
Perhaps it’s the familiarity. But I’ve already pointed out more practical, specific reasons: Should we gather usage statistics about SIP-44 (fewer braces)? - #19 by kubukoz
5 Likes
I see you mention concerns about ambiguity, but I did not see any examples. Do you have any you can share?
I can say that I cant recall any times where I have accidentally written a program with unintended meaning due to whitespace ambiguity, so I think this concern is hypothetical, or you must have a coding style that is very different than mine and predisposes you to issues I don’t encounter.
1 Like
Every time you move any line of code around, you have to fix its indentation. Particularly when copy&pasting something.
This used to be a matter of “press format code hotkey”, but that no longer works as the tooling cannot guess what indentation level you wanted.
Specifically in IntelliJ, you also have to disable a lot of features like auto indent on paste, that are helpful before, but now just jumble up the whitespace, making manual fixing even harder.
Essentially, every indent became a bit of boilerplate that must be manually managed. This is probably fine if you manually indent your code anyways, but indentation was something I never needed to think about before.
Don’t get me wrong. It’s not that important, it’s a papercut. But editing code for me got strictly worse due to significant indent. The only upside – not having to type braces – is kinda negated because IntelliJ and I had a pretty good flow of braces being inserted and removed automatically.
There are also a couple of somewhat common Scala “idioms” like
val dict = list.map: e =>
// maybe some more stuff here
// so the block is a bit longer
e.key -> e.value
.toMap
which were fine with braces but are very confusing without braces, and then you need to think about how to restructure the code.
For the above, you would likely want to put the list.map on the next line, but then you are back to manually fixing indentation of the other four lines.
Adding linebreaks is also a common thing I do, because long lines are more convenient for me while writing, but less readable when reading code. But if significant indentation is involved, adding linebreaks often requires manually fixing indent again (as above).
Again, I am not even against the new syntax, I like it. It’s just an experienced reality that it adds friction basically all the time.
And it is harder to read for me, in the sense that if I have a piece of code I often add braces to better understand the scopes (though, changing the indent to 4 spaces did help with this significantly!)
4 Likes
This is a somewhat disingenuous (or maybe apples-to-oranges) comparison, at least for Haskell. Languages without statements have no need for braces.
4 Likes
This is true and I wish the IDEs were better at it, they could be. It’s still easily worth for the improved readability for me, and you too it sounds like. But not all programmers value readability to the same extent, and some programmers find it totally bizarre how much others care about it. e.g. I am even willing to spend the time vertically aligning = and : across lines in my code, because it makes for more pleasant and insightful literature (I think code is literature), while many mainstream programmers would laugh at that statement. This difference in mindset and values is certainly a large factor underlying the whitespace debate even if there are other objective friction points.
2 Likes
Just in case – scalafmt can do it for you, it has corresponding settings for that.
2 Likes
And I try to avoid writing statements in Scala, building programs almost entirely out of expressions. In this paradigm, braces get in the way. And I think this is why people have negative impressions of significant whitespace from Python; Python is imperative, and long imperative blocks work better with braces, so it is not so attractive in Python. For short declarative blocks, whitespace works better, so it is attractive in Haskell, and heavy-fp Scala.
1 Like
I think that’s great, and I agree that when braces disappear on their own (not through replacing them with significant indentation), it’s a good thing.
I just want to push back a little bit against the argument that “we elite smart people don’t use braces anyway, therefore braceless syntax is good” or “your code is the problem, not braceless syntax.”
Scala isn’t Haskell, and many people write perfectly fine Scala code which – though it may not be the same style that you choose – requires either braces or an equivalent due to statement usage.
The argument I’m defending isn’t necessarily that braces are good, it’s that significant indentation can make things less readable than they’d otherwise be, in perfectly acceptable Scala code.
5 Likes
There are two aspects to that, though.
(1) Some people find indentation a very, very low-salience signal. So it doesn’t really matter where you use it; it’s all bad.
(2) Some people structure their code in ways that make indentation particularly hard to discern.
The solution to these two is very different however.
In case (1), it’s just plain bad. If the person can use IDEs, hopefully the IDE can help increase the salience with lines or colors; but it is just strictly worse because they find looking for } easy and for not easy.
In case (2), there’s a very simple solution: use braces when it’s clearer. Only if Scala becomes brace-free does that not work. Because the lack of indentation clarity is because of how they structure code, they can just not use significant indentation.
I am highly sympathetic to people who are in camp (1) and want significant indentation to go away. It really isn’t a nice situation to be in–other people’s pretty-to-them code is hard to parse mentally. There’s a strong argument to at the very least pay special attention to tooling that can help mitigate the problem, because you can’t just tell a Scala coder “don’t look at other people’s code”.
But I am not terribly sympathetic to people who are in camp (2) and want significant indentation to go away, or who are in camp anti-(2) and want braces to go away, because that means that styles that really work well when used the right way by people who like them are forbidden because the other camp who doesn’t want to use them anyway would, if they did use them, use them in a way that doesn’t work well.
Personally, I write a lot of fairly imperative code and significant indentation makes my code look clearer, at least to me. So I use it.
And when it doesn’t, I don’t use it. (For instance, I usually use braces around class and object definitions.) So for the code I interact with most, it’s almost all upside.
I think I’m in a third camp, or at least an offshoot of camp (1). I think indentation is usually good for readability, but I think it should only be a relevant signal for humans and should be syntactically meaningless. I’m sure that particular debate has already run its course here and elsewhere, so I won’t prosecute the case.
I’ve given up on wanting significant indentation to go away. I mean I do, but it won’t. I know I’ve got bigger fish to fry, but it will always be annoying.
3 Likes