Running Doom in TypeScript’s Type System with Dimitri Mitropoulos - JSJ 684 - JavaScript Jabber

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:05):
Hello, everybody, Welcome to another exciting episode of JavaScript jabb Er.
I am Steve Edwards, the host with the face for
radio and the voice for being of mine. But I'm
your host today, whether you like it or not. Anyway
with me today, I have on our panel mister Dan Shapier.

Speaker 2 (00:19):
How you doing Dan?

Speaker 3 (00:21):
As well as can be expected given that I live
in Tel Aviv.

Speaker 1 (00:25):
Yes, I would say it's rather explosive times, there isn't it.

Speaker 3 (00:29):
Yeah, you can tell Aviv if you want, if you
want to joke about it.

Speaker 2 (00:32):
Yet is it so? Yeah?

Speaker 3 (00:36):
If you put in this way, there's greater than zero
possibility that doing the recording today, I'll need to jump
off and run to the bomb shelter.

Speaker 2 (00:43):
Bomb shelter.

Speaker 1 (00:44):
Yes, yes, if you've been watching the news, you should
know what's going on in Tel Aviv. We'll leave it
at that.

Speaker 2 (00:52):
With me.

Speaker 1 (00:53):
With us, we have our very special guests, mister Dmitri Metropolis.

Speaker 2 (00:57):
How are you doing, Dmitri?

Speaker 4 (00:58):
Great? Great, happy to be thank you.

Speaker 1 (01:00):
And yes, we were asking him ahead of time that
as Metropolis has in the same city where Superman lives,
so you know, it's a it's.

Speaker 4 (01:08):
An old Greek name, so it's probably in the old days,
was pronounced a little different. You know. Ancient Greek was
a tonal language actually, so it had pitches like Chinese. Yes, right,
very different from how it sounds today.

Speaker 2 (01:20):
Yeah, that's true.

Speaker 1 (01:21):
I've spent some time in China, and I have friends
that have lived there for a long time and speak
China Chinese, and the tones make a huge difference in
what you say. You can say one word with two
different tones and they mean two different things. And if
you get lazy, you can say something that you really
didn't want to say.

Speaker 3 (01:40):
It literally means city, doesn't it.

Speaker 4 (01:44):
Yeah. And by the way, which city, people, I think?

Speaker 3 (01:48):
Oh, okay, And by the way, which city do you
actually live in?

Speaker 4 (01:52):
I live in here in Michigan. I live like a
bit north of Detroit, the Mitten State. Yeah. People make
fun of us because you can, you know, you can
say where you're from by holding up your hand, right.
But you know, hey, whatever, are.

Speaker 2 (02:05):
You one of those up people? Are you down on the.

Speaker 4 (02:07):
No, I'm not there. They're called us. Yeah, I'm not aperuh,
but uh, you know it's beautiful up there, so I
won't hate on him.

Speaker 1 (02:17):
There's a I still have this really old humor song
on my computer from a group called the Upers, and
it's about the second week of deer Camp.

Speaker 2 (02:25):
Uh. They were like a little comedy group back in
the day.

Speaker 4 (02:29):
Sounds about right.

Speaker 2 (02:30):
It's a very old song.

Speaker 1 (02:32):
It's a second week of deer Camp and all the
guys are here anyway, So moving on to our topic, usure, Uh,
we're going to talk about Dimitris.

Speaker 3 (02:42):
Oh, I would like to introduce the topic. If you
don't know, I was first of all, I have to
mention that it was when it just when it was announced.
It was obviously my pick on the very next podcast
and I and I basically called shot a shotgun on it,
so with y else could pick it because for me, it's

(03:02):
a totally insane, wacky and out of this world project.
It's simultaneously amazing and I think also educational. The fact
that it's that it was actually created and the amount
of effort that you put into it, based on the
video that being released about it is more or less insane,
and we will obviously learn more about it. So without

(03:27):
further ado, what did you do?

Speaker 4 (03:30):
I think I had a thought, and the thought never
I could never let the thought go. I think that's
ultimately the answer to the question of what I did,
and the thought was, yeah, but there's no way you
could run doom and typescripts type system. You know, that
was the thought. I think that I have opinions that
informed that thought, and one of the core ones is

(03:51):
my feelings about what it means for a system to
be turning complete. So a couple of years ago, someone
posted an issue It's still the Open on the Typescript
repo saying, hey, I was just playing around and I
noticed I think the type system is turing complete. And
it got a lot of press and it was very
you know, we all had a laugh, you know, everybody
typescript nerds had to laugh about it. But since that time,
I think people would say, I'd hear here and there

(04:13):
if someone say, oh, well, but if it's turning complete,
then of course it could you know, X Y Z thing,
and I just think that's baloney. I just it's totally
I just fundamentally cannot get on board with that kind
of thinking because Turing completeness, well we could.

Speaker 2 (04:29):
Incomplete, yeah, touring complete.

Speaker 4 (04:32):
So there's this guy, Alan Turing, and he made quite
a lot of contributions to society, but one of them
was he described a system that we now call a
Turing machine. And Turing machines can be used to represent
arbitrary calculations and you know, perform arbitrary CPU work, and

(04:53):
Touring machines are extremely are well known for being extraordinarily simple. Actually,
you can do it in binary. You can do it
with like a ticker tape. You can think of this
little bug kind of dancing through a ticker tape, you know,
looking at the one zero or one bit in front
of it and making a decision about where to go
and what to do next.

Speaker 3 (05:10):
Basically, it's if I remember correctly, it's a theoretical machine. Yes,
that is the simplest mechanism that can perform any computation.

Speaker 4 (05:20):
Right, So, if you can show that a system is
Turing complete, there's a chain of mathematical proofs that demonstrate
that you could build your way up to creating an
extraordinarily complex system like any In fact, any computer could
be built from the bones of a Turing complete machine theoretically,

(05:43):
and the theoretically part is where I totally fall off
from the bandwagon, because to me, it's not interesting. So
if I told you, hey, you know, Dan, I have
this machine in my basement and it can compute you know,
one plus one, except that it will take one hundred
million billion years and all the atoms in the observable universe.

(06:07):
Isn't it cool?

Speaker 3 (06:09):
Now?

Speaker 4 (06:09):
Tell me Dan, how cool do you.

Speaker 3 (06:11):
Think that is? How? That's how, that's how we're supposed
to prove string theory. I believe they need to build
a Liege hedron collider the size of the universe or
something along these lines in order to prove right.

Speaker 4 (06:24):
So like, I just don't find that super interesting. And
so what happened was, you know, I have a YouTube
channel that I participate in called Michigan Type Script and
I help out with making videos there, and I got
the thought one day, you know, would be a cool
project is to show what the blocker is. Why, to
demonstrate my the thing that I just laid out, which

(06:46):
is that being turn complete is not enough. You need
a lot more into in order to do anything of
any like real significance. And I, you know, thought this
would take one or two weeks maybe of like putting
around with the type system. You know, I have to
mention like I had done a video series on advanced
typescript type stuff. So there's these things called the Type

(07:06):
Challenges made by Anthony Fou really great stuff, but they're
they're very hard, and like the last one is making
a Jason parser purely in Typescript type system. So some
people are not aware that you can do arbitrary kind
of kind of computations. It's called type level programming these days,
and there is a lot that you can accomplish with

(07:27):
very small building blocks, almost like what a turning machine
gives you. And so I just thought I would work
on findings.

Speaker 3 (07:34):
Stop you for a second, please, I'm thinking that we
are potentially losing some of our listeners and the distinction
between running things in Typescript versus running things in the
Typescript type system, because it seems like, essentially it seems
like it should be the same thing, but it totally isn't.

(07:58):
So maybe you can make this distinction clearer before we proceed.

Speaker 4 (08:02):
I love it, Thank you for stopping me. Yeah, it's
a very important distinction. So Typescript's whole point is to
add types to JavaScript. So JavaScript is an existing language,
but it doesn't have a type system in the sense
that you can't say here's a variable, and this variable
is a number and it can only be a number,
so if you try to assign a strength to it,

(08:23):
we're going to have an error. That's something that typescript
gives you, but JavaScript is lacking, and that's the whole
point of typescript in the kind of the most essential sense.
Over the years, as typescript has evolved, there are more
and more things that typescript has enabled you to do
with the type system. So originally it was very simple

(08:44):
types like I just said, like number and string. But
eventually they started being able to do things with what
we call literal types. So what if instead of saying
I have this variable and it's a number, you can
only assign numbers to it. If I say I have
this variable, you can only assign these specific numbers to it.
You can only assign one, two, three, and four to

(09:05):
this variable. And if you try to assign five, even
though it's a number, we're going to give you a
type error. So there are literal types, and you can
do this with strings too, So you can say I
have this variable. The only types that are allowed to
assign to this variable are red, green, and blue. These
you know R E D G R E E N
D L U E those are the available string options

