The Origins of Scala (2009)
artima.com77 points by todsacerdoti 3 days ago
77 points by todsacerdoti 3 days ago
Scala was the second programming language I learned (the first was Java). I think I'm quite lucky to have picked up a language like Scala so early in my programming journey. It made it very easy for me to learn new programming languages, since it made it easy to support wildly different paradigms (which is also what makes it hard to use in an enterprise environment).
yeah, you get everything and the kitchen sink with Scala. Which is actually IMO its biggest weakness. It wants to be everything, and it isn't amazing at anything as a result.
That is why I actually like Scala. I want every tool to be available at my disposal, and I can choose what to use or not use. I want it to be reasonably succinct and type safe.
I don't want the language to dictate how I use it. I'd prefer the language not to look out for me. There might be some, but a lot of languages look out way too much. Golang for example doesn't allow you to compile if there is an unused var. Java with private as the default.
It is great that there is a production-ready language that differs from other languages.
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?
"Among the clients of the Spark runtime architecture, Scala is the most popular language, followed by Python and Java. According to a recent survey by Databricks, the company behind Apache Spark, 71% of respondents reported using Scala for Spark development, while Python was used by 24% and Java by 5%. Another survey by Typesafe on the Spark ecosystem revealed that 88% of respondents used Scala, 44% used Java, and 22% used Python, with the percentages reflecting multiple language usage. Scala is considered the most optimized language for Spark due to its integration with the JVM and its role as the language in which Spark was internally implemented, offering better performance and access to the latest features."
When is this from? I would be shocked if in 2025 most Spark was being written in Scala
August 2024 -- so, dated.. mea culpa https://moldstud.com/articles/p-what-programming-languages-a...
I think the info is even more outdated than that. The article is from August 2024 but it cites "a recent survey by Databricks" that from what I can tell isn't linked to, so who knows what data they're referring to.
I was deep into the big data ecosystem in the 2010s. Those numbers feel like they're from 2017 or so. Scala has been on a slide every since.
>> 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.
Both Perl and Ruby can be, and often are, used instead of Python to great success for similar concerns. IOW, the three are often Liskov substitutable[0].
> Javascript as well.
You're kidding, right?
> What claim to fame does Scala have in this regard ...
Scala supports declarative, generative, imperative, meta, and object-oriented paradigms. All of which are supported by at least, but not limited to, the JVM and JavaScript runtimes.
These capabilities transcend libraries (such as Akka) and/or frameworks (such as Spark).
0 - https://en.wikipedia.org/wiki/Liskov_substitution_principle
It'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 it forward by attempting to make functional programming "industry-ready".
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 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.
Minimalism is indeed the correct term (usually framed as simplicity) when looking at both, language and documentation. But at least it helped that there was always a working compiler and system, not a mere theory.
> 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.
One could argue that Modula-2 was an attempt to fix Pascal for the industry, after all the dialects that sprung out of it, which he wasn't keen on, with the influence from Mesa, after his sabbatical at Xerox.
Also that the way it failed to be embraced by the industry, too busy with UNIX, C and C++, also had an effect on his point of view going forward.
> One could argue that Modula-2 was an attempt to fix Pascal for the industry
There is no evidence that Wirth e.g. ever directly or specifically rebutted Kernighan's famous paper, nor that Modula-2 was a response to it. Modula-2 was a child of the ivory tower (PARC), not industry. Wirth was rather an "escapist" who built his own worlds rather than fixing the real one. He saw Parnas' concepts "in action" during his sabbatical at Xerox. He didn't create Modula-2 to help industry; he created it because he wanted to replicate the Alto workstation experience (which became the Lilith) for his own use and for his students at ETH. Wirth was a brilliant "synthesizer" of academic ideas (Parnas, Hoare, Mesa) who built beautiful, self-contained gardens for himself and his students. He was never the "industrial repairman" that later apologists tried to paint him as.
Why should he?
That paper was only relevant among UNIX people, and largely ignored by anyone doing 8 and 16 bit home computing with Pascal and Modula-2.
It is no accident that to this day, it is the UNIX accolades that keep bringing it back every couple of months, most of whom never used a single Pascal compiler in their lifes, or aware that Modula-2 was already around.
Modula-2 relevance as systems language is quite easy to find out in some of his essays, and the companies selling compilers for Acorn, Amiga and PC.
You said that "One could argue that Modula-2 was an attempt to fix Pascal for the industry". By 1981, the C/Unix team was no longer a "rogue research group" in a closet; they were the architects of the dominant industrial paradigm shift (with Apollo Computer, Sun Microsystems, Silicon Graphics, and even Microsoft all using Unix and C). That's why I mentioned it. Wirth didn't care because his concern wasn't industry. Pascal users helped themselves: e.g. Lisa Pascal essentially included all features from C, which according to Kernighan (who referred to Wirth's original Pascal, not the derivatives) were missing, and even a module and separate compilation concept (four years before Turbo Pascal); they could have used Modula-2, which was around at the time. While Modula-2 was hypothetically a "systems language", it lacked the pragmatic "dirty" features that C, Lisa Pascal, and Turbo Pascal embraced to actually build operating systems and drivers on commodity hardware (unless, again, they were added as an extension by the compiler vendors). E.g. Topspeed Modula supported inline assembly, Acorn Modula included extensions to call software interrupts directly with register mapping; almost all commercial vendors added extensions to bypass strict typing, or direct pointer increment/decrement to support C-style array traversal.
It is irritating that apparently C is fine having endless compiler extensions without which ISO C is equally unusable to implement an operating system[0], a sign of greatness, while the same argument is used to point out as design flaws when it isn't C we are talking about.
[0] - Unless helped by an external assembler, just like on the UNIX rewrite, when K&R C was initially created.
I'm not advocating for C (I wouldn't implement an Oberon/Pascal/Modula inspired C replacement otherwise). C was mostly adopted by industry because it came with Unix and had to be used by the many Unix-based workstation vendors to adapt and extend the OS for their specific need/brand. That a significant OS can be written in C without extensions is demonstrated by the many Unix versions themselves. There is always a remainder which has to be implemented in assembler (e.g. to achieve the system state required to run C functions at all). I can also confirm from my own long-time experience implementing embedded (microcontroller) systems in C that it is possible with standard C. But that's not the point. We were discussing about Wirt's minimalism and his focus on his own and the need of his students (vs. the need of industry). I think Wirth's role and influence are generally romanticized. He was innovative, but he did his own thing. The impact of his work on the industry is almost exclusively in a significantly modified/extended form. These extensions/modifications never came from Wirth himself, and only in exceptional cases did they have “his blessing” (e.g., Object Pascal or Modula-3). It was precisely his aforementioned minimalism that led him to focus on the things that were important to him, rather than on the needs of the industry, whether justified or not.