Zalastax

I would also like to understand better. But it seems like it is visual effects that is meant. These tools were mentioned by name: https://www.kabaretstudio.com/ https://prism-pipeline.com/

Is there not full or at least partial overlap between the 44 % and the 26 %? Which would mean not 70 % but some smaller number?

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

Which I took from its examples in the tutorial: https://strudel.tidalcycles.org/tutorial/

Tidal Cycles can be used to generate sound on your computer but it can also sequence MIDI hardware.

Interesting! I suppose one could prepare for that by having a second profile with just a few questions solved?

You may find my MsC thesis, link in profile, interesting! If I remember my writing correctly, I have similar reflections on CSP.

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.

Natural body of water!

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-...

We're working on a gradual type system for Erlang which also works quite okay for Elixir: https://github.com/josefs/Gradualizer/.

A pretty simple program that fools your brain is one testing the Collatz conjecture: https://cs.stackexchange.com/a/44875

Or did you mean something else?

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.

It looks like fairly standard JS to me. I don't know where to read about it but there are some details on the deprecation blog article: https://blogs.msdn.microsoft.com/ie/2008/10/16/ending-expres...

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.

[1]: http://studentarbeten.chalmers.se/publication/256251-singly-... [2]: https://www.microsoft.com/en-us/research/wp-content/uploads/...

We're adressing the lack of static typing with the Gradualizer project. It's not ready for prime time yet but I find it very promising.

https://github.com/josefs/Gradualizer

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?

Gradualizer supports Elixir. It will move into beta soonish :)

You want reproducibility, the results will be affected a lot by your data source, real citations enable tools like google scholar. Why not cite? I see only drawbacks in continuing with the footnote/no citation trend.

Can you expand on what you mean? What is "the matrix model of computation" and "vectors of unity"?

Which actor model are you talking about? The variants are very different and Hewitt's original paper is mainly referenced for coming up with the name rather and kicking off the field than inventing a usable model.

Type theory is even vaster. Are we talking homotopy type theory? Calculus of constructions? System F?

It's the frequency illusion (also known as the Baader-Meinhof phenomenon).

https://rationalwiki.org/wiki/Frequency_illusion

They are very useful if you follow the philosophy of Erlang: let it crash. It's really important to get easy to understand distributed systems. A good introduction: https://learnyousomeerlang.com/supervisors

As far as I know Pony doesn't yet have a distribution story so supervision might not be priority for the maintainers yet. However, since Pony is an "Active Objects"-language, every actor in Pony is essentially an instance of a genserver - this is what makes it easy to type. Supporting more advanced communication patterns in a strongly typed fashion is rather difficult so for the foreseeable future I believe that a gradual typing approach will be the way to go. Genserver is also very powerful so Pony can likely see good success if they just build in some supervision strategies and make it possible to distribute.

It's possible if you have dependent types and are not afraid to (ab)use the type system. See section 2.4 of my thesis (link in bio) for a taste. You have to squint a bit but a system like that can ensure linearity.

You could just assert that i%2 == 0 via some postulate - as long as the proof is irrelevant for the code that is. Doing so is similar to converting from any in a gradual type system: if the assertion is correct you get correct code with little work and if you're uncorrect you're no worse off than if you had no types at all.

There are difficulties with dependent types, but having to go all in can be avoided via a shift in culture.

But is it though? If your objects are immutable I agree but if you have setHeight and setWidth I don't.

Just to join the choir, in Swedish they're para nuts as well.

Thanks, I did not know that!

TypeScript can do type refinements based on the flow (e.g. a null check refines a type with null to one without) but can't do what you just showed. Are there any tools that can emit the inferred types to source code? I just now got a vision of using flow style type inference to gradually augment a project with either flow or TS types with very little work.