(09:28):
that you can assign to this type. Well, there's another
thing that they added that goes even further, which is.

Speaker 3 (09:35):
That and again I'll stop you for a second just
to clarify why this might be useful, because and I
think your example with colors is excellent because, for example,
if I'm implementing a type or a variable that's supposed
to have contained a color that, for example, use in CSS,
and I don't want to allow any arbitrary string to

(09:59):
be assigned to it. I want the static type checking
to validate that at run time. Well, actually at build time,
I'm validating that I can only assign but the specific
string values to it, and if I try to assign
a general string to it, I will get a development

(10:19):
time or buil time type error.

Speaker 4 (10:21):
Exactly. Yeah, what if you put it you just have
a typo. You know. Typescript is really amazing because it
can keep these kinds of errors, this whole class of
errors out of the program.

Speaker 3 (10:30):
I write red instead of bread or something along it.

Speaker 4 (10:33):
Right, exactly, yeah, perfect. So the second thing that they
added is something called generics. Generics exists in lots of languages,
but generics is a way to operate on types. So
it's kind of like a function. You say, I'm gonna
take as a parameter some other function, Like we were
saying red, green, and blue. Okay, So I'm going to

(10:54):
take some other type and you can add to it,
or you can change it, or you can inspect it
and see what it does and do something different. So
you can say, oh, if it's red, I'm going to
return the number one. If it's green, I'm going to
return five, and if it's blue, I'm going to return
one thousand. You can do stuff like that.

Speaker 2 (11:09):
Is it an oversimplification to say? It's almost like a class.

Speaker 1 (11:13):
Override and object oriented programming where you can take something
and extend it.

Speaker 3 (11:17):
Yeah, but it's done it it's build time or dev
time rather than at run time. You're specifying the type.
The arguments to the type are themselves types.

Speaker 4 (11:32):
So it's kind of like a It's kind of like
its own programming language tucked away inside of JavaScript. It's
like you have JavaScript, and then you have this other
language on top that allows you to kind of speak
in these other terms, and it's often in reference to
what the JavaScript is doing. I mean, that's the intention.

Speaker 3 (11:47):
I'd like you can have another example. I'd likely to
try to give another example that might clarify why something
like this might be useful. Let's say I'm implementing calculator,
a hand calculator, and I want to do it in
a type form, and I want to represent an expression.
For example, I want to represent the addition operator. So

(12:12):
the addition operator has something on the left, the addition operator,
and then something on the right, and I can say
that an expression is a generic type that has a
number on the left and an expression on the right.
So it's so it's am I am? I kind of

(12:33):
getting the point across, Steve.

Speaker 2 (12:36):
Yeah, I think so.

Speaker 1 (12:37):
I mean, being the visual person that I am, probably
be easier to see some code examples.

Speaker 2 (12:41):
But yeah, I think I give you.

Speaker 4 (12:43):
For you sure, Yeah, so you can you can provide
you can create functions that are kind of within the
type system only, and you can create types that you know,
that are just artifacts of the type system that don't
exist at run time. So JavaScript is really weird because

(13:04):
you know, we kind of attached a type system to
it later. I mean, this also kind of happened in Python,
but it's a part of Python, whereas in JavaScript, you know,
there is no part of JavaScript that includes a type system.
It's collect purely typescript and the type Script team there's
no spec for it either, right, it's just something that
they kind of developed and designed and they have documentation,

(13:24):
I guess. But the JavaScript language itself is standardized and
has a specification that's completely abstracted from the engines themselves,
like V eight that run the JavaScript code.

Speaker 2 (13:38):
That's that's the EKMAS.

Speaker 3 (13:40):
Yeah exactly, Yeah, EKMASCRIPT.

Speaker 4 (13:42):
That's an European Computer Manufacturers Association. Yeah.

Speaker 3 (13:45):
By the way, an anecdote, that's the origin of the acronym.
But EKMA is no longer an acronym. They've turned it
into the name. Oh really, yes, so it's literally trade.
It's trademark as EKMA, the word EKMA.

Speaker 4 (14:03):
That's interesting. I had no idea. Well I'll put that
in my bag of bar trip. Yeah. Yeah, useful knowledge exactly.
It's cool to it's kind of fun to know this
kind of stuff though. So what happens is similar to
how we were talking about a turing machine. As you
start to have bigger and bigger building blocks that you construct,

(14:26):
you can start to do harder and harder things. And
my thesis was on this project. You know that may
be true, but there's going to come a point when
you hit some kind of immovable object. There's going to
be some unstoppable blocking point where you can't continue pushing
because you hit some memory constraint, or you hit some

(14:49):
CPU time constraint, or you hit some issue that is
just not solvable with the tools that we have today. Like,
maybe someday someone could do it, but I was sure
that it would not. It would never be possible in
today's Typescript to be able to do something like run
doom and we can talk, we can get into like
what does it even really mean to say that you
ran doom? And I can explain that, But that was

(15:11):
basically the idea of the project.

Speaker 3 (15:13):
But again moving slightly back to the type system itself
in order to say that the type system might be
touring complete. And by the way, typescript is not the
only one. I encountered a similar situation with generics and
C plus plus back in the day.

Speaker 4 (15:28):
Yeah, C plus pus templates are also.

Speaker 3 (15:30):
Yeah, exactly. So basically the fact, once you have generics
and the generics are flexible enough, you become touring complete
because you get effectively loops and conditionals, which is basically
what you really need in order to kind of be

(15:52):
touring complete.

Speaker 4 (15:54):
Interesting side note on that, I learned that actually the
definition of a Turing machine does not include the ability
to loop it. Uh, it's it's so like CE so
c C has a formatting syntax, right, there's like the
C print F formatting. Yeah, it's also considered Turing complete,
but you need to invoke it over and over again

(16:15):
in a loop outside so.

Speaker 3 (16:17):
You can write infinitely long programs.

Speaker 4 (16:21):
So it's not included in the which actually, to me
really adds fuel to my fire because like, I really
have the position and I still do after completing this project,
that calling something Turing machete complete is not really that interesting.
I don't find it that interesting. I think. Actually, I'll
tell you a funny thing about Doom. Actually, independent of
my project, I learned when I released this that the

(16:42):
Doom game, not like the engine, but like inside the
game with your character and the gun and like things
that you can do in the game is known to
be Turing complete. Because you know, I was I was
listening to watching people argue about this in comments, and
you know, one person was saying, well, actually the measure
should be Doom complete. If the system can run Doom,

(17:03):
then that's like the bar of what is mathematically interesting.
And someone said, well, you could make a computer that
only can run Doom and can't do anything else, and
then like, that's not very interesting. You made an ask
basically for just Doom. And then they came back the
you know, the first person came back to say, oh,
you must not be aware that the Doom game itself
is turning complete, and so then you have the full
circle completing the loop that actually and so this is

(17:25):
my my champion thing I'd like to champion to the
world is that actually, Doom complete is the more interesting
mathematical proof.

Speaker 3 (17:32):
By the way, I'm reminded that somebody implemented the CPU
inside my Minecraft.

Speaker 4 (17:37):
Yes, yeah, exactly. Yeah, so it's a similar sort of
project to something like that. Yeah.

Speaker 3 (17:43):
So, going back to what we were saying in the
context of the quote unquote Doom complete, the type system
itself provides the building blocks for implementing additionals and loops, right,

(18:04):
I mean, conditionals would basically be let's say a generic
type that accepts two types and then in a condition
and based on evaluates that condition at build time and
basically would return either the first type or the second
type based on the condition.

Speaker 4 (18:22):
Right exactly. Yeah, that's that's basically the kind of core
building blocks that you have, you have and then from there.
So what's funny is there's no loops in the type system,
but there is recursion, so anytime you want to do
right right, So but I'm saying there's no there's no
construct like in JavaScript you can make you can make

(18:43):
a wild loop, but there's no construct of anything like that.
But you can achieve it by making by making conditionals
that have recursion inside of them. They have to have
conditionals because of course if you don't have a condition
then it could loop forever. But anyway, this is the
construct that you end up using. And so actually all
of the machine state and all the looping and all

(19:05):
that stuff happens with recursion purely.

Speaker 3 (19:10):
Well, you know, when I first saw it, I was
I laughed because again I encountered similar not nothing to
this extent, but similar, let's call it similar kind of
projects in concept, not in scope, back in the temp

(19:31):
C plus plus template days. And basically it's because if
you think about it, type system with generics is effectively
a flavor of lisp.

Speaker 4 (19:41):
Yeah, I tell people that that it's it's it's very
much like a lispy sort of thing where you also
don't have statements all you all you have is expressions.
So you have a you have a sense in which
you can create statements by having an expression that you
know is returned from something else. And there are some
workarounds that I came up with but didn't end up

