> EO is based on 𝜑-calculus (if you want to see its description, join this Telegram chat: @polystat_org).<p>Because putting this description into a doc/MATHS.md file inside the repo itself is too easy.<p>Also, a tip for anyone who decides to put out there a programming language with highly exotic operational semantics: please don't forget to put a quick overview of that semantics in the "Tutorial" section. I suspect most people would be puzzled why output is performed by "making a copy of the abstract object stdout with a single argument "Hello world!".
Re: No mutability<p>Algo 101 (hash, skip list, btree, merge sort) is a thing. Doing so cache friendly is a thing. Knowing that for small N a linear scan may be faster than a AVL/Redblack tree is a thing.
How is one seriously going to skirt this? Containers need mutability.<p>Re: Atomicity failure:<p>Starting with Hoare, popularized by Meyers, combined with aspects of specification side by side with code (ADA, Spark, Frama) failure atomicity is better construed as: post-conditions cannot be met because pre-conditions were not met. Failing to meet pre-conditions is undefined behavior. Going the other way, programmers who don't have a function / class / scope contract have failed to even engage the issue. Claiming no mutation I think is a bit broad, and a bit tangential in the same way that exceptions can be in this context.
Any language built around one idea to the exclusion of others is necessarily a toy.<p>This is not to say that there is anything wrong with toys, as such. Toys can be educational, some very. Just don't confuse it with something that is, or may become, a generally useful tool.<p>This is why "pure object-oriented", "pure lambda calculus", "pure category theory", and "pure logic" languages flop. The world does not consult your language for what kind of problems it should present. The world, instead, presents all kinds of problems. Any big problem will turn out to be made of lots of smaller problems, of all different kinds generally unrelated to the sort the big problem seems like.<p>A useful language has what you need to address all kinds of problems. Useful languages are usually accused of being "impure" or "too complicated". They can't be summarized in a line, or a page. But there are reasons why those are the ones we use.
Hmm. I'm intrigued what they come up with. The creator is something of a firebrand, who tends to 'no true scotsmen' other OOP languages. His ideas are interesting, but often seem impractical in other languages. If he comes up with something effective, I suspect it will indeed feel similar to lisp, and not in a bad way. Even what he's showing right now feels similar to Wisp-syntax with an OO twist.
In the "Things we don't tolerate" list, for "classes" they link to a short post which describes a simple use of prototypes with "types" but not "classes" and ends with "Why not?"<p>Building something can show that an approach is possible, but not why you think it's preferable.