Creator of Scala: Comparing Languages And How AI Will Impact Them | Martin Odersky

Scala之父Martin Odersky：编程语言比较及AI带来的深远影响 Martin Odersky概述了函数式编程的务实优势，提倡值转换模式，同时避免教条式的纯单子（monadic）模式，并对比了Rust、Zig和Go等系统级语言的设计抉择。在回顾Scala的发展历程时，他审视了早期的JVM相关决策、Twitter早期的关键采用，以及对过度抽象的事后反思。谈及AI代码生成，Odersky警告称，人工审查机器编写的代码难以形成规模，进而主张采用更强的类型约束、基于能力的安全机制，并将提示词（prompt）视为一等程序工件。他最后总结道，未来的软件工程师将转型为高层级监控管理者，需要具备更扎实的逻辑和数学基础。 Martin Odersky警告称，人工审查机器生成的代码在规模化下是不可行的，并指出类型系统必须演变为可强制执行的、基于能力的契约，以严格限制AI智能体所能读取、写入或泄露的内容。 (31:00) Odersky认为Rust目前在整个软件行业中存在被过度使用的情况，建议团队只要硬件内存允许，就应默认选择带有垃圾回收机制的运行时，而不是将手动内存管理作为一种智力挑战来承担。 (9:26) 未来的编程语言设计将不再强调人类书写的人体工学，转而偏向机器的形式化约束；Odersky提议将自然语言提示词作为受版本控制的一等工件直接嵌入程序中，以缓解非确定性的代码漂移。 (40:12) 预计在未来十年内，软件工程人员规模将收缩为一支规模更小但技能水平明显更高的队伍，工作重心将从手动编码转向以形式逻辑和数学为根基的AI监督与控制工程。 (43:40)

Martin Odersky contends that as artificial intelligence shifts software development from manual authoring to automated code generation, programming languages must evolve from developer ergonomics toward rigid type contracts, capability boundaries, and formal constraints to ensure humans retain control. Pragmatic Functional Foundations and the Scala Synthesis (0:45) Odersky defines functional programming as "programming with values," where immutable data transformations eliminate hidden side effects and allow developers to reason about programs statically without an interactive debugger. However, he cautions against dogmatic purity that wraps every effect in heavy monadic abstractions. Instead, he advocates for a 95/5 balance: keeping roughly 95% of the codebase in pure value transformations while retaining a pragmatic 5% imperative escape hatch for localized side effects and I/O. Scala was engineered to combine this functional discipline with object-oriented modularity, using method-chaining dot notation to ease API discovery rather than forcing developers into an unorganized "sea of functions." In retrospect, Odersky notes that granting complete expressive freedom from the outset invited severe over-abstraction. Unlike Go, which enforced simplicity through strict syntactic constraints, Scala allowed developers to import complex Haskell idioms directly, creating heavily monadic architectures that teammates struggled to maintain and prompting some organizations to scrap entire codebases. Memory Safety, Garbage Collection, and Systems Languages (8:34) For modern systems programming, Odersky views memory safety as an absolute prerequisite, which directly disqualifies legacy languages such as C and C++. While crediting Rust with proving that low-level memory safety is viable without a runtime collector, he argues that Rust is currently overused. In his view, development teams frequently push Rust high up the application stack into domains where automatic garbage collection is entirely sufficient and JVM pause times are negligible, sacrificing productivity for unnecessary manual control. Conversely, Odersky characterizes Go as a language intentionally anchored to 1990s standards, yet acknowledges that its limited expressive power succeeds in enforcing stylistic uniformity and easy onboarding across engineering teams. In metaprogramming, he praises Zig's compile-time comptime model and contrasts it with Scala's compile-time inliner, which deterministically replaces call sites during AST typing while strictly guaranteeing that expansion cannot trigger downstream type errors. Language Design for AI: Capabilities and Prompts (31:00) With large language models generating massive volumes of source code, Odersky warns that assigning humans to review hundreds of machine-written lines will fail, creating an existential risk as automated agents learn to probe systems for vulnerabilities. As writing code shifts to machines, language ergonomics designed to save human keystrokes (such as terse assignment operators) will lose relevance. Instead, programming languages must provide mechanisms to constrain what an AI system cannot do. Because traditional type systems function largely as bypassable recommendations, Odersky advocates integrating capability systems directly into language types. In experimental Scala research, capabilities treat resources like log files or memory arenas as bounded permissions, preventing return values from secretly holding references or leaking credentials. For developer interaction, Odersky suggests treating prompts as first-class values embedded in source files. Establishing a "prompt blame" record would allow AI agents to parse exact context and make targeted, incremental modifications without suffering from non-deterministic drift. The Evolving Workforce and Formal Verification (43:40) Looking ten years ahead, Odersky forecasts that the software industry will employ fewer engineers, with entry-level qualification bars rising substantially. Rather than writing routine lines of code, developers will function like control engineers overseeing an automated manufacturing facility, requiring deep foundations in logic and mathematics to guide and constrain autonomous models. While formal verification tools like Lean and Coq offer mathematical proof of correctness, Odersky notes that authoring formal specifications for large enterprise systems remains extraordinarily difficult, often exceeding the complexity of writing the software itself. To prepare for this landscape, he advises engineers to build hardware intuition via C and Rust while developing rigorous mathematical discipline through interactive theorem provers. Odersky concludes that maintaining control over AI-generated software requires adopting capability-safe, strongly typed languages that strictly limit machine agency. However, an unresolved tension remains between formal verification, which is technically difficult to scale to large codebases, and natural-language prompt specifications, which risk non-deterministic code drift.

[0:00] Martin Odersky: We are at a moment where it's essentially very dangerous that we lose control as humans. [2:58] Martin Odersky: The other thing is to essentially know when to stop... there is a strand of functional programming called pure functional programming which tries to express as much as possible in pure functions and to sort of delay the side effects to and wrap them up in monads or whatnot, and that can get very inconvenient very quickly. [10:24] Martin Odersky: if you have the memory for a garbage collector, you should absolutely use one because it makes a lot of things simpler. [29:19] Martin Odersky: we do JVM bytecode, that's essentially what it comes down to. [32:26] Martin Odersky: the handle that we can make a contract between the human and the AI that the human can understand and that's concise enough to be reviewed and that essentially the AI can keep to. [32:26] Martin Odersky: Let's face it, type systems are mostly recommendations [36:17] Martin Odersky: in our language that won't be a secret anymore because the type has to declare that the thing I return does hold on to the file. [38:58] Martin Odersky: nobody sort of thought that that was possible before Rust came. [40:12] Martin Odersky: easy to write is definitely not a big criterion anymore. [40:12] Martin Odersky: but then we throw away the prompt or it's hidden in the chat history with the agent. So that's really a shame. [53:55] Martin Odersky: a footnote in memory.

