On braces and indentation-based syntax

Language Design
19

FUD and your Parade of Horribles seems to have no effect on me whatsoever. Never took a single clot shot and begged everyone I knew with the killer exosome to please breath in my face and let me taste a sample of their sputum. Kept trying to get a positive test but the darn things don’t seem to correlate with reality—or at least the reality they purport to tell us.

Two religiously opposed companies would never be candidates for a merger regardless if that had chosen two coding styles of Scala, or Python (or my transpiler to braceless Scala) and braced Scala. You will not be able to prevent someone from creating a braceless Scala. Religiously opposed companies will not conform to any jail you intended to impose on them. Arguing for control you don’t possess is a fallacy. It is destiny and if you do not do it officially then you might end up with several different flavors of it which will be a worse outcome (the same point I made about unsigned types, better to embrace it officially and protected by a optional compiler flag because it has a performance penalty, than to not embrace it and end up with 31 flavors of unofficial libraries which is a much more discombobulated outcome). Bite the bullet because ultimately you have no choice and better to take the lead on it officially.

As for a Sr. Engineer he will choose the company that employs the coding style he prefers. I do not see any problem. Unless you are arguing he will need to read the Scala libraries and thus be turned off if they are not in his preferred style. But how many programmers have been turned off from Scala up to now because of the lack of a braceless style? Your argument may have not have any net effect either way. You lose some, you gain some. But for sure the ecosystem will grow because there are two coding styles available to make more people happy.

Personally I would have no objection if the Scala libraries would remain in curly brace style. For me the braceless style is more for the junior users who probably won’t be reading the libraries anyway. Although I am not junior and I will use braceless but I have no problem reading braced. I prefer the cleaner, more uniform braceless (might be my German ancestry, although I also have Welsh, Irish and Swiss-French-Italian)

They must not need Scala features much. Maybe this is a good filter for users who really need Scala and thus will be its most ardent supporters. I absolutely need type classes and anonymous unions, so Java is not an option for me regardless.

Also I think large companies don’t use Scala anyway, because they ostensibly prioritize breadth of the developer pool over esoteric, geek-cool features. Thus they would choose Java or Kotlin regardless. So the threat is probably mostly irrelevant. The braceless option may increase the number of junior Scala developers.

Maybe nobody uses it because Python can’t optionally compile curly brace code so all the curly brace aficionados departed?

I don’t understand why a tool can’t insert a brace deterministically where every braceless block is? If Odersky adopts my suggestion for the simple rule that every block begins on a 3 space indent, there is no ambiguity whatsoever about which are blocks. As for other optional cases which are not required to be blocks and were not explicitly marked as blocks in braceless code, I guess that is what the author intended, so maybe the translated result is correct as the author intended it? Curly braces can be mixed with braceless code.

No because previously the compiler would not compile my braceless code and the IDE did not understand it.

20

All spaghetti code is hard to read regardless. We should endeavor to write clear code without ridiculous levels of nesting. That is functions are for.

Braces don’t rescue me from bad coders.

21

This is unfortunate, as my concern is neither of these. Bifurcating the developer pool has never ended well, even for languages with a much larger mindshare than Scala currently enjoys. It was a decade of annoyance that Python is just barely managing to leave behind, and it was a significant factor in the implosion of the Perl community.

That’s … cute. C level execs don’t really care about the technical details of a company they’re looking to acquire, they care about retention, risk, and the cost of hiring. A company built on a Java stack won’t hesitate to acquire a company that’s running a Python stack (or vice versa) because either language is relatively easy to hire for and they expect the mindshare loss to be a Ship of Theseus situation.

They are going to be a bit less interested in picking up company that is built on a tech stack that relies on less familiar languages, and Scala currently still qualifies - but being a JVM language is helpful here because the CTO’s can reassure them that everything will still play nicely together.

They’re going to get really skittish if Scala develops a reputation as “the language with developers that tend to leave en-masse when acquired” - my intuition is that you’ll lose people a lot faster when a single commit can entirely rewrite the code in the disfavored style, rather than the slow process of porting existing software to an entirely new language, however this is untested intuition at the moment.

The problem is they’re already annoyingly difficult to hire for, so reducing the pool of interested candidates further is a Really Bad Idea.

It’s all nice-to-have stuff. There isn’t an algorithm in existence that can be implemented in Scala but not Java. It can be a lot easier, faster, and more pleasant to program in Scala, but let’s not delude ourselves here - if companies can’t reliably hire Scala devs that work well with the existing teams, they’re not going to use Scala. Splitting the developer pool is going to exacerbate this issue.

The issue here is that, once removed, the information about what braces were explicitly included is lost, so the round-trip code can end up looking very different.

You misunderstand, the braces would still be there, the hypothetical tooling you could write would just hide them in the IDE.

1 Like
22

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.

23

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
24

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.

25

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.

26

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.

27

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.

28

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.

30

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

31

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.

32

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
33

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.

34

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
35

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.

36

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?

37

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?

38

@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
39

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