Okay, so let me start right away. I can tell you a quick story that I wrote a very short article

on Reddit just a few weeks ago, where I criticized how people use JavaScript these days, especially

the classes and type annotations in TypeScript. And one of the commenters and readers posted a

message under the article, which was saying exactly this, I quote. He said, "I missed the crock for

times." What do you think he meant by this? I have no idea. I didn't hear a lot of that sentiment

during those times, so I'm not quite sure exactly what that means. I think he was talking about

different JavaScripts. The JavaScript we had like 10 years ago and the JavaScript we have now,

and I think he missed the times when we were using the best parts of JavaScript according

to your book and to your vision. Yeah. Since then, the language has gotten a lot dirtier.

They just keep adding more and more crap to it. But the good parts are still the good parts,

and you can still program as though they didn't add any of the new crap, and you can still write

very good programs in JavaScript. Actually, in 2023, you said in one of your talks that JavaScript

is a smelly language. And I wonder which forces strongly prevented us from using the clean version

of JavaScript. What made JavaScript dirty and smelly according to you? Many of the people using

JavaScript came from other languages, and they were very resentful because they didn't want to

be using JavaScript. They wanted to be using the old languages. They didn't want to have to be

learning a new language. And so they used stuff that looked like the old stuff they were doing.

So if they were doing C# or Java or whatever, they wanted something that looked like that in

JavaScript. And so that put a lot of pressure to add class to the language and other things.

This tendency we're seeing now, all of the languages are borrowing features from each other.

It's like eventually they all want to evolve into the same language.

And you kind of wonder, why do we have all these languages? But maybe the end of all this evolution

is there's one language that eats up all the other languages. But that's not really a design path.

So we go along aggluting features, and the features are often not orthogonally meaningful.

There have been a few new languages like Rust. There's some brilliance in Rust.

I think there's also brilliance in Go. But for the most part, all the other languages are trying to

copy each other. I know that TC39, which was the JavaScript standards group, had a lot of Python

envy. They wished that JavaScript were Python. Even though at the time JavaScript was much more

popular than Python, they still wanted to be working on that language and not on the language

they were working on. Maybe there's a reason for that. They want features that they miss and they

actually... I mean, there's a practical reason for that, I think. The industry just demands this.

Yeah. So my contention has always been there's a functional subset in JavaScript, which is brilliant.

It's kind of like Scheme with dynamic objects. And that is such a brilliant design. There's this

wonderful, brilliant thing hidden inside of JavaScript. And I've been very successful just

writing to that subset. And I don't need any of the other stuff. And in fact, the other stuff

is sort of a burden because it gets in the way. But I'm not the majority, certainly, far from it.

Well, let's imagine we design a clean language or we get back to JavaScript, originally remove all

the classes and all the stuff which was added later, and we get to a cleaner language. Do you

think it's in general possible to have a clean language in the industry and keep it that way

for a long time? Or any language would be killed no matter what, or could be turned into Java

eventually, no matter how clean it starts? Yeah. I think it would be dead on arrival

if it had to be thrown into the ecosystem with all the existing languages, which already have

lots of publications around them and lots of user groups around them and a lot of legacy.

But if that language were positioned such that it's solving a new class of problems

that the other languages do very poorly on, then I think there might be a chance.

There are many, you know, pure languages and clean languages like Smalltalk,

Excel, for example, they remain niche languages. They never became standards or, you know, industry

standards. Yeah, it's a real shame. The Smalltalk 80 was maybe the best designed programming language

in the history of languages. They spent almost a decade in design and testing of that language

and refinement and going through many versions until they finally arrived at 80, which was

really, really good. I think it failed in the marketplace for two reasons.

One is the early implementations were not very fast. Eventually, that goes away. Moore's law

makes that irrelevant. So, you know, if we'd just been a little bit more patient,

that one would have fixed itself. The other was it required that you understand how to think

in terms of object-oriented programming. And as a transitional language, that's a really hard thing

to do. So instead, we went with C++, which is an awful language. There's very little defensible

about C++, but it allowed you to be working with an object-oriented programming language without

understanding anything about object-oriented programming. You could still write in Fortran.

You know, it provided better support for the old paradigms than for the new one.

And people said, "Yeah, that's the one we want." And we're still stuck with it. It hasn't died yet,

which is amazing. And they've been adding features faster than anybody else. That language

has been growing and growing and growing. Is there something wrong with us, people,

or the object-oriented paradigm in general? Maybe the paradigm is wrong.

I think the paradigm is wrong. I think object-oriented was an important step forward.

You know, it got us past the procedural. But it shouldn't have been the last step forward,

right? There should have been another step after it, but we're stuck. We haven't been able to move

past it. And so, you know, that's a problem. So I think there is a new paradigm out there. And it's