(20:02):
actually needing to use to kind of fake statements using
generic parameters. But yeah, in the end, it's it's a
very straightforward system. If you just think of it like lisp,
it kind of maps to that fairly, fairly directly.

Speaker 3 (20:14):
So basically, when you write a program, let's put doom
aside for a minute. Let's say I'm writing a much
simpler quote unquote program in the typescript type system, right,
I run the program by executing by executing TSC.

Speaker 4 (20:33):
Right, Yeah, so you run the type checker. So you know,
the thing that we talked about in the beginning that
keeps you from mistyping red or green or blue. That
system is the thing that is actually running your you know, program,
if you want to think of it that way, And
the program is a type, so actually all of Doom
had to be converted in a sense into a single

(20:54):
individual typescript type.

Speaker 3 (20:58):
So that begs the question again before delving into Doom itself. Yep,
how do you input or output anything?

Speaker 4 (21:08):
So ASKI, art is the way that you output? So
you basically because I said that you have a you
know you have strings, I found a way to display
a kind of two dimensional string, so you have new
lines and it's actually new lines are collapsed by the editor.
But essentially what happens is there's a type and you
hover your mouse over it, and what appears in the

(21:31):
hover that's supposed to be the you know, the place
where it is, the place where it tells you what
the type of that variable is. What appears is a
frame of Doom. That's the end kind of result of
the whole thing. As for inputs, the inputs are like
pre encoded, but you can send them in as parameters.
So it's kind of similar to any kind of other

(21:52):
programming where you know you you would have there's no
keyboard inputs and there's no time dimension. So if you
have keyboard inputs you would use is like a list
of keyboard commands, very similar to how like a tool
assisted speed runner works. So you would just say on
this frame, do this, on that frame, do that, and
it would take those on a frame by frame basis
and execute those keystrokes. So I actually also did a

(22:15):
version of pong that is a simplified version of the
whole system, just to demonstrate how that works.

Speaker 3 (22:20):
Basically, you've got let's say, the output is is the
display and the current state, and the input for the
next frame would be the current state and whatever keys
were pressed. Yes, and I air quoted keys exactly.

Speaker 4 (22:40):
Yeah, you got it. It's a it's a it's a
functional Uh, it's just like pure functional recursion state machine. Yeah.

Speaker 3 (22:49):
So that church. You know what I'm referring to with church? No,
well he lambda?

Speaker 4 (23:00):
Oh oh the person, okay, yeah, the church?

Speaker 3 (23:02):
The person?

Speaker 4 (23:04):
Well, what is it? It's what's the theorem? Is it
the church? Something hypothesis? I don't know.

Speaker 3 (23:09):
Oh, I forget, I need to check on Wikipedia or something.

Speaker 4 (23:14):
I'm not so I have to say with like one
fun part of this project for me is I don't
have any I think ignorance played a very key role
in the completion of this project because I didn't know.
I mean, I didn't know anything about any of this stuff.
I had never written C code before, you know, doom
is written in C. I had never touched huge portions
of the things that I learned in this project. I've

(23:35):
had some really fantastic jobs over my career, and I've
really enjoyed the things that I've learned. But I learned
more and on this one project than I did in
the prior ten years of working professionally. Quite hard, I
might add, you know, like you can get out a
lot out of a personal project like this that you know,
my job was to figure out how it all works,
and I had to There's no stone that I could

(23:57):
leave unturned.

Speaker 3 (23:58):
So basically, you're saying you had this crazy idea, you
thought that it must be impossible, and you essentially set
out to prove that it's impossible. Yes, and that every
time you ran into what appeared to be a brick
wall and kind of thought about saying, hey, I proved

(24:20):
it almost impossible. You said, you had the thought of, actually,
I can overcome this challenge, right.

Speaker 4 (24:26):
Yeah, exactly. Yeah, I mean, it's funny. There was someone
on Reddit when that when the video was posted announcing
the project, and we're kind of talking about burnout, and
they said, yeah, I mean, it's kind of weird that you,
you know, I was a little burned out before starting
this project, and this was a kind of way to
rekindle the love of, you know, the software craft and programming.

(24:50):
And they said, it's kind of weird that you solved
your burnout by working eighteen hours a day, because I
worked very hard. But my answer to that is, I
think I think burnout happens when you work on something
and you don't get out what you perceive to be
a result. Actually, I've known people who get burned out
that are not working hard, and that itself can be
like something that burns you out. It's when you don't

(25:11):
perceive there to be something coming out of your efforts.
And this project was the absolute opposite of anything like that.
It constantly happened to me that I would think, no way,
is there any chance that I'm possibly going to be
able to solve that problem? And then some hours would
pass and I'd go, well, you know what, if I

(25:32):
could solve these other three things that are kind of
sub problems of that larger problem, then I probably could
hack my way through it. But I'm not going to
be able to solve those three things, and so I
would go down the path of trying each one of
those things, and for each one of those things, in
many cases, I'd go there's no way. Right over it
always happen all over again, I'd say there's no way.
And then so but that experience of thinking there's no

(25:54):
way I could do it, there's no way I could
make this happen, and then making it happen a day
or a week later, over an over again, on thousands
of little problems, that was very invigorating for me, and
it was very motivating for me.

Speaker 3 (26:06):
And you kind of hinted at that, But how long
did this take you?

Speaker 4 (26:12):
I have such a hard time answering this question. So, like,
in total, from the moment I started trying to the
moment I announced the video was a year and a half.
Over a decent portion of that time I was unemployed,
like let's say three months or four months, and I
worked very very hard on it, Like I was absolutely
at my desk typing for at least eighteen hours a day,

(26:35):
Like I mean there were some twenty four hour stretches
where I literally did not stand up from my desk
for one whole day night cycle.

Speaker 3 (26:44):
If I may ask something personal and feel free to answer,
are you single?

Speaker 4 (26:50):
Yes, I'm not single. I have a wife and two kids,
two young kids.

Speaker 2 (26:58):
I think very understanding.

Speaker 4 (27:01):
Yeah, I think like Actually some people ask on a
to follow your lead on the personal note there some
people ask like, well, like, why do a thing like
this personally?

Speaker 3 (27:11):
For me?

Speaker 4 (27:11):
One of the reasons is I worked so hard on
this project. I really really pushed myself as hard as
I have ever pushed myself on anything for so long,
you know, And I did actually after that three months,
I did do some contracting and I eventually got a
job working full time, and I, you know, fit this
in and I have squiggle comp as well. I started
a conference during the same time. So there's a lot

(27:32):
going on with Josh. Yeah, Josh Gobert, Yes, exactly.

Speaker 3 (27:36):
Well, I guess on this on this podcast as well.
And by the way, I recently just met him at
the conference in Romania.

Speaker 4 (27:43):
So yeah, awesome, Oh yeah, yeah right yeah, And I.

Speaker 3 (27:46):
Have a siren and I will have to drop off.
I will rejoin you hopefully in about fifteen minutes. I
have put problems with that then to all listeners.

Speaker 4 (27:54):
So what happened is I, you know, I put this
project together and it took a year of so much
hard work. And I always say, like, imagine being so.
My wife is not technical, she's not an engineer, and
I just kept telling her this is such a big deal,
this would be really cool if someone could do it.
And she supported me throughout that entire process, and there

(28:15):
was never a moment when she doubted me or said
are you sure this is really worth all this effort?
You know, she would ask how it's going a lot
and I could never really give a good answer because
I thought it was always a day away from being over.
But for me, it did wonders for my marriage in
a lot of ways. Like imagine the trust that's built
over a project like that, and you know, you come

(28:35):
out the other side successful and find out that you know,
you look back and see that your partner was supporting
you and picking up slack the whole way while you were,
you know, in your dungeon, you know, coding for twenty
four hours straight without being you know, there are many
nights where she would set a cold plate on the
table next to me because I missed dinner, and then
she would come back, and you know, these these moments

(28:55):
are temporary. I spent quite a lot of time with
the kids and the family, you know, But from me,
it's very hot and cold, and when it's hot, it's
burning hot, and when it's cold it's ice cold. There
were also days where I didn't touch it. But it's
hard to answer how long I spent because you know,
I remember times where I had to drive an hour
from place to place to get something or do something,
and I don't even remember the drive because the whole
time I was just thinking about like some algorithmic challenge

(29:18):
or some process that I had to work through with
this problem. And it's a you know, it's tough to
it's tough to put it into numbers. Yeah, that's it.

Speaker 1 (29:28):
Sounds like you're pretty bipolar about it, huh. I mean
very hot, I don't.

