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?