kind of obvious, if you look at how the world works, what we're doing now, that none of the

languages do well. So I think there are opportunities to move on, but we're not quite there yet.

Maybe not the paradigm is wrong. Maybe we just teach it the wrong way. Maybe the schools need

to be fixed. Or the books. I don't know. I'm the last guy who wants to criticize schools or books.

So I think it's just that, in general, industry is trying to solve the wrong problem.

Or trying to solve a problem in an old way and not in the new way. So, for example,

all of our current programming languages start from the von Neumann machine. The von Neumann

machine was the first modern description of a digital computer, where you've got a memory

with addressable cells in it and an instruction processor that can take values from the cells

and modify them and put them in other cells. And those cells can contain numbers or characters

or instructions. And that's how all the machines work. We're still making von Neumann machines of

a type. And Fortran, being the first really successful high-level language, was very much

about supporting the von Neumann architecture. And all of our languages since then, or almost all of

them, have been adding features to Fortran. So there's a lot of Fortran. Even some Fortran

syntax still survives in C. And C has been copied in the syntax of almost all the other languages.

So at some level, we're still writing Fortran. The problem with the von Neumann architecture,

and it's a problem shared with the lambda calculus and the Turing machine, is that they assume that

all of the computation is happening in one machine. And that's not the world we live in anymore.

Computation now happens in a lot of machines. We've got clients and servers. That's the most

obvious place. But even in the servers, you often have dozens of machines involved in every

transaction. Stuff's going all over the place. And our languages don't understand that. They

can't cope with programs being distributed. They assume that everything's happening inside of one

memory space. So I think the next paradigm should be one which allows us to more effectively

effectively deal with running stuff in many places at once.

And even beyond that, when we first opened up the barriers between machines and let them

start communicating with each other, that's when all the security problems were discovered.

Because if you allow me into your machine, there's no limit on what I can do in your

machine, and if you allow me in, there's a chance that someone else is going to get into.

And we're still struggling with that.

We've been dealing with that for, let's see, I think it started in the 70s, so it's been

going on.

The problem is almost as old as I am.

And we haven't solved it yet.

And we're seeing terrible consequences.

Like last year, I was, was it last year?

I think so.

I was trapped in Berlin when Delta Airlines melted down because of a security problem

in Windows.

That was a huge software failure, and it was all about security.

It's all because we don't understand how to make machines work together securely.

We've been adding band-aids and ad hoc stuff, but obviously it doesn't work because we still

see these meltdowns from time to time.

Technologies are getting breached all the time, all of our passwords are out on the dark net.

Governments are now attacking each other because of all of these insecurities that are baked

into the architecture.

So I think we need to rethink how all of that stuff works and come up with a way of allowing

programs to work cooperatively with each other and other machines without compromising each

other.

We have a student in front of us who is 17 years old, and we start teaching programming

to that person.

And we start telling that poor young person that there are many machines and everything

runs in concurrency and there is no one central line of commands.

And then we give these students the language which is concurrent, which is parallel.

Do you think they will understand that?

Or they will say, no, please give us the traditional Fortran or JavaScript or C++, which is easier

for us to understand because it's just sequential.

So the student doesn't want legacy, doesn't want tradition, that means nothing to them.

They have no value on legacy.

So they are the ones who might accept the new paradigm.

The problem is with all the old guys, that they've been doing this thing their whole

career and they don't want someone at some point saying, okay, you've got to start over

now.

You are now at the same level as that 17-year-old.

They go, whoa, no, that's not what I want.

And that's why in order to introduce a new paradigm, usually we have to wait for a generation

of programmers to retire or die before we can get critical mass on the next idea.

When JavaScript was introduced, according to my knowledge, it was meant to be a functional

programming language with the syntax which resembled Lisp.

But then they said, no, we cannot accept that in the browser because it's too complex.

So let's make something which is more traditional like Java and then we get JavaScript, right?

Not too complex, but too unfamiliar.

So in the browser, the first programming language was Java.

And Java was the most successful introduction of a new programming language in history.

It took off almost immediately.

Everybody loved it.

It was basically a rewrite of C++, but it got rid of the pointers and was a lot cleaner.

And it was strongly embraced.

And it was the first programming language in the browser and it failed hard.

It just didn't work.

It was too slow, it was too cumbersome.

It did not fit the problem at all.

It was just appalling.

Eventually they figured out that it still had a mission on the server and it did that

a while.

But I think the web would have died and been replaced by something better, except that

there was also JavaScript.

And JavaScript was powerful enough that it could do all of the things that you wanted

an executable internet to do.

And JavaScript succeeded in spite of all of its defects just because it was the only language

in the browser.

It was your only choice.

So if you wanted something interactive in the browser, you had to learn JavaScript.

