←back to thread

1401 points alankay | 7 comments | | HN request time: 0s | source | bottom

This request originated via recent discussions on HN, and the forming of HARC! at YC Research. I'll be around for most of the day today (though the early evening).
Show context
torstenB ◴[] No.11941290[source]
Beside objects one true revolutionary idea in Smalltalk is the uniformity of meta facilities - an object knowing about itself and being able to tell you.

I see so many dev resources burnt just because people build boring UIs or persistence bindings by wiring MANUALLY in traditional languages. All this is a no-brainer when enough meta infos (objects and relations) are available and a program is reflected as data as in Smalltalk (not dead text). You can not only transform data but also your code. Pharo now makes some more additonal steps to enhance reflection (metalinks, slots, etc).

What do you see as next steps in using metadata/-infos for (meta)programming ...

replies(1): >>11945881 #
alankay1 ◴[] No.11945881[source]
I think one of the biggest blindnesses of our field is scaling (and I'm not sure quite why). This leads to an enormous amount of effort at roughly the same scales of some good ideas decades ago. (I think my background in molecular biology -- which continues to a very small extent -- helped this a lot. At some point one has to grapple with what is more or less going on and why it more or less works so amazingly well.)

What would a programming language be like if we actually took the many dimensions of scaling seriously ... ?

replies(1): >>11946464 #
heurist ◴[] No.11946464[source]
Would you consider the actor programming paradigm to be a good scalable model? It largely matches what I observe in both nature and where we seem to be headed with software engineering (containers in the cloud, near-trivial redundancy, stability, and scalability when properly designed). When I consider society I see a complex network of distributed actors, and when I consider my mind/brain I see the same. At this point in my philosophical development I am definitely resonating with the actor model, but I'm sure you are more familiar with this paradigm than I am - if not actors, where would you recommend searching?
replies(1): >>11946559 #
1. alankay1 ◴[] No.11946559[source]
I have every reason to like Actors! But think about scaling for a while, ...
replies(2): >>11946837 #>>11955631 #
2. heurist ◴[] No.11946837[source]
Great advice, I am currently lacking there. Thank you!

Edit: A follow up if you don't mind - have you investigated multi-agent autonomous systems or agent based modeling?

replies(1): >>11953539 #
3. alankay1 ◴[] No.11953539[source]
Sure ...
4. heavenlyhash ◴[] No.11955631[source]
Can you share some more seeds of thought on this? I sense you have better questions here than anything I can yet think to ask, myself :)

I'll take a crack at some things:

Actors are great patterns for encapsulating concurrency, but struggle in scaling --

because failure domains and persistence/forgetfulness on an intergalactic network aren't always lined up on the same borders as the actors?

What are some of dimensions of scaling would you identify as under-understood?

replies(1): >>11955741 #
5. alankay1 ◴[] No.11955741[source]
Just to bring up one possibly helpful analogy:

Suppose we have a good model of atoms -- how much of this will be a good way to think about living systems? (Or should we come up with better and more useful architectural ideas that are a better fit to the scales we are trying to deal with -- hint: in biology, they are not like atomic physics or even much of chemistry ...)

A point here is that trying to make atomic physics better will only help a little if at all. So trying to make early languages "much better" likely misses most if not all of the real progress that is needed on an Internet or larger scale.

(I personally think that much enterprise software even today needs architectural ideas and languages that are different in kind than the languages of the 60s and 70s (meaning most of the languages used today).

replies(1): >>11956289 #
6. heavenlyhash ◴[] No.11956289{3}[source]
(preface: Riffing wildly here -- and may have gone in a different direction than your analogy's original intent --)

So, regardless of whether or not actors are a good pattern, what we need is scale-free patterns?

I can see how getting hung up on actors as a programming language feature would impede that.

How can we make the jump to scale-free, though?

- With actors, historically, we seem to have gravitated to talking about them in terms of a programming language feature or design problem -- while in some sense it implies "message passing", we usually implement the concept at scales of small bits of an in-memory process.

- With processes in the unixish family, we've made another domain with boundaries, but the granularity and kind of communication that are well-standardized at the edges of process aren't anywhere near what we expect from the languages we use to craft the interior of processes. And processes don't really compose, sadly.

- With linux cgroups, things finally go in a tree. Sorta. (It's rough trying to stack them in a way where someone arbitrarily deep in the tree can't decide to take an axe directly to the trunk and topple the whole thing). Like processes, we're still handling granularity of failure domains here (better than nothing), but not defining any meaningful or scalable shepherding of communication. And we still haven't left the machine.

I'm sold that we need some sort of architectural ideas that transcend these minutiae and are meaningful at the scale of the-internet-or-larger. But what patterns are actually scalable in terms of getting many systems to consensually interoperate on them?

I'm twitchy about trying to define One True Pure Form of message passing, or even intent passing, which seems to be a dreamier name that still converges at the same limits when implemented.

But I dream that there's a few true forms of concurrent coordination pattern that really simplify distributed and asynchronous systems, and perhaps are scale-free. Perhaps we haven't hit them yet. Words like "actor" and "agent" (divorced of e.g. programming language library) sometimes seem close -- are there other concepts you think are helpful here?

replies(1): >>11956408 #
7. alankay1 ◴[] No.11956408{4}[source]
One of many problems with trying to use Unix as "modules" and "objects" is that they have things that aren't objects (like strings, etc) and this makes it difficult for arranging various scales and extensions of use.

It's not so much "scale-free" but this idea I mentioned elsewhere of "find the most difficult thing you have to do really nicely" and then see how it scales down (scaling up nicely rarely even barely possible). This was what worked with Smalltalk -- I came up with about 20 examples that had to be "nice", and some of them were "large" (for their day). We -- especially Dan Ingalls and Ted Kaehler -- were able to find ways to make the bigger more general things small and efficient enough to work uniformly over all the scales we had to deal with.

In other parts of this AMA I've mentioned some of the problems when extended to the whole world (but go for "galactic" to help thinking!)

Almost nothing in today's languages or OSs are in the current state of "biology".

However, several starts could be to relax from programming by message sending (a tough prospect in the large) to programming by message receiving, and in particular to program by intent/meaning negotiation.

And so forth.

Linda was a great idea of the 80s, what is the similar idea scaled for 40 years later? (It won't look like Linda, so don't start your thinking from there ...)

Etc.