4 ms·

Beautiful semi-obituary + personal impact report. Odersky has done very impressive work (I only recently learned about his work on TurboModula-2 - cool!), but

by jll29 3y ago

Beautiful semi-obituary + personal impact report. Odersky has done very impressive work (I only recently learned about his work on TurboModula-2 - cool!), but his work is not focused on simplicity as Wirth's was - I wonder if he tried hard to adopt Wirth's simplicity mantra or not (given how he praises it in the article)? Scala's type system is quite complicated, for instance, and the notion of "object-functional" itself, as a hybrid concept, lacks simplicity.

zokier 3y ago
Yeah, I too found the praise for Wirthian ideals funny in the context of Scala. But on the other hand I believe Scala 3 did clean up lot of things, so maybe there is still something there?
pohl 3y ago
Interoperating with Java was a requirement. That immediately takes simplicity off the table if the goal is to bring FP to the JVM.
- macintux 3y ago
  Admittedly this is from a distance, having only toyed a bit with each, but Clojure always seemed much simpler than Scala.
  - pohl 3y ago
    That follows from Clojure being dynamically typed, though. Different design constraints lead to different results.
- bigbillheck 3y ago
  Why's that?
  - switchbak 3y ago
    Types interop on a VM that wasn't designed for a more complex one like Scala has. Collections interop between Java<->Scala. Scala's (immutable/mutable) collections are not built on the Java ones, and they provide helpers to translate between the two. Calling conventions, name mangling, Java to Scala issues, etc.
    - fulafel 3y ago
      FP doesn't need complex type systems though. And there's not a lot of type stuff on the JVM level, it's more dynamic than you'd think.
      - switchbak 3y ago
        I’m not defending Scala design just describing the interop challenges given said design. Scala was certainly envisioned with a strong type system in mind. The JVM doesn’t mandate mandate that, true, but the compiler they wrote did.
deleted 3y ago
[deleted]
Nullabillity 3y ago
Scala has accumulated a lot of cruft on its own over the years and it hasn't always succeeded, but at the same time I'd say that a core value has always seemed to be trying to unify Java's weird special cases ("why does every class member have to support being static, instead of just supporting first-class singletons?", "why are primitive types not part of the type hierarchy?", "why null?", or even "why are some type conversions hard-coded in the compiler?").
- n_plus_1_acc 3y ago
  They cleaned up a lot of warts (like implicits) with scala 3
  - _a_a_a_ 3y ago
    I don't think implicit's were a wart, and AFAIK in Scala 3 implicits effectively still exist but with a different syntax (but not touched it for a while, so may be wrong)
    - agrounds 3y ago
      Scala 2’s implicits have been a source of great pain in many Scala codebases at many different organizations. They are too powerful. The situation is comparable to languages that depend on gotos instead of structured control flow elements (for/while loops, if statements, function/subroutine calls). I can’t speak for Scala 3 as I haven’t used it at all. If they’ve limited the power of implicits to a few more structures usages it would be a great benefit to the language.
      - _a_a_a_ 3y ago
        Too powerful? Or just ab/mis-used?
      - sideeffffect 3y ago
        In Scala 3, implicits live on under a different name. They're called _given_s. But they're reduced to just one use case: propagating a context through (and deriving one given form others). And Type Classes are subsumed under this use case. The other use cases have been essentially removed: * Extension methods are now its own feature, relying on completely different mechanism * Automatic conversions have been severely curbed and de-emphasized, although they are still there, but much more explicit