That was a fluke, that was a one in a billion thing.

You can't depend on that ever happening again, I don't think.

But still the syntax was not made Lisp-like, it was made Java-like.

Yeah, well the problem with the Lisp syntax isn't that it's complicated, it's actually

extremely simple.

It's just it's weird and unfamiliar.

With a good IDE to balance all the parentheses for you, it's in the noise, it doesn't matter.

But at that time the IDEs were not powerful enough to do that well.

So they made it look like Java, which was a source of confusion because a lot of people

thought, "Well, I can just, this is Java, right, so I can just write Java in it."

And that didn't work.

So sometimes it's easier if you're going to something which is completely different other

than something that's kind of like what you're used to but is not in ways you don't quite

understand.

There was a huge difference between Java and JavaScript to my knowledge is that JavaScript

has objects and Java has objects and classes.

And it seems that they both call themselves object-oriented languages, but fundamentally

they are very different.

The presence of classes makes a difference as far as I understand.

Well, although JavaScript now has classes too and sort of always did.

If you understood what a class actually was, you could create classes in JavaScript and

a lot of people did.

And I showed people how to do that.

So in that respect they weren't that different.

The main difference between them, I think, is that JavaScript had a type system which

was not strong enough to protect you from making errors but was annoying enough to impair

your productivity.

JavaScript didn't have the type system so you're kind of on your own but you could also

be much more expressive.

It was much more dynamic.

You could do things like load little pieces of program individually and the browser just

kind of put them all together.

That's how the web works and you could argue that's a stupid way for the web to work but

that's how the web works and it works.

You could never do that stuff with Java.

It's not dynamic enough.

In one of your talks you said that the ability to extend an object in runtime which exists

in JavaScript and doesn't exist in Java is one of your favorite features of the language

which makes the language beautiful.

Do you still think that way?

At that time I was an advocate of prototypal inheritance which is something that JavaScript

has which is fairly unique.

I've decided I'm not an advocate for that anymore.

I think inheritance in general, it was a bad idea.

The thing about inheritance is basically I've got this thing and I want another thing which

is similar to it but slightly different and so I'll have this one inherit from that one

and I just list what the differences are and that's a really quick way to get started.

But when the inheritance chains start getting long, it gets really complicated.

You've got all these things kind of forking out and if you have a design error at one

level that design error propagates into everything else, it's just a mess.

In retrospect I think that's a really bad way to construct stuff.

Like that except any kind of exception-based thing I think looks really good in the small

but doesn't scale.

What I'm advocating now is having two flavors of objects.

One is data objects.

We have got objects just with lots of data in them and they're malleable and you can

update them and do whatever you need to do to them.

That's where you keep your state and then you have objects which are frozen which only

contain functions and those functions close over one of those objects.

Those functions can also take other objects as inputs and so they do the work of classes

and that they give you the encapsulation but instead of building by inheritance, you build

by composition so you can have lots of different things that you're aggluting into one of these

things and it's all hidden inside of the closure of functions.

I think that's a brilliant way to do software construction and JavaScript is sort of unique

in the way that it provides that.

Can we call these objects pure objects?

Purity arguments often go to dark places so I'm not sure I would call them pure.

In some languages, you would call it a struct or you would call it a hash table or a dictionary

or something.

It's just some collection of key value pairs and that turns out to be a really powerful

idea.

the languages have a thing like that. Now one of the weaknesses in Fortran was it didn't have one

of those things. But since C, we've had them. The problem with C's struct is that they're not

dynamic. So you're stuck with a brittle structure. But in most of the more recent languages,

the things are more dynamic. So you can update the number of properties within the object and

grow it or shrink it, do what you want, so that they're very adaptable. And the JSON format

was designed for supporting those sorts of objects and allowing us to transport them from one language

to another. But still we have functions inside objects. And some people misunderstand object-oriented

programming. They just understand objects as storages for functions. And then they make

these functions long, like very long sometimes. They just become procedures, which are no different

from Fortran procedures. Yeah, exactly. You can always write Fortran in any language.

So some people say that functions and control flow structures and if-then-else-for-while loops,

they are sort of things that destroy object-orientation.

That we should not have them at all. And that would make our languages pure object-oriented.

That doesn't make sense to me. So we need these statements and control flow.

Well, functions should be the interfaces to the objects. And how the function accomplishes its

work is nobody's business. A function should be a black box. And inside of it, you pass it an object

and it's going to do some work on the object and give it back to you. You shouldn't care how it

goes about that. So if it wants to use ifs and loops, I think that's fine.

And how can we prevent these long, long functions or procedures? How can we teach programmers not to

do that? Keep them small. Separate your scope into smaller objects.

I don't know. People have been struggling with that problem since Fortran. One of the features

