That’s a pretty fair summation of the problem, for my particular case.
Unfortunately, as described previously described (extensively), for me this isn’t a subjective aesthetic preference, it’s closer to an accessibility issue. The closest analog I could think of is if someone decided to take the Red/Blue Function thought experiment and implement it with red and green, then told everyone with red/green colorblindness that, if they’d just try it a bit more, they’d get used to it.
I don’t know how common my difficulty parsing this syntax is in the general community. I doubt it’s really common, but I also have no reason to think I’m unique. So until the tooling is in place to work past the readability issue, optional braces act as a gatekeeper for the rest of the functionality (at least in my case), and I cannot recommend upgrading.
Funny…I find the end markers make it even worse. (The reason it is funny is this is my code that I posted as an example. Different people have different preferences!)
Someone could make a tool to render indentation as braces or render braces as indentation? Since there is no ambiguity once it compiles?
Chrome GitHub Scala 3, braces toggler
I can read both, it’s been fairly simple for me. But I tend to use mix of these.
First of all - although I’m skeptical about optional braces, I’ll be happy to try them out and see how coding in that style feels like in a larger project. I’ve been skeptical about many things that turned out to be really great, hence I’m skeptical about myself as well
Anyway, one thing that we would really need if a new degree of freedom is introduced on the syntax level, is
(a) scalafmt support
(b) a blessed, “default” scalafmt configuration
That would allow to cut short any non-productive and long discussions about how Scala code should look like. For those who really, really want to customise - this would still be an option, but let’s be honest - once an official style is adopted, 99% would use it and most of the syntax layout discussions would be cut short.
I’ve started using scalafmt a while ago, and this has been truly liberating, as it’s one less concern that I have to think about ;). The scalafmt layout is simply good enough.
@adamw We’ve actually been working on scalafmt Scala 3 support and we have almost finished with the “non-optional-braces” part and I’ve actually started experimenting with optional braces too:
It seems that we should be able do provide sensible support soon, but I also started thinking about the possible essential options. Until now I came up with:
indentation width setting (default 3)
rewrite braces with 3 settings: rewrite to braces, rewrite to indentation and keep current (default: keep)
If anyone has any ideas on what could be essential for Scala 3 adoption let us know. For now I’ve also been thinking of automatically adding an end statement to longer blocks, but that seems more like nice to have.
I have stayed silent about that topic so far, but if we’re starting to discuss what the default in scalafmt should be, I have to voice my concern.
I really don’t think it should be anything but 2. Scala has had an indentation width of 2 forever. It’s the one syntax formatting thing everyone has agreed on. Every Scala codebase out there is formatted with 2 spaces indentation. Changing that default means that migration is impossible. The promise that we can progressively remove braces from a codebase when we touch relevant lines is completely broken if the indentation width is not supposed to be the same.
I am not disagreeing. I prefer 3 visually, and some people prefer 4, but we cannot mandate anything. The default should be what most code uses today. But it should be easy to reformat if someone chooses a different default.
It should be, but it is not like that. I prefer 4 space myself. A relevant scalafmt issue is closed with “working as intended”. There is no way it’s going to happen unless you are also BDFL in scalafmt. https://github.com/scalameta/scalafmt/issues/1493
At start, I thought of changing it only for the indented blocks, but it makes sense to keep it at 2 to ease the migration effort, which I haven’t really thought about
I think since there so many changes coming with Scala 3 it might warrant adding the indentation width option or at least reopening the discussion.
I don’t have any strong arguments against the indentation based syntax itself. I am a little bit sceptical but that’s just my personal taste.
When it comes to introduction of indentation based syntax (a.k.a optional braces) to scala I share the concerns of others about tooling, but I saw that this point was already addressed in this discussion to some degree.
One point which I still find missing is that the ability to have either indentation based syntax or braces, is a great opportunity to start another of these infamous, never-ending, holly wars about which one is better.
Formatters like scalafmt are here to liberate us from such invaluable arguments.
Even if scalafmt will be able to support fully indentation based syntax, programmers will fight about which syntax is better (similarly like we do it here:) )
At this point I see no other option than to make one of these a preferable, official syntax for the scala language in order to avoid that.
As many of those who try, said that they like it, I’m ready to put my skepticism aside and vote for the default indentation-based syntax.
Which means scalafmt (or some other tool) should rewrite any other syntax to this one.
As for the projects which are in the migration period such settings would be unwanted, there should be a way to turn it off (still by default it should be turned on).
I know that it may seem very controversial at the first glance but consider another point of view.
A lot have been said about making the scala language easier for newcomers and I think that having a cohesive syntax around the whole ecosystem is one of the factors which matters.
I think it is not fair. There are 2 camps may be because the people have different experience and tasks. Why java\javascript programmers should suffer because of python programmers for example?
OK, I tried to keep me away from the discussion, but I can’t stay silent anymore… I’ve been using scala since year 2005. I work for a quite large enterprise company with Java as the only language until recently (+ kotlin now), But nevertheless, I gradually introduced Scala into a team of sceptical java developers. Now we have around 40 projects/modules using scala. Our codebase is a mix of java and scala, all new code is scala in the project I work with. Few years ago I could just easily recommend scala to a developer from another project. Now I can’t. There are quite good/STABLE/backward compatible alternatives to scala. Java is much better than it was before. Kotlin is there as well. We still struggle to migrate our codebase from 2.11 to 2.13, it’s such a pain to migrate several projects at once. And no customer pays for such work. I had a hope that things would be better and more stable with scala 3 (tasty would solve it), but it turned out to be quite the opposite. It looks more cool than 2.0? Probably. But there are tons of good and dead languages. All this is just more unpaid work and frustrating discussions about styles / tabs / spaces. Some.people don’t want to learn new cool stuff and rewrite things, they want to get a job done and done only once. I don’t see how I can explain to everyone that now we either learn the new syntax because the old one becomes deprecated/obsolete/not-cool or we live with the old syntax until scala stops supporting it with a sudden use of the BDFL. I don’t regret using scala, but I am much more open to alternatives now.
Sure, the options for 2/3/4 spaces should be there, as well as options to change the default style. But we should have a default style - whatever it is! That will close all of the syntax discussions before they get open ;).
Also, reading code where you are familiar with the formatting is easier than reading code formatted in a weird way. One less obstacle to understanding.
There is always a dynamic tension moving forward into a new space. And most of the bikeshedding and resistance comes from the “uncanny valley” psychological phenomenon. If you review most of the comments, they are strongly biased towards “stay as close to Scala 2 as possible, or people will be uncomfortable with the change” or towards “go further from Scala2 as possible” to get away from the Scala 2 bogeymen. Those attempting to find the middle are finding strongly biased responses in an attempt to get them out of said valley and into the their own comfort zone.
This is where I am grateful Odersky is acting as a BDFL. That is the only way we are going to get to the holy land which appears to level somewhere within this uncomfortable uncanny valley.
Said a different way, if you have a strong (bikeshedding) opinion in this area, check to see which side of the valley to which you are biasing. And then attempt to think about the completely other side of the valley. It will help remove some of the psychology of one’s personal identity from the discussion reducing the implicit “threats” of abandonment if things go far away enough from what you are personally comfortable.
Language change is uncomfortable. Full Stop. The only way forward is discomfort. What I am observing as Scala 3 progresses is borderline miraculous in how well it is going for managing the complexity, adaptability, and future productivity.
You don’t need to learn new syntax. You can mandate braces on your projects and very little will need to be changed. Daniel Spiewak has a presentation about migration to Scala 3 (https://www.youtube.com/watch?v=jWJ5A1irH_E) and, for the most part, you don’t need to change anything.
lol. It was quite a rude and personal comment from you. I didn’t ask for a psychological profile of me or any of my colleagues.
You got it wrong. I understand that a good bunch of people are using it for research / books / education / personal projects, but that’s not the case for everyone. Commercial companies are to make money and solve real problems. Some are PCI/OWASP certified and require a code review of every and single change in code, including ones done by a formatting tool! If a language doesn’t guarantee compatibility/stability and requires constant efforts for migrations then it’s probably time to look for alternatives. I expected SIP and Scala Center to be some sort of such guarantee, but I was wrong. Typescript is a nice example of how well one can both improve a language and stay true to the original idea without breaking stuff just because it looks better in a printed material.
I think we can close the thread now. We have argued all the points, most of them many times over.
The discussions and suggestions were very useful. For leaving out braces after classes we went back and forth between two designs: with and :. I believe both would have been absolutely fine. In the end, : won since it was for most the more appealing choice in practice, and since it generalizes well to supporting optional braces in method calls in future versions of the language after 3.0.
Other things that materialized from these discussions:
Clarify the underlying layout meta rules, both as a justification of the current design and as a guideline for further developments
The -Yindent-colons option is too restrictive and has to be refined.
Layout rules should become stricter over time. Right now, they are intentionally loose to allow as much Scala-2 code as possible, no matter what its indention regime is. But it’s foreseeable to tighten this over time.
As a final note, it’s deeply weird to see some of the same arguments against including this as the default syntax being used to support changing the import syntax at the last moment.
