Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Origins of Scala (2009)

artima.com

Post reply on HN
Print view View original

71–80 of 97 posts

Re: The Origins of Scala (2009)

#71

Post by Rochus »

pjmlp wrote: post #68
Rochus wrote: post #52

Earlier quoted context omitted.

> 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 sa…

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…

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.

Re: The Origins of Scala (2009)

#72

Post by pjmlp »

hocuspocus wrote: post #70
pjmlp wrote: post #67

Earlier quoted context omitted.

All irrelevant when politics are involved. You will never get me to say anything positive about the Kotlin advocates on Android team. It isn't only Scala, it is using Java 7 samples to sell Kotlin, the original language for Android, still used for the large majority of Android tooling, where your argument fails flat. They have begrudgingly being updating Java support, up to Java 17, when Java 25 is the latest LTS, be…

I'm not defending JetBrains or Google's decisions. But I don't see why anyone should try to rewrite history. Scala had a decade head start. Many people at Google are aware of Scala, some being former LAMP students or staff. Google doesn't simply add a language to their small list of sanctioned toolchains. Kotlin was specifically designed to win the politics argument, using technical merits: full interop, gradual adop…

Kotlin won Android on internal Google politics, zero technical merit.

Feel free to write another long reply on how Kotlin is somehow special, going to replace Java, while the first iteration of Kotlin Native was a failure with a broken design on its reference counting memory approach, and there is still no KVM to replace the JVM in sight, despite such greatness as pointed out in Android circles.

Re: The Origins of Scala (2009)

#73

Post by hocuspocus »

blandflakes wrote: post #60
palata wrote: post #20

Earlier quoted context omitted.

I was first a big fan of Scala, and while I still like it, I am now really into Kotlin. I don't find it disappointing: I tend to consider that Scala was an inspiration for Kotlin. Maybe Kotlin won by being simpler, and definitely because of the tooling and community: being backed by JetBrains and Google helps. For a long time, the tooling was very limited with Scala, which must have slowed its adoption, right?

Kotlin is pretty nice. I think the build tool in Scala being so esoteric didn't help with adoption; I remember avoiding Scala for a few years because dealing with sbt left a horrible taste in my mouth.

Scala CLI should have happened 5 years before, but honestly sbt has improved a lot, the DX is mostly fine since the 1.0 release and it's maintained plugin compatibility for 8+ years.

Gradle is worse on several dimensions, which didn't really hurt Kotlin's adoption, nor seems to fundamentally bother Android developers (ok, they have little choice here).

Re: The Origins of Scala (2009)

#74

Post by pjmlp »

Rochus wrote: post #71
pjmlp wrote: post #68

Earlier quoted context omitted.

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…

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.…

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.

Re: The Origins of Scala (2009)

#75

Post by hocuspocus »

pjmlp wrote: post #72
hocuspocus wrote: post #70

Earlier quoted context omitted.

I'm not defending JetBrains or Google's decisions. But I don't see why anyone should try to rewrite history. Scala had a decade head start. Many people at Google are aware of Scala, some being former LAMP students or staff. Google doesn't simply add a language to their small list of sanctioned toolchains. Kotlin was specifically designed to win the politics argument, using technical merits: full interop, gradual adop…

Kotlin won Android on internal Google politics, zero technical merit. Feel free to write another long reply on how Kotlin is somehow special, going to replace Java, while the first iteration of Kotlin Native was a failure with a broken design on its reference counting memory approach, and there is still no KVM to replace the JVM in sight, despite such greatness as pointed out in Android circles.

I haven't defended Kotlin's approach in any way, I don't know why you want to put words in my mouth.

However if you don't see why Kotlin was well positioned, while Scala was not, then you clearly don't know much about either language.

Technical merit is subjective, but different design decisions can precisely be made to win politics or not, and JetBrains made the right ones, first to convince people internally (who knew about Scala, you know), then Google, as they were fairly well aligned.

Re: The Origins of Scala (2009)

#76

Post by pjmlp »

hocuspocus wrote: post #75
pjmlp wrote: post #72

Earlier quoted context omitted.

Kotlin won Android on internal Google politics, zero technical merit. Feel free to write another long reply on how Kotlin is somehow special, going to replace Java, while the first iteration of Kotlin Native was a failure with a broken design on its reference counting memory approach, and there is still no KVM to replace the JVM in sight, despite such greatness as pointed out in Android circles.

