This content is an interview with Mike Samuel, a software engineer and creator of the programming language "Temper." The discussion centers on his career journey, his work on foundational Google products like Google Calendar, his research into web security and programming language design (including the Kaha project), and his current venture, Temper, which aims to simplify library development across multiple programming languages.
Mind Map
Click to expand
Click to explore the full interactive mind map • Zoom, pan, and navigate
Our goal is really allowing developers
[music] to support many language
communities with libraries and libraries
need to have idiomatic interfaces and I
think any overarching framework would
[music]
Hello, welcome to DevTools FM. This is a
podcast about developer tools and the
people who make them. I'm Andrew and
this is my co-host Justin.
>> Hey everyone. We're really excited to
have Mike Samuel on with us. Uh Mike,
you're another Google powerhouse. It
feels like we've had a few of those on
lately. Uh so I mean you're pretty
legendary. Uh you created uh Google
Calendar uh which I use every day. Uh
sometimes much to my chagrin but not
because of your work. It's a it's a
wonderful tool. Uh, and I I have my life
is filled with colorful blocks. Uh, and
I'm really excited to talk about that
and some of the other work uh that
you're doing now. Uh, but before we dive
into all that, why don't you give us a
little backstory? Uh, how did you get to
where you're at?
>> Yeah, thanks so much for having me on.
I'm a programming languages person. I
Yeah, did Google Calendar obviously
partly because I have a strange
relationship to time and the only way I
can keep myself organized is externalize
that. Um but yeah, I uh am a programming
languages person. I've dived into, you
know, web development, but I keep always
circling back to uh to programming
languages. It's partly it's, you know,
do something that's not programming
languages, do something that's not
developer tools related, and find out
something that really really annoys me.
And then at some point, you know, the
the urge to kind of go fix that problem
takes over and dive back into languages
and dev tools and then hope sometimes I
solve a problem, sometimes I don't, but
do something else interesting and and
end up, you know, so my outer loop is
kind of do a thing, get very frustrated
with the thing, try to fix that
frustration. Maybe you bet 300 and
that's pretty good. [laughter]
But yeah, I I' I've done some things
that people have found useful over the years.
years.
>> Cool. Let's let's start at the top.
Google Calendar, big one. You built it
in 2006. Uh building that at that time,
like was it was a different era of the
web. What challenges came with trying to
build like such a fullfeatured calendar
in the web? Because back then, like it's
hard to believe these days, people
didn't look at the web like they do
today where it's like a bunch of apps.
Gmail and Google Calendar and a lot of
other Google products kind of changed
the the vibe there. So like how was that
developing it back in the day?
>> Yeah. So I think it might have been
Google's third JavaScript heavy web
application and and people were Ajax was
the big term at the time. Asynchronous
JavaScript and XML. I [laughter] I think
XML's forgotten. Um but yeah um it was
very much roll your own. And so there
were no large JavaScript libraries. I
think jQuery was probably a glean in
somebody's eye, but JavaScript did not
have a module system. And so it was very
much kind of like trying to build these
large JavaScript applications. And what
did we have? We had a lot of people who
knew nominal typed languages like Java.
And so it was a lot of bespoke tooling
to try to make people writing in static
languages like Java productive at
producing JavaScript. And Google and the
other players, Yahoo was very big at the
time. Um Microsoft as well obviously
were trying to come up with an
ecosystem, bootstrap that ecosystem. Um
and so it was very interesting. um I
think a precursor of uh Typescript. We
had a precursor of Typescript TypeScript
which kind of had overlaid a a Java like
type system on top of what we were
doing. But of course there was no class
syntax at the time. So you were still
making uh classes and trying to model
your problem domain by you know tacking
pieces on to functions, right?
And so I I think uh a lot of where we
are in a much better place ecosystemwise
today than we were then. But uh but
yeah, I think a lot of I I and and
others working with me on on calendar
and people at Microsoft and Yahoo were
doing and and obviously the the Gmail
and Google Maps people. I think we uh
figured out an awful lot of like what is
missing from the JavaScript ecosystem.
And though we didn't actually fill those
gaps, that what kind of came out of that
discussion was how do you take dynamic
languages where you're shipping the
source over to the browser and build
good tooling around it? Bundlers, type
checkers, llinters, all those and
experiment frameworks, all of that kind
of grew out of of a lot of the
experiences that we had then. So was
that sort of the start of the closure
compiler because I I think that clo the
closure compiler was like released like
in 2009 or something but I assume that
it started well before then.
>> Yeah. So closure compiler actually I I
believe an early version of Gmail
shipped with the closure compiler using
the closure compiler and so you think of
closure compiler as this combination of
code quality checker. It does some type
checks and bundler and minifier allin
one. Actually the first version of Gmail
shipped with it as a dynamic just in
time bundler. So uh Gmail started off
with an experiment framework. Maybe if
you're in Google, you're opted into
certain pieces of JavaScript and and web
content. And it, you know, it was part
of our localization story, right? You
get strings for your local. So if you're
if you're using Gmail in Canadian
French, then you're going to get those
translation strings. Those actually
would appear as just lists of strings in
the JavaScript. [laughter] Um, and so
we're taking all this content from
various places, uh, CSS, translation
strings, JavaScript, mushing it
together, um, and mapping identifiers
that appear in code in and in CSS
together, taking all these things,
taking some experimental code that your
account has opted into, compiling it all
into a bespoke, you know, bundle of
JavaScript just for you and sending it
down the wire.
So yeah, it actually started off not as
an ahead of time bundler but as a just
in time bundler specifically built for
Gmail and then it got factored out and
that is what finally made it into um the
open- source closure compiler tools. It
was actually just called JS compiler
inside Google and then eventually the
the term closure became our branding for
that and some template languages.
>> Cool. So after that uh you went into the
security team. You looked at everybody's
code seemingly at Google and did a lot
of interesting things. Is that where you
started to gain the vision of what
you're working on today by like seeing
these crosscutting problems across this
enormous company?
>> Yeah. So, um I think kind of I actually
did a a left turn like you said from
Google calendar into security uh
engineering and and that was partly
driven by Google calendar. So I was
thinking we've got we're building this
heavy interface for calendaring. Um but
a lot of people have very kind of taskspecific
taskspecific
understandings of time. So Lawyers have
dockets. Doctors have rounds.
People who they may not speak any
English. They're not well served by the
web as a whole. They probably have other
ways of doing things. Village life in in
in some place with poor internet
connectivity, right? You know, it it
doesn't make sense to have a Silicon
Valley user experience designer paid
several hundred,000. to economics just
don't work. So, could we democratize to
some degree the interface to to
calendar? Um, and it turns out that very
much depends on [laughter]
security concerns. Can we allow somebody
to create a craft a custom user
interface that serves some small user
community that they understand really
well without opening people up to abuse,
right? their personal data getting
phoned home and that kind of stuff. Um,
and so this isn't yeah I I got into
security engineering from there and and
never did solve that problem. Um, but
that kind of led to the Kaha project
which is a uh object it's a programming
languages object capabilities version of
of kind of the webstack language. Um,
Um,
>> I'd love to talk a little bit more about
that. I hadn't I hadn't heard of that
project. Um I I was thinking being that
you're you're a PL guy, I was thinking
about uh the fact that like when I've
come into the the web world, there's
it's easy to see it as a compilation
target. Let me treat it that way. Yeah.
>> And if you think about like how people
are writing a lot of like web
applications today, a lot of folks are
using like let's say like React and
Tailwind and and things like this and
they're they're distilling it down to
almost this um single language. That's
that's a rough approximation because
it's uh JavaScript and a bunch of other
things under the hood. But it's
interesting that we have like HTML, CSS,
and JavaScript are these like compile
targets. So I'm curious like this
project that you're mentioning how you
were like thinking about that and what
the shape of that was.
>> So uh kaha the uh uh it's it's a
programming language approaches to
security kind of project and and and
just kaha in in Spanish it means um
strong box cash register something you
know a box that you use to protect
something valuable. I think it's it's
cognate with kaisha in Portuguese which
I think means bank. Um and so it's it's
it's we named the project after these
kind of the idea of containerization
within the browser. And so we ended up
seeing chunks of the browser and that
allowed us to and and the end goal here
was mutual suspicion. you want uh
multiple independent pieces of code uh
uh
operating together without each being
able to protect protect their security
properties from the other. Um and and so
object capabilities are an approach to
that. It's the idea you can have objects
that they have some private state. They
maintain their own invariance. Right?
these things are true no matter what
methods you call. Um, and you can hand
off authority, right? The right to
write, the right to render something
into some DOM subree is linked to some
object. And I can deny access to
pointers, right? By reasoning about how
values flow through the system. That's a
skill programmers develop just in the
course of like learning languages and
debugging programs. the by following how
values flow through the system, you're
also modeling how authority and
privilege flow through the system. Um
and and so we got like I think we were
successful in our language design goals.
We were not successful in getting this
adopted by the developer community at
large. Um but what we did I think
spawned a huge amount of kind of web
security research. I think as a
programming language project I I think
we failed as a making the web safer for
people their privacy all that kind of
stuff. Um I think we did a lot of really
good work. So
>> So the language was mostly as much about
like exploring security on the web and
like how you build things for the web in
like a safe way.
>> Yeah. And and I think if I I was
obviously younger than um how time
works, but
maybe if I had to go back and tell my
younger self something, um I think
object capabilities are a lovely
approach that that I use in my own work.
I'm a a big kind of reliable systems are
my jam, right? Um but I think it's not
for everybody. I think you know what I
would go back and tell myself if I could
is focus on crafting languages and tools
so that blue teamers, right, the
security folk who focus on defense and
on supporting developers so that blue
teamers can audit large amounts of
application code efficiently and help
assist developers in in the kind of
security properties that they're
interested in. Um so focus on making
best practices the easiest practices and
also in smoothing interactions between
developers and devops and blue teams. Um
so um I think that's yeah it's very hard
to impose discipline on large groups.
There's a lot of kind of friction there
and until you've got a developer
community that has bought into your
goals, you're not going to be able to by
fiat use this language instead of this
other language. And while you're talking
there, a lot of what you're saying
reminds me of wasome like we have this
containerization primitive now. It's a a
little more heavy-handed than I think
what Kaja did. Kaja seems like it's a
little more fine grain to your
application. What are your thoughts on
uh Wasom after doing all that stuff?
>> I knew the Knackle NACCL native client
um about the chemical symbol for salt um
and and so they were very much doing um
object capabilities
from the point of view of instruction
sets and I think then Mosilla came up
with ASM.js JS which is we can pick a
subset of JavaScript that has where the
semantics of it like it's JavaScript but
you're you're using doing things with
numeric where it's very clear what you
know that this variable only holds a
number right and so you're not saying
it's a number but you're doing things
like oring things with zero so only a
number could come here now we can use
that to do very efficient uh compilation
and I think their experiments with that
led to WASM which I think they were like
we're not doing native client we're not
going to standardize that instead let's
standardize this ASM.js GS and then
they're like, "Oh, we learned so much
from this. Now we're going to
standardize something that looks an
awful lot like native client." Um, and I
think they ended up with a wonderful uh
kind of instruction set and have very
interesting things to say about how do
we do crossplatform
kind of compilation. I think the WSM
runtime is interesting. I'm less I find
the containerization aspects less
interesting. I think you know your
claims about the containerization.
You can use an external kind of system
called interception facility and get everything
everything
that you want. But you know there is to
some degree value in being able to run
like a WASM runtime alongside something
else. And I think it's other than that I
think it's it's like growl like here's a
really good runtime
um with kind of an instruction set
definition that solves all of your kind
of cross-platform problems and we can
run multiple things next to each other.
Um but a lot of times you don't have
control over the runtime. Um, and so
it's it's not a broad-based solution to
like if you're doing a programming
language and you're going to compile to
binary and you control your runtime, WSM
is a is I think a wonderful choice um
for for kind of building your runtime.
But I think these one runtime to rule
them all approaches,
you know, um I think they're
interesting. I I don't think they're
actually going to succeed at ruling them
all, right? I think if if one of them
was going to win, I think Growl would
have achieved kind of greater
penetration, market penetration than
than it has.
>> Yeah, it's a I think anytime you you set
out with a project like that and you're
trying to solve like everyone's problem, you're
you're
technology either gets like so
overloaded or you know it like you have
to compromise somewhere, right?
>> Yeah. And I I think kind of the the one
thing that WASM doesn't have and and
it's an intentional choice. I think
probably the right choice is it doesn't
have an object model, right? Um and I I
think the Wom interfaces I think there's
there's a sub project WY or something
which is is is is trying to address that
problem and and and it's a very
difficult problem that they're they're
biting off, right? You've got small
string optimizations. You've got like
big int optimizations which are critical
like and those blur the idea of like
what am I what is this data? It could be
a pointer, it could be something else,
right? Um and so there's low-level
problems with having an object and by an
object model I mean you've got some
value and you need to be able to ask it
questions, call methods, get properties
out of it. And so a question might be
like what is the third character in this
string and you that that's a question
that doesn't make sense across
programming language definitions at high
level semantic levels and you can't just
and and many language runtimes at the
low level they also have different ways
of answering that questions again small
string optimizations for example um and
so you it's not trivial to just say I'm
gonna have my Python objects talk to my
rust traits.
Um, so yeah, like I I just yeah, Wom is
a very is a solution to a very specific
problem and is a very high quality
solution. I I sometimes hear people and
they seem to think that it's it's
solving more kind of programming
language stack problems than it's
actually claiming to. Right.
>> Totally. And I think that's a good
transition. So let's talk about what
you've been working on more recently. Uh
so you have this uh company sort of
around this uh I'll say programming
language uh temper. Um I would love to
learn more about like what motivated you
to start that uh starting a business
around a programming language. Uh it
seems like a tough thing to do. Uh yeah,
>> just like starting a business around a
database, you know, these are like when
you have very technical products, uh the
the business side can be hard, but would
love to hear like sort of what your
motivation is and um maybe I don't know
tell us more about Temper.
>> Yeah. So um I guess we uh talked briefly
about my tenure in in Google security
engineering group and I think the last I
was at Google for 17 years and I I left
six years ago. My last kind of chunk of
time there, I was on a team that was I
think there were 10 of us. And I think
between us, we knew a ridiculous number
of programming languages. It's it's the
if you're doing security engineering
work, you can't just learn JavaScript,
the good parts. You need to learn the
sneaky parts and the really really bad
parts, right? [laughter]
This is all defensive code. Um and and
so when I say I know a language as a
security engineer, it's it's you're
focusing on if Python is a security
engineer, you write code and you're
like, okay, uh Python 2,
what how the string what the strings are
depends on car flags passed to the
compiler. [laughter] So it's these
little strange things that you you're
you're always cognizant of of uh corner
cases. So we had 10 people who knew an
inordinate number of languages used
within Google despite Google's best
efforts at topdown say these are the
only supported languages and we were
tasked with taking on kind of
infrastructure projects writing library
code improving DSLs and build systems
and and and static compiler checks. Um,
and yeah, it you we had to be incredibly
tactical because can you maintain 10
parallel versions of a library that does
some incredibly important task? And the
answer is yes, but these these teams are
hard to staff, right? Um, and the more I
thought about it, I the more I thought
if we had one way of specifying a
solution, we could provide so much more
value. And then I started looking into
it. Hey, I'm maintaining this library in
Java which in HTML sanitizer which is
used by the Android and iPhone Gmail
apps the the iPhone uh app by some J2
objects Java to objective C translation
right um there's nothing about HTML
sanitization that is specific to J the
Java language right the definition of
here's the HTML grammar.
grammar.
Here's what makes HTML safe, right? I
can take an email body, HTML email body,
and turn it into something that's safe
to render in the browser without risk of
XSS. That's just a string to string
transform. Like I could have solved that
problem for the entire open-source
community if I didn't have this language
multiplicity problem. And as one does,
you recognize a problem and you obsess
about it. And if you're a little weird
like me, you start seeing that problem
everywhere. Um, and so, uh, I left
Google for a host of reasons, um, on
good terms, but, you know, mostly due to
do with where I was in my life, right?
Um but uh I left Google and I started
looking into it and digging around and
doing comparative programming language
linguistics which not really a thing. Um
and I started to look at like what is
actually preventing us from writing a
library once to solve a problem. I want
people who think deeply about a
particular problem to be able to support
all the programming language
communities. And and so part of it was
just really crystallizing that goal, but
also I did a lot of this comparative
linguistics and realized, no, I I think
there actually is a, you know, usable
language in the middle of all these kind
of intersecting,
you know, constraints. Um, and so that's
what I've been working on. Yeah, just a
programming language designed from the
ground up to translate well to all the
other languages. kind of going back to
Wom rather than having one runtime to
run all the languages. This is one
language that kind of works by
translation and fits into any runtime.
And so it to some degree it's it's the
flip, right? I'm not trying to solve the
same problem as WSOM. Um I'm solving
something else. But but the real goal is
allow everyday programmers to who
understand some problem domain really
well to support all the other
programming language communities with a
library that kind of encapsulates their
knowledge about that problem.
>> So this is this is so fascinating. So
you're you're sort of building this the
highest level language that just like
transpiles or compiles into target
languages in in all the different
places. Um are are there things that you
explicitly like hey transpauling to like
this kind of language is like this is
out of scope you know I'm like not
trying to
>> get everything and so yeah I mean I
think broadly we talk about language
paradigms right and there's functional
paradigms and there's object-oriented
paradigms and then there's logical
paradigms and I think if you did a
programming languages course in
university you probably heard heard
about prologue and the you and prologue
it's it's a full-fledged programming
language but you're probably not going
to write um doom in it right um I mean
somebody probably has but um it's yeah
it's so there are I think we fit
squarely into the kind of light
objectoriented right uh but with
functional affordances
um scheme and so you know any kind of
imperative functional language where
you've got mutable state we can do that
well so we can do your lists we can do
uh JavaScript is is functions as values
it's functional in that sense pure
functional languages it gets a bit
harder often they have very particular
constraints around things like effects
right and so uh and a language like
effect is probably going to be harder
for us but you know I It it actually
turns out functional languages you can
there are ways you can bolt this on
object-oriented languages like Java and
C um easy for us uh JavaScript and
Python you've got classes you can change
those classes we just translate to
classes that we don't use that extra
dynamism right and so that's also a
sweet spot for us and so I think you
know kind of the the emerging consensus
it it went from the 70s and 80s where
maybe we have languages we built the
database it
um or very memory oriented languages
like cobalt and forran where you're like
I think about how I'm going to lay stuff
out in memory and how I'm going to move
data through the memory and transform it
and I don't really think about values
prevalue orientation languages uh
surprisingly I think we have something
useful to say there but but yeah they're
very different and require kind of a a
somewhat different approach but yeah
that that's what we're aiming at is uh a
language that is very familiar to
everyday programmers in the combination
of of functional and object-oriented
uh that I think Martin Oderski uh
described very well with Scola um but
you know we're not aiming at at Scola's
user base our language it kind of it
looks like TypeScript right just so that
it's it's familiar and easy to read
>> so when designing this like this
language of languages like are you
constrained by the languages you compile
to? Do those languages influence
decisions you make in temper?
>> Yeah. And so that's one of the reasons
why I spent a couple years doing
comparative linguistics was just to
understand and I think that's what
differentiates us from from other
languages like uh Scala. uh it's a JVM
language that calls itself a
multiaradigm language. So it's it's very
functional, but it also interfaces with
Java code well that's object-oriented.
Um and Scala works on the JVM. It also
translates to JavaScript. There's a lot
of languages out there that translate to
JavaScript. I think uh even some of the
new beam VM languages like Erlang and
Glee. Uh what they don't do though is
they don't tend to take the next step
and like there's a lot of Python code
out there and it would be awesome if we
could just interact with a data
scientist's Jupyter notebook, right?
They don't do that [laughter] and that's
Python uh for a variety of reasons is
just harder, right? Um and uh Scola
tried to get running on the net runtime.
So C for example, right? I mean you
would you would think F and Scala
actually seem to have a lot in common.
Scala already interacts very well with
Java programs, right? You can make mixed
programs from Java and Scola, run them
in the same VM, no problem. It turns out
C thetnet runtime uh I don't want to get
too jargony there's it has a limited
form of monomorphization which
complicated that incredibly and
especially the way like nullable
references to things like integers and
interactions with that and so despite
putting quite a bit of effort into it
Scola never got to run on the net
runtime So yeah, if you want to run
inside many many many runtimes, you need
to look at these and make very specific
choices and bite some uncomfortable
bullets um early in your your language
design process. And so that's what
that's really what differentiates us. We
designed specifically with this goal in mind.
mind.
So at the start you had like a set of
languages that are like these are the
ones we'll support and like it's not
like it'd be infeasible to fold in more
after the fact since we've already made
all these decisions. Yeah. There's
there's there's no kind of real it would
be nice if there was some overarching
theoretical framework where we're like
and now [laughter]
we we've described each of the existing
programming languages in this
overarching theoretical framework and
now here's the language design falls out
of that theoretical framework and and
that's it's it's not how language the
way language semantics are done. it it
just there isn't and I think our goal is
really allowing developers to support
many language
uh communities with libraries and
libraries need to have idiomatic
interfaces and I think any overarching
framework would not capture kind of
idiomaticity and so what we really are
doing is picking a set of definitional
elements ments that translate well and
then doing some al and augmenting that
with um some very careful API design so
that we can get consistent semantics
around weird strings right they started
off as arrays of bytes and then we
realize hey the world doesn't just speak
English and a little bit of Greek right
I I forget exactly what's in the
extended ASI but Um and and so strings
went from a fixed width encoding
to UCS2,
another fixed width encoding just twice
as large to UTF-16
and UTF8 which is variable length
encoding. Right? So yeah, we're
combining very specific design choices
around language definitional elements um
to that map well to the 20 most popular
industry programming languages today.
Hopefully 10 years from now they'll
still serve the 10 most widely used
programming languages. Um so that's
that's kind of our our goal and yeah an
understanding of our user community. you
shouldn't need to understand the
idiosyncrasies of memory management in
10 programming languages to be able to
uh write libraries with us and then that
focus on on idiomaticity. Um and so
that's yeah it's it's it's kind of like
is there any reason can you construct a
language or can you pick an existing
language that we can't translate to?
Yes. Yes. Sure. But you know it's it's
by analysis of programming languages
understanding the trends in programming
language development so that we can try
to abstract that out and and produce
something useful and I think if we're
successful to some degree we will shape
[laughter] our own future right so one
strategy is is get big enough fast
enough so that um you affect the
conversation in ways that uh continue
your value forward, right?
>> Yeah, absolutely. So, if like enough
folks are using temper and writing
libraries in it, then the downstream
language is like, okay, you know, I'm
thinking about these constraints or
adding these features, but this is
actually going to make it harder for
people to interop with. So, like maybe
I'll like take a different path or
simplify or something. Yeah, that's
definitely a an interesting strategy and
I think we kind of see that in in some
places too of like especially like
compiling to JavaScript which you
mentioned being like this thing that
sort of ends up shaping how people are
thinking about programming language
design which is so fascinating to me. Um
I want to talk a little bit about the
experience of writing a library in
temper. Um, so I've noticed just like
digging through some of the the samples
in some of your your past talks that um
a lot of the expression of of temper
code right now is sort of an illiterate
programming style. You have this
markdown where you have like your uh
this sort of like pros your sort of
description of what's happening. You
have your your temper definitions for
for logics or the logic or types and
then like even tests sort of like being
collocated in this in this like markdown
file for this feature. um talk a little
bit more about like the explicit design
um and like sort of I don't know the the
the experience you're going for here and
how you how you think like people
writing temper like what what it looks
like for them.
>> Yeah. And so I think there's a you can
write a file and if it ends with temper
it's it's just code in a language that
like I said earlier looks a lot like
TypeScript, right? We wanted I I'm not
interested in doing syntax design. I
want people to be able to read it
easily. Um, but yeah, you can also uh
write a temper.md file and if you indent
your code by four spaces, then that's an
unfenced code block and we just pull
that out. Um, and so yeah, the idea here
is I think literate programming goes
back to uh is it can with uh latte? [laughter]
[laughter]
>> Yeah, it's got
>> Yeah. And so I think Canth had some very
explicit goals, some of which worked and
some of which didn't. So I call it semi
literate programming. Can wanted a a set
of macros that would allow for natural
language style coding. That was very
much back in the day. That was an
interest and cobalt obviously build
itself as here's a language that is
close enough to English that a project
manager can read the cobalt code. Now it
turns out cobalt is also incredibly
verbose. So you can read it. You
probably want to read 50 pages to kind
of where a two paragraph English
synopsis would serve. But you know you
could. So yeah, it it's it's jettisoning
those goals. And the idea here is, you
know, libraries have a narrative
structure, right? It's not a program
which starts at a particular point and
ends at a particular point. A library is
a toolbox, right? And so you can start
off in your markdown by explaining
here's the problem we're trying to solve
and why, right? And then you indent some
code. Here's a definition. Here's how
we're expressing. And so the the natural
language pros what and why the code gets
into how and then for example and now
we've got uh some unit tests and so that
it's kind of the the goal here is allow
for storytelling right and we just pull
out the code parts uh reorder them based
on some dependency analysis and then
translate them. But the markdown is
really a first class part of the
ecosystem. So I I think I refer to
Jupyter notebooks. I there's a huge
amount of interesting stuff on how data
scientists I think uh more we could
learn more from how data scientists work
in in in producing languages for more
traditional developers. But uh Jupyter
notebooks are not a first class part of
the Python ecosystem. you can't go from
a Python file and import a notebook,
right? Um and and so I think we made a
very intentional decision. Design the
module system, the library system, the
packaging and these highlevel uh
groupings upfront and make sure you know
where we're doing this embedding. Um
it's also a first class part of the
ecosystem. It works with imports. It
works with our dependency analysis
stuff. Um but then I think there's
another goal here and you know we want
problem solvers to be able to solve a
problem comprehensively across you know
the open source ecosystem or across a
closed source organization right um a a
silly example it's it it seems trivial
how many weekdays are there between
these two dates as far as the
organization counts right you know
that's kind of something you should be
able to solve you might be able you
might need to do that in a Monte Carlo
simulation, you know, very fast in in
Python. You probably need to be able to
do it in your customer management system
when you're computing things about
coupons, right? Maybe that's written in
Visual Basic. Um, and you know, you
probably need to do it in backends and
maybe on your customerf facing mobile
apps, right? So, kind of solve that
problem, but that requires input from
developers and subject matter experts,
right? Um I had you know the subject
matter experts who do not have computer
science degrees you know often they're
lawyers or they're business development
folk. Um and so the way I see this
working is you draft out a document in
markdown or maybe a more traditional
standards format like bike shed or EC
markup or respspec. Right? one of these
formats. Um maybe the subject matter
experts contribute most of the pros. The
their engine their engineering point of
contact is going to write the code that
implements that. Both sides might be
implementing tests, right? Tests tend to
be pretty formulaic. It's actually I
I I worry about the overuse of AI
methods in in producing code. So our
translation is all compiler methods
based, right? Um I think there's
opportunity, but I think one opportunity
for it is a a subject matter expert,
maybe they're a social scientist,
uses AI to to turn their description of
a corner case into a unit test. Maybe
that unit test compiles, maybe it
doesn't, but they can add it to the doc.
Um and they can say, "Here's in in in in
human language. I don't want to be too
English ccentric in pros here's why this
corner case is important then indented
for things test
curly brackets assert blah blah blah
blah right you know
>> so the literate programming style see
like I love how you you talked about
Jupiter like it's odd to me now that I
think about it that we don't have these
environments that kind of match how we
would want to develop things like it
makes a lot of sense like I'm writing a
library it needs documentation all one
file and then that being like the unit
of of thing that like is really cool to
me and an interesting idea. Uh but the
literate programming style also seems to
really go well with like AI and what we
have today like you just being able to
describe a thing and then like that's
the first thing you do then the second
thing you do is implement. It's like it
feels like that feedback loop is
probably pretty powerful within temper.
>> Yeah. if you want to be able to use AI
tools um to refactor code or extend it
or add to it um having that context
about why we're doing things right
there, right? I don't have to assemble
like my documentation
and I I think documentation does get out
of date even where it's when it's living
right next to the code that implements
it. But I think yeah um having having
that documentation that is is readable
by the subject matter experts but also
by AI tooling and by the compiler I
think um gets you that that you the the
context that works on multiple levels
the why the how and yeah like also just
rerun these tests internally
um uh when you're doing your uh agentic
code generation and stuff. I'm afraid
I'm I you know I I try to keep up up to
speed on the the AI coding techniques,
but uh some of the terminology I I've
never really seen crisp definitions of
what it quite means.
>> Yeah. And the space is moving so fast
too that it's like unless you're like
really working in it every day, it's
hard to stay on top of. I wanted to I
mean we're on the topic of AI and
usually as we're wrapping up we always
like to ask a future facing question and
um you have this long story career
working across uh large applications
across security domains where you have
to go deep on languages. You're thinking
a lot about how people write and share
logic across ecosystems or do you know
security audits across ecosystems and
you're building this language that can
transpile itself into a bunch of other
target languages and trying to think
about language semantics and ergonomics
and everything as you're doing that. Um,
and this is like an incredibly
interesting and valuable tool. And at
the same time, there's this sort of like
shift in the industry about how people
are writing and thinking about code.
Some of it good, some of it not good.
Um, a lot of folks are using AI as a
translation layer between libraries. So,
they'll be like, "Oh, I I see this
Python library. I want it in JavaScript.
I'm going to like throw it in claw and
ask it to do a thing." And it like spits
out something. Um the the thing is
there's a separation and a divorce
between like intent and knowledge and
like the thing that jumped out to me
earlier is you were talking about like
as a security engineer on a language I'm
thinking about like how does string
allocation work at the baseline level
because there are those things that you
can use a language like in a very valid
way and it's like unsafe uh because you
have to know some of those underlying
semantics and then I'm just curious
about like as you think about how we
build software going forward, how you
want to see us build software going
forward and like maybe the the trends
that AI are pushing us in like um what
are the opportunities that you're
excited for with temper or just like the
industry and like what like worries you
uh about some of these shifts?
>> So what worries me about the direction
the the software practitioner in kind of
our industry is is headed as a whole or
>> Yeah. Yeah. if you had to if you think
about like well let's just start with
opportunity like so you're working on
temporary you it seems like there's this
fantastic opportunity to sort of like
help people write you reasonable code so
let's let's just start there like what
is the what is the opportunity for us
going forward uh when we think about how
we write software
>> yeah and so I mean I think um you
mentioned security and this is something
obviously it's on my mind because it it
has it's a life that I I've lived and I
think the beer in the room is AI so uh
elephant in the room uh it's in the room
with us and I think uh AI for coding is
a lot less problematic than the effect
of AI on for example elementary school
education or uh artists and musicians
who who create copyrightable works for a
living right so just I think um but we
do want to encourage responsible AI use
and I think today's systems, the systems
we build, they're multi- language
systems. We've got, you mentioned like
JavaScript heavy apps when I was working
on Google calendar and and it was not
app-based. You had a website, you
visited the website, the website talked
to a server, the server talked to a
database, we're all friends, right? Um,
but you know, today's languages are even
more multi- language than before. We've
got data scientists working in Python.
We've got the web stack he is heavily
centered around JavaScript and WOM.
We've got backend languages usually done
in a language like Java C where you can
get hundreds of people working on
essentially the same program um or lots
of people building microservices, right?
These the our systems are multi-
language systems glued together by JSON
over HTTP. >> [laughter]
>> [laughter]
>> This is not where any distributed
systems academic would have predicted we
would end up with, but it is what we're
dealing with. And so I think I think the
the where temper can really add value is
we can produce more robust systems. Like
for software to be good for people, it
needs to reliably do a thing that they
want, right? And so you know we can
produce more reliable systems better
serve our end users if we can share
across all those nodes in a system. If
you know the data scientists simulations
their results are in fact accurate
because their simulations of logic are
actually using the same definitions that
we're going to deploy in production.
Right? if you know our mobile devices
can operate in offline mode because they
can accurately simulate and some of what
the backend will do if they were
connected, right? Um if you know all
these kinds of if we have the same type
definitions on two sides of a network
pipe and the encoding and decoding logic
have some useful relationship between
them. Now we've got type guard rails.
Maybe we can extend our static analyses,
right? Our static analyses right now I'm
analyzing your Python program, but it
just gets a value from one web service
and sends it off to another, right? Like
that that code that I'm analyzing, it's
it's it's a it's a little disconnected
island. Can we start to stitch together
our analyses if we have these common
reference points? Um, and I think to
some degree, what are AI best practices?
Nobody knows what those are going to be
yet. I think a lot of people are making
predictions, but if one of the things
that we seem to agree on is somebody who
understands how systems fail needs to
look at the systems we're producing. If
we're producing code in multiple
languages and we can get some of that uh
in a language that translates reliably
to the other languages that's reducing
and test all those translations by
translating our unit tests that gives us
confidence about the system. And so I
think um as we figure out what are the
ways what will software practitioners
what will software development look five
years from now. Um I think Keer's value
proposition is not like use this
language instead of another one. Um it's
use it alongside these other ones and
support the larger development. But I
think even within the most code is
written by AI scenario which like I mean
you ask AI to translate a specification
into code now are you maintaining that
specification and the code in git or do
you like it's the code right like um if
you're translating something into five
languages using AI are you now
maintaining five things times as much in
git No, I I think traditional compiler
methods combined with AI are the
probably only feasible path towards like
semi-reliable software that kind of
comes out of this ongoing discussion
that we're having. And I think temper
fits very much in that multiplier for
kind of traditional compiler methods.
>> Well, it seems like you've built
something really cool here. Uh it's a
grand vision. I hope it plays out. I'll
be watching from the sidelines, but
thanks for coming on and talking about
it. this was a really fun and
enlightening conversation around all the
different language things that you've
been around. So, thanks for coming on
and talking about it.
>> Yeah, thanks Mike. Uh, Temper is
incredibly interesting. [music] Uh, if
folks want to learn more about Temper,
where would the where would you like to
point them to?
>> Oh, uh, I should probably have had that
available. So, uh, Envy Samuel at on
Blue Sky is where I chat with people.
Um, let me just drop you a a link in the
chat um with uh our and we're getting to
the point in the language where um
[music] it's still early adopter style,
but it's getting to be a fun language to
work in. And uh yeah, that temperlang.github.iotld,
temperlang.github.iotld,
that's temper language documentation.
>> Nice. Awesome. Well, thank you so so
much, Mike. This [music] has been an
absolute pleasure. uh and excited to
learn more. >> All right.
>> All right. [music]
Click on any text or timestamp to jump to that moment in the video
Share:
Most transcripts ready in under 5 seconds
One-Click Copy125+ LanguagesSearch ContentJump to Timestamps
Paste YouTube URL
Enter any YouTube video link to get the full transcript
Transcript Extraction Form
Most transcripts ready in under 5 seconds
Get Our Chrome Extension
Get transcripts instantly without leaving YouTube. Install our Chrome extension for one-click access to any video's transcript directly on the watch page.