in Fortran was subroutines, which allowed you to break your program into smaller programs or

smaller pieces of program and have them call each other. And that was a brilliant idea.

The initial motivation was for efficiency so that you could reduce the amount of memory that you're

using. If you're doing the same thing in two or more places, you could put it in a subroutine

and you save all that memory. And that was really important when we measured memory in K,

particularly when it was one or two digits of K. That importance has gone away now since

memories are so incredibly big, which is great. It's really nice that memories are really big.

Unfortunately, our programs get even bigger somehow

because there are no limits on how big we make things. And so we don't have to think

efficiently anymore. But the more important value of subroutines was it allowed us to break things

into pieces that were easier for us to understand. So you take a bunch of functionality and you put

it in a thing and give it a name. And that name should be enough to give you an idea of what that

thing does. And then you can call that wherever you need to. Maybe you only call it in one place.

That's fine. So you can break the program down into little boxes and you can understand the boxes

one at a time. You don't have to understand the entire program at once. And that was really

valuable. And it's still really valuable. And I think that's still one of the major benefits

of functions. We stopped calling them subroutines. We call them functions now, but it's the same idea.

So how do we teach people to use functions properly? I don't know.

We've had Fortran since the 50s. We should have figured this out by now. But it's still a struggle.

Objects also play the same role. They help us decompose larger scope into smaller pieces and

then give these pieces names. And then we know what's going on in these objects without looking

into it because we know the name. Yeah. So the best features of the languages,

I think, are the ones that help us understand what the programs are doing.

And I think all of the other features are distractions. So the objects love the objects.

The functions, I love the functions. You can get rid of just about everything else. I'm happy with

that. I can build applications out of the objects and the functions. And there are also actors,

which you talk about for quite often recently. And they are supposed to be replacing objects,

according to a few of your presentations. I don't see them replacing them, but I

see them as a more powerful paradigm. So actors were invented in the early 70s,

about the same time that small talk was being invented. In fact, the two almost have a common

origin. And the actor paradigm was inspired by small talk, or an early version of small talk.

When Alan Kay talked about small talk, he said, "You've got objects that send messages to other

objects." And people at MIT heard that and wondered, "What's this message passing thing?"

And developed a programming paradigm based entirely on message passing. And it was brilliant.

But it went nowhere. It was not adopted. Although a subset of it turned into the Scheme language,

which wasn't very popular, but was extremely influential. All the language designers know

Scheme and are very much influenced it. In fact, the best parts of JavaScript come from Scheme.

But Scheme didn't quite get the actor model right. But the thing that's brilliant about

the actor model is that all the computation is based on message passing. And we have experience

with message passing in the browser. That's how events work. An event is a message from the UI

system that gets sent to an object, and the object decides to highlight a field, or I'm going to

clear the page, or I'm going to do whatever I'm supposed to do with this.

We can take that same idea and apply it to the network so that we can send messages over the

wire. And that's really powerful because that's a way that we can have our programs communicating

with other programs. I've got an actor on my machine, there's an actor on another machine,

or I don't even need to know where the other actor is. It might be on my machine, it might be

on the other machine. I talk to it in exactly the same way. And so that's a primitive on which we

can build distributed systems. So I think the actor model should be the next paradigm.

You remember Corber.

I do, yeah.

That was the same direction, I think.

Well, they were trying to figure out a way of representing

specifications of data structures to allow programs on different systems to be able

to communicate with each other. And it turned out to be extremely complex.

It didn't fly.

Eventually it failed. It was largely replaced by XML, which was attempting to do the same thing.

It came at it from a completely different paradigm. They said, "Let's assume that the

stuff that our data structures are actually documents, and we can pass documents back and

forth." But that turned out to be crazily complex. So I do a query of a server,

and it would send back a document, and now I have to query the document to find out what I want to

find out. It was grossly inefficient and weird. So I came up with JSON, which was a subset of

JavaScript objects, which we just say, we pass an object back and forth, and that most of our

languages, while they might be incompatible in lots of important ways, they all have something

that we call a number, and they can all agree that they can represent a number as a string of digits.

And they all have a text, and we can say for the purpose of communication, the text is

a quote mark, and some characters, and an end quote. And we've got true and false, and we can

have an array of stuff, which is just a sequence separated by commas. And we can have key value

pairs inside of curly braces. All the languages can understand. Yeah, we can make sense out of that.

And so JSON, very, very lightweight, just says, "Okay, you can make one of those,

send it to another machine, and they can make sense out of it." And that's been incredibly

successful. When I first introduced JSON, there were a lot of people who said that cannot possibly

work. It cannot possibly work. XML is really complicated for a reason. That complexity is

there, and someday you're going to understand why that complexity is there. It turned out we never

understood why it was there. It was just complicated. It's because they were trying to solve the problem

