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.
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-...
Totally agree. I think that locality is what separates true functional programming from languages where some of functional programming features have been added on top. Immutability and types that track effects are means of achieving locality.
Sure, but my point still stands: figuring this out doesn't require arcane knowledge, contrary to what was suggested. The code inside the expression looks like standard JS. The downvotes and your reply suggests I should have communicated more clearly.
But that's not how one should read "that is". The author should have used "e.g." here, no question. Using "i.e." would imply that there exists only one nondeterministic function in MySQL, which is not the case.
I touched on this in my MSc thesis [1], see section 2.6 and 3.4.1. The original CSP can only work if you stay on a single machine. You can have channels in a distributed setting but you need to make the reading capability of a channel limited to a single consumer. If there are multiple possible readers at the same time it gets impossible to know where to send each message and in a distributed setting there's no way of solving that, short of solving distributed consensus. Cloud Haskell [2] section 4 touches this as well.
Your point still stands but, since the field has so many terminologies that are conflated, I wanted to let you know that "active objects" is a specific kind of actor model and Erlang is not an instance of that model. Active Objects is essentially Java but with asynchronous calls, much like using gen_server for everything.
A good paper that untangles the terminology is "43 years of actors: a taxonomy of actor models and their key properties".
Sure,and lots of codebases are completely untyped. I find it great that you can opt out of the theorem proving that type checking is when crunch time comes. As such it functions as a loan and your organization should strive to pay back the debt when it can. Nothing can save you if you never get a calmer period.
I instead proclaim that it brings you the best of both worlds. Finding the right mix of static/dymamic is a balance act but if you do so you get the benefits of static types (safety, documentation, tooling) and dynamic types (fast prototyping, not having to write convuluted code to please the compiler). What are the killer features that gradual types lose out on?