[0:00] We are at a moment where it's [0:02] essentially very dangerous that we lose [0:04] control as humans. [0:06] >> This is Martin Oderski, the creator of [0:08] Scola, and I asked him all about [0:10] programming languages and how they're [0:12] going to change in the future. [0:13] >> I believe right now Rust is actually [0:15] overused. So Zik is I believe is much [0:18] better because the the inlining [0:20] mechanism is much ser. This pisses off [0:22] both communities and they're promptly [0:24] declared jihad. If the code is AI [0:27] generated, then the focus has to go [0:29] elsewhere. And I think the focus will go [0:31] to the interfaces and to the types. [0:33] >> 10 [snorts] years from now, do you think [0:35] there will be more software engineers [0:36] than today or less? Here's the full [0:39] episode. [0:45] What is functional programming and why [0:47] should an imperative programmer care [0:49] about the functional way of programming? [0:52] So functional programming is programming [0:56] with values. Uh so you don't have state [1:00] that changes like mutable variables that [1:02] change or arrays that change. You have [1:05] values and you have functions and the [1:06] functions transform these values into [1:08] other values. So it's a very restricted [1:11] form of programming and most real [1:13] functional programming languages uh are [1:16] impure in the sense that yes of course [1:18] at some point you have to touch state [1:20] and change things and write to standard [1:22] out and things like that but the idea is [1:25] to do that sort of uh very late. So to [1:28] have the largest part of your program [1:31] represented as values and functions that [1:33] transform values and the benefit you get [1:36] from that is essentially much better [1:39] predictability and fewer bugs because [1:42] these side effects to let's say a global [1:44] variable or a field in some object graph [1:46] or things like that they can really uh [1:49] trip you up. Uh they can they can [1:51] essentially they're an undocumented [1:53] effect of your function. So it's not [1:55] reflected anywhere typically but may [1:57] maybe you have a comment if if things [2:00] are good uh and and these things are [2:03] very hard to keep in your head and [2:06] generally reason about. So the advice [2:08] from functional programming is [2:10] essentially to keep these things to the [2:12] bare minimum and possibly to nothing if [2:15] your function maps into these things. Um [2:19] the other reason why function [2:20] programming is nice is that it's very [2:23] directly linked to mathematics. Uh so in [2:26] mathematics you have theories of let's [2:28] say polomials or strings or lists or [2:32] things like that. And in none of these [2:35] theories you will find the concept of [2:37] mutation. It just doesn't exist. So you [2:39] can take a polomial and you can [2:41] transform it into a new polomial but you [2:43] can't change a coefficient coefficient [2:45] at 3 at the third coefficient and [2:48] pretend it's the same polomial. It's not [2:50] in mathematics, right? It's clearly [2:52] something different. So functional [2:53] programming you could say follows quite [2:56] closely the way mathematics sees things. [2:58] >> What would you say to someone that [3:01] doesn't do functional programming [3:02] because it's not convenient? I [3:04] >> I guess two things. one is uh uh it's [3:07] it's a learning uh uh curve. Uh so [3:11] initially you you're sort of your brain [3:14] is wired to be to do imperative [3:16] programming from when you were very [3:18] young. I imagine most people learned an [3:19] imperative language first and then it's [3:22] hard to see how you would express things [3:25] differently. [3:26] uh but if you persist in that a little [3:29] bit and it doesn't really take much then [3:31] you will essentially reap the benefits [3:33] very quickly that you say well I [3:34] actually my program got a lot clearer I [3:36] can understand it better uh I don't [3:39] really have to track uh some uh steps go [3:43] step by step through through my program [3:44] with a debugger or things like that to [3:46] to figure out what it does typically I [3:49] don't need a debugger when I write [3:50] functional code that that's really not [3:52] not uh not not necessary [3:55] u the The other thing is to essentially [3:58] know when to stop. So uh there is a [4:02] strand of functional programming called [4:04] pure function programming which tries to [4:06] express as much as possible in pure [4:09] functions and to sort of delay the side [4:11] effects uh to and wrap them up in monuts [4:14] or whatnot and that can get very [4:17] inconvenient very quickly. Uh so uh the [4:21] my answer to that would be it really [4:24] depends and in most cases it's [4:25] completely okay to have your side [4:28] effects as long as these are well [4:30] documented and and you you you use them. [4:32] So basically use these things in [4:34] moderation. I would say functional [4:36] programming is great for 95% of your [4:38] program and if you need some side effect [4:41] some imperative uh feature for the last [4:43] 5% that's also okay. Is there any [4:46] quantitative measure of the um I guess [4:50] the correctness benefits that functional [4:52] programming gives you over imperative? [4:55] >> Um I I think there are some studies. Uh [5:01] it's not quite clear how significant [5:04] they are. I think people criticize them [5:06] a lot. The [snorts] studies tend to say [5:08] that a language like Scala would have [5:10] fewer bucks than a language like C or [5:12] C++. But uh I don't really want to sort [5:16] of insist on that because these studies [5:18] are very hard to do and the methodology [5:21] is very hard to get right. I believe the [5:23] effects come uh are uh become more [5:26] important in large programs than in [5:28] small ones. For small ones you can do [5:30] anything really. You can write it with [5:31] you can write a loop, you can write a [5:33] recursive function. It doesn't really [5:34] matter and it's [snorts] it's very much [5:36] a matter of taste which one you prefer. [5:39] But in a large system I believe so I [5:42] believe that let's say static types have [5:46] certainly proven their worth and even [5:47] that we don't really have a conclusive [5:49] study that shows it. I mean I can point [5:51] you to a study and if you're a dynamic [5:54] typing enthusiast and you can point you [5:56] will point to another that essentially [5:58] claims the opposite. So it's very very [6:00] hard to do empirical software [6:01] engineering on that scale. Um and uh so [6:05] I'm afraid I I can't really give a good [6:08] answer. I just have the feeling that [6:11] mostly functional statically typed [6:13] languages is sort of a sweet spot for [6:16] for getting programs right. Maybe the [6:19] other thing is when you really need to [6:20] get them absolutely right like with with [6:23] proofs and things like that. Uh if you [6:25] do rock or lean or any of these things [6:28] these are all functional languages. So [6:30] people wouldn't wouldn't even attempt to [6:32] do something like C C++ here. When you [6:36] think about Scola in the environment of [6:39] all programming languages, what sets [6:41] Scola apart? Or maybe put in another [6:43] way, why should someone learn Scola in [6:46] 2026? [6:47] >> Well, Scala is the only functional [6:50] language that is also a very capable [6:54] object-oriented language. In fact, it [6:56] was born uh by the idea that we can [6:59] actually make a fusion of the two in a [7:01] way which is not a side by side but [7:03] which really combines the features in a [7:06] in a nice synthesis. So that was what [7:08] what Scala was about. That's what I [7:10] wanted to show and I think that's been [7:13] largely successful. So you can write [7:15] really beautiful programs in this [7:17] combination. uh object-oriented [7:20] programming comes in when you talk about [7:22] components and modules and uh [7:25] essentially encapsulation these sort of [7:26] things where functional programming [7:28] typically doesn't really have a very [7:30] strong story. I mean there are languages [7:32] like standard ML or or camel that do [7:35] have very capable module systems but [7:37] other functional languages don't and and [7:40] people when they think of functional [7:41] programming they don't really think much [7:43] about components and interfaces and [7:46] these sort of things which are things [7:47] that I believe also matter very much. [7:50] >> Could you give an example maybe um like [7:53] an object-oriented thing that you could [7:55] do in Scola but you couldn't do in [7:57] Haskell which is pure functional. it's [8:00] sort of ingrained. It's in the whole [8:03] fabric of the things that everything is [8:05] essentially objects what what you do. Um [8:09] so so one thing that you get is what I [8:12] think Simon Pton Jones called the power [8:14] of the dot uh that you say it's super [8:16] convenient. You have an object and then [8:17] you do dot and then you have the [8:20] environment that immediately tells you [8:21] what are the methods and fields of that [8:23] object that they can use them. So it [8:25] focuses your mind. Whereas in function [8:27] programming, it's typically you have a [8:28] sea of functions that can uh be be [8:31] applied to arguments and you have to [8:32] figure out what they are. [8:34] >> When you think about the systems [8:35] programming languages like Rust, Zigg, [8:38] Go, C, C++, uh in your opinion, which [8:41] one would you say is kind of the best [8:44] one and then maybe we can compare it to [8:45] Scala? [8:46] >> In this day and age, a systems [8:48] programming languages needs to be memory [8:50] safe, guaranteed memory safe. So that [8:52] would already exclude quite a few of [8:54] them but it would leave Rust and Go I [8:57] think and Rust and Go are at different [9:00] levels. Go is really not not a sort of a [9:04] nuts and bolt systems programming [9:05] languages is more language in which you [9:07] would write let's say an application [9:09] server or some middleware or some cloud [9:11] infrastructure or things like that. It's [9:13] not something you would use for embedded [9:15] say which which you would would use Rust [9:17] for. So I think in their domain both of [9:20] them are are probably the ones that that [9:24] are the leading ones that I would take [9:25] most seriously. [9:27] >> And then when you compare you know Rust [9:30] or Go with Scola what are the pros and [9:33] cons of the different language designs? [9:35] What's something that Rust does better [9:37] than Scala? Something that Scola does [9:39] better than Rust [9:40] >> so Rust is closer to the metal. you have [9:43] better performance guarantees I guess uh [9:46] the fact that Scala is a garbage [9:47] collected language means that you always [9:50] have some pauses I mean garbage [9:52] collection colle collectors have become [9:53] quite quite capable I mean they're [9:55] brilliant and the pauses are really very [9:57] very small but it's fact it's it's a [10:00] fact that you do need a big chunk of [10:03] memory to run fast and I guess Rust [10:06] could could run in much much smaller [10:08] memory so I believe that's that's better [10:10] for embedded systems and things like [10:12] that. I believe right now rust is [10:14] actually overused because a lot of [10:16] people push sort of rush rust for things [10:19] higher higher up in the stack where you [10:22] garbage collector is fine but uh [10:24] essentially you you still want to write [10:26] code without and that is for me a bit an [10:31] exercise in [10:34] uh I don't know just intellectual that I [10:36] can do it I I don't think really think [10:38] there's a there's a big sense in it that [10:41] if you have the memory for a garbage [10:42] collector, you should absolutely use one [10:44] because it makes a lot of things uh [10:47] simpler. So yes, of course, if given [10:50] enough uh brains, I can write code [10:53] around and I can do that. But why should [10:55] you? I mean, it it it can be much [10:57] simpler. [10:59] So that was for Rust. Uh for Go, go is [11:02] um sort of a language a bit that that [11:06] lags behind. I mean was intentionally [11:08] designed to be to be very very small and [11:11] essentially to be the standards of the [11:13] languages in the '9s. U so now they have [11:16] gotten generics which is a big step. So [11:18] I believe that sort of is sort of a step [11:22] forward for that but it's still a fairly [11:24] limited language what you can do which [11:27] has an advantage that essentially it is [11:30] forces a very uniform style because [11:32] there's not much of different things you [11:34] can do and that's probably it a culture [11:37] fostered to do things in a certain way [11:40] which makes it easier to essentially [11:42] read one's other's programs and and [11:44] essentially jump in a new code base and [11:46] things like that. So I think that would [11:48] be my main advantage of go that I see [11:50] there. [11:51] >> Is it possible to turn off the garbage [11:54] collector in Scola? [11:55] >> Not in production. Uh so we have some [11:58] research that uh would let you use [12:01] essentially your own memory allocators [12:04] and things like that. Uh uh the the way [12:07] let's say Zigg does it. The problem with [12:09] that is always that you uh you you can [12:12] leak references into memory that you [12:15] reclaim and then all hell breaks use [12:17] lose essentially your your pointers [12:20] point to memory that's undefined and and [12:23] so but in in Scala we we now have a very [12:27] good way to actually track these [12:28] references so we can actually prevent [12:30] that statically by the type system that [12:32] this will never happen and you can still [12:34] have your own allocator. That said, we [12:37] haven't really shipped that in [12:38] production yet. So, right now, I would [12:40] say you use the garbage collector, [12:41] escala. Yeah, [12:42] >> I see uh a lot on the internet people [12:45] comparing Rust and Zigg or kind of a [12:48] fierce debate on which one is better. [12:51] When you think about Rust versus Zigg, [12:53] what are the merits of the two compared [12:56] comparing to each other? So what I can [12:59] see is Zik has a really nifty uh compile [13:02] time uh uh uh construct uh essentially [13:06] inlining where the compiler does smart [13:09] inlining and and and that is quite clean [13:13] and quite powerful and Rust has has [13:16] macros but I think they're more clunky [13:18] than there is than the zik version. Um [13:21] in Scala we have something quite close [13:23] to zik. We also have essentially very a [13:27] thing that's based on on inlining and [13:29] optimizations by the compiler. Uh but we [13:32] have a restriction which I believe sik [13:34] doesn't have and that is that um there [13:38] cannot be additional type errors after [13:40] inlining. So the thing is you inline and [13:43] then the question is is the inline [13:44] program guaranteed correct uh so type [13:47] correct or might you have type errors? [13:50] The typical example where you might have [13:52] type errors is C++ templates. In fact, [13:55] that's quite quite scary in C++ that you [13:58] can expand a template and then you get [14:00] very very complex type errors and very [14:03] very hard to to to debug things. So, ZIK [14:06] is I believe is much better because the [14:07] the inlining mechanism is much ser. [14:10] >> When you say inlining, can you explain [14:12] the concept? Inlining just means that uh [14:15] in in Scala we can write inline in front [14:18] of a of a function and that means that [14:21] the compiler will uh before it starts [14:25] code generating. So during the time when [14:28] it looks at the type code which are [14:30] trees it will take the function body [14:33] when it sees a function call to that [14:34] function it will take the call and [14:36] replace it by the body and then it will [14:39] do some optimizations. it can say okay [14:41] so here we have essentially an app an [14:44] application to let's say a value which [14:47] is a lambda and but I know where the [14:49] lambda points to so let me forward the [14:51] call right to the function uh so and and [14:54] with that you can already do quite a bit [14:57] of uh essentially optimizations which [15:00] are guaranteed because the the inliner [15:03] must inline that's that's not a thing [15:06] like an optimizer has essentially [15:08] discretion whether they want to inline [15:10] things or not and so you can never rely [15:12] on that but an an inliner which is uh [15:15] essentially a compile time based on the [15:18] typer must inline so you can rely on it [15:21] and const explore by in in zik and C++ [15:24] is essentially very similar [15:26] >> okay so it's a way to get rid of the [15:28] function call or the overhead of a [15:30] function call and tell the compiler you [15:33] can do more because it's all I guess [15:36] inline [15:37] >> yeah you reveal the implementation and [15:39] That means you you can you can uh the [15:43] compiler can do something with that. [15:45] >> When you think about all the dynamically [15:46] typed languages, um which one stands out [15:50] as one that you think is kind of the [15:52] best among them? [15:53] >> Python is ubiquitous. Um and it has a [15:58] nice syntax. It uh a lot of the Python [16:01] programs look like they're very easy to [16:04] read. So that's definitely an advantage. [16:06] and and the other one would probably be [16:09] something like scheme uh which is sort [16:12] of very grounded in computer science [16:14] theory and lambda calculus and things [16:16] like that. So both of them are sort of [16:19] interesting in their own way but of [16:20] course Python is 100 times more popular. [16:23] >> If you compare Scola to Python for [16:26] instance I guess what are the trade-offs [16:28] that the two languages took? I think the [16:31] gap is closing because Python now [16:34] actually has an optional type syntax and [16:37] a number of type checkers that check [16:39] that syntax in Python is getting some of [16:42] the features that Scala had since the [16:44] beginning like pattern matching is in [16:46] one of the the recent Pythons. So I [16:48] think actually the gap is closing not [16:50] just between Python and Scala but but [16:52] between a lot of programming languages [16:53] in general there sort of all drift to a [16:57] standard set of features which mostly [16:59] come from functional programming [17:01] actually pattern matching for instance [17:03] strong type systems uh generics [17:06] polymorphism all these things came from [17:09] closures all these things came from [17:10] functional programming and so the gap is [17:13] closing in that in that sense um Python [17:17] is um I think the main advantage of [17:21] Scala over Python is that it is it has a [17:24] strong type system that is always on and [17:27] that gives you essentially guarantees uh [17:30] that essentially certain bad states [17:32] can't can't can't happen. So, so you [17:34] really can rely on it. Whereas I think I [17:37] believe the Python type system, well, [17:39] it's just syntax. It has a number of [17:40] type checkers, but in general there's [17:44] there's le you you have fewer guarantees [17:47] and I believe it's also the ecosystem [17:48] and culture that doesn't value types as [17:51] much in Python. So, I think that's [17:52] probably the main difference. [17:54] Fantactically, the two languages I think [17:57] with Scala 3 are actually also quite [17:58] close. So, Scala 3 looks a lot like [18:01] Python. Um, in that sense, uh, you could [18:05] say well can see it as a [18:08] as a language that has strong types and, [18:12] uh, runs on on different runtimes than [18:14] Python. Or I should say the other thing [18:16] with Python which is really great is [18:18] that Python is a fantastic glue language [18:20] because I can essentially have very very [18:23] efficient linkages to to high [18:25] performance C++ libraries. uh uh pandas [18:29] or numpy or things like that. [18:32] >> You mentioned that a lot of the [18:33] programming languages they're kind of uh [18:35] drifting or kind of being inspired by [18:38] the other ones and you know adopting new [18:40] features in the design of Scola. Is [18:42] there a programming language that you [18:44] admire most and influences Scola the [18:47] most? Historically, Scala was [18:51] essentially you could say it was a blend [18:53] of Java, [18:55] Okamel and or standard ML which is close [18:58] an [snorts] MLike language and and [19:00] Haskell. Uh so I I I I'm by trade well [19:05] I'm by trade an imperative program. My [19:07] PhD is from Nicholas W. So I know [19:09] Pascal, modular that was sort of my [19:11] first generation of languages and I [19:13] liked them a lot and then I became sort [19:16] of a converted functional programmer. So [19:18] I I looked very closely at ML, Okl, [19:21] Haskell and these things and then um the [19:25] Scala came about sort of there was a [19:27] predecessor language called pizza and I [19:30] was working on that with Phil Wadler [19:31] who's one of the Haskell original [19:33] designers and the idea was to have [19:36] essentially an accessible functional [19:38] language on a very widespread platform [19:40] which was a JVM at that at that point [19:43] and um the uh in order to prepare for [19:48] that I wrote a Java compiler. So that's [19:51] how I learned a lot about Java and what [19:53] Java was. And in the end I I had had to [19:56] say well it's actually quite useful. I I [19:58] I was quite dismissive at first but [20:01] afterwards I found it actually quite [20:04] useful. I mean this was very early Java. [20:06] This was Java even pre 1.0. So so now [20:08] Java is is of course even more useful [20:11] but also a lot bigger than what it was [20:13] at the time. Um so when we came up with [20:17] with Scala which was sort of the second [20:19] iteration after pizza, pizza was the [20:21] language I did with Phil water. Uh the [20:24] the [20:26] ideas came mostly from Java uh Okamel [20:30] for the modules and the component module [20:33] and Haskell a lot for the standard [20:36] libraries. So if you look at the [20:38] function names of the in the Scala [20:40] standard library then there's sort of a [20:41] mixture of Okamel and Haskell you could [20:43] say but you you recognize a lot of [20:45] things coming from both of these these [20:47] languages [20:48] >> if I recall correctly uh Java was had [20:52] some sort of licensing with it or was [20:54] owned by a company. Um how were you able [20:58] to build on top of Java or did you have [21:01] to pay for licenses or how how' that [21:04] ecosystem work? the language standard [21:06] was open source. Um there were there was [21:09] a lot of experimentation with Java at [21:11] the time. Um I think the only thing that [21:15] Sun was that was the company at the time [21:18] they're very particular about is that [21:20] you absolutely if you did something that [21:23] was using Java and had Java in it you [21:25] had to call it Java and and and you [21:28] couldn't have a different name. So [21:30] that's why initially for instance [21:32] Microsoft clashed with them. Uh and then [21:35] Microsoft went went went away and and [21:38] designed C which was sort of a a Java on [21:41] some steroids. They they threw in a bit [21:44] more than what Java had at the time. U [21:47] the I think the nastiness came Sun was [21:50] actually quite an open company. Uh so at [21:53] the time we no we were not worried about [21:55] that. So that was in the time frame from [21:57] 1998 to 2004 2005 something like that. [22:03] Uh and at the time there was no issue. I [22:05] think the issue came later when Sun was [22:07] acquired by Oracle and Google forked [22:10] Scala on Android Java on Android and [22:13] that's when the fight started but that [22:14] was much later. So uh when you say that [22:17] Scola was using the JVM or built on top [22:20] of it um like concretely in the the tech [22:23] stack what does it mean that Scola uses [22:26] the JVM like how does Java source code [22:29] eventually execute on a machine? [22:32] >> So the JVM is u essentially defined by [22:36] its bite code. So the bite code is [22:38] essentially an intermediate format which [22:40] you can translate your program into and [22:43] then the the bite code is run first by [22:46] an interpreter and then essentially by [22:48] an optimized compiler just just in time [22:51] compiler JIT so that's called JIT they [22:53] they they do that and [22:57] so if you can if you know how to uh [23:01] output bite code and that's not very [23:04] hard then you can run on the JVM so So [23:06] that's essentially the the idea. The [23:09] harder part then is interrupt that you [23:11] say okay I run on the JVM. I have to [23:13] make sense of all these Java libraries [23:15] out there. So I have to somehow map a [23:18] Java concept into a Scala concept [23:21] [snorts] so that the compiler can [23:22] understand what it is and I can document [23:24] what it is in for Scala programmers that [23:27] maybe don't understand much Java. So so [23:29] that that is sort of a work that is sort [23:32] of goes more into the details. That [23:35] said, I mean that's not the only uh [23:38] Scala platform. So it was born on the [23:40] JVM, but now it also exists uh on on [23:43] JavaScript and NodeJS uh on WAM and and [23:47] on native. So it's really a [23:48] multiplatform language. OpenAI, [snorts] [23:51] Enthropic, Cursor, and Verscell all use [23:54] this product to make their lives better. [23:56] And the problem it solves is when you're [23:58] building SAS or an AI product and you [24:01] want to sell to other companies, there's [24:03] all these requirements you need to meet. [24:05] There's SSO, there's SKIM, there's [24:08] arbback, there's audit logs. These are [24:10] all things that take time to integrate [24:12] but aren't the main focus of your app. [24:14] Work OS is an API layer that lets you [24:16] meet all of these requirements in just a [24:19] few lines of code. So, let's say you [24:20] have a new SAS product and you want to [24:22] sell to other companies. Work OS will [24:25] solve all of these critical feature gaps [24:26] for you. You can check them out at [24:29] workos.com to learn more and get [24:31] started. And I appreciate them for [24:33] supporting my work and sponsoring this [24:35] podcast. Jira bytassian isn't just for [24:38] tracking work anymore. Now you can pick [24:40] your favorite AI agent to assign tasks [24:43] to and they'll get access to the rich [24:45] context that's already in Jira. When the [24:47] agent is done, it surfaces pull request. [24:50] That way you can get more done with your [24:52] favorite agents all in one place. Learn [24:54] more at jira.dev. That's jir.dev. [25:00] Appreciate them for sponsoring the [25:01] podcast. And back to the show. Let's say [25:04] I write a Scola program. Uh I have the [25:06] source code. I have to compile it and [25:09] then I have some Java bite code and then [25:13] I call I don't know JVM and I pass in [25:16] this bite code and it just works. [25:19] >> Yeah. Yeah, exactly. Yeah. [25:20] >> What would the advantage be of compiling [25:23] Scola to Java byte code instead of doing [25:27] something like C and C++ where you [25:29] compile it all the way to machine code [25:32] from source? [25:33] >> We we have that too. And so the Scala [25:36] native compiles directly using LLVM to [25:39] to native code. Um the advantages of um [25:44] compiling to bite code is essentially [25:47] again the interrupt can use all the Java [25:49] libraries. Then uh the the garbage [25:52] collectors. So the the JVM has actually [25:54] very good garbage collectors, high [25:56] performance ones. Um and um and the [26:00] runtime loading. So, so what what I can [26:03] do on the JVM is I can compile let's say [26:07] a oneline thing into a little Java bite [26:09] code and I can immediately load that by [26:11] code and execute that and that makes it [26:13] very easy for instance to have a ripple [26:16] because that's how how how a ripple [26:18] would work a redevelop print loop so I [26:20] would just generate a snippet of Scala [26:23] code to bite code load it into the [26:25] running JVM process and it gets executed [26:28] and that's much harder if you go to [26:29] binaries basically the binary ers don't [26:31] really have a concept for that. [26:33] >> You mentioned that you wrote a compiler [26:36] for Java like before Scola and I I've [26:38] heard that compilers are notoriously [26:41] hard to build. Um can you explain the [26:43] hard parts and why they're hard? [26:46] >> Compilers are [26:49] very intricate. Um because uh I think [26:53] there there a lot of requirements on a [26:56] compiler. So you have languages which [26:58] are already complex artifacts. Uh then [27:02] you have a thing called type inference. [27:04] So you have a type system but [27:06] essentially you demand the compiler to [27:10] essentially infer a lot of types that [27:12] make sense because you as a programmer [27:14] thinks well the compiler should know [27:16] that and it should uh but actually to [27:19] for the compiler to do that is is quite [27:21] hard. And then then you of course you [27:23] also demand that it would would would [27:25] generate very efficient code for your [27:27] program because again the compiler [27:29] should know that right so there's a lot [27:30] of demands on that plus there's a demand [27:33] that it should should be very very fast [27:35] uh and to square all these demands [27:38] requires quite a bit of work basically [27:42] there are also things that make it [27:43] easier for compilers because they're [27:46] fundamentally deterministic programs. So [27:48] essentially you run a compiler on a [27:50] source and you should you always get the [27:52] same output. So it means they're easier [27:54] to debug. You can just replay things and [27:56] repeat things. Whereas if I would have [27:59] some cloud service or distributed [28:01] application that has other nightmares, [28:03] right? That every run is different and [28:05] how how do you even figure out what goes [28:07] wrong? [28:07] >> So when you wrote that compiler uh I [28:10] think espresso for Java um how long did [28:14] it take to write that by hand? uh at the [28:17] time it took me about 3 months I think [28:20] not full-time maybe half time three [28:22] months half time something like that but [28:23] that was a very simple compiler too so [28:26] that's the other thing with compilers [28:27] they typically start simple and when [28:30] you're at the 10 year mark or 20 year [28:31] mark then there's lots and lots of [28:33] essentially other requirements to a [28:35] compiler that make them more complex. [28:37] Were there libraries that you could rely [28:39] on to to kind of piece together [28:42] components of it or did you have to [28:43] write you know everything from scratch? [28:46] I wrote there was a library to uh [28:48] generate uh bite codes I think uh I [28:51] think I used that in that version. Yeah [28:53] I did. Yeah. So there was a a library [28:55] that essentially a high level library to [28:57] just assemble by codes and and put them [29:00] in the to the right format and things [29:02] like that. Uh but that was essentially [29:05] it. The rest I wrote by hand. Yeah. [29:07] That's crazy because well I mean these [29:10] days a lot of people even more so now [29:12] we're thinking less using AI more to [29:15] kind of you know write the code. So [29:17] that's pretty impressive. I saw one of [29:19] the big I guess moments for Scola was [29:22] that Twitter adopted it and I wanted to [29:24] know the story behind that. How did they [29:26] choose such a obscure language at that [29:29] time? [29:30] >> It was very obscure at the time. That's [29:32] true. Uh so I believe the story was [29:35] Twitter originally was written in Ruby [29:38] and um it wasn't very reliable because I [29:42] believe it's again a problem with [29:43] garbage collector and memory management [29:45] and things like that. So uh the uh and [29:49] it was a small company at the time. So [29:51] 25 people uh including the ops people [29:54] and um the uh essentially the the board [29:58] and the VC investors said you can't go [30:01] on like this being unreliable like that. [30:04] You should do Java because Java was sort [30:06] of the solid choice at the time. But the [30:09] the the some some of the engineers at at [30:12] Twitter they wanted essentially [30:13] something more fancy as a programming [30:15] language and there were some people who [30:17] knew Okamo and liked Okamo but of course [30:21] Okamel didn't run on the JVM and then [30:23] they found Scala and said well Scala is [30:25] actually quite a lot like Okamo and we [30:28] can tell our investors that we do Java [30:30] because it's not a lie we do JVM JVM by [30:33] code that's essentially what it what [30:35] what where what it comes down to. So [30:37] that's why why they picked it and they [30:39] were quite the first but once they [30:40] picked it sort of the floodgates opened [30:42] because at that time they were very uh [30:45] interesting company and a lot of people [30:46] admired them. So a lot of people [30:48] followed and did the same thing then uh [30:51] mostly they came from dynamic languages. [30:53] So Twitter came from Ruby others came [30:55] from PHP or uh yeah JavaScript uh things [30:59] like that. I mentioned a little bit that [31:02] you know AI is kind of generating a lot [31:04] of code and I wanted to ask you what you [31:07] thought maybe the future of programming [31:09] languages might look like if you kind of [31:12] speculated or drew out further into the [31:15] future like if AI is generating more of [31:17] the code. How do you think that might [31:19] affect the programming language [31:20] ecosystem? [31:22] >> Yeah, I think right now we are sort of [31:24] in an existential crisis, right? So we [31:26] have [snorts] AI generating the code but [31:29] uh uh humans being asked impossible [31:32] tasks like to review all this these [31:35] mountains of code and things like that [31:36] which will never work. Um and uh at the [31:40] same time a AI is also gotten extremely [31:42] good at exploiting vulnerabilities in [31:45] code like we we all heard of Fable and [31:47] and and things like that that you can't [31:49] use it anymore because it's too [31:51] dangerous. It will exploit things. So [31:55] um we are at a moment where it's [31:58] essentially very dangerous that we lose [32:00] control as humans of what what actually [32:03] happens here and uh that's a challenge [32:06] that I think programming languages can [32:09] help meet and probably definitely not [32:11] only programming languages that's no [32:13] silver bullet but they definitely can [32:16] help things. Um so I think one of the [32:20] things is that the focus if the code is [32:24] AI generated then the focus has to go [32:26] elsewhere and I think the co focus will [32:28] go to the interfaces and to the types. [32:31] So I expect types will become a lot [32:33] stronger and more precise than than what [32:36] we had because types is essentially the [32:38] handle that we can make a contract [32:41] between the human and the AI that the [32:43] that the human can understand and that's [32:45] concise enough to be reviewed and that [32:48] essentially the AI can keep to uh we [32:51] have to level our game quite a lot. Uh [32:54] because right now I mean let's face it [32:57] type systems are mostly [32:59] um uh recommendations. Uh they're mostly [33:04] uh things that uh mostly hold but not [33:07] always. There are no guarantees because [33:08] you can always have a cast or well you [33:11] you use some dirty memory or I mean [33:14] there there are number of a lot of [33:15] techniques to sort of undermine the type [33:18] systems and we have to close all these [33:19] holes from the beginning because uh once [33:22] once there is a hole somebody can [33:24] exploit it. Uh so I think strong types [33:27] strong highle types will help. Um and [33:31] then I think the the other part is [33:33] generally the programmer has to think [33:35] much more about what are the [33:36] requirements and what are the [33:40] essentially the high level [33:41] specifications [33:43] uh and be able to leave the code to be [33:47] generated by somebody else in confidence [33:50] and uh I think we're not quite there yet [33:53] but we we we have some ideas how we [33:55] could get there. uh so one one uh [33:59] technique that I believe uh we can use [34:02] and it has been around for a long time [34:04] but maybe it's time has come now this [34:06] capabilities capabilities essent [34:09] essentially was used in operating [34:10] systems to give very fine grain [34:12] permissions to to uh entities users [34:16] programs and things like that and uh I [34:19] believe that can be used also for agents [34:22] and the agentic AI to say well once we [34:25] have agents We have to give agents very [34:28] precise and fine grain capabilities what [34:30] they can do and that lets us essentially [34:32] be confident about what they will not be [34:35] able to do like they will not be able to [34:37] leak my API keys or my email or or do do [34:42] other things right so I think that's [34:44] that's an important part uh and the [34:48] existing languages are uh not there yet [34:51] uh I think Scala is halfway there at [34:54] least it's there where in essentially [34:56] stuff we're working on which we have in [34:58] the lab and we have released as an [34:59] experimental feature. So I'm quite [35:01] excited about that. Um the first thing [35:04] that you have to do is definitely be [35:07] memory safe. So a language that [35:09] essentially is is not safe in memory [35:11] that lets you essentially uh access [35:15] undefined memory uh is immediately out [35:17] because you can't you can't guarantee [35:19] anything. So that's in that sense it's [35:22] good that there is a drive to use let's [35:23] say rust as a memory safe language we're [35:25] even that that was even promoted by the [35:28] American government I believe so that's [35:30] definitely a very useful drive but I [35:33] think you need a lot more because you [35:34] need much rest talk folks essentially [35:37] mostly or only about memory you need to [35:40] talk about a lot more things than memory [35:42] you need about essentially read [35:43] permissions write permissions access to [35:46] secrets all these things that that are [35:49] that are uh uh that go beyond that and u [35:54] you could say okay uh that [35:57] Martin you're totally unrealistic [35:59] because uh all our software is written [36:01] in C and C++ and we will not be able to [36:04] rewrite that uh but that I believe AIS [36:08] can help there right so AIs are great to [36:10] re in rewriting software so if we know [36:13] what to rewrite too I think we could we [36:15] might be able to get there [36:17] >> you mentioned some of those experimental [36:19] features in Scola that um might have [36:22] some sort of safety guarantees or signal [36:25] capabilities. Can you explain what that [36:27] might look like or maybe give an [36:29] example? [36:30] >> So, so a simple example would would be [36:32] let's say somebody gives me a file and [36:34] um uh and uh I have access to the file [36:39] let's say a log file or something like [36:41] that. I have access for a file for a [36:43] limited time and then I I need to close [36:45] it. So typically I have a operation that [36:48] essentially somebody passes I a file to [36:51] me to an operation that my program [36:54] provides and the program does something [36:56] with the file and then the environment [36:58] will close it. But how do we make sure [37:01] that I don't hold on to the file after I [37:04] get it back to the environment or after [37:06] I I I pretended I'm finished with it [37:08] because hey I I have a file. I could [37:10] have stored it in a variable. I could [37:12] have stored it on the side. I could have [37:14] gone g come g come g come g come g come [37:14] g come g come g come g come g come g [37:14] come g come g come g come g come g come [37:14] g come g come g come g come comeone back [37:14] to it and done something with it. So uh [37:17] capabilities help me prevent that [37:19] because essentially I I can say okay so [37:21] this file is a capability and then I can [37:24] further say well this capability can be [37:26] used only in a limited scope and the [37:29] type system will make sure that the [37:31] capability doesn't escape and the way we [37:33] do that is that if a type refers to [37:36] capabilities so if I have a a thing that [37:39] I say I give you back a a lambda or a a [37:43] stream and it holds on to the file. So [37:45] the stream holds on to the file in [37:47] secret. In our language that won't be a [37:50] secret anymore because the type has to [37:52] declare that the thing I return does [37:55] hold on to the file. The file is a [37:56] capability and I can't essentially hide [37:59] capabilities I have access to in my [38:02] type. I have to be I have to declare [38:04] them and that gives me essentially this [38:06] this control that then I can also [38:08] enforce to say well at this point you're [38:11] not allowed to have any capability [38:12] because the type that I enforced you to [38:15] have is a type that doesn't hold [38:16] capabilities and that's that way I [38:18] enforce with the type system something [38:20] which uh previously hasn't really been [38:23] enforcable [38:25] uh with for memory safety it's [38:26] essentially the same thing with arenas [38:29] uh that I I have an area where I [38:32] allocate memory and then I want want to [38:33] get rid of it. I have to make sure I [38:35] don't have pointers pointing into it and [38:37] that's exactly the same the same [38:39] situation and and let's say for [38:43] accessing secrets again. So it's a very [38:45] common pattern that I say in certain [38:47] situations I want to make sure that you [38:51] don't have uh or that you only have a [38:53] set of defined capabilities that I give [38:56] you and nothing else. You mentioned uh [38:58] memory safety is an absolute uh table [39:01] stakes. What are the programming [39:03] languages that you think of that are not [39:05] memory safe? I know there's C, but what [39:07] are the other ones? [39:08] >> The big ones is C, C++. Um I I don't [39:12] know about I think Zik or Nim or other [39:14] low-level systems languages are not [39:16] memory safe. So that was sort of in Rust [39:19] the a big achievement that you say you [39:21] can be a low-level systems languages and [39:23] be be memory safe. nobody sort of [39:26] thought that that was possible before [39:27] Rust came. Uh so so that's why I would [39:31] think I don't want to say anything wrong [39:33] but I would think that essentially most [39:36] other low-level systems languages would [39:38] not be memory safe. Um but you really [39:41] need more than memory safe. You really [39:43] need capability safes that you say you [39:46] when I essentially hang on tell you I [39:48] can't sort of forget capabilities to say [39:51] I hang on to something and I I just [39:52] conveniently forget that I have access [39:54] to that and I can't forge capabilities [39:57] to say well if I need a capability I [39:59] just make one up. And so these two [40:02] things need to be prevented and that [40:03] goes go that goes beyond memory safety. [40:07] But memory safety without memory safety [40:09] essentially you have nothing because you [40:10] can fake everything. [40:12] >> A lot of programming language design and [40:15] how we write code in the past is writing [40:18] the source code so that it's um it's [40:21] it's nice for humans to read. But if [40:24] humans are no longer interacting with [40:26] the code, what kind of things come to [40:28] mind that we might not care as much [40:31] about but are good for machines to read. [40:34] For instance, [40:35] >> the first thing is uh maybe sometimes [40:38] you want to read it uh but you probably [40:40] wouldn't have written it. So easy to [40:43] write is definitely not not a big [40:45] criterion anymore. Easy to read to some [40:48] degree. Yes. But that means you don't [40:50] need any these these sort of syntactic [40:52] hacks like to write plus+ in C or things [40:55] like that that's easy to write right. So [40:57] but I I don't I mean I'm sure we will [41:00] still have that but it doesn't really [41:02] matter anymore. I mean whether [snorts] [41:04] I write an assignment in in long form or [41:06] with X++ whatever. So I think these [41:09] things won't won't matter much less. the [41:11] things that matter much more are or that [41:14] continue to matter and uh are [41:18] essentially high level ways to constrain [41:21] and specify what my program should do. [41:24] So uh constrain what it should not do. [41:27] Uh that's that's one of the things and [41:29] also specify what it should do. uh and I [41:32] mean some people say it's a golden age [41:35] for formal verification because we can [41:37] be very precise in our specifications [41:40] and our AI can actually not just finish [41:43] the program but also the proof that the [41:45] that the program actually meets the [41:47] specification and I think that's true [41:49] that's really very exciting in in in a [41:51] lot of areas but in the large uh the [41:55] problem is you often don't really have [41:57] the formal specification or it's just as [42:00] hard to write a formal specific [42:01] ification than to write a program or [42:03] sometimes even harder. So that means [42:05] that we will still have live in a world [42:08] where we specify things by natural [42:11] languages by prompt to the agent and and [42:14] the agent then will will do the code. [42:16] But I imagine that also the that will be [42:19] a lot more [42:21] um formal in a way. So, so in a sense [42:25] right now the prompts I mean it's [42:27] fantastic what they can do with the [42:28] prompts but then we throw away the [42:29] prompt or the it's hidden in in the chat [42:32] history with the agent. So that's really [42:34] a shame. So I really should should have [42:36] the prompts as first class values in my [42:39] program that I can say well essentially [42:41] that's what the program is about and if [42:43] I change the prompt then the AI will [42:46] know essentially what the incremental [42:47] change was and change the program [42:49] incrementally. these sort of things. [42:51] That's another thing that I think we'll [42:53] see in future programming languages for [42:55] a agentic programming. [42:57] >> Maybe like some kind of meta meta [43:00] information about the program almost [43:02] like a git blame but like a you know [43:05] prompt I guess blame of what generated [43:08] that that part of the code. [43:11] >> You should be able to to to keep that [43:14] around and and come back to it. Yeah. [43:16] Also because you want you might want to [43:17] change, right? You might want to say [43:19] well now it's exactly the same but I [43:21] want to change this little detail but I [43:24] don't want the LLM nondeterministically [43:26] to generate a new program because that [43:28] way well it might get a lot of other [43:30] things wrong that I reviewed already. So [43:32] there really should then be an [43:34] incremental small change to the code and [43:36] that means I keep I need to keep the [43:38] prompt as a part of my program. [43:40] >> 10 years from now do you think there [43:42] will be more software engineers than [43:44] today or less? [43:46] I think there will be less uh the [43:50] uh and it will be a higher um [43:55] profession that is essentially has [43:58] higher standards. Uh so it will be [44:00] harder to become one. You will know be [44:02] able to know quite a lot of logics and [44:04] maths to be competent at essentially [44:08] keeping AI on the good track and things [44:10] like that. It's sort of can say it's [44:12] sort of like a like a control engineer [44:14] for a factory where you don't understand [44:16] many things in initially. It means that [44:19] there must be more you must be higher [44:22] skilled than a a factory worker of uh 50 [44:26] years ago or something like that and I [44:28] think the same will will happen for [44:29] software where you will need fewer but [44:32] more qualified people. One thing that a [44:35] lot of people recommend is to become [44:37] better at programming you should learn [44:39] multiple languages and I wanted to know [44:42] aside from Scola what are the top [44:45] programming languages you would [44:46] recommend people learn to expand their [44:48] mind. So definitely a systems language [44:51] uh I think to to know how how how [44:54] hardware works and how software links [44:56] with hardware I would learn a systems [44:58] language and um [45:01] I'm sort of torn between C and Rust [45:04] there because C has going for it that [45:06] it's very simple and very close to a [45:08] thing in Rust you have to learn a lot of [45:10] abstractions but on the other hand it is [45:12] memory safe so I would say probably [45:14] initially see to figure out what these [45:17] things are and then if If you decide to [45:19] become a systems programmer as a career [45:21] then you should switch to rest I guess. [45:23] So that would be one thing. Uh the other [45:26] thing would be something more [45:29] uh with a verification improving [45:32] background because that will be a lot [45:33] more will become a lot more important. [45:37] So I would actually do a course in in [45:39] lean or or rock or one of these [45:42] languages uh to say where we we should [45:45] be able to use AI or to to to have to [45:50] develop first an intuition what it means [45:52] for a program to be correct because I [45:54] guess for most people have only a very [45:56] very uh fuzzy fuzzy intuition for these [46:00] things and and learning one of these [46:02] languages would sharpen the mind. [46:05] Um yeah, so I think those and then of [46:07] course Scala too as a language that [46:10] essentially sits right in the middle [46:11] where fairly fairly provable strong [46:14] types uh high expressivity these sort of [46:17] things. [46:18] >> Yeah. When you think of a top technical [46:20] book that you might recommend people [46:22] does anything come to mind? [46:23] >> I got a lot out of uh structure and [46:26] interpretation of computer programs that [46:28] was a book from the '9s. It was the [46:30] intro text at MIT at the time uh or 80s [46:34] even I think um and in fact this the [46:38] courses I taught on Corera and and uh at [46:41] DPFL are based quite a lot well to some [46:44] degree they're based based on that [46:46] material. So of course not the same [46:47] language and strong types instead of [46:50] dynamically type but still [46:52] >> when you look back on your career why [46:54] did you choose to work in academia [46:55] instead of industry? When I came to the [46:58] end of my studies, I uh was asked to do [47:00] a research project and the project I [47:04] picked or the prof then asked from me to [47:07] modulate that a little bit. In the end, [47:09] I found it super interesting to say I I [47:11] work on something that I don't know [47:12] whether it has a solution or not. Uh so [47:16] uh it it might be that uh the question [47:18] is yes, it might be the question is no. [47:20] We have to do research and that's sort [47:22] of how it started. And then [47:26] then I I believe the the main advantage [47:30] of uh being in academia is really the [47:33] long term and being independent. So in [47:36] the long term I mean ind in industry I'm [47:39] sure there are many periods including [47:40] now where I could be paid 10 times what [47:42] I'm being paid at university if I joined [47:46] Google or any of the other companies in [47:48] Silicon Valley. But um then times also [47:51] change and sometimes essentially what [47:53] you do is no longer relevant and then [47:54] it's very easy to get fired and to [47:58] then you say no big deal I can do [47:59] something else but at a university you [48:02] have essentially long-term tenure to do [48:04] exactly what you want. So no manager you [48:06] can do define your own research agenda. [48:09] Of course you have to get some money [48:11] that that that is uh is hard. You have [48:14] to get grants and things like that. you [48:16] have to convince students that what you [48:18] do is uh is the right thing and but [48:21] that's also very rewarding working with [48:23] students. So I think I in in the end I'm [48:25] I'm very happy that I took the career I [48:27] took. [48:28] >> What about looking back on Scola? Um you [48:31] know do you have so much experience [48:32] there. What are some things that went [48:34] well or things that didn't go well and [48:37] maybe some learnings you could share? [48:39] Scala was initially this experiment that [48:41] we could uh combine object-oriented and [48:44] functional programming and technically [48:47] that experiment was a big success uh um [48:51] in terms of the ecosystem it had a lot [48:54] of challenges. I don't know whether you [48:55] know there was a there was a short [48:57] incomplete history of programming [48:59] languages by James Ivy which is quite [49:01] hilarious and there was there's a [49:02] scholar entry there that this says I [49:05] discovered reef spell sandwiches and I [49:08] had an idea to essentially have a [49:10] language where you put in both object [49:12] and functional and then it ends with [49:14] this pieces of both communities and [49:16] they're promptly declared jihad and [49:19] that's [laughter] at the at the [49:21] beginning it was very funny but uh in [49:23] retrospect That's to a large degree what [49:25] happened. I mean there was there were [49:27] there were a lot of fights and cultural [49:28] fights and things like that. So um and [49:33] um [49:35] we might have uh it was a challenge and [49:38] I don't know in retrospect I think it [49:43] might have been [49:45] more prudent to be more careful [49:48] introducing functional features because [49:50] that sort of was we went in uh [49:53] essentially [49:55] quite complete. So essentially you can [49:57] port most Haskell programs to Scala [49:59] maybe that you you find them a bit less [50:02] attractive looking but you can do it and [50:05] that was that brought in essentially [50:09] different cultures very [50:12] and it caused a big clash of cultures. [50:14] So uh for instance in go Go was a lot [50:18] maligned because they didn't even have [50:20] generics right and it's it's true it was [50:22] a ridiculous language but uh by not [50:25] having it initially you sort of form a [50:27] culture that when you add it nothing [50:29] much will go wrong and people won't [50:31] overabstract or things like that and by [50:34] essentially going full hog into into it [50:36] with Scala from the start we were not [50:38] protected against that and people did uh [50:41] reach abstraction peaks and over [50:43] abstract it and and things like that and [50:45] that's they still do it to this very [50:47] day. So essentially having fancy [50:49] abstractions is great but you have to [50:51] use them responsibly and uh that then it [50:54] sort of clashes with the natural urge to [50:57] just try out all these fancy things and [50:59] do do something that in the end maybe [51:02] neither no you nor understands very well [51:05] and it could have just been a simple map [51:07] or things like that but uh yeah why do [51:11] use that when it can be complicated? Why [51:13] would that upset someone? [51:15] >> Because of the library ecosystem. I [51:17] think that um [51:20] um the [51:22] so libraries are are important and [51:26] because they sort of set the agenda how [51:28] you express your programs and in [51:30] particular the the uh the libraries that [51:34] come from the Haskell side. They're [51:35] essentially monatic frameworks and they [51:37] require you to express your whole [51:39] program as a monot which is a concept [51:41] that works well in functional [51:43] programming. I have my reservations. I [51:45] wouldn't actually do that in my in my [51:47] scholar programs, but by having [51:50] prominent libraries out there, uh it's [51:53] quite normative that people feel like [51:55] they they're being a [snorts] scholar [51:57] programmer, they're required to program [51:59] this way. And then of course there are [52:01] opinion leaders and conferences and all [52:03] these things that uh tell you how how [52:06] you should be writing your programs [52:09] where I would say I I think the most of [52:12] the scholar community is actually very [52:13] very levelheaded and and and and and I I [52:16] think most of the advice is great but uh [52:19] then um yeah uh it's it's still a [52:24] challenge because it's just too easy to [52:27] to mostly it's not really the opinion [52:29] leaders is in the in the community. But [52:31] let's say it's your boss. You have a [52:33] small team in a in a company. Your boss [52:35] came from Haskell and says, "Hey, this [52:37] is great. We do exactly like Haskell. [52:39] The whole thing." And then two years [52:41] later, the boss's boss says, "No, nobody [52:43] can understand this code. This code and [52:45] the project is canled." So these things [52:47] happened in in in in the industry. Uh [52:50] I'm not saying that they they that all [52:53] projects are like that. Not at all. I [52:54] mean there are lots of really great [52:56] success stories of Scala but that's [52:58] essentially a challenge in terms of [53:01] tech. Um I I think in the end um I wish [53:08] we had been a bit less dependent on the [53:10] JVM u uh in the sense that we took a lot [53:14] from Java that intuitively makes sense [53:18] but in the end and and was very [53:20] important for interrupt but in the end [53:22] wasn't wasn't [53:24] could have been done better. So for [53:26] instance uh in in Java being an object- [53:30] oriented language you have universal [53:32] methods like tworing and equals and hash [53:34] code and they're defined for everything [53:36] and languages like Rust or or Haskell [53:39] there are no more more discriminating. [53:41] They have a thing called type classes [53:43] where essentially you at compile time [53:45] you tell exactly where you have equality [53:47] and and hash code and these things and [53:49] it's a bit more tedious to set these [53:51] things up but it it in the end it's also [53:55] safer. So I wish we had that and and we [53:57] did we couldn't because we sort of [53:59] adapted Java's notion of what what an [54:02] object is and it already came with all [54:04] these things which is sort of very [54:06] convenient but in the end uh caused [54:09] friction. If I went back to you at that [54:11] time when you were starting it, I said, [54:13] "What do you think's going to happen 20 [54:15] years from now?" What would you have [54:16] said? [54:17] >> I would probably have said that uh well, [54:19] it was a footnote in memory. Uh uh [54:22] because I mean, let's face it, you you [54:24] do a you do a thing and initially we had [54:26] maybe five users or something like that [54:28] outside our group, some something like [54:30] that, right? So, so and you don't really [54:33] expect that it would change a lot. Uh [54:37] and so I don't know I think it was was [54:41] quite quite by surprise that this [54:43] actually happened. Uh [54:46] and um I think the reason why it [54:49] happened was that at the [clears throat] [54:51] time [54:53] um Scala was a good [54:56] bridge between dynamic languages that [54:59] are slow and sometimes they crash and [55:03] solid languages, statically typed [55:05] languages like Java uh which were at the [55:08] time quite cumbersome to write code and [55:10] there was a lot of ceremony and things [55:12] like that and and Scola to the inferred [55:15] types. So you had types but you didn't [55:17] see them much. So it felt like a dynamic [55:19] language. Uh but it had also the [55:21] solidity of essentially a good platform. [55:24] And I think that's what made it. And [55:26] we've we've been copied a lot by a lot [55:28] of other languages that put in in these [55:30] features then five or 10 years later or [55:33] things like that. But at the time it was [55:34] sort of scala that that was the first [55:36] one that had it and that's sort of why [55:39] it happened. Um but um I wouldn't have [55:42] foreseen that by no means. [55:44] >> Looking back on your career uh when you [55:46] just graduated college and kind of [55:48] started your career um knowing what you [55:51] know today what advice would you give [55:53] your younger self? [55:55] >> I I think to take risks be adventurous [55:58] paid pay it out. So essentially don't [56:01] follow [56:04] the the mainstream. Uh if if you take a [56:07] fancy to do something wild uh and crazy [56:10] technically take the time to do it and [56:13] do it. Um uh but I mean yeah so that's [56:16] what I would of course I mean you still [56:18] need to sort of stay on track somewhat [56:20] but uh I don't want to you to exaggerate [56:23] that either but [laughter] but yeah so [56:25] so basically be a bit non-confirmist. [56:28] >> Awesome. Well, thank you so much for [56:30] your time, professor. I really [56:31] appreciate it. [56:32] >> Thank you, Ryan. [56:34] >> Hey, thank you for watching this [56:35] podcast. If you liked it and you want to [56:36] see the show grow, please support with a [56:39] comment or a like. Also, if you have any [56:42] recommendations for people you want me [56:43] to bring on, please drop a comment. [56:46] Guests like Barbara Liskoff, Mike [56:48] Stonereaker, Mark Brooker, these were [56:50] all people that I brought on because [56:52] someone left a comment. On another note, [56:55] aside from the podcast, I'm working on [56:57] building the ergonomic keyboard that I [56:58] wish existed. Here's a glance at the [57:01] prototype. It's a split keyboard, so [57:03] there's two sides. Um, this is in the [57:05] case, but yeah, we launched on [57:07] Kickstarter and we hit our goal within 8 [57:09] hours of launching. I really appreciate [57:10] it if you were one of the people who [57:12] grabbed one of the early units. Um, [57:14] we're now working on the long journey of [57:16] building the tooling now. So, if you [57:18] still want to pick one up, I've left the [57:20] late pledges open on Kickstarter, so you [57:22] can grab one there. I'll put a link in [57:24] the description. Thank you again for [57:26] watching the podcast and I'll see you in [57:29] the next