Skip to main content

Martin Odersky's thoughts on "Lean Scala"

What do you think? #Scala

odersky.github.io/blog/2024-04…

Lean Scala

Program code is for communicating between humans, not just for instructing computers. So we strive for code to be lean. Lean code is simple and understandable. It is as concise as possible without losing clarity.
Martin Odersky (Language and Code)
#scala
This entry was edited (7 months ago)
in reply to Alex Nedelcu

Daniel Spiewak
Daniel Spiewak
• •
I mean… there are fundamental technical challenges with the style he is advocating. It isn't just a subjective, aesthetic question. I have yet to see him acknowledge these challenges or put forward an opinion on how they can be addressed, much less make a real argument that the resulting situation is preferable to the one we're in today.
in reply to Daniel Spiewak

Alex Nedelcu
Alex Nedelcu
• •

are these concerns expressed somewhere? I may know what you mean, but want to be sure.

From my pov, Scala is a hybrid and it will always have an imperative side. And right now the standard is s.c.Future. Due to how we work with interruption in CE, I actually prefer to wrap Java APIs instead of ones working with Scala's Future. A standard solution for the imperative side would be preferable to the status quo, IMO. But then again, this takes focus away from monads.

in reply to Alex Nedelcu

fanf42
fanf42
• •
iirc, it was discussed at length in an difficult thread leading to jdg saying he stood back from his herald position of Scala voice or something like that. The corresponding blog post is from 2023-05-13, so perhaps looking what thread was hot one year ago on contributors.scala-lang.org (likely) with these proponents would lead to what you are looking for

Scala Contributors

for Scala contributions, language evolution discussions, standard library evolution discussions, and so on
Scala Contributors
in reply to fanf42

Daniel Spiewak
Daniel Spiewak
• •
I also discussed it at length in a thread on this platform quite a while back. Can’t remember off hand, but basically it boils down to the fact that due to lack of language support, direct style offers no way of creating a user space data structure approximating a coroutine with any real granularity, nor does it offer a graceful path into higher-order control structures when they are useful.
in reply to Daniel Spiewak

Daniel Spiewak
Daniel Spiewak
• •
The various “direct syntax on monads” libraries do make this possible, but due to lack of language support they tend to have really rough edges. Making this technique first class (and further refining it) would essentially make everyone happy and avoid torpedoing Scala’s most industrially successful ecosystems, but that argument has been made and rejected.
⇧