(emphasis mine). This wasn’t a fatal flaw. He listed advantages too. (Go look in history.) He was suggesting living with the disadvantages. And he was willing to consider good arguments and widespread opinion.
That the opinion didn’t mostly align with what you wanted doesn’t mean that it wasn’t considered. That the arguments were dismissed as unconvincing or insufficient (actually, if you read the rest of Martin’s point, he does admit that there are some good arguments against :; it’s other people who seem to not care) doesn’t mean they were ignored or that it was all pointless.
Given that I’ve been following this particular feature for well over a year now, I don’t think that’s a fair assumption. Particular to this thread, I’ve read every single message in this thread, most of them several times, and am familiar with the comment you quoted.
The problem isn’t that the pros and cons of the features weren’t showcased, the problem is that statements indicating it’s too late to change anything make it very difficult to trust that the feedback provided was actually considered.
Initially, the call for feedback was very broad:
It wasn’t until 76 posts into the thread that it was clarified that the thread wasn’t about including it or not, it was about potentially changing minor details of the proposal:
That basically meant that the bulk of the previous discussion was completely irrelevant, because it was about something that was a complete non-starter, and that was known well enough in advance that it should have been stated up front - particularly as it was acknowledged that this is probably the single most controversial change, and simultaneously the one that’s had the least input from the community (and as a result, the least number of eyes on it).
So the discussion switched to the much narrower scope of end-markers, the end of which was a comment that indicated any change was out of scope, because the feedback requesting the changes came too late to be considered:
So I have trouble trusting that the feedback was received and considered in good faith, not because I didn’t see the changes I would have preferred, but because I didn’t see any changes in 300+ comments. This feature has seen very little in the way of public feedback or revision, and even folks on the SIP committee have expressed doubts that it’s a good idea, so it is passing strange that nothing worthy of adoption came out of this discussion beyond “maybe indent 3 spaces” and “maybe get stricter about layout rules later”.
I think it is unfair to accuse others of being inattentive.
Getting a response to feedback is not evidence that the feedback was relevant.
I was conflicted from the beginning when this thread was opened, whether I should even participate, because it was not clear to me whether anything was still open to discussion, or whether it was all a charade. But then I thought, after I repeatedly voice my skepticism, I might as well put it all on the record now. At least, when years later everyone realizes what an unmitigated disaster this is, I can say “I told you so”. It may look nice for CS homework problems, but it is not scalable.
The other thing: I care about governance. If you were paying attention, maybe you saw my messages about governance from a while back. Dictatorships are bad in the long run, no matter how benevolent they may appear. The gold standard is governance by a committee representative of users, making decisions with super-majority. There was reason to hope that the Scala community was moving there, but we now know it is not.
Moreover, while dictatorships are not good, they may be bearable as long as there is reason to believe that one’s priorities somewhat align with that of the dictator. For me, that has been the case with Linux and Python (in the past). In the case of Scala, I am concerned that my priorities as a software engineer building complex applications according to user requests may not be in line with a dictator who is primarily a teacher and researcher, and therefore mostly cares about teaching CS 101 and about making experiments.
I have no idea what kind of experiments will make it into Scala 4, but I’m afraid it can be a lot of things. Maybe, there will be a new theory called DASH calculus, which will be far superior to DOT calculus, so there will be an experimental compiler called Dashy, and a new type system and a different way type inference. The way that implicits/givens will work will change completely, and same for macros. The SIP committee will decide to make Dashy the new backend, so then we can’t have a SIP process on every item, and while we’re in the process of uprooting everything, why not throw in Reverse Polish Notation. And we will be invited to give feedback, but mind you, the course material has already been printed.
I’m not yet at the point where I would abandon Scala, but I’m far less passionate about it than I used to be. I was the one who introduced Scala to a team that had been using Java and Groovy, but for future projects, I will be far more open to using something else.
If we weren’t prioritizing teaching materials over a healthy process to evolve the language, we wouldn’t be trying to squeeze so many language changes into one release (evolution step) in the first place. The amount of risk we are taking on is staggering.
I certainly hope it will turn out amazing or at least okay, but I am still very worried that there will be too much negative reaction to Scala 3 and its popularity will drop even lower than it already is.
I really don’t get how it was possible to invest so much money into creating courses based on a language change that was not set in stone, or how it was possible to set such a major change in stone with so little research or even community engagement.
That’s not how you fail to “actually consider” the feedback.
“Improving concrete aspects of the proposal” does not mean “discard the proposal”. Implicit in “improving” is that the proposal will be kept, and implicit in “concrete aspects” is that it will keep the same general character. The only clarification needed was that “put under an optional flag” was out of bounds (already iffy, given the language).
So you were apparently under a misconception from the start. It happens. No big deal.
That’s not how I read this. I read it as follows:
I simply don’t think it would work better than what was chosen
meaning that this specific proposal isn’t (given the ensuing discussion) a clear win, and
at this late point we should be way beyond considering more changes.
we shouldn’t change things just for change’s sake; the change needs to really earn its keep, which this doesn’t. (Arguable…I think it does. But the overall sentiment was not strongly in favor.)
Why are you discounting the suggestions to change things, followed by counterarguments and many people saying, “No, I like it the original way better”?
Well, that’s the charitable interpretation. The uncharitable one is, well, worse. But the claim is clearly wrong, contradicted by evidence in this very thread.
I rather doubt it will be an unmitigated disaster. Any time it starts getting bad, you can just use braces. It may be bad, though, as it gets increasingly awkward with scale. And it adds complexity to the language which may or may not be paid back by a cleaner style. If a disaster, I think it will be a strongly mitigated disaster.
I agree, but I don’t see how this is more than a rounding error in that calculation. The feature just isn’t that impactful, not with the kind of tooling that’s supposed to be around, and not given that it’s entirely optional.
Taking syntax away (e.g. procedure notation, as-you-please infix notation, etc.) has an unavoidable impact, while new optional syntax has a much milder impact.
For someone who keeps bringing up this accusation, you seem to be reliably glossing over my core concern. Most critically: if a decision has already been made, then humoring folks with a discussion that goes nowhere isn’t considering feedback, it’s putting on a show. This isn’t something that even needs to be done maliciously or intentionally, confirmation bias is something that has to be actively avoided, and we’ve seen plenty of things that certainly look like that’s what’s going on.
“This is not ready for prime-time” is valid feedback, and concrete concerns were raised, repeatedly. SIP are not universally adopted, so discarding was absolutely a plausible outcome (until further clarification was provided). Putting it under an experiment flag was raised because we can see there is potential here, however it’s objectively an immature feature, so we felt a soft launch was a reasonable suggestion.
This isn’t what he wrote, and completely changes it from “we should be way beyond considering more changes” to “we’re still considering more changes, provided they’re sufficiently well reasoned”, which is pretty much the exact opposite meaning.
Simply because the discussion and suggestions are completely irrelevant if no change was ever on the table. My kids can suggest and discuss all they’d like and I may even acknowledge any particularly well reasoned points, but if the decision that there will be no desert tonight was already made, there will be no desert.
You’re missing some important context:
That means that, if this goes out, it’s going to be taught as The Way to at least all the new Scala devs who pass through the Coursera course or Scala Center language tutorials, which means ongoing impact in one of two directions: either it will propagate into every codebase, or those who find it hard to work with will have to actively work to help new devs unlearn this habit during onboarding. It’s already hard enough to help them unlearn bad Java habits - and it’s not like it’s exactly easy to find Scala developers to begin with - so any increase in recruiting or onboarding difficulty is going to cause an increase in the cost to adopt or just stay with Scala that we can ill afford. It’s also going to cause a bunch of arguments about code style, and that’s another area where Scala already has a really bad reputation - this thread is going to happen over and over and over again, in pretty much every company that uses Scala, and that is not a good look for the language.
This is not something that’s going to be off in a corner somewhere, it’s probably the single most immediately noticeable user-facing change. It’s concerning that one of the strongest arguments for keeping this feature in (the cost of reworking the course materials and books) implies that, despite feedback which can be charitably characterized as “mixed”, short-term documentation costs (steep though they may be) are considered more important than long term increases in total cost of ownership.
If this get’s a soft launch, what exactly is the downside?
Work will need to be redone that either never should have been done, or should have been done with the understanding that it was relying on an experimental feature that could be changed or deprecated at any time (just like everyone who wrote macro tutorials in the beginning)
Early adopters will have to add a compiler or language flag, something that they’ve demonstrated consistent willingness to do.
If this does go in, we’re rolling the dice for next to zero demonstrable gain. There’s been no indication that this will bring in anyone new, or make it easier to sell adopting Scala, or really do anything other than “look cool”, and there have been several credible warning signs that this is going to make it harder to convince an engineering team to adopt Scala.
As someone coming from F# directly to Scala 3, it has caught my eye and I have been playing with Scala since the past month. I always hesitated trying Scala 2. But with Scala 3, it appears to be a lot more approachable, cleaner and I welcome the changes. I don’t think this is zero demonstrable gain.
All the asking of feedback is for “how to improve this proposal”, rather than “whether we should do this at all”. It’s like making a statement saying this is done for sure, and you just deal with it.
I’ve spent some time with new syntax. I like it in new code but when I started to rewriting old code I couldn’t. There was something odd when I tried to use helper functions with multiple parameters lists and lambdas.
I really liked new syntax but only when there was braces as fallback. Current state seams to be ‘half baked’ to me, and introducing it as new default looks risky.
I hope it will stay as experimental during 3.0 release, hidden behind compiler flag. There is still some gray area where new syntax just looks worse than old one.
To clarify, I absolutely agree that some people will find this syntax more pleasant, so it would probably be more accurate to say there is zero demonstrable net gain.
Stated another way:
Are the people who would be attracted by this greater than the number of people who will look at it and think, “cute teaching language,” and decide it’s probably not worth their time interviewing for a Scala job?
Is such a large change to how the language looks going to go so smoothly that it’ll attract more engineering teams because they think it shows reliability, or will they be reminded of Scala’s old reputation for massive version incompatibility problems1 and be more resistant to considering it?
There isn’t, currently, any real evidence this will go our way, so it’s a really big gamble.
1: Yes, this is still with us, and I ran into this concern “in the wild” as recently as this past November.
Since this might be related to my comment that Dotty has been available for a long time, let me clarify that. Whether someone was paying attention or not and what avenues to provide feedback were available at that point is beside the point. It might be a point worth bringing up separately, but it is immaterial to this discussion. What was asked was feedback from people who used it or interacted with it in a meaningful way. It is obvious that there’s people who want a different kind of conversation, and it might be fair to point out this isn’t the conversation they want, but it’s unfair to criticize it for failing to meet expectations of that different conversation.
I also take issue with “accuse of being inattentive”. Attention is a limited and valuable resource. I didn’t pay attention to it, for multiple reasons: I trust that people who are actively engaged in language design are more informed than I; I don’t believe Scala success depends on this, given it isn’t the case for the successful languages; and, to be honest, it is an insignificant change. It’s not like we are debating the merits of block vs file vs permanent-storage backed variables as medium for source storage. Braces vs significant space is a bike-shed discussion if I ever saw one, but I respect that people disagree with me. Anyway, just trying to say I’m not calling out people on being inattentive, just saying having relevant experience was a prerequisite for this discussion so let’s keep civil about it.
Overall I’m in favour of new indentation syntax as it makes code little bit more consistent and less noisy, however there some minor problems/disadvantageous which I can think:
New syntax will cause a lot of inconsistency between different codebases, and will only cause more holywars around formatting and approach (which is counterproductive).
I’m not really in favour of end ... as it increase boilerplate, require additional support from editor and generally takes more space, I would personally stick to curly brackets for class boundaries, as most editors have hints on brackets boundaries and it’s not that common to have really deep nested structure or long file (at least in fintech)
Overall I think optional braces might get some resistance in companies with Java as primary language such as mine (especially with strict formatting rules).
This. I’d rather not have the feature ready for Scala 3 and give it time to mature than let it escape into the wild and have people complain that Scala sucks because the syntax needs to be changed again after release. After all; there are still cases where the optional braces syntax doesn’t have a good (any) answer.
To be honest, to me the new syntax looks little bit more readable than the old one with curly braces.
But this my subjective personal opinion , because my first functional language was F#, but for the community this changes can be destructive
Why do I think so? Let’s take a look at a history:
The conclusion is that there is not a clear benefit for it and the required invested time and efforts would be too high.
There is no clear consensus that this change is desirable.
In the ensuing discussion, there is a bit of confusion over whether the old syntax would continue to be supported, and if so, if adding more ways to express the same thing is bad. SIP Committee
Consider syntax with significant indentation. 192 likes / 295 dislikes and many controversial comments. Even at the discussion stage, there is no general consensus. The same disagreements will continue in a daily development.
Does anyone know any other language with 2 different syntaxes? Nemerle - you could write in it in both regular C# and scala-like syntax. The author of Nemerle, called it an advantage, because you could choose the syntax you want. Probably, many peoples don’t remember Nemerle, because Nemerle is dead and no one uses it.
10 years ago, the advantages of Scala over other languages (especially Java) were obvious. But now, in 2021, more and more languages have these benefits. Even conservative Java has lambdas, stream-api, case classes, pattern matching, ADTs and etc.
I think Scala faces more significant challenges, such as: contract-based programming, refines types like LiquidHaskell and etc. Something that other languages do not yet have and can increase the speed and safety of development.
But with Optional Braces beginners will complain that they have to learn two different grammars. Mentors will have to explain the difference and the “correct” way (which will be different for everyone) and duplicate teaching materials. As tool and compiler developers, you will have to duplicate solutions and fix bugs in two grammars. And for what? For subjective “I like it, It’s looks cool”?
Attention is limiting! So there’s no great shame in being inattentive. If I overlook something, and someone says I’m inattentive, I say, “Oops, yeah, I missed that” and move on. If my premise is based on the non-existence of the thing I missed, I change my point of view or explain why non-existence isn’t actually necessary and refer to other evidence.
I didn’t gloss that over! I provided direct quotes demonstrating that you’re wrong (or it’s a really elaborate show, involving multiple people putting on a play).
But Martin was the one discussing dessert, in the analogy.
Agreed. This is a substantial drawback, and one that hasn’t been, as far as I can tell, sufficiently strongly argued against, especially since the different-code-styles thing was precisely the argument to restrict infix notation.
Of course, practice matters. If in practice, changing between infix notation and not tends to trip people up badly, while braceless syntax vs braces is totally fine (I would expect the opposite, but let’s suppose it is this way), then both arguments would be valid. But you’d need evidence that such was the case.
Otherwise, I agree that this criticism is reasonably weighty, and it would be good to have a compelling answer to it.
(I hope we focus on compelling points, not on presumptions of bad faith.)
Unfortunately, it sounds like bad word choice is causing unnecessary friction. “inattentive” implies “negligent”, “sloppy”, or “neglectful”, so an assertion of being like “You were being inattentive” that attaches those characteristics to someone is not going to be well received. “You appear to have missed…” on the other hand is a statement about something a person did, rather than who they are, so is less likely to cause trouble.
The issue here is that those quotes don’t actually refute the concern that the decision was predetermined because they show no evolution of thought on the subject. It’s just a loop of variations on, “fair point, I still think : works better”.
This doesn’t need to be the result of an elaborate show, confirmation bias and sunken costs are more than enough to produce this result. My original goal of trying to keep this as an experiment is probably unachievable. What is achievable is to help make it more likely that this sort of situation is avoided in the future, by reducing the chance of getting to the point where feedback is requested in a post hoc manner.
If the Scala Improvement Process was actually followed then this was avoidable, but then again that would have delayed Scala 3 release and experimental use significantly. It’s difficult to bridge the two approaches. Sometimes you have to go agile and things fall through the cracks that would have been a avoided in a normal process. So we end up with this thread (maybe the longest in this forum?) which is here to let users vent more than actually achieving anything tangible. That’s OK too.
It was certainly sloppy to charge that outcomes were predetermined without noticing and addressing, directly, the extensive post (and several others) specifically pondering particular changes in response to comments.
No it’s not! There are many comments not from Martin favoring :. I am posting only key snippets in favor, not the arguments against. The attentive will notice that I have said so, and will respond accordingly. My point is merely that there is a good deal of sentiment (sometimes with argumentation, usually not) in favor of :after Martin suggested changing to with.
You’re trying to characterize this as a foregone conclusion.
Indented blocks would go in RC1. Template bodies would come… later. So, for the moment we would have semi-braceless and colon-free syntax. I think it would make a lot of people happy. given with {} would not be so much of a problem. End markers could be postponed too as AFAICT they don’t make unanimity either. Same for 3-space indent.
I hope you didn’t perceive this as a sentiment in support of :, because it is not intended to be a such. I still think that we ought to further explore the design space for optional braces, the current implementation – to me – seems lacking.