Speaker 4 (29:31):
Know, very cold. Yeah I suppose. Yeah, Well, I mean like,
I don't know. I don't think I have a diagnosis
or something like that. But it's just I don't find
it difficult to focus for long periods. I've always been
that way. It's it's but I also don't find it
hard to you know, it just depends on what mode
I'm in, but I find it very easy to switch
into a mode where it's like hyper focused, And I
find it also easy to switch into a mode where

(29:53):
I'm doing ten different things at once and like none
of them really get the attention primary attention. Yeah, that'd
be the way I would put it.

Speaker 3 (30:03):
Yeah, So.

Speaker 1 (30:06):
I'm so other than you know, wanting to achieve fames
so that you could be on this podcast. You know,
I think of the the quote you know Edmund Hillary,
why did you climb out evers?

Speaker 2 (30:21):
Because it was there? You know?

Speaker 1 (30:25):
So does this Uh I'm trying to think how to
ask the question. So now that you've done this, is
this yeah give you skills?

Speaker 2 (30:34):
You think that uh?

Speaker 1 (30:36):
Serve you? You know in job hunt or job? Is it
just more for personal satisfaction? Like, Hey, I did something
that I thought was impossible. Right, you know, what's the
what's the worldwide fame that is?

Speaker 4 (30:47):
I'll tell you. I'll tell you the truth, the truth.
It's hard to explain this without making myself sound like
a like total psycho. But the reality is the way
that I built is if I had completed this project
and closed my laptop and never spoke of it again
to anybody and like maybe my four or five closest
friends know that I'm working on it, but then like

(31:08):
the world never heard, I would probably have been like
ninety five percent as satisfied as if like what I
did end up doing, which is like announcing it and
open sourcing it and getting a lot. It's brought me
a lot of recognition, which I'm very happy to have.
But I didn't do it for those reasons. I did
it because I think I was born with the how

(31:28):
hard could it be? Jane, You know, it's kind of
like what you said with the mount everst quote, just
I thought it was. I also the ignorance played a
huge role because I frequently thought I was just on
the very cusp of hitting the problem that I thought
would end the project. Because all I wanted was to
end the project. It wasn't. I didn't want this to work.

(31:49):
I never believed It's funny. I have lots of recordings
of me working on this because I knew I might
make a video, and there's a recording of me the
moment that it The project succeeded the frame of Doom rendered,
which took twelve days of running the type checker in
like one hundred and seventy seven terabytes of typescript types
and it's like a whole thing. But it's interesting that

(32:10):
like it's kind of hard to pick out what Like
if I showed somebody the video, it's just like four
minutes of me staring at the screen in silence, just
like like in disbelief. I mean, it's I could not
believe that it worked, because I never believed that it
would work ever until I couldn't deny it anymore because
it was already done. And so it's one of those
things where if I had known better what I was

(32:33):
getting into, I would never have started. And yeah, I mean,
I just I think anybody. And I have friends who are,
like I think, are much better engineers than I am,
that are much more experienced in some sense than I
am with these kinds of systems level programming tasks, and
many of them told me like, why are you doing this?
This is this is not gonna work. How could this work?
And I'd be like, yeah, I believe that it won't

(32:54):
work as well, I'm right there with you. I also
don't think that it's gonna work. However, you know, h
turns out it did.

Speaker 1 (33:03):
Yeah, Yeah, it's funny. I'm looking at I'm thinking of
Dan's questions. So I'm looking at the are programming thread
on Reddit with the video, Like, first question is what
kind of daily occupation of regular financial backs fort do
you need to have the guts to invest six months
into a joke?

Speaker 4 (33:24):
It is a joke, yeah, I mean, I think, like,
what's funny about the way that this works out is
I said the little, you know, personal tidbit about my marriage.
But actually, from like a career standpoint, what I learned
and this project will I mean, it's I am so
much more capable now than I was before because there
I mean, I had never written C. Now I've written

(33:45):
tons of C. I mean, for me anyway, I've written many, many, many,
tens of thousands of lines of C and worked with
C and refacted C code bases in LVM. I had
never I didn't really know what LVM was, but now
I know quite a lot about the internals of LVM
and how it all works. Also, web assembly, we didn't
touch on it yet, but the way I actually physically
achieved this goal was by building a web assembly runtime

(34:08):
purely in tech script types, compiling doom to web assembly
and then running that in my run time. And so
I built because I built a full web assembly runtime
from scratch, Like there's like one hundred and sixty instructions
that I implemented. And when I say from scratch, you know,
I have to remind you, like there's no addition in
the type system, so even addition was not available to me.

(34:28):
I had to build addition off of abstractions of like
adding and removing characters to binary strings that have like,
you know, thirty two ones or zeros stacked next to
each other in a string. So I had to create
all kinds of abstractions and constructs I didn't know. I mean,
it's like down the list, I didn't know anything about
you know, two's complement binary numbers. And I built a

(34:50):
garbage collector is in the runtime. I didn't know anything
like how garbage collectors work and how that stuff works.
So all these things are so directly applicable, and it's
kind of funny. Before or I announced the project, that
kept happening that like basically every other day at work,
something would happen that I would be able to contribute
to my like what my team is building or what
somebody else on the company is building. That was a

(35:11):
skill that I picked up working on this project. I mean,
it's just it's so directly works out that way, and
so in the end, I think I got a lot
out of it from that perspective. If that makes any sense.

Speaker 2 (35:24):
Oh no, it makes perfect sense.

Speaker 4 (35:25):
You know.

Speaker 1 (35:26):
One of the things that I don't know if you
how often you listen to us, But one of the
things I talk about is the kind of person that
I am is very similar to you, and that I
like to know the internal details of how something works.
You know, what's the little pieces that make it work.
Because once you understand the smaller pieces, then that helps

(35:51):
you understand the bigger picture and maybe even troubleshoot better.

Speaker 4 (35:54):
You know.

Speaker 1 (35:54):
I started out my tech career back in the You're
doing you know a long time ago, right two years
after Doom came out. Let's put it that way. And
I remember Doom being is Duke Nukem. Is that you
see the character and Doom or is that.

Speaker 4 (36:15):
It's a different game. But actually the guy in Doom,
his name is Doom guy.

Speaker 1 (36:19):
Okay, they all start with d you know, they run together.
I've never been at a gamer myself anyway, I've always been
the kind of person who likes to know the the
intricate details of how something works, and from my job
it was sort of necessary. The classic example I always
give is as a Spanish speaker, I was somebody who

(36:39):
learned language really easily. But there's two different ways you
can learn. I think that you can learn a spoken
language more so than like a programming language, where there's
you know, the conversational people that you know. You take
a conversational Spanish class and learn how to speak phrases
and and stuff, and you know how to say what
you're saying, but you don't really have to understand the

(37:00):
building blocks. Whereas the way I learned it was learning
the building blocks, you know, verbs, verb, conjugation, which is
sort of the crux of any language, right, nouns and
all the different well all the different verb tenses and
and that kind of stuff, so I understand it. So
then once I have the building blocks, then I can
piece things together and make a more complete whole. I'm

(37:21):
waxing eloquent here, but I just started. So I just
started a new job this week in a new company,
and going through the interview process, which is long in itself,
one of the questions I got was basically, how I'm
trying to remember how it was phrased, but how do
you troubleish you? What's your how do you troublesh you?

(37:42):
How do you figure something out? What your tools? And
my answer was the best way to be able to
do that is to know the system right. If you
know your system, you can spot when something's wrong, as
compared to trying to figure out, well.

Speaker 2 (37:56):
This must be this year, this must be there.

Speaker 1 (37:58):
If you know how it's supposed to work, then you
can identify when something doesn't work. I can remember my
first career out of college was in a bank. I
worked as a in the operation side of a branch
and I did a lot of training and teller training
and stuff in the day, and I can remember hearing
a story of this. This was probably more before my time,

(38:20):
but to me it makes perfect sense that the way
they used to train tellers was you just give them
cash and have them count cash, sit there and count
for a long time, and then you start throwing in counterfeits.
And because you know the original so well, then you
can easily spot a counterfeit something's wrong.

Speaker 2 (38:37):
All let's get you back to your point. You know,
you're talking about knowing.

Speaker 1 (38:40):
Web assembly and low level c stuff in garbage collection
and binary and strings and stuff like that, that if
you know all those little pieces, all the details, then
you can easily one, you can easily build something. In
two you can spot when something's going wrong. That's got
to be an amazing WELLLGE sad to have to be

(39:04):
able to know all that low level stuff and then
piece it all together.

Speaker 3 (39:07):
Welcome and I'm back. Yeah did you miss me?

Speaker 4 (39:10):
Yes we did.

Speaker 2 (39:11):
Oh you were gone? Oh okay, anyway.

Speaker 3 (39:14):
Happy happy to report that apparently nobody was hurting this
barrage all right. Yeah, so well, anyway, I.