the wrong way. JSON was just as simple as you could make the thing, and it worked. Every language now

can understand.

how to read and write JSON, which means that you can communicate with any program, no matter

what language it's written in.

And that's pretty neat.

And the particular flavor of that language comes out of JavaScript, you know, JavaScript

kind of...JavaScript has become crazily complicated, but there is a beautiful, clean core to JavaScript,

which is universal, and everybody understands that universal bit now.

I think the intent of XML was to have a document which, when you open it, you don't need to

ask a question, what is it and where it's coming from, you know everything about it

because it has proper meta information, like the link to the schema, link to the region

of that.

So it's like a universal document format, which apparently was not that needed in many

systems.

Because JSON is specific, if you get the piece of JSON document, and if I don't know where

it's coming from, I have no idea what to do with it.

So JSON is okay if the sender and receiver, they both understand what's going on.

But XML is something that if I open the XML document coming to me from I don't know where,

I still can understand what's going on because there's a lot of meta information there.

Well, the main information you get there is in the tags.

But you also have to go through a big transformation, you know, you can't really represent arrays

in XML.

You can have lists of things nested together, but it doesn't say that it's an array necessarily.

So you have to do a transformation, and you have to deal with the difference between elements

and attributes.

You know, if this time it's an attribute, this time it's an element, do they mean the

same thing or not?

So there's a lot of unnecessary complexity at that level.

JSON was designed specifically to allow languages to talk to each other.

And XML was not designed for that.

It was designed for formatting documents.

And they said, well, as long as we went to all this trouble, maybe we can also use it

for this other thing.

But it turned out JSON works better.

If we imagine these actors who talk to each other on different computers, then it seems

that all the actors, they need to be subscribed to some sort of event bus and listen to messages

and send messages, receive messages.

That's what's supposed to be there?

Not necessarily a bus.

So every actor has an address.

And you can only send a message to an actor if you know its address.

If you don't know its address, you cannot send a message to it.

That is where the security of this comes from, that we can restrict the way in which addresses

become known.

And so if you're an outsider, there's no way you can acquire an address.

So there's no way you can get into the system.

And so I can send messages directly to an actor.

And it might be on another machine, it might be many hops away.

I don't know or care.

It just gets there.

So messages will get delivered to the actors on arrival.

If the actor is busy, they'll get held in a queue and will eventually be delivered in

arrival order.

And the actor can then decide what to do.

So it's not a strict call return protocol.

Most of our protocols now seem to be call return, like HTTP.

So that makes it hard for some kinds of applications where you want the server to tell you that

something happened.

But if you don't ask the server to tell you if it happened, there's no way for it to tell

you because the client has to initiate all the messages.

And also the client has to wait for a reply, even if he doesn't care about the reply.

So in an actor system, an actor just sends a message and he can send several messages

to several different objects and all the messages go out.

We can do call return semantics if you want to.

So a message comes in and I can send a reply to that message.

But generally it's just one message.

So that allows us to do things like flow-based programming where I've got a network or a

graph of actors and each one will receive a message, do some work on it, and then forward

it to the next object or next actor and they'll keep going.

So I don't need to get returned on the first one, I just send it to the first guy, he takes

care of it and so on, it all gets done.

So we cut the number of messages flying around in the network by half because we don't need

the reply messages generally.

And there is no guarantee that the reply may come?

There's never a guarantee.

There's some people who talk about guaranteed message delivery.

That's a myth.

That's impossible.

Something could happen on the machine.

There might have been a bug in the actor, the system might have crashed, there might

have been a bomb in the data center that blew everything up, or a power failure.

You don't know why the message didn't come back.

But there are reasons for why a message can't come back, it cannot be guaranteed.

So another part of the paradigm is that we have to be ready to deal with failure.

If we're programming in a world where everything is guaranteed, eventually when the failures

come they're going to be catastrophic.

So instead you need to have failure built into the paradigm.

Failure is always an option.

I think Erlang did a brilliant job in showing us how this can work.

And I think we take that idea that when things go wrong we can selectively restart the stuff

and get back to a clean state and recover.

That's the best we can hope to do.

The callbacks which we have in so many places in Node.js, it resembles the actor model to

me.

It's a start, yeah.

You also have no guarantee, right?

You just call the function, provide a callback, but you don't know whether the callback will

be ever called.

That's right.

It's a subset of the paradigm.

So browsers and Node, because it's based on the browser model, are the first step toward

it.

So I think if we ever do get to full-blown actor systems, web developers will be the

first to embrace it, because they're already doing some of it.

There's some new stuff they'll also have to learn, but they will be in a much better position

than everybody else.

I've heard so many complaints from programmers about that.

They say all of these callbacks, they just increase complexity of the design.

Because every time you call a function you need to think about providing the callback.

