Scala 3 significant indentation

Language Design
#75

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.

#76

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.

#77

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
#78

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
Feedback sought: Optional Braces
#79

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
#80

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
#81

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
#82

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
#83

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):

  1. A correction about the feature’s name
  2. An affirmation that significant whitespace will be the recommended default
  3. A promise of a pending announcement wrt revised timelines
  4. 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.

#84

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
#85

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
#86

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
#87

While that’s a fair distinction to make generally, I don’t think it’s a particularly useful one to make in this case because there hasn’t been an opportunity for feedback by the community at large, other than a few threads like this where the vocal subset have attempted to force the issue to the forefront, mostly unsuccessfully.

This is also part of the reason that, speaking for my own concerns, this is being brought up in the context of significant whitespace and not one of the other big changes (e.g. givens) because those have generally been subject to lively debate and many of the suggestions and concerns raised in those discussions have been incorporated into (and generally improved) the resulting designs.

Stated another way, while the other big changes may not have adhered to the letter of the SIP process, they’ve stuck close to the spirit of that process. The way that significant whitespace has been handled departs from both, and that’s extremely unsettling because, while you may feel that it’s a trivial change as a language designer, as a language user I haven’t found that to be the case, and I’m clearly not the only one.

I would have said the same about infix at the start of this process :wink:. The problem is that, if a change as big as significant whitespace can be made without getting community feedback, it creates the very uncomfortable precedent that anything less disruptive that this can be done if @odersky reads a paper he finds particularly convincing and has a few weekends to spare.

#88

Please prove to me that the majority of the community dislikes optional braces for all cases.

You’re just choosing an arbitrary default here (assume no change unless majority provably wants it), and then you’re implicitly leveling an accusation against the language designers (ignoring the community) because they didn’t choose the same arbitrary default as you did. And again, that’s a very very serious accusation to make over a feature as trivial as significant whitespace. Why aren’t you making this argument about something more substantial, such as the elimination of higher-rank existential types? Or the severe restrictions on type projections? Or the addition of multiple implicit parameter blocks (and unfixing their location from the end)?

6 Likes
#89

I can assure you that significant whitespace has been the source of much more significant ire and debate than almost anything else. That’s not to say that anything has made it into the language without careful examination, but your characterization is exactly backwards. The change was made very carefully, and the community has been loudly involved since it was first publicly mooted. I’m not sure exactly what you want here. Everyone’s voices are being heard, it’s simply that the language authors don’t agree with you.

Let me put this a different way: simply because their opinion differs from your own does not mean they have acted impulsively or unilaterally. They just… don’t agree with you.

Have you used Scala 3? Or, alternatively, have you used Scala 2 without significant whitespace? (seeing as the language already has elements of this)

First off, that’s quite uncharitable to Martin. I can honestly say that I’ve never met anyone who considers changes for longer or more deeply or carefully than he does. Even syntactic changes go through a lot of consideration before he proposes them, much less commits to the compiler.

Second, the entire Scala community uses (and seems to like!) significant whitespace and has since the beginning. Semicolon optionality only works due to magic newline and double-newline semantics. It’s not at all a stretch to see this, fundamentally, as an extension of that very popular feature. From that perspective, this feature has been in consideration for a decade and a half.

2 Likes
#90

That’s simply incorrect. There’s never been a, “what do you all think about this?” on the subject. The change was initially introduced as, “this is something we’re experimenting with, and will gather feedback on in a few months.” That was literally years ago at this point, and the last time it was even mentioned before the comment that sparked this thread was about a year ago, when it got a brief mention in a survey of 2nd year CS students.

Yes, immediately after this was introduced and we were asked to try it out, with the anticipation that there would be an opportunity to provide feedback. This opportunity never materialized.

Nobody is perfect, or perfectly consistent. While @odersky is generally very conscientious about this sort of thing, this time doesn’t seem to follow that pattern. As far as I can tell, @lihaoyi created an experimental project exploring significant whitespace back in 2013, Martin found it at some point and decided to experiment with it, never got around to refining it (even @lihaoyi has reservations about the current implementation ), and at some point the powers that be just sort of assumed everyone was on board with it.

The problem was, they never actually got community feedback. Because of this, a bunch of irregularities never had a chance to be ironed out, and we’re heading into Scala 3 with a new default that’s highly irregular, and that stands out particularly starkly because of all of the other changes that have been careful to increase the language’s regularity.

So while that might not be a fair characterization of Martin’s default behavior, at least from the outside it’s happened once, and what has happened once can generally happen twice.

Addendum:

Note that, while significant whitespace is generally accepted as a good thing, that’s not what this change is about. It’s about significant indentation, which is a different kettle of fish. I’ll try to be more intentional about not mixing terms.

#91

You are implying the vocal subset is different from the community. How do you know it is? What if the majority of the community hates the change? There is a process to help to find out. Any one who wants to avoid the process exposes themselves to the suspicion that they wouldn’t like the outcome of the process.

The status quo prevails until a decision is made to change things - and there is supposed to be a process for change. Therefore, the default should not be arbitrary.

What is the relevance of this what-about-ism? Of course, I am also against other changes without proper process or proper community feedback. Also, as I said before: some changes were maybe an inevitable consequence of the decision to change the backend. The syntax was most definitely not.

1 Like
#92

Community members have spoken up, but always against being told that this was not the proper time. Until it was a fait accompli.

So, you are saying the change was decided by the “language authors”. Care to elaborate who these language authors are?

1 Like
#93

I don’t think any amount of argument here will convince either side that the majority of the entire community welcomes, or loathes, optional-WS. Only a tiny amount of the community visits these forums for example. We can speak for ourselves and our circles but that’s about it unless you’re out there doing surveys. It’s moot in this context, isn’t it?

Even any kind of assertion from Martin himself that braces will remain in 4.0 is moot because it wouldn’t be some legally-binding contract. It would just be a prediction about the future. If all kinds of new information came in over the next 10 years to change that prediction does anyone really think Martin or anyone else would say “well, it’s overwhelming a good idea but we’d better not do it because I said on a forum many years ago that I wouldn’t.” I understand wanting assurances but even if it were promised it would be unrealistic.

Instead wouldn’t the path to consensus be to

  1. clarify how the SIP process will be involved now that we’re at the tail-end of Scala experimentation and design. (I commented further down the mountain in more detail about this and I think this is really important.)
  2. consider if putting optional-ws behind a -Y flag would satisfy the majority of both camps.

?

5 Likes
#94

I have just opened a formal feedback thread on optional braces. Quoting the last paragraph of that post:

I also apologize for having sought feedback so late in the game. We dropped the ball on this one. It was because due to Covid all SIP activity was dormant since March 11th. We should have opened this thread over the summer, but nobody thought of it then.

10 Likes