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.
5 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.
2 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