Euclidean rythms are well supported in the Tidal Cycles family of live programming environments. Here's a demo that you can play with online: https://strudel.tidalcycles.org?fTGy0eTiAUox
My view on 2 is that you get into a quite different mindset when you program actors, compared to objects. For starters, since each actor is scheduled separately, it becomes routine to not assume too much about the internal state of the actor. So you won't see many getters + setters in Erlang, for example. You also need to structure your program to not communicate unnecessarily, since communication may fail and requires you to wait for the other actor to reply. This makes you to think about what state should belong to which actor. It is quite subtle and is best seen by experiencing it, but I think the programs turn out quite different, and in my view better. Actors are not perfect for everything but to me they are what object oriented programming should have been.
I realized additionally is that Armstrong has other complaints about OOP like inheritance. What I said above in that classes and functions are like a self-contained programs with structs and functions. I wasn't considering inheritance, but once you start inheriting it gets murky:
Joe Armstrong: Because the problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle
But some of his other complaints don't feel as right to me:
I do love the implementation of Erlang and the reliability. I think it would fun to try actors and see if it changes how I view software engineering. I bet it would.
Yes, it's super difficult to limit the receiving end. If you use a mailbox type, it quickly needs to handle basically all shapes of data. Session types or similar are needed to get all guarantees we want but are super complicated. I looked at this in my MSc thesis "Singly typed actors in Agda": http://studentarbeten.chalmers.se/publication/256251-singly-...
That seems kind of bogus because you've just disguised an unsolved math problem as a computer program. It's like me making a program like this:
if fermats_last_theorem_holds(x,y,z):
halt()
else:
infinite_loop()
Will this program halt for all possible input integers > 2?
It may be able to "trick my brain" but only because I don't have a PhD in mathematics. Obviously no general algorithm can solve this, or else said general algorithm would easily be able to solve all unanswered questions in mathematics, physics, etc. Yet, human mathematicians are able to determine whether my program above halts, even if a general algorithm can't.
> you've just disguised an unsolved math problem as a computer program
But that's the point! The halting problem hides inside of it all of the complexity of math, including the dark tricky self-referential corners. Saying that you can solve the halting problem is tantamount to saying you've solved Godel incompleteness.
If you applied the halting proof diagonalization step to yourself (modeled as a machine built of out physics) you would find that it spit out something very complicated that ultimately amounted to a program equivalent of a statement of the form "The physics machine that I am cannot prove this statement". If you proved the statement then that would disprove it, which is the core of the problem.
