The Next Programming Language by Douglas Crockford

Most of our current programming languages are descended from Fortran and C. While they were important advancements in the 1950s and 1970s, they are crippled by the assumptions that were profoundly important at the time: memory was measured in kilobytes, and a program executed slowly in a single process in a single machine. The descendant languages inherit this genetic weakness. We know that the languages we use are all deficient, so we keep adding features to them, but it seems there are never enough features. These languages will never be good enough. In today's world, computers have literally a million times more memory than was available to C. That truth should excite us to consider designs that are free of the small memory constraint. In today's world, programs are distributed. They run in many machines simultaneously, in various tiers and services and clients and servers, some under our immediate control, some we know are not under our control, and some that we think are under our control but are not. Our programming languages should be built specifically for this situation. Our focus on bloating the old languages distracts us from the more fruitful path of migrating to new languages that are designed explicitly for networking, with fine grained security at the foundation. You should not be limited by your grandfather's language. You deserve something better. This talk will suggest a possible way forward.

[@soggy_dev]

"There's an army of programmers maintaining that awful language" talking about C... We just going to pretend that we haven't wasted millions of engineering hours forcing JavaScript into every nook and cranny imaginable?

[@adammontgomery7980]

As soon as he said that I tuned out. It's old, and maybe outdated, but it bootstrapped our modern age. I think it's wonderful in it's simplicity

[@Stopinvadingmyhardware]

it’s not the language itself, it’s the compiler

[@abdellahcodes]

It seems the next programming language has a lot of bureaucracy 😂😂 Liasons and Minions and no Hello World

[@torarinvik4920]

I think the best paradigm depends on what the program is supposed to do. Generally Im in favour of a function OOP style like Scala, and F#. Of mainstream languages Swift is the one that comes closest, and also does have Actors built into the language itself.

[@cbbcbb6803]

Very interesting video. It would be great if every language could use every other language as a client. Or just use the custome libraries from other languages. Not likely to happen, but it would be great is it were possible.

[@kcvinu]

It is possible if there is a universal data type which is supported by every languages. We can pass data between two different programs.

[@Grimly89]

You already have that if you provide a http+json api. You really don't need to know what calls you or what you are calling.

[@cbbcbb6803]

@@kcvinu So, how do we make everyone use a universal data type specially for purposes of transferring data? Is that possible?

[@codeman99-dev]

Thank you for providing a great example why I don't want to use the actor model.

[@dishantsoni482]

Young Programmers need to listen to this and this man!!

[@RealLionTion]

Already am

[@equivocator7727]

It's highly evident that performance is of minor concern to this guy. If we listened to him, our already incredibly slow software would only get slower!

[@dandogamer]

So actors perform their tasks serially, so what happens if lots of clients want work doing? Is it ensured that we wont send to an actor already performing work because if not then that could lead to unpredictable latency.

[@robertoprince6804]

It can be done with virtual threads and events systems. All of it has precedents with Time Sharing computers, Erlang and Operating Systems. You can do something similar with Go and Node.js Spawn process. What he is saying is to make it a language paradigm and a communication protocol.

[@DmitryShpika]

Multiple actors + mailboxes/queues

[@waffle98501]

The proposal "Misty" sounds a lot like JS talking to PHP with PHP using webworkers to reduce the workload of the server ..... Butt Ugly, but functional. O'course, you could have JS running on a server with webworkers ... Just image trying to debug that ... what could go wrong?

[@dokoit]

I agree Erlang BEAM is great! Especially with Elixir

[@capability-snob]

Now if only BEAM had private addresses 👌

[@driziiD]

man is a humble giant

[@michaelslattery3050]

History tells us that for a language to become successful and popular it usually must 1) be familiar; be somewhat similar to existing language(s), 2) be somewhat easy to learn for beginners, 3) be quicker (or easier) to write new code, 4) have descent performance (usually). This is why LISP has taken so long for uptake, and why Haskell likely never will be mainstream. Ruby and Javascript have been the gateway drugs to making LISP and other functional languages more acceptable. Unfortunately, making a language with fewer flaws isn't necessarily a recipe for success.

[@bsljth]

It also needs to have a multi-million dollar organisation to market it.

[@davedoublee-indiegamedev8633]

Add to that 5) It needs to be useful. What can I make with JavaScript? Well, anything, really. Web apps, mobile, desktop, AI, servers, embedded even. If I have a front-end in JavaScript, damn well I will use JS for the back-end as well! And I mean I can simulate the Actor architecture with JS HTTP servers, or any language for that matter; not sure we need a new language for that.

[@asdqwe4427]

I somewhat agree about async await, but promises are way better than every library handling callbacks differently.

[@andrez76]