I haven't defended Kotlin's approach in any way, I don't know why you want to put words in my mouth. However if you don't see why Kotlin was well positioned, while Scala was not, then you clearly don't know much about either language. Technical merit is subjective, but different design decisions can precisely be made to win politics or not, and JetBrains made the right ones, first to convince people internally (who k…

I know enough about Google politics, and JVM ecosystem is part of my toolbox since 1996, starting with JDK 1.0.1, I have lived through all hype cycles of JVM guest languages since Beanshell was introduced.

Re: The Origins of Scala (2009)

#77

Post by Rochus »

pjmlp wrote: post #74
Rochus wrote: post #71

Earlier quoted context omitted.

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.…

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.

Re: The Origins of Scala (2009)

#78

Post by blandflakes »

hocuspocus wrote: post #73
blandflakes wrote: post #60

Earlier quoted context omitted.

Kotlin is pretty nice. I think the build tool in Scala being so esoteric didn't help with adoption; I remember avoiding Scala for a few years because dealing with sbt left a horrible taste in my mouth.

Scala CLI should have happened 5 years before, but honestly sbt has improved a lot, the DX is mostly fine since the 1.0 release and it's maintained plugin compatibility for 8+ years. Gradle is worse on several dimensions, which didn't really hurt Kotlin's adoption, nor seems to fundamentally bother Android developers (ok, they have little choice here).

I'm not advocating for Gradle either, but you already pointed out why the build tool being bad is relevant for Scala and not for Kotlin - Android developers have enough other reasons that they're going to use Kotlin, even though Gradle sucks. Scala developers... don't, and so just another straw stacked on a camel's back, so to speak.

Re: The Origins of Scala (2009)

#79

Post by hocuspocus »

blandflakes wrote: post #78
hocuspocus wrote: post #73

Earlier quoted context omitted.

Scala CLI should have happened 5 years before, but honestly sbt has improved a lot, the DX is mostly fine since the 1.0 release and it's maintained plugin compatibility for 8+ years. Gradle is worse on several dimensions, which didn't really hurt Kotlin's adoption, nor seems to fundamentally bother Android developers (ok, they have little choice here).

I'm not advocating for Gradle either, but you already pointed out why the build tool being bad is relevant for Scala and not for Kotlin - Android developers have enough other reasons that they're going to use Kotlin, even though Gradle sucks. Scala developers... don't, and so just another straw stacked on a camel's back, so to speak.

I'm not saying it played no role, but I think sbt's negative impact is overblown.

Maven is old and the DX isn't particularly stellar either. User friendly build tools are a relatively recent development in the programming language landscape. Hell, until uv, Python managed to be much worse than anything on the JVM.

I work at a company that used to do a lot in Scala, and I've seen the decline first hand. Lack of investment in basic upkeep and maintenance is the real killer. Bitrot hurts in Scala more than in Java. And sbt is not the biggest offender there.

Re: The Origins of Scala (2009)

#80

Post by palata »

blandflakes wrote: post #58
palata wrote: post #19

Earlier quoted context omitted.

I remember being a big fan of Scala, and before Scala 3 it was looking to me that Kotlin was becoming a big competitor. Could that be, or do I have my timeline wrong?

It competes in some ways and not in others. It does a pretty good job of providing similar benefits as many Scala ecosystems, but providing approachability over purity. Kotlin becoming The Official Android Language helps it quite a bit, though the future gets interesting if Google successfully abandons the JVM entirely to rid themselves of Oracle. I'm skeptical that Kotlin targeting multiple runtimes is a winning pro…

> I'm skeptical that Kotlin targeting multiple runtimes is a winning proposition

Kotlin multiplatform being adopted by Google for huge projects like Google workspace makes it sound like it may actually be a winning proposition, if you ask me. Kotlin is replacing the more-than-a-decade old, battle tested, Java-to-ObjC translation at Google. I find that very impressive.

> also Rust is probably the better choice than Scala Native for that kind of code anyway

For sharing code between e.g. Android and iOS, Kotlin multiplatform seems to become the better solution. If you use Rust, you still have to call it from Swift and you just introduced a 3rd language.

I have always hated multiplatform frameworks, but Kotlin multiplatform is actually something that I find interesting (and flexible enough that you can choose where it makes sense to use it instead of committing to a whole framework).

Post reply on HN