Instead of doing the traditional call, call, call, just the sequential, the Fortran style.

Yeah.

That perspective led to the invention of, what were they called, remote procedure calls

or remote method invocations, where the idea is we want to be able to call a subroutine

on another machine, but we want to hide the fact that we're doing that.

We want to make it look like an ordinary subroutine call.

And I'm saying subroutine just, I don't know, because I like the word subroutine.

The problem with that is that you've got big performance problems, because the calling

program is blocked until you cross the network and stuff happens and the reply comes back.

You don't know how much time that's going to be.

And so you're building huge delays into your program, which you cannot see by reading the

source code.

And that's really problematic if you want to have any kind of performance.

That program cannot be doing anything useful while it's waiting for that remote procedure

call to resolve.

The bigger problem is that call can fail.

The message may never come back and so it's going to hang forever.

And in that state there's no way that it can recover from that.

And so that's a huge error.

So I think that's just a bad paradigm.

So instead of trying to hide the realities of the universe, we should instead learn to

embrace the realities of the universe and learn how to deal with these temporal events

as they are.

When people started doing event handling in JavaScript, there were a lot of people who

were really resistant to it.

When they wanted to, say, read a text field, they wanted to just stop and do a read statement

and have it stop until someone typed something in.

But if you have a dynamic UI, that cannot possibly work.

You don't want to stop because they might instead want to click on a button instead or type

in a different field.

We want people to have the freedom to do whatever they want.

You don't want to be locked into a particular sequence of blocking events.

And so there are complaints that this is an unnatural way, using an event loop and events

to do UI is unnatural.

It's an inversion of control.

It's not the way God wants us to write programs.

It's just wrong.

But it turns out it's exactly right.

having these independent events so that, you know, an event handler is basically a callback,

right? So, you know, if you think about it right, it is not all that complicated. You

just say, "I want to hear from this and this is what we'll deal with that when it happens."

You just, we're going to take that and apply it to everything.

Yeah. It works perfectly for the UI programming, but if it's just a simple script, which for

example, supposed to read the content of a file and then save it to another file and

then read another file and then save it to another file. Just four simple steps, which

supposed to go one after another. Then in the callback fashion, we need to go into four

levels of nesting because we provide one callback and inside these callback, we call another

operation and then provide another callback. So you can imagine how it's going to look

on the, on the screen. It's going to be deeper and deeper nesting and people complain about

it. And they, and what they do and they use promises, which you know about, which you

also, I mean, you know how promises work in JavaScript.

Yeah. Promises were invented at a company that I started. So I know all about promises.

So the problem with the nested callback thing is it's the wrong way to, to do this stuff.

So if you do things the wrong way, then it's easy to get frustrated. So I completely understand

that. So the right way is you take each of those steps in whatever the process is going

to be, and you put each of those steps in a separate function. So each of those becomes

a black box. Okay. Which is the right way to do stuff anyway, right? That's what we

invented subroutines for. That allows us to, you know, clearly say, you know, this is depth

one, you know, that the name of the function might be step one and it's going to do this.

And each of those steps will return a function that takes a callback, which I could explain

that better another time. But basically we've got these four boxes which represent those

steps that you want to do. I have a, a JavaScript package called pronto, which contains a function

called sequence. So you say pronto sequence and the four black boxes, just put them in

an array and pass it to that. And it will manage taking the calling one and taking its

result and passing it to the next one and so on, sort of like a pipe. There's also one

called parallel, which does the same thing, except it calls them all at once and returns

an array of the four results and you can put these together in lots of interesting ways.

So we separate the units of work from the flow, from the control flow. The reason the

nested event handler thing doesn't work is we're mixing all that stuff up. And so the

flow and the work get all messed up. It's worse than using go-tos, which were the way

we used to do it wrong. So taking a more functional approach, it's possible to end up with programs

that work better, that are much more flexible and are easy to read and maintain. You don't

need promises, you don't need async/await. My biggest problem with async/await is that

people are trying to make their programs look like they are linear when they are not. And

so they don't understand how their programs work. They put async/await into the program

and hope that that makes it work, but they don't really understand what it's doing. And

any time you don't understand what your program is doing, that's when bugs happen. Things

can go wrong. It might just be performance problems where it takes a really long time

and you can't figure out why. Or it might be that you got the flow wrong in ways that

you don't understand because you don't know what steps the program is actually running

in.

By listening to you now, I think maybe the async and this await keywords was a mistake

in the language.

I think it was. Concurrent programming turns out to be a really important way of dealing

with lots of stuff going on. And people have been trying to do asynchronous programming

or concurrent programming well for a long time. And there have been a number of bad

approaches to doing it, like threads and synchronization, which is the way Java tries to deal with this.

