4 ms·

For the unaware: Odersky himself is a “modern day Wirth”. Amazing language designer. He’s responsible for generics in Java and the Scala language.

nickpeterson 3y ago
It’s interesting that odersky helped put generics in Java and also made Scala. Don Syme helped put generics in .net, and then made F#. It feels like two people on a very similar trajectory.
- mjburgess 3y ago
  The question, "how do we make functional languages popular, (useful?) in the enterprise?" was a question in the air for, i'd, say decades. The 00s answer was to create a merger between enterprise langs (Java, C# etc.) and functional langs in a new language. The net result, as we know now, was to push those langs to adopt functional features -- rather than to shift to others. I suspect the question for the niche programming community, of the next decade, will be "how do we make effect systems popular?" or some such thing. Or, "how do we make AOT metaprogramming popular?" etc. (cf., jai, zig... carbon, circle, ...) I suspect if a post-C++ new-wave gets popular, with structural typing and ct metaprogramming, we might see the same in C# quite easily
  - pjmlp 3y ago
    You already get them with code generators and Rosylin, but it is a bit painful to use.
    - SideburnsOfDoom 3y ago
      There is also a new compiler feature, "interceptors" that swaps in calls at compile-time. https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-12#interceptors https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs... This looks very hard to use well, but that's because "it's not for you" to use directly in app code, rather it's a low-level building block for such AOT and code generation patterns and toolkits.
      - gfraiteur 3y ago
        Agreed. Roslyn analyzers, code generators, refactoring providers and other extension points are not designed for application developers but are rather building blocks. We built a code generation and analysis framework based on these Roslyn extension points. It's called Metalama: https://doc.postsharp.net/metalama https://doc.postsharp.net/metalama.
      - pjmlp 3y ago
        I hate it, as it is a bad approach to what should have been a proper AOP framework like PostSharp or Microsoft Fakes. Instead we will end with a special cased mini framework, designed to override reflection code for the purposes of AOT code generation. Something that AOT toolchains for Java have solved much better with agents, PGO and config files. From my point of view, it is neither a good approach to sort that out, nor a good AOP alternative.
- santiagobasulto 3y ago
  I didn't know Syme helped with generics in .net. Very interesting indeed. I think it makes sense for these people to create their own "perfect" languages. I'm not aware of C#, but I know (or knew) Java very well. And Generics always was a half-baked option for a broken language. From a purists' perspective, in Java "everything is an object", except ints or floats, but we have Integer or BigInt, but then we have `null`, but then... if Integer extends from Number, does that mean that a List<Integer> extends from List<Number>? Nobody knows... Those things are what I feel Odersky wanted to solve and couldn't with Java, so he went "Bender Style".
