On braces and indentation-based syntax

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.

1 Like

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.

That is not my definition of writing braceless code. That is some annoying tool interfering with my rapid coding.

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.

1 Like

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.

2 Likes

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.

Build that strawman.

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.

:pray: 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?

@shelby3

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.

11 Likes

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.

On behalf of the moderation team, we are closing this thread because multiple posts have violated the Scala Code of Conduct.

13 Likes