I think it was a terrible mistake because that leads to deadlocks and races. And the

hardest bug I ever had to find was a race to two things happening at the same time.

Because you can't look at the code and see what happened. It's about the interaction

of things that you don't see. So, you know, debuggers don't help you, tests don't help

you. That's really hard. So, that's a terrible way of doing things.

I think if the flows are fairly simple, then the callback is effective. But if the flows

are more complicated, like you described, then you need something like the pronto package

that I'm describing. I think that provides the best way of putting this stuff together.

It's readable and maintainable.

And your MISTI project, the language which you designed, it doesn't have all these problems

of JavaScript. It's more pure actor model?

So it depends on your perspective. So MISTI is my actor language. So it's my interpretation

of how to solve the distributed programming problem. And I started with JavaScript because

I think there's a lot of value in JavaScript. But I started by fixing every design mistake

in JavaScript, at least according to my understanding. And I believe my understanding is the correct

one. So the syntax is quite a bit different. It doesn't have semicolons in it, for example,

because JavaScript is a language that has semicolons but doesn't completely require

semicolons and that ambiguity is a source of bugs. So that was bad. So the correct way

is to either require semicolons everywhere or not require them anywhere. And so that's

the approach I took. So my language looks more like Python than it looks like JavaScript.

But try to simplify all of that as much as possible. And then use that language to create

actors. So you've got MISTI programs and MISTI programs compile into executables which run

in actors. And my goal is that I can take a distributed system, put it all in one machine

for development, and then for deployment we can put it off in all the other machines with

no code changes. And I think I can do that. So it's horizontal scalability by design.

And it supports the flow-based model. There are lots of ways that you can use it. But

the key thing is that you can have communication between things which may be remote. And so

you get a lot of natural parallelism if you design your programs correctly. Now, you're

not guaranteed to get that improvement. For example, if you're still stuck in a A, B,

C mentality, then I'll do A and then I'll send something to another machine and it'll

do B and it sends it to another machine, C. If that's all you're doing, you're making

things slower, not faster, because you're paying for the network time. So you want to

figure out a way to allow for multiple things to be happening simultaneously. And so this

language doesn't require you to do things that way. But if you do, then you can get

huge improvements in performance. This reminds me a little bit about data flow evaluation

concept. Very much so. Yeah. In hardware. Yeah. So this is data flow in software. But

yeah, it's the same idea. You know, thinking about how... So in this case, the data is

flowing through messages, but it hopefully will tend to flow to where it is needed, where

it can be acted upon, and then further flowed to where it's next needed. But usually data

flow is in the hardware. That's how they design CP. Yeah, that was an early imputation of

it. But if you think of it just in terms of how data flows, instead of hardware flowing

within one box, we now have software flowing across many boxes. That's the same basic concept.

In this MISTI project, the language is already in production mode, or it's still experimental?

It's still experimental. So the reason I call it MISTI is because it is vaporware. It's

a long way from being releasable. I can't guarantee that it'll ever be released. But

I'm working on it. And I think I'm doing it correctly. And hopefully someday you'll

get to see it. So for the programmer, it will not be obvious that two actors are located

at different machines? Right. So the place where MISTI differs from

languages like Go that are also trying to solve a concurrency problem, actors do not

share memory with each other.

So that there's no shared memory.

So each actor could be in its own machine by itself, you know, virtually it would be

like that.

So even if two actors are on the same machine, they can only communicate by sending messages

between each other.

Having that isolation means that we can easily then move to the network.

Because in a network, you can't share memory, right?

Well, there have been people who actually have tried to do that, where they try to simulate

shared memory over the network.

I think that's a really wrong-headed approach.

So instead, actors go the other way and say there's no sharing of memory at all, ever.

So even if two actors happen to be on the same machine, they are never allowed to share

memory.

That machine reminds me of enterprise Java beans, which had a similar idea.

You just talk to an object, but you don't know where the object actually is.

Maybe it's somewhere else on another machine.

But again, it didn't fly.

Yeah, it had other problems.

It was never about concurrency at that time, it was just about talking to objects.

So it's not about data flow, it's just, okay, here's my object, I don't want to see where

it is, I just talk to it, I just call a method and it goes over the network.

And then execute it somewhere else.

An amplification of the idea behind networking, right?

You've got an address of a machine, you can send a message to that machine.

We can treat objects the same way, we can treat actors the same way.

But then JSON and web services, they just replaced all this and no enterprise Java beans

anymore.

So JSON also has a role in this networking too.

So sometimes when people are designing distributed applications, they'll be thinking about it

in terms of APIs.

And so they'll come up with protocols that are extremely chatty.

For example, say you want to do like a remote canvas.

So I want to have my machine right on a canvas on another machine.

So one way you could do that is I send the command over, open a canvas and it sends me