@10:14 I'd rather think he's trolling... I mean, I'm sure he knows Smalltalk couldn't have solved the problems C++ solved (considering resource and efficiency contraints; not possibility). Still... Let the C++ mocking go on; it's part of the culture.

[@u9vata]

I edited this comment to be more "useful" instead of ranting only. I think the most useful is to realize the agents are basically what other people call components previously and there are real working solutions to this. Where this would have place? For example maybe removal of OOP and just adding this and modules would fit better. Isn't this just Dynamic dispatch, components, OSGi and some other things already easily done in Java lets say? To be honest even corba has elements of this already and countless systems implement it - just they are all far from the JS world so I guess they are unknown to JS native populations... Debugging this kind of system can be very hard. I was doing this shit in OSGi basically with added life cycles and it can grow into hell - yes it has some useful properties, but dangers as well.

[@SimGunther]

If we're calling the actor model a totally "new paradigm" since it was made in 1973, why couldn't we also introduce the totally "new conditional paradigm" called "KAIL Selectors", which were a new twist on conditionals starting in the early 1970s by David W Embley. I'm surprised that it took this long to get someone's attention too!

[@KManAbout]

This sounds like temporal with go and grpc

[@capability-snob]

Can grpc shortcut the return value? I'd figured grpc's failure there was the reason Cap'nProto is a thing.

[@brendanhansknecht4650]

This sounds terribly wasteful with a lot of unnecessary indirection. I wish people would take performance more seriously and stop wasting all of the wonderful resources on our modern machines.

[@elmersbalm5219]

Seems like Crockford is stressing the issue of concurrency and distributed processes. An area prone to leaking, bombing and crashing.

[@user-vn9ld2ce1s]

I don't know... Seems a lot more confusing than just the "regular" object-oriented way. But he may be right, who knows.

[@bricecarpentier5817]

How is this new? My curriculum had lessons about this 20 years ago?!

[@KManAbout]

I think he means as primitives in a language

[@bricecarpentier5817]

@@KManAbout now that you mention it he might very well, yes!

[@bricecarpentier5817]

but it does look a lot like Multi Agent Systems (now to be fair it just happened that one of my teachers at the time was a researcher specialised on that specific topic)

[@benheidemann3836]

There “doesn’t look like what it’s doing” thing is very strange… firstly it implies we’re should all use assembly language for everything and secondly async/await is so much obviously better than callbacks 🤔

[@SaHaRaSquad]

No, he's right imho. Async/Await makes code deceptively misleading about its asynchronous nature. Hiding code/behaviour is the feature's whole purpose, and it's weird that people thought it's a good idea while simultaneously preaching about readable code. This particular problem has been solved in cleaner ways decades ago. Trying to fix callbacks with async/await is like fixing a pothole by covering it with cardboard.

[@capability-snob]

Promises are intended to make explicit where concurrency is happening and which computations may fail later. This idea of bringing into focus the distributed, asynchronous behaviour of large systems and allowing you to reason about their behaviour locally is much clearer in E, the language that introduced them; but in both cases the intention is to make a clear distinction between synchronous and asynchronous behaviour, where async/await attempts to blur that line.

[@benheidemann3836]

@@SaHaRaSquad can you point me in the directions of some cleaner solutions to the problem. I’m interested to learn more about how to handle this problem since my own experience is only with callbacks, promises and async/await. Of these, I would generally elect to use async/await for most practical use cases but I’m 100% open to learning about other ways of doing things :)

[@benheidemann3836]

@@capability-snob I agree that this is the intent of async/await. However in my experience, in 99% of cases this is not a bad thing. Maybe we work in different problem domains though - what background are you approaching this from?

[@SaHaRaSquad]

@@benheidemann3836 In my experience the sane way to achieve concurrency in complex software is the actor model with message passing. It's proven successful over decades by now. What's so amazing about it is that it handles concurrency in a way that you barely even need to think about it as developer. Basically every component runs in an isolated process and communicates with others using messages. That way it doesn't make a difference for your code whether the software runs on one CPU core or on 10 machines, you always just send and receive the same messages and all the concurrency is handled in the background. Just like you don't need to care whether the post office needs to cross a river to deliver mail or not, you just need to read the letters and respond to them. Since I used this in a project async/await feels like caveman tech.

[@dnkreative]

When you haven't heard about Occam's Razor. No thanks.

[@grb1915]

Describing the actor model as having been discovered at MIT in the early seventies seems somewhat imprecise. Presenting the right way to think about the actor model without referring to its inventor Carl Hewitt is ... well based on Mr Crockford's definition Hewitt might be 90 percent right on his actor definition.😂 Moreover, Reviewing language and paradigm history without any mention of Java and Scala/Akka and define the way forward for the industry at large might be incomplete.