throwaway89988 3y ago
Sorry, but Odersky is nothing like Wirth. Scala failed hard because it is kitchen sink of every half baked feature someone wanted to write a PhD thesis about. The graphs of the interdependencies of the standard library are an excellent example of a totally insane design, the Scala data structures have been at least an order of magnitude slower than the JVM native ones. Don't get me started about the tooling, which is too slow for any real world projects. (The only ones I regularly see to use Emacs are Scala developers, because opening projects in an IDE like IDEA could take up to 30 min on high end workstations.) Wirth valued clean design, speed and simplicity. Odersky wants to compete with C++ for complexity. As the article stated, for Wirth a feature would have to pay for itself regarding complexity, speed and usability. If someone can demonstrate how Scalas features came to pay for themselves, I would appreciate a pointer. Finally... generics in Java are a shit show, thanks to type erasure. Fair enough, Odersky was probably forced for this implementation, thanks to backwards compatibility, still, nothing to be proud of.
- dragosiulian 3y ago
  > it is kitchen sink of every half baked feature someone wanted to write a PhD thesis about. Having been a PhD student in his lab between 2005-2010, I can attest that's not true. Language design was definitely Martin's prerogative. As a PhD student, a lot of time went into implementation efforts, and while several features did end up in PhD theses, the last word on what goes in the language was Martin's. Scala was ultimately a research project, with ambitions to succeed outside of academia. As such, some ideas worked better than others (pattern matching and case classes vs specialization). As it became clear that the language was picking up in the industry (lead by Twitter around 2008), many of these experiments moved into compiler plugins, macro libraries or research forks. > Sorry, but Odersky is nothing like Wirth. I haven't known Wirth to venture into such broad statements, but given what's been written about the way he lead his lab, I would say there were many similarities: a strong bias for solid implementation work, the (bootstrapping) compiler as a litmus test for features or performance work. And yes, a focus on simplicity. Unfortunately, simplicity is often confused with familiarity. What's simpler: having statement and expressions as separate concepts that don't mix well, or only expressions? Most people coming from C and Java would have internalized the dichotomy and find it (or at least, back in the day, found it) "complex" to think of every expression having a type ('void' vs 'Unit'). The same goes for the split between primitive and reference types vs a unified type hierarchy. This is not to say Scala doesn't have its warts, and implicits (in particular, implicit resolution rules) combined with macros could lead to a lot of pain. Hopefully there are lessons learned there and Scala 3 is better. > Scala failed hard Far from obvious. Databricks has probably upwards 10MLOC of Scala code, and seem to be doing very well (https://www.lihaoyi.com/post/TheDeathofHypeWhatsNextforScala.html#the-present-on-the-slope-of-enlightenment https://www.lihaoyi.com/post/TheDeathofHypeWhatsNextforScala...). Plenty other examples. Could Scala have been more successful? Undoubtedly. But it's far from a "hard failure". New languages have adopted many Scala features, so nowadays Scala is believed to pay for itself only when using pure-FP libraries. That's very unfortunate if you ask me, since I believe there's a pragmatic sweet spot that lies around the style best illustrated by Haoyi Li's ecosystem of libraries.
geodel 3y ago
So modern day Wirth is quite different from antiquity Wirth. Java generics are quite complex they have multi hundred pages books to explain it all. Scala a really clever language, perfect for 1 line code doing 50 line equivalent of Java code. Slow compile times and immature tooling is another important feature of Scala.
- kagakuninja 3y ago
  Current Scala compile times really aren't that bad. Yeah, Go will be 10x faster, but then you have to use Go... For a typical micro service, I never think about compile time, thanks to incremental compilation. Even a full compile is not bad. Tooling is also fine, although Scala 3 set things back. IntelliJ now supports Scala 3 adequately.
  - geodel 3y ago
    Well, its like one can always tolerate shortcomings when they like something/someone. Reasons can always be added later for liking something but rarely other way around.
    - kagakuninja 3y ago
      Look, I've been using Scala professionally for 8 years. I don't notice that my compile times are any slower than Java, although I haven't tried any meaningful comparison. There are some notorious libraries like Shapeless than can kill your compile times; the solution is to not do that, unless the trade off is worth it to you. It could be x1.2 slower, maybe even 2x, and I wouldn't notice it, because it is fast enough. IntelliJ has incremental compilation. Compile times only matter when I do a full rebuild, and it is still fast enough. If I had to build a giant mono-repo like at Google, then the compile speed of languages like Go become important.
jll29 3y ago
There was a language called Pizza that Odersky wrote while in Karlsruhe (before moving to EPFL Lausanne), and that became part of "standard" (not as in ISO, but as it SUN-approved) Java as "generics". https://en.wikipedia.org/wiki/Pizza_(programming_language) https://en.wikipedia.org/wiki/Pizza_(programming_language) https://www.reddit.com/r/scala/comments/8c7h8f/history_the_pizza_language_is_an_extension_to/ https://www.reddit.com/r/scala/comments/8c7h8f/history_the_p...

nickpeterson 3y ago

It’s interesting that odersky helped put generics in Java and also made Scala. Don Syme helped put generics in .net, and then made F#. It feels like two people on a very similar trajectory.

mjburgess 3y ago
The question, "how do we make functional languages popular, (useful?) in the enterprise?" was a question in the air for, i'd, say decades. The 00s answer was to create a merger between enterprise langs (Java, C# etc.) and functional langs in a new language. The net result, as we know now, was to push those langs to adopt functional features -- rather than to shift to others. I suspect the question for the niche programming community, of the next decade, will be "how do we make effect systems popular?" or some such thing. Or, "how do we make AOT metaprogramming popular?" etc. (cf., jai, zig... carbon, circle, ...) I suspect if a post-C++ new-wave gets popular, with structural typing and ct metaprogramming, we might see the same in C# quite easily
- pjmlp 3y ago
  You already get them with code generators and Rosylin, but it is a bit painful to use.
  - SideburnsOfDoom 3y ago
    There is also a new compiler feature, "interceptors" that swaps in calls at compile-time. https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-12#interceptors https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs... This looks very hard to use well, but that's because "it's not for you" to use directly in app code, rather it's a low-level building block for such AOT and code generation patterns and toolkits.
    - gfraiteur 3y ago
      Agreed. Roslyn analyzers, code generators, refactoring providers and other extension points are not designed for application developers but are rather building blocks. We built a code generation and analysis framework based on these Roslyn extension points. It's called Metalama: https://doc.postsharp.net/metalama https://doc.postsharp.net/metalama.
    - pjmlp 3y ago
      I hate it, as it is a bad approach to what should have been a proper AOP framework like PostSharp or Microsoft Fakes. Instead we will end with a special cased mini framework, designed to override reflection code for the purposes of AOT code generation. Something that AOT toolchains for Java have solved much better with agents, PGO and config files. From my point of view, it is neither a good approach to sort that out, nor a good AOP alternative.
santiagobasulto 3y ago
I didn't know Syme helped with generics in .net. Very interesting indeed. I think it makes sense for these people to create their own "perfect" languages. I'm not aware of C#, but I know (or knew) Java very well. And Generics always was a half-baked option for a broken language. From a purists' perspective, in Java "everything is an object", except ints or floats, but we have Integer or BigInt, but then we have `null`, but then... if Integer extends from Number, does that mean that a List<Integer> extends from List<Number>? Nobody knows... Those things are what I feel Odersky wanted to solve and couldn't with Java, so he went "Bender Style".

throwaway89988 3y ago

Sorry, but Odersky is nothing like Wirth. Scala failed hard because it is kitchen sink of every half baked feature someone wanted to write a PhD thesis about. The graphs of the interdependencies of the standard library are an excellent example of a totally insane design, the Scala data structures have been at least an order of magnitude slower than the JVM native ones. Don't get me started about the tooling, which is too slow for any real world projects. (The only ones I regularly see to use Emacs are Scala developers, because opening projects in an IDE like IDEA could take up to 30 min on high end workstations.) Wirth valued clean design, speed and simplicity. Odersky wants to compete with C++ for complexity. As the article stated, for Wirth a feature would have to pay for itself regarding complexity, speed and usability. If someone can demonstrate how Scalas features came to pay for themselves, I would appreciate a pointer. Finally... generics in Java are a shit show, thanks to type erasure. Fair enough, Odersky was probably forced for this implementation, thanks to backwards compatibility, still, nothing to be proud of.

dragosiulian 3y ago
> it is kitchen sink of every half baked feature someone wanted to write a PhD thesis about. Having been a PhD student in his lab between 2005-2010, I can attest that's not true. Language design was definitely Martin's prerogative. As a PhD student, a lot of time went into implementation efforts, and while several features did end up in PhD theses, the last word on what goes in the language was Martin's. Scala was ultimately a research project, with ambitions to succeed outside of academia. As such, some ideas worked better than others (pattern matching and case classes vs specialization). As it became clear that the language was picking up in the industry (lead by Twitter around 2008), many of these experiments moved into compiler plugins, macro libraries or research forks. > Sorry, but Odersky is nothing like Wirth. I haven't known Wirth to venture into such broad statements, but given what's been written about the way he lead his lab, I would say there were many similarities: a strong bias for solid implementation work, the (bootstrapping) compiler as a litmus test for features or performance work. And yes, a focus on simplicity. Unfortunately, simplicity is often confused with familiarity. What's simpler: having statement and expressions as separate concepts that don't mix well, or only expressions? Most people coming from C and Java would have internalized the dichotomy and find it (or at least, back in the day, found it) "complex" to think of every expression having a type ('void' vs 'Unit'). The same goes for the split between primitive and reference types vs a unified type hierarchy. This is not to say Scala doesn't have its warts, and implicits (in particular, implicit resolution rules) combined with macros could lead to a lot of pain. Hopefully there are lessons learned there and Scala 3 is better. > Scala failed hard Far from obvious. Databricks has probably upwards 10MLOC of Scala code, and seem to be doing very well (https://www.lihaoyi.com/post/TheDeathofHypeWhatsNextforScala.html#the-present-on-the-slope-of-enlightenment https://www.lihaoyi.com/post/TheDeathofHypeWhatsNextforScala...). Plenty other examples. Could Scala have been more successful? Undoubtedly. But it's far from a "hard failure". New languages have adopted many Scala features, so nowadays Scala is believed to pay for itself only when using pure-FP libraries. That's very unfortunate if you ask me, since I believe there's a pragmatic sweet spot that lies around the style best illustrated by Haoyi Li's ecosystem of libraries.

geodel 3y ago

So modern day Wirth is quite different from antiquity Wirth. Java generics are quite complex they have multi hundred pages books to explain it all. Scala a really clever language, perfect for 1 line code doing 50 line equivalent of Java code. Slow compile times and immature tooling is another important feature of Scala.

kagakuninja 3y ago
Current Scala compile times really aren't that bad. Yeah, Go will be 10x faster, but then you have to use Go... For a typical micro service, I never think about compile time, thanks to incremental compilation. Even a full compile is not bad. Tooling is also fine, although Scala 3 set things back. IntelliJ now supports Scala 3 adequately.
- geodel 3y ago
  Well, its like one can always tolerate shortcomings when they like something/someone. Reasons can always be added later for liking something but rarely other way around.
  - kagakuninja 3y ago
    Look, I've been using Scala professionally for 8 years. I don't notice that my compile times are any slower than Java, although I haven't tried any meaningful comparison. There are some notorious libraries like Shapeless than can kill your compile times; the solution is to not do that, unless the trade off is worth it to you. It could be x1.2 slower, maybe even 2x, and I wouldn't notice it, because it is fast enough. IntelliJ has incremental compilation. Compile times only matter when I do a full rebuild, and it is still fast enough. If I had to build a giant mono-repo like at Google, then the compile speed of languages like Go become important.

jll29 3y ago

There was a language called Pizza that Odersky wrote while in Karlsruhe (before moving to EPFL Lausanne), and that became part of "standard" (not as in ISO, but as it SUN-approved) Java as "generics". https://en.wikipedia.org/wiki/Pizza_(programming_language) https://en.wikipedia.org/wiki/Pizza_(programming_language) https://www.reddit.com/r/scala/comments/8c7h8f/history_the_pizza_language_is_an_extension_to/ https://www.reddit.com/r/scala/comments/8c7h8f/history_the_p...