Speaker 1 (39:26):
Was saying eloquent about knowing the details of a system
based on what he learned from this project.

Speaker 4 (39:31):
So I think it's actually a perfect segue. Is something
that I hope people take away from this project is
it's such a complex system that there's no way I
could have kept it all in my head. And I
knew that from the very first commit. From the very beginning,
I knew if there's if I ever really get far down,
if like if I hope I find an early stopping point,

(39:52):
but if I find a mid stopping like I never
thought I would get to the end, so that was
like never on the table. But I thought, even if
I get to a midway stopping point, I we need
to have an extremely extensive test suite. And so the
way that I set it up is basically I run
the same set of inputs against all these programs that test.
Because I told you there's like one hundred and sixteen

(40:13):
instructions that I had to create in the web assembly
run time. So the system is set up to test
the same inputs in that runtime six different ways. And
so the I'll say them very fast. The first way
is just you know, let's say the numbers are one
and two and the operation we're doing is addition. So
we run one plus two in JavaScript, so okay, that's fine.

(40:36):
We run one plus two as strings as binary strings
in JavaScript, that's fine. We do it again in typescript
types purely, so we have a typescript you know, a
routine that can do binary arithmetic, but it doesn't know
anything about web assembly. It's just very low level. We
do it again with decimal numbers in JavaScript, which actually
under the hood converts to binary. That's four. Number five

(40:58):
is where it starts to get really interest. I take
those numbers one and two and I wrote, I hand
wrote a web assembly program that like is like four
lines long and basically just does that one instruction, takes
those two parameters and does that one instruction in the
simplest way possible. And then number six is the where
the rubber meets the road. I run that same set
of inputs in my web assembly run time, which itself

(41:21):
is pretty simple, right, but it's taking that web assembly
artifact that I also ran through the JavaScript web assembly
run time that's built that chips with Node, and you
know JavaScript is built into the JavaScript system. And this
was the method by which I discovered all kinds of
things that I had bad assumptions about that I I mean,
you say assumption, but it's like unknown unknowns. You know,

(41:41):
things I didn't know that I didn't understand, and you know,
some of them got pretty far. Like you know, you
may have heard of like little endian and big Endian.
I had heard those words before, but I didn't really
understand what they mean. And I accidentally. You know, you
have a fifty to fifty chance of implementing a system
one way or the other if you're packing bytes into
memor object, and I accidentally implemented the whole system Big

(42:03):
Indian without knowing it, And it was actually my test
suite that uncovered this for me. Once it works out
that if you, you know, you pack all the bites
in reverse and you read them all out in reverse,
you can get away. You know, webasitmbly is Little Indian
by spec it has to be Little Indian. But it
was only once it was very far along. Actually it
was only once I started working with memory instructions that

(42:24):
operate on a portion of a of a byte, so
I'm sorry, a portion of a word, so like just
the first four bites or the last four bites. Then
I started to get really weird results and I couldn't
figure it out, and so I fixed it. And then
later I was like, wait a second, is this what
Indian this is? And I google it and it's like, oh,
that's ending. So now I'll always know for the rest
of my life.

Speaker 3 (42:42):
So now if you google it, do you know where
the terms come from?

Speaker 4 (42:46):
Yeah, it's like, what's on? What part is it? Does
it go?

Speaker 3 (42:49):
Where the name Big Indian and Little Indian? Do you
know where the origin of the name?

Speaker 4 (42:56):
No, it is. I thought it was just like end, like,
what's what's the significant bit?

Speaker 3 (42:59):
So it's from it's from Gulliver's travels when when he
visits the land of Lilliput. They have there there there
are actually two countries there and they have a war
and the catalysts for the war, you know, speaking of wars,
the catalyst for their war is when you have a
soft boiled egg, which side do you break the egg on,

(43:22):
the Big Indian part of the egg or the little
Indian part of the egg. And that's that's that's the
that's the source of the war. And Gulliver obviously brings
about peace and whatnot, but that's where the terms big
Indian and little Indian.

Speaker 4 (43:39):
You guys really got my number. I love this kind
of trivia stuff, so that's really awesome. Thank you for sharing.

Speaker 3 (43:43):
I'm mister, you know, especially as related to history and
programming stuff, so I probably have missed it. You were
talking about the fact that you implemented web assembly in
the type system, so you effectively did not run doom
is doom. You compiled doom into web assembly and then

(44:05):
ran the web assembly in your type system run time.

Speaker 4 (44:09):
Yes, it was the first thing I tried. You know,
actually a friend of mine said, hey, who's very smart
in these things? He said, you could probably do a
Klang compiler target target And I was like, Okay, I
don't know what clang is, I don't know what it compiles,
and I don't know what a target is. But I
started looking into that, and I, you know, eventually, actually
it's what the funny thing is is, later I learned

(44:30):
quite deeply what Clang is, and I worked a lot
with Clang and different C compilation tools. But yeah, in
the end, I tried web assembly and it never stopped working.
So some people ask me like how why did how
What was your process for selecting web assembly, And it's
like it was the first thing I tried. I had
never worked with web assembly before. I had no contacts
or exposure to it whatsoever. This was this was the beginning. Yeah,

(44:53):
to me, playing always just a loud sound.

Speaker 3 (44:56):
Well, yeah, it's a c Lang compilation. Basically, it's the
output of LVM or something, right.

Speaker 4 (45:04):
Yeah, it's a C compiler based on LVM. It's part
of the LVM project and yeah, it's it's very closely
tied to that.

Speaker 3 (45:12):
So essentially, anything that can be compiled down to web
assembly can actually be run theoretically at least on your system. Yep,
super cool.

Speaker 4 (45:23):
Yeah, I mean it's funny. Like I showed this to
a few people before it was public, and you know,
there were about two people who had the reaction that,
like Dimitri, you're like vastly under selling what this is.
By talking about like focusing on Doom, you're ignoring the
fact that you built a full web like any I
can run Pong, I can run Tetris, I can run Pokemon,
I can run anything, you know, not just games, but

(45:44):
you can do any kind of arbitrary web assembly computations
with your system. And yeah, that might be true, but
you know, Doom makes a better headline.

Speaker 3 (45:57):
Now. Again, I apologize if this is something that you
spoke about while I was otherwise engaged. I understand that
you actually had to modify the typescript compiler a little bit.

Speaker 4 (46:13):
Yeah, so it was always very important to me. Like,
so I'm a typescript nerd. I mean, I'd love not
to be. Some days, I actually prefer rust quite a lot,
which some people find surprising. Typescript is definitely not my
favorite language to write in. It's just the thing that
I've written the most in and have the most familiarity with.
But you know, in the end, I tried pretty hard

(46:38):
to create something that you know, doesn't know anything about
Doom and doesn't know anything really about Typescript internals. And
there are limits in the Typescript type system that try
to keep you from doing things like this. So they
are like we talked about recursion, Okay, so Typescript has
a recursion limit. It's arbitrary. It's completely arbitrary. It's one

(47:04):
hundred recursions. If you make a type that recurses one
hundred times, it will Typescript will stop and report an error.
And that's just a thing that they built into Typescript
to prevent runaway you know, complexity that you like, accidentally
do some kind of matrix multiplication of you know, wide types,

(47:24):
and you get this like really crazy thing that takes
so many you know, could take years to compute or
whatever you like. That's it's just a it's just a
safety check. It's a safety guard. Well, when I was
developing this, I really needed to remove those safety rails
because I needed to experiment with things that you know,
I would later be able to break up into smaller

(47:44):
pieces I knew, but like when you're in the weeds
kind of trying to shoot around ideas about how to
work on something, it's kind of nice sometimes to like
let it be dangerous. And so I modified I patched.
It's just like ten lines of patches. It's not anything major,
but there are these like you'd think, like, Okay, if
the recursion limit is one hundred, does that mean there's
a place in the code base that says, like, you know, recursions,

(48:06):
number of recursions equals equals one zero zero, And yeah,
there is. So I just went to those places. I
found those limits whenever I hit them, and I just
changed them to like infinity, so that.

Speaker 3 (48:17):
I would probably also the number of types that can
exist in the system.

Speaker 4 (48:22):
Right, Yeah, there's a there's a type instantiation limit. There's
there's a couple limits. And so these limits are kind
of core to the Typescript system, but they're totally arbitrary,
and it actually does work without Like the final thing
that I created will render the frame of Doom with
vanilla Typescript with no limits removed. But it was just

(48:44):
very useful while I was working to be able to
kind of like soft remove those limits.

Speaker 3 (48:50):
So you know, so how long does it actually take
to render one frame of Doom on your computer?

Speaker 4 (48:56):
Yeah, so it took took twelve and a half days
to get to render the first frame, and it was
very important to me. Actually, I did a little squarely
business inside of the Doom code to make sure that
the first frame is inside of a game level, because
the real first frame of Doom is actually just a
static asset. It's a there's like an image that ships

