I would love to write braces to keep me away from failure in production
I’d really like this meme of “too many ways to do things” to die. It’s such a thought-terminating cliché, which does not apply at all to powerful languages like Scala, where having many options is actually a strength.
Are you telling me it’s a problem that xs.distinct and xs.distinctBy(identity) and xs.toSet.toList and xs.groupBy(identity).map(_._2.head) and
val seen = mutable.Set.empty[T]
xs.filter(x => !seen(x) && {seen += x; true})
all do the same thing is a problem?
More generally, are you saying that languages should be inexpressive enough that you can only do each thing in a single unabstracted way?
Sheesh! Not every language has to be like Python or Go.
That’s a consequence of the fact powerful languages allow domain-specific abstractions to be designed, and again it’s a strength. Humans don’t really think in mutable variables and for loops; they think in high-level and composable concepts.
10 Likes
My concern with academics running the show is not so much having new features. I’m more concerned with how much weight is given to the response of students taking CS 101, or how pretty that recursive Fibonacci calculation looks like.
Or how Scala is trying to compete with Python by becoming more like Python.
6 Likes
This is just toxic flaming. Scala 3 hasn’t even been released yet, and even if you’re using a pre-release you can either:
- Simply not use it
- Completely disable it with a compiler flag
The Dotty team has said numerous times that braces will never be removed from the language syntax, so you can just keep on pretending they’re mandatory if you want to. Also, if you already “gave up”, then why are you still here and why do you care?
This is both insulting and wrong.
5 Likes
So, I’ve been mostly ignoring this round of this argument – at this point, it’s a fait accompli. I find the braceless syntax much harder to read in the code examples I’ve seen, but I suspect we will mostly ignore the feature at Rally (most of the serious Scala engineers there appear to dislike it almost as much as I do), and we may decide to write scalafmt rules to constrain it.
That said: the Dotty team kind of broke the trust of some of us when it comes to this. I doubt I’m the only one who remembers where this started, with Martin saying that it was just an experiment that he was trying out for his classes, and we shouldn’t worry about it. I objected to that at the time, that it needed to be seriously discussed before it was put in the main fork, and was basically ignored.
And then the Dotty team made it ever-more-central to their work, until it was a fait accompli, and largely waving away the strong objections in the PRs around it. (I pretty sure that I’ve never gotten so many thumbs-ups on a GitHub PR comment as I did on that one, and the bulk of the commentary on that immense thread was opposed to pushing it into 3.0.)
So you’ll forgive me if I have a little trouble trusting the core Dotty team’s assurances that they won’t then push to remove braces altogether in a later version. While I think the “academics” argument is nonsense, I do think they’ve been too cavalier about community objections to this enormous surface-syntax change, and so far I don’t see much reason to believe that that’s improving. There’s been too much tendency to say, essentially, “We like this, and we know what we’re doing better than you, so it’s going to be this way.”
I’ve been a major booster of the Dotty project for years now, talking it up and keeping folks informed, and I still like almost everything about it. But I think this feature, regardless of its merits, has been terribly mismanaged, with community input treated too casually. At this point that is what it is, but I’d like to hope that we will learn better for the future.
7 Likes
You’re missing my point here. There are many valid objections against pushing optional braces into 3.0. Raising these eloquently could very well convince the ones in charge to rethink this. Insults are just counterproductive.
There is an absolute 0% chance of this happening. It would be a significant breaking change to the language. It will never happen.
1 Like
I’m not insulting anybody – I’m just stating my perspective. I sincerely believe that this feature has been mismanaged from a community-involvement viewpoint (largely because, based on his statements, I believe Martin became overly invested in it), and I’ve stated why the history leads me to believe that.
I have been doing so, repeatedly, both here and in the Dotty repo, for the better part of two years now – this is not a new conversation. Many other folks have made the same arguments. We’ve largely been brushed off, so I have little reason to believe that you are correct here.
In 3.x, probably not. Why do you think people aren’t going to push for this in 4.0? We’ve built the technology for making significant breaking changes, and IIRC members of the Dotty team have said in as many words that they want to get to the point where braces are entirely unnecessary. From a code POV, it would be a relatively straightforward migration in the modern scalafix world. The problem is that it would be a gigantic training disaster, but that argument has been largely ignored so far in these discussions.
I don’t think it’s going to happen overnight, but I fully expect there to be people pushing for the complete elimination of braces in 4.0, unless there is an explicit formal statement from Scala Center that that will not happen. Frankly, I would greatly welcome such a statement – I expect to be having major arguments at my dayjob over this topic, and that would go a ways to calming them down.
2 Likes
I totally agree with everything @jducoeur says, except that I want to note that the academics reference totally does makes sense, because I do remember the argument at one point being: “We tried this with CS students and they liked it”.
It is therefore a valid concern that Scala will gradually be turned into a teaching and research language, and then for serious software engineering we will need something else.
3 Likes
Exactly. Plus no one seems to get my point about there being too many ways to do/say things syntactically. The more ways you can say something the more ways people will use. Sure you can tell your team not to use xyz, but what happens when you want to use libraries/frameworks and each has a different syntax? All of the sudden it looks like you are using 5 @#$@#% languages. Where do you as a business hire a person that has memorized all of the inside and outs of Scala to know all of the variations in syntax? Now how do you put together a team of those sort of people? You simply don’t.
Which is why I said it isn’t good that academics won’t listen to business people.
Adding features constantly won’t make a language popular with people that own a business or managers, because that means paying people to do busy work of constantly rewriting and maintaining your code base instead of using that time to develop and innovate new features. This is why languages like old fashioned C are looking better by the day. C is almost done changing, you can write code one time and it is good for a long time, any updates will be minor. I just looked and am amazed C has taken tiobe index #1 spot How? Because older developers rather write code 1 time in 1 syntax which other lower devs can understand.
I don’t like how those with different opinions are treated by this community either.
I would very much like to. However, the Scala Center is not in a position to issue such a statement, since we don’t hold a majority of votes in the SIP committee. In fact, I am the only voting member of the SIP committee working at the Scala Center.
I’m afraid that even a statement by the SIP committee will not generate much confidence, because “significant whitespace” aka “sometimes optional braces” aka “optional braces in some cases” became the Scala 3 default syntax without approval by the SIP committee.
It is an interesting question what could possibly provide such confidence.
1 Like
If I may, I would like to try my best to make a constructive argument in favor of making optional braces an experimental feature in Scala 3.0:
Some members of the community obviously have reservations against optional braces, even if they can still be used. As I’ve heard Martin say in presentations: “Scala 3 is when the books will have to be rewritten.” Because of this, features need to get into the language now if they change foundations in such a way that books become outdated when they are added.
Optional braces is by definition not a breaking change. In my humble opinion, what’s important do get into the new books is semantics and things like how givens work. None of this would actually become irrelevant or outdated if and when braces become optional in the language. It would be a quite minor thing to introduce them in a reissue. Books written with brace-syntax would not become outdated and irrelevant just because optional braces is added in 3.0.4 and it says on the internet “Braces are optional now.”
I would go as far as arguing that if the brace-less syntax is really so confusing for people that they merit throwing out all books and documentation, then that in and of itself a huge argument against introducing it.
For this reason, I humbly suggest that optional braces is made an experimental, opt-in feature just like -Yindent-colons. Then the focus can be on the really interesting changes in 3.0, community can try optional braces at their own pace, if there are issues with the new syntax they can be sorted out, and if they are met with enthusiasm from most people, add them then.
Thoughts?
4 Likes
Hang on, you don’t represent all businesses, all hiring managers, nor all teams. There are plenty of teams that work very, very well in Scala, and many teams do so with the understanding that the warts and aspects that they find unfavourable, can be dealt with in such a way that it doesn’t come anywhere close to negating the huge benefit that Scala provides over other languages. There’s definitely more annoying migration/busywork that you have to do sometimes as compared to other languages, but in my experience having used Scala for around 10 years on a number of very large codebases, it’s rare, and doesn’t take that long anyway. Not to mention that with every passing year, the tools that allow us to automate the migrations get more and more capable. Scala 4.0 is at least 10 years away and you can bet that if Scala 4.0 did decide to drop braces in favour of WS, scalafix or a similar too just do it all for you. The idea that you’d have to pay 10 devs for a month to migrate your codebase (10 years from now) is never going to happen, and I wouldn’t worry about it if I were you.
Now how do you put together a team of those sort of people? You simply don’t.
You simply do, as we simply have been for ages.
Which is why I said it isn’t good that academics won’t listen to business people
Personally I’m so sick of hearing this argument. I’m not an academic. I have my own business in which I’ve invested basically my whole life and soul for years now. I’m looking forward to Scala 3 with glee. I want new features. I’m already waiting for new features pushed to 3.1. I’m willing to spend literally one dev-day per 100,000k loc if I want to improve my codebase with new feature when they become available. Some businesses rely on sweeping tech-debt and crappy architecture under the carpet for as long as possible, some business take an extra few % longer to achieve goals so that their stuff actually works and/or to keep future dev costs down. Many business are in between and off to the sides. Academics vs business is a completely false dichotomy.
13 Likes
And I’m an academic, and I am looking forward to Scala 3 but with great trepidation also because I know that I don’t have the time or attention to fix my old code for various academic projects, and I certainly can’t count another Scala programmer being hired to work on this stuff in any useful timeframe.
(In fact, mostly I’m still on 2.12 because the collections rewrite broke too much of my stuff (deprecation of procedural syntax clobbered a lot too), and I can’t afford the time to go fix it all.)
So–agreed. There might be, potentially, an “industry/business” vs “academic” dichotomy, but this isn’t it.
Different users have different appetites for new features and different ability to handle changes. That doesn’t mean you never change the language or libraries. (That is a niche one can occupy…C has that niche, and Java used to, but it left it after Java 8.) It just means that the changes shouldn’t be gratuitous. If they’re serving some purpose, well, that’s how the language and standard libraries get better (on average, over time).
6 Likes
I am a software engineer working for an academic research institution that employs hundreds of software engineers, many of which use Scala.
I love working with academics. I’m also fine with the usual model that there is an academic called the principal investigator, who is basically a benevolent dictator for life (if they don’t get fired or run out of grant money). It is fine as long as I can be confident that this person is willing to listen to the relevant people.
It is difficult to have that confidence when a process is ostensibly established and then not followed, or when we start hearing arguments like “My students like it, so I’m sure you are going to like it, too, if you give it a try”.
2 Likes
May be it is not so hard in test samples. But it is just less productive in my experience. The braces just help me to analyze, copy\paste, refactor code which I work on. (Even very simple text editor can process braces correctly).
I have been working in python recently. I am used to indentation very quickly, but I just less productive, it is not the biggest lost, but it is a lost. I don’t see how yaml take over the world so this feature seems very suspectible for me, I can imagine where this feature has advantages but as you have said:
And to say the truth the ability to throw away braces just scares me. Ok, they say it will never happen. But it just means that such disadvantage will stay forever.
3 Likes
I’m all for more ways to do things, provided they’re built up from common, well designed, sensible constructions. People think in different patterns, and I think it’s a mistake to try and force everyone into a box that may not fit them.
This is part of the reason I dislike @infix, because it’s not the library maintainers that are going to need to look at and understand my code. I will, and while it might be easier for some, infix is harder for me to understand. I like that infix calls are currently allowed, because I understand that for another subset of the population, the reverse is true.
Significant whitespace has it’s place, both for the people who find it easier to read generally, and in some particular situations I find it helpful (though not generally, usually in embedded DSLs). What I object to is the unproven assumption that this is the way of the future, and that presumably because of that assumption, it’s jumped the regular process.
I’d welcome this change behind a language flag. This would give time to work out the irregularities, and for the community to decide how useful and usable this actually ends up being. Gradual adoption in this manner certainly hasn’t held back other language features that have proven their worth over time (like higher-kinded types), and I haven’t heard anything even close to a reasonable justification for why this particular change should be special.
That being said, we’re currently at 77 comments, and the responses from the SIP committee or Scala Center have been only tangentially related to either of the two major concerns (specifically, the feature itself, and the way it’s bypassed the published processes):
- A correction about the feature’s name
- An affirmation that significant whitespace will be the recommended default
- A promise of a pending announcement wrt revised timelines
- Declining to comment on the elimination of braces in 4.0
This really doesn’t help the impression that, at least on this particular issue, the concerns of the community are not terribly relevant to Scala’s future.
I am just one SIP committee member, but:
My overall sense of the multiple discussions we had on this is, there was definitely a lot of ambivalence about this change on the committee, but I don’t recall any of us being firmly opposed.
If I had been asked to formally vote on this 1-2 years ago, I would have said let’s postpone it until after 3.0. These days, I’m warmer to the change, for multiple reasons:
- I’ve had more time to get used to the idea.
- I’ve had more time to actually use the new syntax.
- I’ve had more time to watch other people also gradually getting used to it or even liking it.
- The Scala 3.0 release date was pushed forward, making more time for big changes to get in.
- Scala 3 became more ambitious overall. Some of my initial ambivalence came from initially having a different vision of what Scala 3 was. My starting point was, let’s swap in the new compiler and try and limit how much other change occurs. That vision I had didn’t win out, and probably I was wrong. (I am cautious by nature, but sometimes language design is about making big, bold moves.)
- Some of my fears about making a big change like this stemmed from fear that there wouldn’t be enough people involved and enough time to make all this change happen. I’m no longer worried about this. There are a lot of people working on Scala 3 (and tooling and docs and so on) and despite the broader scope, Scala 3 is really happening, we are nearly there.
3 Likes
Let’s be careful to separate “the concerns of a vocal subset of the community” from “the concerns of the community.” Both are relevant to the future of Scala, but it is a little presumptuous to assume that the entire community is unified in their concern about this feature and this feature specifically.
I feel like part of the problem here is a conflation of two questions: significant whitespace as a syntactic change, and the process around changes in general introduced in Scala 3. The former, to me, is trivial. I can only speak personally, but I just frankly don’t care all that much. As a language designer I lean modestly towards significant whitespace since it removes the need for hacks like formatting tooling. As a user, I like uniformity (something which significant whitespace promotes) and I do like fewer syntactic elements, but I don’t care enough about this specific element to make a fuss either way. So again, please be careful about implicitly over-generalizing specific objections to the entire community (which is massive and varied).
As to the second element (process around introduction of changes in Scala 3)… I find it rather weird that this objection is being raised in the context of significant whitespace and not in the context of any one of the other much more substantial changes to the language. Scala 3 is changing a ton of things, most of them in a fully backwards-compatible fashion (like significant whitespace, which does not result in a removal of curly braces). Basically none of those things have gone through the SIP committee, because it was effectively impossible to do something like that with such an active development process and with so many things in motion at once. The SIP committee is great for incremental changes made slowly; it isn’t great for large projects such as this one.
That’s not to say that things are being done in an ill-considered or hasty fashion, but it does mean that the committee process is simply inappropriate, and I’m not aware of anyone on the committee who believes otherwise. (though I haven’t spoken to all of them)
I’m not going to speak in any official capacity (since I have no official capacity in which to speak), but having spoken to a number of core decision-makers in this process (notably, Martin) and having listened to their thoughts about the future… braces aren’t going anywhere. You may be interested to note that Haskell retains its braces to this day, just as Scala retains its semicolons. If you prefer brace style, I think it’s safe to say that you will always be free to use it, and I’m sure someone will write some tooling which enforces this automatically in builds.
11 Likes
Well, please prove to me that the majority of the community like optional braces for some cases.
Or otherwise, please acknowledge that the community as a whole has not been heard.
1 Like