sideeffffect 3y ago
> [Odersky's] work is not focused on simplicity as Wirth's was - I wonder if he tried hard to adopt Wirth's simplicity mantra or not I would beg to differ. I think he's very much aiming at simplicity. Btw, the essence of Scala really is simple. Take for example DOT (Dependent Object Types is the theoretical calculus Scala is based on), it is simple https://www.scala-lang.org/blog/2016/02/03/essence-of-scala.html https://www.scala-lang.org/blog/2016/02/03/essence-of-scala.... as video https://www.youtube.com/watch?v=bZEWNKzhBoU https://www.youtube.com/watch?v=bZEWNKzhBoU Or take his emphasis on simplicity in practical software engineering: https://www.youtube.com/watch?v=-qf8yteuxPs&pp=ygUObWFydGluIG9kZXJza3k%3D https://www.youtube.com/watch?v=-qf8yteuxPs&pp=ygUObWFydGluI... Than there is the question of practical concerns with Scala, like fitting onto the JVM, interoperability with Java, superficial features for programmer comfort (or lack thereof) and the tendency of some people to use the most powerful features for the simplest of problems that inevitably lead to messy codebases. And that certainly makes things complicated. > the notion of "object-functional" itself, as a hybrid concept, lacks simplicity I think this is misunderstanding about what Scala is all about. Scala is not supposed to be 50% functional and 50% object-oriented. It's supposed to be both 100% functional and 100% object-oriented (aka having powerful module system) _at the same time_. It's supposed to be a concrete proof that this dichotomy (FP vs OOP) is false and you can have both in the same language with the same features. This is contrary to other languages which may have support for FP and OOP but have _separate_ support for each, like SML, OCaml or F#. Scala is in this tradition, but different, it supports FP and OOP with one set of features. And from this point of view it is _simpler_. Whether people find it _easy_ is another question.
- jll29 3y ago
  > It's supposed to be both 100% functional and 100% object-oriented (aka having powerful module system) _at the same time_. That is well said, and I agree. And it certainly is an acomplishment, it's even in some way elegant, but I would not call it "simple". Simple is a compiler book in less than 100 pages that _also_ includes the full source code of a compiler that can compile itself, or a language the syntax graphs of which fit on a single paper page of ordinary size. Odersky saw that to make impact, you need to interact with an existing, large library ecosystem instead of "build it all yourself", so I'd say he is a realist-pragmatist whereas Wirth was a practicising (self-made) idealist-minimalist. I think I will get out my old MODULA-2 book in honour of Wirth again and play with GNU Modula-2 a bit, let's see how that feels after 24 years of C++/Java/Python in-between.

by jll29 3y ago

zokier 3y ago

Yeah, I too found the praise for Wirthian ideals funny in the context of Scala. But on the other hand I believe Scala 3 did clean up lot of things, so maybe there is still something there?

pohl 3y ago

Interoperating with Java was a requirement. That immediately takes simplicity off the table if the goal is to bring FP to the JVM.

macintux 3y ago
Admittedly this is from a distance, having only toyed a bit with each, but Clojure always seemed much simpler than Scala.
- pohl 3y ago
  That follows from Clojure being dynamically typed, though. Different design constraints lead to different results.
bigbillheck 3y ago
Why's that?
- switchbak 3y ago
  Types interop on a VM that wasn't designed for a more complex one like Scala has. Collections interop between Java<->Scala. Scala's (immutable/mutable) collections are not built on the Java ones, and they provide helpers to translate between the two. Calling conventions, name mangling, Java to Scala issues, etc.
  - fulafel 3y ago
    FP doesn't need complex type systems though. And there's not a lot of type stuff on the JVM level, it's more dynamic than you'd think.
    - switchbak 3y ago
      I’m not defending Scala design just describing the interop challenges given said design. Scala was certainly envisioned with a strong type system in mind. The JVM doesn’t mandate mandate that, true, but the compiler they wrote did.

deleted 3y ago

[deleted]

Nullabillity 3y ago

Scala has accumulated a lot of cruft on its own over the years and it hasn't always succeeded, but at the same time I'd say that a core value has always seemed to be trying to unify Java's weird special cases ("why does every class member have to support being static, instead of just supporting first-class singletons?", "why are primitive types not part of the type hierarchy?", "why null?", or even "why are some type conversions hard-coded in the compiler?").

n_plus_1_acc 3y ago
They cleaned up a lot of warts (like implicits) with scala 3
- _a_a_a_ 3y ago
  I don't think implicit's were a wart, and AFAIK in Scala 3 implicits effectively still exist but with a different syntax (but not touched it for a while, so may be wrong)
  - agrounds 3y ago
    Scala 2’s implicits have been a source of great pain in many Scala codebases at many different organizations. They are too powerful. The situation is comparable to languages that depend on gotos instead of structured control flow elements (for/while loops, if statements, function/subroutine calls). I can’t speak for Scala 3 as I haven’t used it at all. If they’ve limited the power of implicits to a few more structures usages it would be a great benefit to the language.
    - _a_a_a_ 3y ago
      Too powerful? Or just ab/mis-used?
    - sideeffffect 3y ago
      In Scala 3, implicits live on under a different name. They're called _given_s. But they're reduced to just one use case: propagating a context through (and deriving one given form others). And Type Classes are subsumed under this use case. The other use cases have been essentially removed: * Extension methods are now its own feature, relying on completely different mechanism * Automatic conversions have been severely curbed and de-emphasized, although they are still there, but much more explicit

sideeffffect 3y ago

> [Odersky's] work is not focused on simplicity as Wirth's was - I wonder if he tried hard to adopt Wirth's simplicity mantra or not I would beg to differ. I think he's very much aiming at simplicity. Btw, the essence of Scala really is simple. Take for example DOT (Dependent Object Types is the theoretical calculus Scala is based on), it is simple https://www.scala-lang.org/blog/2016/02/03/essence-of-scala.html https://www.scala-lang.org/blog/2016/02/03/essence-of-scala.... as video https://www.youtube.com/watch?v=bZEWNKzhBoU https://www.youtube.com/watch?v=bZEWNKzhBoU Or take his emphasis on simplicity in practical software engineering: https://www.youtube.com/watch?v=-qf8yteuxPs&pp=ygUObWFydGluIG9kZXJza3k%3D https://www.youtube.com/watch?v=-qf8yteuxPs&pp=ygUObWFydGluI... Than there is the question of practical concerns with Scala, like fitting onto the JVM, interoperability with Java, superficial features for programmer comfort (or lack thereof) and the tendency of some people to use the most powerful features for the simplest of problems that inevitably lead to messy codebases. And that certainly makes things complicated. > the notion of "object-functional" itself, as a hybrid concept, lacks simplicity I think this is misunderstanding about what Scala is all about. Scala is not supposed to be 50% functional and 50% object-oriented. It's supposed to be both 100% functional and 100% object-oriented (aka having powerful module system) _at the same time_. It's supposed to be a concrete proof that this dichotomy (FP vs OOP) is false and you can have both in the same language with the same features. This is contrary to other languages which may have support for FP and OOP but have _separate_ support for each, like SML, OCaml or F#. Scala is in this tradition, but different, it supports FP and OOP with one set of features. And from this point of view it is _simpler_. Whether people find it _easy_ is another question.

jll29 3y ago
> It's supposed to be both 100% functional and 100% object-oriented (aka having powerful module system) _at the same time_. That is well said, and I agree. And it certainly is an acomplishment, it's even in some way elegant, but I would not call it "simple". Simple is a compiler book in less than 100 pages that _also_ includes the full source code of a compiler that can compile itself, or a language the syntax graphs of which fit on a single paper page of ordinary size. Odersky saw that to make impact, you need to interact with an existing, large library ecosystem instead of "build it all yourself", so I'd say he is a realist-pragmatist whereas Wirth was a practicising (self-made) idealist-minimalist. I think I will get out my old MODULA-2 book in honour of Wirth again and play with GNU Modula-2 a bit, let's see how that feels after 24 years of C++/Java/Python in-between.