(49:17):
with the file, that ships with the I don't want to.
We can get into Doom like how Doom works internally
if you'd like, But anyway, it's not actually that hard,
Like it's just it's just a picture that was put
into the codebase. But I don't want to do that.
I want to I want to boot the whole game.
I want to boot the enemy system. I want to
boot the game. Map rendering it does like some kind
of it's not ray tracing. What is it called ray casting?

(49:41):
It does ray casting to to kind of like figure
out all the pixels of all the obstructions and all
the geometry of the level. And you know, there's like
a system for your weapon and your health.

Speaker 3 (49:50):
And your side is in the side. I need to
mention that way back when in the day, I in
the nineties, I actually worked at the company, at the
gaming company, and I literally implemented, uh this the doom
ray casting algorithm. The game that we developed. It was

(50:12):
kind of like a multi user doom game. So I
basically found uh uh pseudo code description of the algorithm.
I figured it out, I implemented it in c It
was too slow, so I actually then compiled some of

(50:35):
it into assembly language and hand optimized the assembly language
that came out. So this this was obviously from my
pre JavaScript days, so I'm kind of familiar with some
of the stuff you're talking about, even though it was
a long time ago. So you picked a random frame
inside uh, play the inside of the level, and then

(50:58):
just rendered the first frame, right.

Speaker 4 (51:00):
Yeah, you can actually change the game asset to force
you into a level and immediately.

Speaker 3 (51:04):
So that's why I've it ran for twelve days? How
did you know that it wasn't just stuck?

Speaker 4 (51:11):
So funny story. The run that succeeded was about the
eighteenth or twentieth run. I stopped counting after eleven, so
I mean it took it took almost a whole year
to get to the point of like being able to
even try to run the because the game is very large, right,
It's like kilobytes of are actually megabytes rather of JavaScript.

(51:33):
I'm sorry, I have typescript types in one file. It's
not like these systems are not made to handle megabytes
of a single type being megabytes long. And so it
took a long time to get to that point. I mean,
when you build a system this way, you kind of
can't run it until you've implemented all of the instructions, right,
you like, even if there's one and if you have
one hundred and fifteen out of one hundred and sixteen

(51:54):
instructions like it, you will What happens when you get
to that instruction you haven't implemented yet is the system
will crash. And so it took a long time to
get to that point. But once I got to that point,
it did infinite loop multiple times.

Speaker 3 (52:06):
There.

Speaker 4 (52:06):
I kept track of the runs, and I was monitoring
their you know, their their their progress, like how many
instructions they had gotten along through, and I could I
implemented a system that would kind of dump the what
it was working on to disk temporarily, so that I
could take a peek at what it was working on
and see like how it was going. So it was

(52:27):
a long process of getting to that, and I didn't
really think, you know, you know, speaking of family stuff,
it's funny how how life happens. But actually the final
successful run was was spun off on the night of
Halloween twenty twenty four, and I was running out the
door and I thought, you know, I'll just I'll start
another run because the previous one had failed earlier that

(52:48):
day and we were going to go trick or treating
with my kids around my neighborhood. I thought, you know,
I'll just I'll just go push play. I'll come back
to it as probably gonna feel like I had long
given up on it, the idea that it would just
work by that point, and of course that was the
run that you know, eventually succeeded twelve days later.

Speaker 3 (53:03):
What can you describe your reaction?

Speaker 4 (53:08):
Yeah, yeah, so I was I was saying, oh, you're gone,
but it's fun to talk about. I genuinely, in my
heart of hearts, never believed this would be possible. I never,
at any moment believed it until the very last millisecond
when I couldn't deny it anymore. I mean, so I
was recording the screen, and I recorded myself working on

(53:29):
this throughout the project, and that was part of what
was in the video. And there's more that I'm planning
to release on this. But it's funny to watch back
the video because it would have been nice if I
had some kind of like big reaction, but it's just
I was just stunned. I was just like immobilized, and
it's like four minutes of silence. Yeah, it's just like
total like total disbelief and shock. And actually you can

(53:51):
see my eyes kind of darting around the screen trying
to find a place where like it didn't render a
column in the level or something, you know, some geometry.
I just never I never believed it would be possible.
I just never believed it until well, I couldn't deny
it anymore and it was done. So yeah, it's funny,

(54:11):
Like I don't know, I'm gonna, like I said, make
a video about the why of this project, like why
did I get trying to do this? And I have
to find a way to like make it more palatable
to show that reaction because my reaction is basically just
me just being like, you know, just breathing.

Speaker 3 (54:29):
Happy, and then what did you do the next day?

Speaker 4 (54:33):
I mean, I think I did what I would have
done if I had been on the other side of this. So, like,
one of the things I told to my wife is
like listen, because she would ask me, like what, like,
explain to me why this. She had never heard of
doom and stuff, so she doesn't know the history of
people trying to run things into the way. No, she's
not an engineer at all. So I would try to
explain this, and I would say, Okay, look, here's what

(54:53):
it boils down to. If I was on the other
side of this and somebody released this project, I would
my eyes would glaze over. I would have to take
the rest of the day off work. My eyes would
glaze over. I would I would walk outside and stare
at the sun and probably go blind, Like I would
question everything about the universe if this, like it would
really rock my world. If this is possible, it just

(55:16):
can't be possible. So like all trying to do a
show why it can't be possible, which means I could
be done at any moment. I could be done today,
I could be done tomorrow, not sure, but I knew
that if I was on the other side of this,
I would just be like totally, totally shaken. And despite that,
I was in the driver's seat all along because I
had this attitude of this couldn't possibly work. Yeah, that
ended up. That ended up happening. I didn't stare into

(55:37):
the sun and go blind, but all the rest of
it did that. I just kind of walked around, you know,
like fuzzy, Like my body felt fuzzy for hours afterwards.
I just could not believe that it was like finally
in front of me. I spent a long time believing
it wouldn't be possible. Funny, it's such a stupid thing,
but you know, here we are.

Speaker 3 (55:55):
That's well, you know the things in't like. By the way,
have you actually tried to run it on the new
GO compiled type compiler?

Speaker 4 (56:03):
No, and I will never So one of the things
that is interesting, I also promised my wife I would
never open the project up again. But actually I don't
need to do that because I it sounds funny to say,
but I have like absolutely no interest in continuing this,
Like I didn't have interest in doing it in the
first place. I just got kind of nerd stiped into it,

(56:23):
so to speak.

Speaker 3 (56:24):
It's just that instead of twelve days, it should take
a day and a half.

Speaker 4 (56:27):
Yeah, and some people some people said like, oh, but
you know, like what about the second frame? You know,
that was one of the common complaints on the announcement videos,
like but you didn't show any gameplay, And it's like, look,
if I had rendered a hundred frame, someone could say
what about one hundred and first frame? Like, on a
mathematical level, it is literally equally as an interesting to
say that I rendered one frame as a did render

(56:48):
one hundred, like or a thousand or whatever the first level, Like,
I don't care about that part. There was the whole
purpose of this project was trying to kind of like
trick the typescript type system into doing this like very
difficult task.

Speaker 3 (57:02):
And II the point was never to actually play Doom
at the frame rate of one every twelve days.

Speaker 4 (57:09):
Yeah, I say in the video like I didn't do
this because I have no better way to play Doom.
You know, there's lots of ways I couldn't played Doom
if that was my goal. This was like a kind
of mathematical pursuit, you know, academic pursuit.

Speaker 3 (57:23):
Yeah, it'll be interesting. I'm sure somebody will pick up
the conflict or the mental or something.

Speaker 4 (57:28):
And it's open source, so if you know, if somebody
listening is one of those people that would like to
kind of I don't know what the next level of
this would even be, because to me, like Doom is
kind of like the finish line. Some people have asked me, like,
why did you go from nothing like this ever having
been done before all the way to Doom with no
stops in between, And you know, it comes back to
this recurring thing. It's just because I thought it wouldn't

(57:50):
be possible. So if that's your mindset, there's no reason
to play around with like Pong or Tetris or Pokemon
building up to it, Like, just go straight to doom,
to the hardest thing and show why that can't be done.

Speaker 3 (58:01):
And then and also the fact that you implemented web assembly, right,
is the fact that you could run now run anything
on it that, like we said that can compare the
web assembly. So Doom is just one example. It could
be anything else.

Speaker 4 (58:17):
Yeah, And in fact I did actually maybe I'm fibbing
a little bit, I did actually implement one other program first,
and it was Conway's Game of Life. So you know
Conway's game of life is this thing called a cellular
autonoma autumata for anybody listening, And it's just kind of
like a it's kind of like imagine a piece of
grid paper and you make a game out of like
rules about which you know, grids are filled in on