back a canvas token and I say, okay, using this token, set the pen to black, move the

pen to zero, draw to that, so on, you know, I send all these commands one after another.

And I wait for a round trip on each one of those.

That's going to be extremely slow because you've got all this network overhead going on, right?

The correct way to do that is I create a JSON message.

The JSON message says, okay, make a canvas and set the pen and do all this stuff.

So I send one message, it goes, okay, boss, and then it does all the stuff much faster.

So if you think about the remote application just as another flavor of a local application,

you'll get the performance things wrong.

But if you have tools available to you like JSON, you can almost eliminate the cost of

all the network I/O because you can put a lot of information into a single message.

In one of your talks, you said that one of the drawbacks of JSON is the lack of support

for blobs for binary data inside.

Yeah, that's a problem.

I didn't do blobs because JavaScript didn't have blobs and my design criteria was it had

to be a subset of JavaScript.

So for the networking layer of MISTI, I have a different language, which is called Nota,

which is a slightly more binary-flavored form of JSON, which knows about blobs and knows

about some other secret things that I need in order to implement the MISTI protocol.

So it's not strictly textual.

So it's going to be faster to encode and decode, probably going to be quite a bit smaller.

Like protobuf, which is popular.

A similar kind of idea.

This one I designed specifically for MISTI.

I'm not advocating it as a replacement for JSON because I think JSON is fine for most

of what it does.

In fact, the MISTI system will also use JSON at the higher levels.

So when the actors talk to each other, they'll be talking in JSON, but when the network is

talking between the machines, they'll be talking in Nota.

One last point, which is the most interesting for me.

In one of your talks, you said that the future hardware has to provide support for objects

and for actors.

And that's not happening so far.

We don't have that.

We don't have hardware for GPU, for network PU.

We have something for large language models, but nothing for actors, objects, or something

like that.

So is it coming?

So I have a friend who is designing an actor CPU.

So every instruction is a message send, except extremely low level.

It's a really interesting architecture.

I don't know if that's the future or not.

I'd like to see it be.

But everything I want to do in MISTI, I can do with today's hardware.

So that's not a requirement for my project.

If someday we do get that new actor hardware, I think that's going to be really interesting.

But it's not, in my view, a requirement for going forward.

Because you said the von Neumann architecture, it was invented 70 or 80 years ago.

And all the languages which we use now, they are all based on this hardware, which is sequential,

which is instruction by instruction going forward.

And it doesn't know anything about objects.

It doesn't know anything about even function calls.

It's still based on subroutines and procedure calls.

Yeah.

I think that's why I still talk about subroutines, because basically, that's what the hardware

is doing.

But that works.

I can build an actor language on top of that.

And a lot of the system security will come from the language itself.

So the language will not allow the actors to get into each other's memory.

And that by itself improves the security situation by a lot.

It enables the remote stuff, but it also makes each individual actor a security block by

itself.

No direct memory access into the actor?

No.

The only way you can communicate with an actor is to send it a message.

And if it chooses to respond to you, then you get what it decides you get.

And you can't compel an actor to give up its secrets.

Because in any language, modern language, mainstream language, even though they declare

encapsulation and object-oriented flavor, it's still possible to get directly into the object

and see what's going on there.

Yeah.

And often, that's by design.

You got things like package scope, which allow you to see into something that you shouldn't

be able to see into.

And often, those sorts of features are thought of as features, as useful tools.

And they are useful, but there are certain uses you don't want to encourage.

And so you have to be more careful in how you design stuff so that the bad uses aren't

benefiting from the things you put in for, hopefully, good uses.

Let's try to give our listeners some call to action.

Do you need help in the MISTI project?

Do you need contributors?

Not yet.

Eventually, I will.

I'm not quite there yet.

I have a plan.

I've got the parser working.

I'm partway through the code generator.

I think I've got the architecture all nailed down.

So I'm kind of going through the development chain now.

Once I get to the part where it can generate Intel code, which is executable, at that point,

I think I'll start asking for help because we'd like to see tools around it.

We'd like to see optimizations on my instruction path because I'm doing quick and dirty stuff,

and eventually, we want to have production quality stuff.

And so all of that needs to be cleaned up.

And I could get to it eventually, but if we could get a community interested in it, that

could go faster.

MISTI will have a policy machine built into it, which makes decisions that build time

about what sub-programs, programs are allowed to link with and what secret powers they're

allowed to have.

That machine is also written in MISTI and can also travel across the network, so that

makes it possible to have remote administration of software libraries on different machines.

All sorts of interesting ways to go and it kind of explodes in the possibility space.

Definitely a community would be great at working that stuff out.

I'm not there yet.

OK.

Thank you very much.

Thank you.

This has been fun.

Yeah.

Very good questions.

Thank you.