Going beyond JavaScript and Actor-Based Programming: an Interview with Douglas Crockford

In this episode, we are going to meet someone who's been incredibly influential not only in the world of JavaScript, but in the de facto language of the Web, I'm talking about JSON. Douglas Crockford's book, "JavaScript the Good Parts" is a seminal book that rapidly moved the adoption of the JavaScript language forward.
Douglas shares a bit about his journey, and what he's working on next: actor-based programming.
Actor-based programming is a mathematical model of concurrent computation. In actor-based programming, an "actor" is an object that can receive and process messages, and can also create and manage other actors. Actors are completely independent of each other and interact through asynchronous messages.
Actor-based programming is different from object-oriented programming (OOP) because actors pass messages through time, while OOP passes messages through memory. Actors are stateful, meaning they have internal state.
Subscribe to @intelligence-ai for more content on innovation, intelligence, and collaborative systems design.

[@OwenBickford]

If you like the idea of actors passing messages in a dynamic language with concurrency baked in, you’re going to love Elixir. It inherits all of the features of Erlang with a more accessible syntax. 17:05

[@codeconcept]

Great interview that allowed me to know more about actor-based programming. Thanks guys :) I'll surely also watch the other video on JSON-unify ;)

[@DejayClayton]

I'm so glad I stumbled upon this video. I've had a loose idea in my head for the past two decades about the future of computing, and it looks exactly like the Actor system described by Crockford. I had no idea the concept was even formally defined, because I don't spend a lot of time researching theoretical systems. Combine the notion of actors with a "work communication protocol" similar to smart contracts, and there's the possibility for massive, distributed, peer-based computing systems that use open marketplace negotiation principles to accomplish some truly amazing things! Such a system under the guidance of an AI control network could be confusing beyond human comprehension, but orders of magnitude more efficient than any scheme we could design ourselves.

[@h3techsme]

I love the proviso in description of of functional languages as "not gettting sloppy with mutation" and I also agree that there are circles in functional programming which are a bit too precious by half with the concept. However there *is* a form (in Elm and 'Elmish' in F#) where the immutable "model" maintains state and simply re-writes it as the state is updated. That may on its own be a bit too precious by half - gaining the benefits of mutability *without* mutable compute structures in memory. But it *does* have the benefit of preserving the "inner loop" of testability afforded by 'pure' functions and allowing dispatches out to *true* impure functions that manage the mutable state outside of the MVU loop.

[@tesilab994]

From 20:25 Crockford says: "An Actor is a computational entity with state that it can mutate, which gets us into a conflict with the functional programming guys" This needs comment. 1. "The functional programming guys don't want any mutation": The functional programming position on mutation is that it is of course essential, but must be segregrated, so there is as large an identifiable body of code that is mutation free -- a functional core -- with as small a practical outer effectful "membrane" as possible. Non-functional approaches don't facilatate any such segregation. 2. That actors are about mutation: it's true that actors are themselves effectful shells, but with a tweak: Hewitt's definition makes clear that "state" of an actor does not change while it is operating. Rather its state is REPLACED when its processing of a message concludes. (See kzbin.info/www/bejne/bZbVe2R6i8SHotE at 4:21.)

[@edgeeffect]

One of my regrets is that there's only one "... The Good Parts" book. I can't think of a single programming language that couldn't benefit from a "... The Good Parts" book!

[@AdrianBoyko]

A couple thoughts: First, does he know that the Pony programming language exists? It’s, by far, the purest actor-oriented language in existence today. If you don’t grok actors but want to, Pony is the best place to start. Second, it’s sad that he typically presents actor-oriented programming in a networked context. It is also hugely helpful on a single machine with many CPU cores, especially when your language has “reference capabilities” built into the type system. Ref caps free the actor model from messaging constraints such as the need for messages to be immutable or copies.

[@cbbcbb6803]

Is anyone working on a replacement now? I think paradigms are a trap.

[@szymonbaranowski8184]

everyone busy learning another js framework and library 😂 he wants to make something better for web which runs on outdated concepts that simply worked I think we will need rebuild structure of internet (like irati idea) starting from grassroots from core software closest to hardware so that your app would swim like fish in ocean not spreading roots like a plants through dead roots of previous plants

[@botondvasvari5758]

elixir or akka ?

[@MathewGarland]

Yes, obviously he hasn't really delved into Elixir, but that really surprises me! Surely his reference to Erlang would lead one to assume he knows of Elixir. Elixir's actor model has to be one of the better, more modern actor implementations which has great Web integration as it stands.

[@niclash]

​@@MathewGarland Has Elixir gotten beyond the Erlang VM? Otherwise, it inherits the "actor implementation". Pony Language uses a different actor implementation (and mindset), statically typed and data race free with strong concurrency guarantees without locks.

[@eemajinemirror9249]

So... Elixir, then? 😏

[@szymonbaranowski8184]

I'm interested how such message would look like. And how different actors find common language to speak. Wouldn't it need to specify in every program it's own API and modifying all existing APIs like translating every existing languages to new language and without standard and adoption every programmer would build own language bridge but i guess it's inevitable and the same as learning curve in everything new that's why this lazy generation prefers groupthink and building new things on top of agreed least bad generally accepted thing being JavaScript

[@m13v2]

just grab any oo language, honour the information hiding idea and thus stop returning values from method calls. 😁

[@faridguzman91]

javascript just needs to die off.. blazor and wasm need to be standard

[@LettersAndNumbers300]

Let’s make babies

[@marleneashten2052]

👉 "promosm"