The Origins of Scala (2009)
41–50 of 97 posts
Re: The Origins of Scala (2009)
#42Scala is a great language, and functional programming (not pure functional) made me a much better programmer. And functional error handling is a fantastic way to model success and failure, whether you’re using Either or the newer Result type. I have to both agree and disagree with some of the commenters here regarding why scala declined in usage. There are several reasons. 1. People just got fed up with the push towa…
Amen. My eyes start to glaze over whenever I read about covariance.
It's one thing if a feature works because of category theory, but if you just "feel like arrays should be covariant", and then the actual category theorists come along and can't work with its limitations, maybe give it a miss.
Re: The Origins of Scala (2009)
#43Have error messages improved? I remember trying it few years back but the error messages made it hard to debug. Is it due to use of JVM? Sorry for my lack of knowledge since I rarely program in JVM based languages.
Re: The Origins of Scala (2009)
#44Earlier quoted context omitted.
They really obliterated their momentum with how they went about Scala 3, unfortunately.
Why is that? I think they did a lot of things right. Offer automatic conversions, backwards and forwards compatibility from a sufficiently recent 12.x version. I think mostly Kotlin being simpler and Java gaining features ate the lunch. Also, software like Akka and Spark becoming less prevalent hurt because they were big reasons for devs to learn the language. Not to mention the community drama. The only bad thing wa…
Macros were an experimental Scala 2 feature, but were used all over the Scala ecosystem. Because they were considered experimental a good migration story for them was never developed. That lack of support stopped migration efforts dead in their tracks at our company for a long while. It just wasn't worth contributing simultaneous support for Scala 3 and Scala 2 macros to every third party dependency who used Scala 2 macros. That said, we did it for some and lived on a fork for others.
IDE support for Scala 3 was really rough when it first released. We checked in on it with every IntelliJ release for roughly 3 years before we decided it was far enough along. Prior to that it was rough enough that we froze migration efforts in order to keep the tooling usable enough for engineers to be productive.
Re: The Origins of Scala (2009)
#45Earlier quoted context omitted.
Every significant language became multi-paradigm these days, but you can do it intentionally, like Scala, or you can do it badly.
Python is multi paradigm, but does several things really well that other ecosystems do not. Javascript as well. Java as well. What claim to fame does Scala have in this regard, aside from being the best supported language for Spark for several years before PySpark overtook it? Perhaps Akka before the boneheaded decision to paywall that ecosystem?
Re: The Origins of Scala (2009)
#46It's interesting that Odersky started with Modula-2 (implementing a Z80 compiler), did a PhD with Wirth, but there discovered that functional programming offered a level of theoretical rigor and mathematical elegance he missed in Wirth's imperative languages. Wirth was generally critical of the complexity and abstraction often associated with functional languages. Rather than rejecting Wirth's pragmatism, he carried…
For me the right path is Oberon => Oberon-2 and Component Pascal => Zonnon and Active Oberon.
Yes, I know he wasn't directly evolved with those ones.
I see the several revisions of Oberon-07 as an entertaining exercise in minimalism, which fails to understand the industry.
Something that Niklaus Wirth complained about in his rant about Software Engineering, not understanding why Java and C++ and not Oberon won the hearts of companies.
I was fortunate to attend his Oberon session on Oberon Day at CERN, 20 years ago, while a genius programming language designer, expecting software engineers to recognise great design and naturally embracing it, was expecting too much.
Re: The Origins of Scala (2009)
#47Scala is a great language, and functional programming (not pure functional) made me a much better programmer. And functional error handling is a fantastic way to model success and failure, whether you’re using Either or the newer Result type. I have to both agree and disagree with some of the commenters here regarding why scala declined in usage. There are several reasons. 1. People just got fed up with the push towa…
1. There was never a push. Functional ecosystems are simply the ones that survived. You can't blame communities that keep the language alive for doing what they want, and not what you want. Without Typelevel and ZIO where would be Scala 3's adoption today? 2. Android has never been even remotely relevant to the space where Scala exists. And no, this was not a missed opportunity for the language. People who think Scal…
Kotlin would be irrelevant on the JVM space otherwise, only something being pushed by Jet Brains that some folks play with outside the company.
There would not exist a Kotlin Foundation which is basically Jet Brains in bed with Google.
I keep waiting for the announcement of Google's acquisition from Jet Brains.
Re: The Origins of Scala (2009)
#48Scala is a great language, and functional programming (not pure functional) made me a much better programmer. And functional error handling is a fantastic way to model success and failure, whether you’re using Either or the newer Result type. I have to both agree and disagree with some of the commenters here regarding why scala declined in usage. There are several reasons. 1. People just got fed up with the push towa…
1. There was never a push. Functional ecosystems are simply the ones that survived. You can't blame communities that keep the language alive for doing what they want, and not what you want. Without Typelevel and ZIO where would be Scala 3's adoption today? 2. Android has never been even remotely relevant to the space where Scala exists. And no, this was not a missed opportunity for the language. People who think Scal…
Kotlin is not simple at all, it has a lot of keywords for strange and very specific features and corner cases, it's hard to remember them all. Moreover, the Intellij Kotlin plugin is somehow slower than Scala's despite being a 1st party language and not having implicits, how they managed to achieve that is a mystery.
Re: The Origins of Scala (2009)
#49Earlier quoted context omitted.
Why is that? I think they did a lot of things right. Offer automatic conversions, backwards and forwards compatibility from a sufficiently recent 12.x version. I think mostly Kotlin being simpler and Java gaining features ate the lunch. Also, software like Akka and Spark becoming less prevalent hurt because they were big reasons for devs to learn the language. Not to mention the community drama. The only bad thing wa…
From my perspective the two biggest challenges of the Scala 3 migration were macros and poor tooling support. Macros were an experimental Scala 2 feature, but were used all over the Scala ecosystem. Because they were considered experimental a good migration story for them was never developed. That lack of support stopped migration efforts dead in their tracks at our company for a long while. It just wasn't worth cont…
Re: The Origins of Scala (2009)
#50It's interesting that Odersky started with Modula-2 (implementing a Z80 compiler), did a PhD with Wirth, but there discovered that functional programming offered a level of theoretical rigor and mathematical elegance he missed in Wirth's imperative languages. Wirth was generally critical of the complexity and abstraction often associated with functional languages. Rather than rejecting Wirth's pragmatism, he carried…
I can relate to Odersky, similar to him, while I appreciate Niklaus Wirth's work, I don't appreciate the quest to minimalism that he went down after Oberon. For me the right path is Oberon => Oberon-2 and Component Pascal => Zonnon and Active Oberon. Yes, I know he wasn't directly evolved with those ones. I see the several revisions of Oberon-07 as an entertaining exercise in minimalism, which fails to understand the…
> I see the several revisions of Oberon-07 as an entertaining exercise in minimalism, which fails to understand the industry.
His main motivation was to minimize the amount of work porting his original system to his own, FPGA based processor board. His fans interpreted the “new” language more as a new prophetic proclamation, but in reality it was only about the feasibility of his post-retirement hobby project. This became clear at the latest when people wanted to run a benchmark on the system and discovered that the compiler couldn’t generate such large binaries. There was simply a fixed maximum size, but for many years no one noticed this.
He has always positioned his languages for education and limited himself to the systems that can be realized with them. If his goal had been to meet the needs of industry, he would have acted differently. After a very brief foray to an industrial job in the sixties, he immediately returned to academia and hardly looked back.