(58:37):
the paper. And I wrote that and see, so that
was the first C program I had ever written. And
that completed in January twenty twenty three. So from January
all the way until November was how long it took.
Like it was a pretty full functioning system at that
point for the instructions that Conways needed. And again I

(58:59):
wrote it in see not in straight web assembly. So
there's actually quite quite a lot of instructions. There's like,
let's say eighty instructions or something like that that Conways needed.
But it took a lot more to get Doom running
than just that.

Speaker 3 (59:12):
There's quite a lot the last you know, the thing
about software projects, well, I guess projects in general is
that that eighty twenty rule, the last twenty percent takes
eighty percent of the time and effort.

Speaker 4 (59:25):
Yeap basic definitely was the case here.

Speaker 3 (59:29):
Super cool, and then you basically just put it aside
and continued with your with your life.

Speaker 4 (59:35):
Yeah, I haven't touched it, not one bit since the
day of the announcement. Anyway, I had to like rework
the read me. It's funny. I committed a lot. So
if you read the commit history, it looks like I'm
totally like out of my mind, which maybe you could
argue that I was while I was working on it.
But it's a lot of like capital letters and exclamation
points and a decent amount of swearing. And actually there's

(59:57):
I have a sort of self deprecation. I find self
deprecation very motivating for whatever reason, and so like in
the codebase, it's like there's a little there's a lot
of like you, dummy, what are you doing? Type of
comments and things. But you know, whatever the case, maybe
it was a solo project and you know, you don't
have to follow all the rules you do at a

(01:00:18):
project at work.

Speaker 3 (01:00:19):
But yeah, no, what came out when it came out.
You spoke with some typescript or web personalities I recall
from your videos in particulars in particular your conversation with Anders. Yeah,
so can you tell us a little bit about that.

Speaker 4 (01:00:36):
Yeah, that was that was a really awesome moment. So
because of the channel and work that we've done on
Michigan Typescript prior, I had an opportunity to do some
videos there. I think probably four or something five members
of the team have been on the Michigan Typeescript channel
for various you know, it's always very nerdy things about
interviews about typescript or trying to solve particular type challenges

(01:00:56):
and stuff like that, and so I had been asking
them about you know, hey, you know, it'd be really
cool because when I showed it to people privately, people said, hey,
I wonder what Anders, the creator of typescript, thinks about this,
And I would say, you're not going to be the
only person wondering that. I'm going to try. And so
I tried and tried and tried, and eventually they said,
all right, all right, we'll throw you a bone. And

(01:01:16):
you know, Anders, I'm very gracious that he took the
time to meet with me and I had a chance
to show him the project and kind of give him
a demo of it. Yeah.

Speaker 3 (01:01:26):
Yeah, I'm literally an an Anders fanboy.

Speaker 4 (01:01:31):
Most of us are.

Speaker 3 (01:01:32):
Yeah, well, in my case, it goes even further back
because he's not only the guy that created the typescript,
he's also the guy that created c Shark and Turbo Pascal. Yeah,
and that of thing.

Speaker 2 (01:01:46):
Actually that brings memory.

Speaker 4 (01:01:48):
I can't believe that I forgot to say this to
him when I met with him, but I was just
so nervous in starstruck. But Turbo Pascal is actually the
language that the original Tetris was first implemented in.

Speaker 3 (01:02:00):
Turbo Pascal is the programming language that made me a programmer.
I literally ran Tuba Pascal. For our listeners who don't know,
Pascal is a programming language originally created by Nicholas Worth
for teaching computers. It's a typed programming language based on

(01:02:23):
the Alghol family of programming languages. But my point was
that up to that point I was writing writing ugly
basic stuff, and then this thing comes along with an
integrated IDE and a super fast type safe and a
compiler for type safe programming language. So I literally almost

(01:02:44):
overnight went from being a hobbyist to an actual programmer.
It's really thanks to Andrews and tuber Pascal. You know
what's funny, but the amazing system.

Speaker 1 (01:02:54):
When I was in college. So I graduated college in
ninety one and I took a basic class. I want
to say eighty nine to ninety. I think remember programming
in basic, and then I took Turbo Pascal my senior year.
Barely passed by the skin of my teeth. I mean,
I barely passed, and I can remember, and this makes

(01:03:16):
me laugh today.

Speaker 2 (01:03:17):
I can remember having problems.

Speaker 1 (01:03:20):
Getting my head around things like a raise, you know,
and we had we had to come up with this
card game for a final project, and I barely did
the minimum.

Speaker 2 (01:03:31):
Didn't even do that. And there's just one girl.

Speaker 1 (01:03:32):
In the class who aced it, and she had gambling
and you could place bets on things. It just totally
blew away. And then, you know, I got into PHP
later and lived in a raise for.

Speaker 2 (01:03:41):
A long time.

Speaker 1 (01:03:42):
But but oh man, Turbo Pascal brings back, so either
nightmares at the same time.

Speaker 3 (01:03:49):
Yeah. So he did pscal, did Delphi, the Delphi programming language,
then he did then he created C sharp and now typescript.
He's he's one of my death heroes.

Speaker 4 (01:04:02):
Interesting, it was all right, it was a big moment. Yeah.

Speaker 1 (01:04:05):
So we're sort of running out of time here, So
before we wrap up and move to picks. Is anything
else we didn't cover that you wanted to cover, Dmitri.

Speaker 4 (01:04:14):
I think we got it. I just hope people that
hear about this project understand a few basic things that
made this successful, contrary to most ways that we like
to think about, you know, building complex systems. If I
had sat down to make a plan, this would never
have been possible. I just put one foot in front
of the other every day, and I kept notes about

(01:04:34):
what I needed to do next as I went. But
I never at any point had a big, grand plan
about how to do this, and it was probably not
even possible in my case because I would never have
been able to know what things I would hit.

Speaker 1 (01:04:45):
So in other words, it was more of an agile
methodology than waterfall.

Speaker 4 (01:04:50):
I don't know. Those are both trigger words for me,
so I can't I can't comment, but but I think
that sometimes people struggle with motivation to try, and I
think that trying is all you need to do. In
a lot of cases, I didn't have a I never
got down on myself about failing because the definition of
failure was built into the thesis I was trying to fail.

(01:05:13):
I was trying to fail. I was trying to make
it not work and just trying to find why it
can't work. And I think that I learned from this
and I hope people can get from it that you know,
I said earlier in the call that ninety five percent
I would have been ninety five percent is happy if
I never told anyone about it. The five percent is
I really do get a lot of enjoyment out of people,
you know, have reached out to me privately and online

(01:05:35):
and stuff saying like I, because of this project, was
inspired to pick up some old project that I had
given up on and I'm going to give it another shot.
And I hope people take that away. And that's like
really the main message I want to leave people's minds.

Speaker 3 (01:05:48):
Having One more important thing that you said that I
wanted to call out because I think it was very insightful,
is about taking big problems and breaking them down into
smaller problems and doing this project process recursively. And I
think this ability of breaking down difficult problems into smaller,

(01:06:15):
more manageable problems and then composing the solutions back in
order to solve the original big problem is what makes
an engineer an engineer. Really, Yeah, this ability to me,
is at the core of what we do, and it
was really insightful for you to bring that up and
really important.

Speaker 4 (01:06:35):
I think I couldn't agree more. Yeah, I love it.

Speaker 2 (01:06:40):
Alrighty.

Speaker 1 (01:06:41):
So with that we will move on the picks. Picks
are part of the show where we get to talk
about anything we want to talk about, whether it's tech
or non tech related. So dan' le you go first today.
What do you have for us besides sirens going off
in the background.

Speaker 3 (01:06:56):
Well, my pick will actually be in this vein. So
without going into you know, the details of what this
war is about and whatnot, we are living in a
situation where in Israel we are we are having large
missiles being fired at us, and by large I mean

(01:07:20):
something like one thousand pounds warhead full of explosives. As
you can imagine, that can cause a lot of damage.
And what makes a huge difference is the fact that
we've got the system in place for intercepting and shooting
down missiles. It's not a fool proof system. Such systems

(01:07:42):
cannot be fool proof by definition, but it's very effective.
It's something like it has an activity of something like
ninety percent, which is like huge in these types of scenario.
If you think about the fact that around thirty people
have been killed in Israel census things started, think of

(01:08:04):
you know, they make it ten times bigger or even more,
that would be yeah, you know, devastating. The reason that
I'm picking this is that I'm proud to say that
in my background, I was actually involved with the creation
of these systems way back when when I actually served

(01:08:26):
in the IDF, I served for several years as an
officer in the Israeli Air Force and where I primarily
served was at the Air Force Ts Range, where I
was intimately involved with the development the development of the
aero system, which is that part of the multi layered
missile defense system that actually is intended to intercept and

