I had already thought of that, but I guess I should have preempted your misunderstanding as follows.
But you argued there would be no true translation from braceless to braced, thus I would not be able to write my code in braceless to begin with, if we accept your assertion.
And if your assertion is false, then there is no need for any of this acrimony because we can translate back and forth between the styles.
As ever, life is more nuanced. Information can be hidden more easily than it can be reconstructed once lost. Itâs simpler to write a filter to hide the braces the IDE would have inserted for you, than it is to reconstruct the braces that a human would have intentionally included or omitted.
The automatic translation is really only a one-way trip, unless youâre willing to accept a lossy translation.
Addendum
And important point you seem to missing is that, normally, a change that makes development marginally easier for some and near impossible for others would have been rejected. In this case, Martin reversed that, and fewerBraces is just another step in that direction.
Yes, you may prefer not to have to deal with braces, but treating that preference as an equal concern to the physical inability to read code without them is all sorts of messed up.
I donât hate braceless style, braceless style disqualifies me from participation in Scala development.
Last I checked the Scala developer pool was so minuscule (on the verge of extinction) it needs any boost it can get. I believe the braceless syntax might provide that boost. It will also further differentiate it from Kotlin which has been eroding Scalaâs market share. We need Scala to survive. It has come very close to dying from my perspective. Thus Scala needs a larger ecosystem, so arguing to hang on to the current measily ecosystem instead of trying to expand the ecosystem doesnât make sense to me. Besides those who absolutely need Scalaâs unique features are not so fragile as to abandon it because of the new optional syntax. What they going to migrate to, Haskell? Haskell also has a non-braced syntax.
I am not well versed in Pythonâs history but wouldnât the lack of static typing play a significant factor there, because thereâs facets of the styling you canât really get unambiguously right without it. How can one cite Python of an example of what not to do when it has 30% market share compared to Scalaâs 0.63% and Kotlinâs 1.44%?
Scala is not going to be the better Java. Kotlin has that locked up. Scala needs another niche.
Do you want Scala to die just because of your intransigence about braces? Will you be happy then? I want Scala to thrive.
Everything here screams for creating a version of Scala that has a larger developer pool. What is your proposal? Scala 2 status quo?
The popularity of Python seems to be a good target. If you can mostly make Scala code resemble the advantages of Python but then add type classes and static typing, youâve carved out a niche that nobody else has, especially not on the JVM.
Your argument distills down to letâs keep our horrible situation intact and take no steps to attempt to rectify it. You want to preserve what appears to be nearly entirely non-existent. Scala already is a no-go for corporations. We know that. And the only way to change that is to broaden the developer pool.
I bet there wonât be any splitting because the supply of junior devs will expand and overwhelm the small pool of laggard diehards who refuse to adopt the sanctioned braceless default. Those junior devs will eventually become senior devs. We need to recruit junior devs at a faster rate. The braceless style and building libraries to be more friendly to Python developers might be a strategy for achieving that goal. Stuck in the mud with the status quo is not a plan.
Afaik, itâs not possible to adequately simulate type classes well in a language without higher kinds and implicits. There is the Lightweight technique for mapping the Functor onto a phantom type, but this is really a can of worms that doesnât really work well generally. You can implement any algorithm without typeclasses or with some kludge but you really lose the entire raison dâetre of typeclasses. Maybe big corporations donât care about how much productivity they waste as long as they can hire enough coders. Scala may never have any USP for corporations. But a stuck-in-the-mud minuscule developer pool is not helping.
If you truly believed the situation were that dire, youâd absolutely oppose this. This change was done with only token feedback from the community and has been repeatedly received pushback - not only from those like myself who think itâs a categorically a bad idea, but also from those who think the idea is good and the implementation needs work.
The only thing worse than declining to make a move because of fear, is racing after a gut feeling that lacks that data to support the hypothesis that itâll gain more developers than itâll lose.
How is that you misunderstood what I wrote? If I have to write the code with braces initially that defeats the point doesnât it. You are agreeing with me (that if I accept your assertion) that if I write the code braceless, then I can not be guaranteed of a fidelity translation to braced.
Where is your data? Python has 30% market share. Scala has 0.63%. It is worth a try. And nobody who needs Scalaâs unique features is leaving. If they do not need the unique features, then they were probably not staying anyway. If you need Scalaâs unique features, you will not leave after all.
This appears to be the point of confusion. You can currently enable a setting in IntelliJ that automatically inserts braces when you hit Enter, if it thinks youâll need it. So if IntelliJ is right often enough for you, then you can mostly write without having to worry about braces, other than occasionally flagging the ones youâd like to see.
On the other hand, trying to add back in braces where none exist will end up adding them in a bunch of places they arenât actually needed, and we lose the pleasant middle ground that we enjoyed in Scala 2.
Nobody is forcing you to use braceless. Curly brace style is still available. But you are trying to force everyone else in the entire world to use your preferred style for coding Scala. Shouldnât we be more tolerant of each other?
I would be happy if the Scala libraries would still be written in curly braces so you would be entirely appeased.
Just let me have braceless for my code which you will never need to read.
Strident phrasing like that used aboveâlikening an institution of imprisonment, torture, and death to a statement that a particular language construct feels particularly awkwardâdoes a lot more to create animosity than does the original discussion of preferences for language features.
I am very much a supporter of simple and regular rules. I almost invariably argue for this. However, within the bounds of such regularities there is room for some degree of aesthetic preference, and itâs necessary to be able to discuss these things in a way that admits conveyance of the degree of oneâs preference.
The problem with the end map idea is not the regularityâalthough it does have a regularity problem with multiple parameter listsâbut that end map seems like it ought to end a statement, not be in the middle of of a fluent chain. Iâm totally fine with the idea of end map.
But Iâm not very fine with the idea of end markers followed by .. The precedence of associativity feels wrong, and the overall flow feels wrong. And, for regularity, you must absolutely also allow
if true then
"cod"
else
"salmon"
end if
.length
and
Option("hi") match
case Some(s) => s
case _ => "bye"
end match
.length
If you donât, then the end map thing feels like an exception, even if you can make a more complicated set of rules that admits it but not the above.
My statement was addressing your and othersâ religious pushback against having two optional styles. Your attempt to paint me in a bad light by juxtaposing a strident statement against a more benign but incorrect characterization of the position I was responding to, is disingenuous. You (and another) are/were indeed advocating a position where there should be no tolerance and instead only one style shall be allowed:
Also I bet you only work on your own code, because you told in the past what you usually use Scala for.
Moving onâŚ
I agree, except I also donât like the end markers in any case. I was already composing a reply to @sjrd about that.
You offered yourself that there should be simple rules, but more variants styles make for more rules. This is inherently contradictoryâresolvable, as goals are often in conflict, but the resolution isnât apparent.
Furthermore, I was pointing out the necessary consequence of the statements you made yourself in trying to defend your position. My point was that you had made a dubious argument. Your quote doesnât show âno toleranceâ; it shows that you have incorrectly described the potential drawbacks of having multiple options.
That is: people have to work with the variants.
If tooling can overcome the differences so theyâre hidden, that could possibly be okay, but I havenât ever seen that be remotely workable. People post code snippets in discord, in text editors, in screenshots, etc.; you can favor your style via adopting tooling that helps hide the other stuff from you and/or convert it, but you canât avoid substantial exposure.
Anyway, even if I had said that absolutely only one variation was acceptable under any circumstances, your parallel still would have been a sizable rhetorical escalation.
Iâll try to restrain myself from saying any more, as this is getting too far off topic.
The main technical point is that variations increase complexity, so theyâd really better be worth it; and a secondary point is that although there is a potential to use tooling to help people use their favored flavor, itâs an imperfect fix.
I think Scala wonât die because the venerable Odersky and his academic team wonât let it die. But it has of late been ostensibly languishing in no-mans land going no where of significance (other than possibly influencing other languages as a research language which was one of its stated raison dâetre) with the exception of Scala.js which seemed to be a significant infusion of interest.
Thus there is nearly no risk to the downside of any design change Scala attempts because there is no significant developer pool at-risk. Itâs all upside, so might as well swing for the fences. I believe you entirely (and frankly it appears to probably be intentional disingenuous) mischaracterize the situation and the risks. I surmise that Odersky is merely being polite by explaining and then ignoring beyond explaining instead of saying âgtfo if you donât like itâ. Because he is tasked with trying to elevate Scala from a small entrenched group of intransigent, fickle, highly controlling, inflexible users to a tool that young junior developers will embrace in droves. Heck many of you (e.g. @Ichoran) hate typeclasses which is one of Scalaâs essential features not possessed by any of its competitors (and I wish we could add Go as one of the competitors with a 3rd compile target to further expand Scalaâs market share).
I hope Odersky reads my suggestion in this thread to adopt a simpler rule for the braceless indenting.
In my opinion the braceless indenting (Python-like) syntax is intended to onboard junior developers and thus minimizing complexity should be the paramount objective. A major complaint against Scala has been unnecessary complexity.
I urge Odersky to minimize complexity (special cases) and regularize as much as possible, so we can conserve the complexity budget for those very unique features of Scala such as type classes and implicit resolution.
I was arguing for simpler rules for the implementation of the braceless style. You responded as if someone was stabbing you in the back, claiming that having two optional styles meant you could only work on your own code.
Then you tried to paint me in a bad light while trying to not acknowledge the ridiculous claim you had made which caused me to respond in kind. Now youâre trying to âbacksplain away your dubious and highly dramatic assertion, by moving the goal posts. And trying to claim some higher ethical ground. In all my interactions with you, you are the master of passive aggressive tactics which are clearly on display again here.
The claimed inability to read well written (not badly coded spaghetti code) braceless are not credible. The protagonists overplayed their hand with drama, FUD and a Parade of Horribles.
Besides thereâs no huge pool of developers coding in large groups right now with the extant style that we are in danger of losing. Probably just a few highly vocal curmudgeons who program solo anyway (which theyâre not transparent about), trying to retard any experimentation that might have the potential to elevate Scala out of the cellar it is mired in.
Also the protagonists are overplaying their hand as to the extent of code written by others in the style they loathe which they will be forced to try to read. There may be some, but probably only a fraction of the code they read on a daily basis. They are overstating the potential harm to themselves.
Maybe the tooling will be a few months or up to year behind (e.g. different colors for vertical traces of blocks) and maybe the Scala libraries wonât be held back in curly brace style in the interim to accommodate, but the curly braces folks will survive either way. Letâs hope they can be better accommodated. I would bend over backwards to try to minimize the impact on those who prefer curly braces but selfish disingenuous manipulation dissolves some of my illusion that weâre all sincere and unselfishly working together for a common goal.
As if I was only replying to you. My reply was a pushback against all of those who are overplaying their hand in trying to prevent braceless from being an option in Scala. Nevertheless you did explicitly say you would only be able to code by yourselfâwhich is apparently what you mostly do anyway, lol. Thus entirely handicapped entirely because of the extreme power of an optional braceless syntax and I guess because the handcuffs are included at no extra charge?
For those cases of snippets shared outside of tooling, will that be substantial exposure to massive spaghetti code that makes braceless hard to read? Or substantial exposure to small snippets which others (including I think yourself) have admitted they find the braceless style is an improvement?
For me spaghetti code is difficult to read whether it be braced or not. Arguing in the context of the idiosyncratic cases is not germane. Bad code is bad. Itâs unwise to expend our design and complexity budget trying to accommodate bad code to make it less bad, at the cost of major design wins that could elevate the entire ecosystem.
Ideally there should be a clean break between braceless and braced, so then thereâs really no additionally complexity in that each camp reads the style they prefer to read. The only complexity in that ideal is only introduced when there are shared libraries. Perhaps the Scala libraries should be offered in both styles as one of the costs of offering both styles in the compiler, so that they can claim they have genuinely maintained official support for both styles. I donât think it is reasonable to force the Scala team to code the compiler in both styles, as anyone who is senior enough to understand the compiler design is going to be able to read both styles and I wonât find credible any claim to the contrary (maybe there is the ultra-rare exception but that wouldnât be statistically relevant worthy of consideration anyway).
The rub though is that we are realizing in this discussion that certain Scala features donât play well with braceless style, specifically the blocks as function parameters such as lambdas and Unit. And some of those cases are probably going to work better as mixing braces with braceless, thus the clean break is lost in those cases. If I understood Odersky correctly it seems he is taking the Steve Jobsâ meme (âdonât hold the iPhone that wayâ) of donât create those multiple block parameters per function. Multiple blocks as function parameters are actually a very messy programming paradigm, so I think I tend to agree with Odersky if that is his stance. To make Scala more accessible (reduce that complexity) we should avoid these abstruse and fugly constructs. Itâs in the hands of library designers to create more beautiful APIs and make Scala more palatable among junior developers a la Python.
If the goal is achieved then braceless is removing complexity for junior developers coming from Python, not adding it as you claim. In other words there may be a push underway to make Scala more palatable and less abstruse. If that is the case then I am applauding. But letâs keep typeclasses as that is a killer app of Scala, even if some of you donât use it and donât think so. That is a discussion not for this thread though.
Born and razed (literally by flame throwing Zulus) in New Orleans to the ripe age of 15.
The coding Gods are good and wise. Yet we do need to be aware of introducing unnecessary complexity in the design of the braceless blocks. Please review my stance on your current design which I think adds unnecessary complexity. The braceless option is supposed to maximize consistency. I urge you to discard trying to be accommodate variable spacing which admits other sorts of bugs and prevents line continuations. Standardize on 3 spaces please as it will fit best the overriding goal of the braceless option.
Not on my desktop display unless I rotate my screen and I still think I have excess horizontal space if rotated. Do you actually program on a mobile phone or tablet device? Or some 3:2 aspect ratio small laptop such as the Surface? Anyway the curly brace style still available to you.
Another benefit of enforced indenting is consistency of formatting. I am not yet clear if Scala (havenât played with version 3 yet) is enforcing the indent spacing but I donât understand how it can distinguish and achieve line continuations without hardcoding the indentation spacing?
I am not privy to the motivation of those who pushed this new feature successfully into Scala against the wishes of some vocal members in the community. Iâm presuming that Scala needs an infusion of junior developers and more onboarding of a developer pool and itâs obvious that Python sits at the top of developer market share at 30% and probably even higher than that if measured by the youthful demographic. So making Scala look more like Python might possibly pay huge dividends in the area where Scala is current the weakest. So maybe we need to look outside the tunnel vision of a myopic focus on how it affects the extant ecosystem and what could be the greater ramifications at-scale. Recognizing the supreme importance of scaling is what elevated Steve Jobs and Elon Musk. Jobs personally recruited and hired my former boss (Mark Zimmer) and he shot down one of my bosses ideas, âit wonât scale.â Great coders may not have great business acumen so let us be circumspect as to the limits of our (e.g. your) individual talents (and admirable analysis) as admirable as they may be in their own right.
Iâm against the proposal for end markers. Braces could replace any need for end markers where an explicit end marker is desired. Why introduce a third syntax for such a dubious gain and which @Ichoran has already pointed doesnât generalize intelligibly? We are proliferating syntax which is adding complexity. The braceless syntax should be kept as simplistic as possible without extra ornamentation attempting to outsmart Pythonâjust be Python with static typing and hit the sweet spot instead of yet another case of Scala shooting itself in the feet by trying to be too clever. When we simpletons in the braceless bliss need to punt from our warm, flannel braceless universe, then to braces it is (to meet up with the mean and lean Scala genesis) and nothing else. Please donât proliferate as that has been the bane of Scala in the past. Please learn from past mistakes.
Also the IDE could do all of that you state for end markers without the pleonastic clutter, except the (quite unnecessary and ridiculous as we canât build seat belts for everything in programming) secondary check. I hope these regrettable end markers are optional (and preferably deprecated into the trashbin asap). I would probably chose to never subject myself to such pointless make-work.
Ostensibly the variability has a purpose of making Scala more palatable for the mainstream junior developers that rave all over Python?
Welcome back to the Scala world. Iâm happy that the language has made enough appealing changes to draw you back in.
That said, you have jumped in with a very confrontational style that has steered this topic in a (personally) off-putting direction.
âThus there is nearly no risk to the downside of any design change Scala attempts because there is no significant developer pool at-risk.â
My career, colleagues, and community take exception to this. Just because you havenât been participating does not mean that this entire realm is not significant.
Youâve made your positions about whitespace abundantly clear, and now we can wait for more input from others in this space.
That is in refutation to the argument that there will be a mass exodus of large companies from Scala due to offering an optional braceless syntax (and note I qualified my statement with ânearlyâ meaning obviously not advocating shooting ourselves in the feet and why if your sincere objective is productive discussion would you reach for such a âfootlooseâ interpretation?), because large companies have already written off Scala due to the small developer pool. I think it was obvious I was not speaking about small companies because even my protagonist wrote that Scala would revert to small companies and I am pointing out there is no reverting involved.
Actually incorrect synopsis. I jumped in with an attempt to find a happy compromise and mutual understanding but the protagonists slapped down my olive leaf with a dump truck load of (seemingly intentionally disingenuous?) FUD. Overplaying their hand with scare tactics and victimization pleas which have no basis in reasonable appraisals of the reality.
How about being genuine and donât patronize me. I have a spike to maximum on my neurotypical perception. If you really want to welcome me then please be honest and fair with your appraisal. If you want to criticize me then spare me the passive aggressive pretension please. I am more than willing to be friendly with sane individuals who speak honestly and forthrightly.
Why are you criticizing me for responding to those who responded to me as if that means I am overposting when there were responses needed. Did I prevent anyone from posting? I had completed my responses 5 hours before you posted.
If youâre sincere about productive discussion please direct your comments to my salient points. You didnât address a single one of my points genuinely. I decline your fact-free ad hominem as it is entirely off topic and not even accurate nor astute.
I will continue to engage in productive, honest discussion with those who wish to do so. I invite you to join. I so far found my replies to for example @sjrd to be an honest and productive exchange, although he hasnât yet made any response to my thoughts. Not that heâs obligated to. I posited a possible reason for the leap to two styles and my opinion of the value. I donât find any acrimony nor confrontation attitude in my response to his points.
Just go ahead and ban me if it is going to be like this where snipers come malign my genuine attempt to have a productive dialogue that helps Scala. I had already offered a specific proposal for simplifying the braceless parsing rule. Would be par for the course if I were banned when trying to be productive.
(@Ichoran and I should recuse ourselves from interacting here.)
Iâm still trying to wrap my mind around this. So as best as I can ascertain thus far that what you are implying to me that a block can be created in the Scala AST without using braces to delimit it? And there are cases where braces can be use to create something which is not a block in the Scala AST? So the brace has been overloaded in Scala syntax to create multiple things in the AST? And thus yet another example of the irregularity of Scala that makes it such an abstruse language and thus such a small developer pool.
I dispute your math. The potential of new junior developers coming from Python to Scala could possible be an order-of-magnitude more than the existing pool of Scala developers. Also you seem to not be that enthusiastic about type classesâ ditto @Ichoran. So I am getting this idea that maybe many of the small pool of extant developers arenât even really that tied to unique Scala features and probably originate from Scalaâs OOP legacy which is gradually being deprecated to a unique-selling-point (USP) which Scala has which Kotlin and all the rest donât have. Type classes are amazing for refactoring code and as a partial solution to Wadlerâs Expression Problem especially when combined with the new anonymous unions.
Yet you can still code with braced in Scala. And nobody will be forcing you to read my code. If you had only argued for keeping a copy of the official libraries in both braceless and braced I would have been on your side as a reasonable request. If you had argued for faster implementation of multi-colored vertical traces of blocks in the IDE, I would be your ardent supporter. But by now I have figured out that you do not want to be reasonable. You are making your best attempt to entirely obstruct progress and overvalue the gullibility of people who fail to see how out-of-touch with reality your claims of doom and harm are. Your lack of awareness of how your claims play out socially and their actual weight in the real world is almost like your autisticâ oh wait you are.
Ftfy. Hyperbole. That is a highly exaggerated claim.