(01:08:49):
destroy the ballistic missiles.

Speaker 2 (01:08:52):
Most that Iron Dome.

Speaker 3 (01:08:53):
No, so most people are familiar with Iron Dome because
it got a lot of press and it's got a
cool name. But iron Dome, like I said, it's a
multi layered system. Iron Dome is actually for the lowest layer,
so it's against mostly against rockets. So when Hamas was
firing rockets at Israeli cities, those who were intercepted by

(01:09:16):
the Iron Dome. But then you've got, you've got additional layers,
You've got David Sling, and finally you've got the arrow.
And the arrow is the one that's supposed to intercept
ballistic missiles. Ballistic missiles, in case you don't know, literally
fly out into outer space before falling back down to Earth.

(01:09:36):
And the arrow is actually able to intercept those missiles
in space. It's pretty nuts when you think about it.
So right now Israel is using Arrow three. I'm old,
so I was actually involved in the development of Arrow one.
But you know, things grow, you know, evolve from one

(01:09:56):
to the next. So I'm proud to say that I
had mice all part in the development of that system.
Hopefully this war will end soon and we won't need
those anymore, and at least in the immediate future. Until that, doo,
I'm happy to have them and to have them protecting us.

(01:10:17):
And I guess that, oh yeah, my personal part was
relatively small that so that would be one pick. The
other is not a pick. It's more of an announcement.
In the last episode that recorded, I told that there's

(01:10:38):
a conference in Israel. Actually it's a dual conference. It's
React next and No TLV. They are kind of back
to back conferences. React Next is Israel's largest front end conference,
and No TLV is obviously about node. Josh was actually
supposed to come and keynote the No TLV conference. Obviously

(01:10:59):
he can't do this at this time. I was actually
supposed to keynote React Next. You know, for obvious reasons,
these conferences have been postponed. So now they've been rescheduled
from the end of this month to mid December. Hopefully
by that time all this stuff would be behind us
and we can have conferences like normal human beings. And

(01:11:24):
that would be my announcements and picks for today.

Speaker 1 (01:11:27):
I guess alrighty, I will go next and go to
what I prefer to think of as high point of
our podcast, which is the dad jokes of the week.
The other day I went into the library and I
told the library and hey, I'm looking for a book
about turtles. And he said hardback, and I said, yes,
with small heads, all right, okay. Questions, So humans can

(01:11:55):
catch diseases from monkeys and bats, but why not anteaters
because they're filled with antibodies, right, okay?

Speaker 2 (01:12:08):
And then and.

Speaker 1 (01:12:09):
Then one day I made a call and I said, hey,
is this the Gambling Addicts hotline, and the operator said, yeah,
how can I help you? I said, the dealer had
a ten against my sixteen? Should I hit or stand.

Speaker 2 (01:12:25):
Right? I was asking for help on gambling anyway, Yeah,
I get it, d met You looked a little confused.

Speaker 4 (01:12:32):
I don't think I still I think I still don't
get it.

Speaker 1 (01:12:34):
But well, you know, gambling at and you called to
get help to avoid gambling, but I was calling for
help on a.

Speaker 3 (01:12:39):
I can't tell a funny story about the fact that
you know some and this is a true story. So
the company that I used to work, we would go
out to eat lunch at some restaurant and we would
go there pretty regularly, so we got into kind of
friendly terms with the owner and he would come and
say it with us when we arrived and he and

(01:13:02):
he liked gambling. He would literally, you know, when he
could go to some casino to play. And he told
us about how stupid some of the other gamblers are.
That he was at the roulette table and it came
up black like four times in a row, and one
of the other people put on black. The bet on

(01:13:24):
black again, he said, what's the chance of having coming black?
Five times in a row, and we and we didn't
want to and we didn't want to correct him because
we didn't want to get poisoned the next time we
came to eat.

Speaker 2 (01:13:42):
Yeah, all right, Gimet, you your turn.

Speaker 4 (01:13:45):
I'm going to give it up to ts morph. For
those of you who haven't seen it, it's a project
that allows you to do conversions on the kind of AST.
You can describe changes and refactors to a project based
on its AST and it it's a pretty cool project.
And I don't know, I just I like. It is
the first thing that came to mind. So I thought
it'd be authentic if I just tell you what is

(01:14:06):
on my mind that I like. Let's see, is that
the pickway? Is there two things I'm supposed to pick?

Speaker 3 (01:14:12):
You can pick whatever you want. I expected you to
pick a squiggle cony.

Speaker 4 (01:14:16):
Oh yeah, okay, okay, great, you read my mind. Also,
so we've talked about Josh Josh okay, yeah, so okay
before the call, I was saying at squiggle comp, so
I run a conference with Josh Goldberg. We're co founders
of squiggle comp. And the name is such because it's
a dev tools conference. So there's lots of people that

(01:14:38):
are making dev tooling and that's their kind of bread
and butter, even internally at a company, but externally library
authors and stuff like that, and Google COMP is a
place for those people to get together and ruminate in
the things that they learned building these tools. It's a
cross language conference, so it's not a type trip conference only.
We have representation from RUST. Last year we had ZIG.

(01:14:58):
This year we're having Glean as well, up and coming
language C plus plus C Sharp is also represented GO.
There's two talks focusing on Go this year. So it's
a really cool opportunity to get experience and exposure to
what other communities and other languages are doing. And yeah,
we're very passionate about it. Of course you have to
be to run a conference. But I didn't even realize that.

(01:15:20):
I didn't know that we were even being video recorded today.
Last year at the conference, somebody spilled some coffee on
a bunch of Squiggle COF twenty twenty four shirts and
so we couldn't sell them. And so now I have
like five Squiggle comp shirts, which means that when I
reach into my drawer to pull out our shirt in
the morning, there's a abnormally high chance that I'll pull
out a Squiggle Comp shirt which is very comfortable, so

(01:15:40):
it works out.

Speaker 3 (01:15:41):
A little bird just mentioned, A little bird called Nick
called Josh just mentioned on our chat that you have
a great dad joke about Richard Nixon.

Speaker 4 (01:15:54):
I don't have a great dag joke about Richard Nixon.

Speaker 3 (01:15:56):
Astant.

Speaker 4 (01:16:01):
I don't know, I don't know. Sorry, I'm sorry to
disappoint you, Josh. I may I may, I may know.
Have forgotten. I'm not very I'm not very funny. Maybe
I can own that.

Speaker 3 (01:16:17):
Oh well, By the way, I highly recommend people watch
the videos that you created. Where can people find them?

Speaker 4 (01:16:27):
Well, sorry, I just one last thing I forgot to mention.
So Squiggle Comp this year is in Boston on September
seventeenth and eighteenth. It's a really cool venue. It's in
the New England Aquarium and there's a big Imax screen
so it's like super comfortable and where it's a two
day conference this year. We just this week announced all
of the speakers and all their talk their talk topics,
so you can go read the list to just go

(01:16:47):
to squigglecof dot com. C s q U I G
G L E c O n F and you'll find
all the information there, so please take a look. Also,
in kind of parallel to that, yes, I run the
kind a video aspect of Michigan type Script, but there's
lots of other people involved with Michigan type script. Is
this other project from my home state. Here in Michigan.
We have a meetup that meets once a month. Actually,

(01:17:09):
we were meeting in two weeks from yesterday, and we're
going to be uh definitely represented. We have a few
people coming out to Squiggle Comf as well from Michigan.
So it's a it's a good time. I enjoy this
kind of stuff. Labors of love, you.

Speaker 3 (01:17:22):
Know, So I have as a homage to Josh, he
basically wrote out the joke.

Speaker 4 (01:17:28):
Okay, all right, let's hear it.

Speaker 3 (01:17:30):
So, so it turns out that Richard Nixon worked at
the restaurant. Apparently he mostly worked front of house. They
offered him a space in the back of the house
like working food prep and culinary work, but he declined,
saying I'm not a cook.

Speaker 4 (01:17:50):
That's a joke.

Speaker 2 (01:17:51):
That was a long road for that one, but we'll
give it to.

Speaker 3 (01:17:56):
It's not me, it's Josh, all right, right, all.

Speaker 1 (01:17:59):
Right, so that awesome dad joke. We will end this
episode of JavaScript Jabber. Thank you Dimitri for coming on,
thank you Dan for joining us, Sirens.

Speaker 2 (01:18:06):
And all, and

Speaker 1 (01:18:08):
We will talk to you next time on JavaScript Jabber

All Episodes

Running Doom in TypeScript’s Type System with Dimitri Mitropoulos - JSJ 684

Episode Transcript

Popular Podcasts

Dateline NBC

Stuff You Should Know

Law & Order: Criminal Justice System - Season 1 & Season 2

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}Running Doom in TypeScript’s Type System with Dimitri Mitropoulos - JSJ 684