Because putting this description into a doc/MATHS.md file inside the repo itself is too easy.
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!".
According to it, "π-calculus" is something they made up for the eolang and not a standard term.
Here is my take on that calculus based on reading through section 3 in the paper. Note the paper is pretty weird and likes to make its own notation, so it is possible I got some things wrong:
It is starts with a pretty standard immutable language: "object" is a set of (name, value) pairs; "value" is either object or "data" (like a string, bool etc...); everything is immutable but you can make a copy an object with some attributes changed. There are no concept of "types" -- instead, you define objects with some fields set to NULL (spelled β in the paper). There are also a bunch of term defined, like "abstraction", "application", etc.. -- but they all mean "make a copy of an object with some fields changed".
The "twist" is that the language has no functions per se, instead it defines AST-like structure: there is a syntactic sugar that handles things that look like function applications. So when you see:
stdout "Hello world"
The "stdout" is what's called "atom", a class which is defined "outside of Ο-calculus formal scope". All the actual work is defined via those atoms, which are out of scope. Unfortunately, this means that Ο-calculus itself does not define much, and is basically a fancy way to write AST.
Is there a shortage of existing object calculi that I am not aware of? Even Abadi-Cardelli's calculus can already do just as much, and is also smaller and more concise.
Agreed. Even a link to Wikipedia would be useful: π-calculus is not the easiest thing to search for, and I'm certainly not going to sign up for a Telegram account just to find out what this is all about.
> <a 47-line XML file />
I have little idea why this is here, what on earth it's for, what π-calculus is, or anything! I don't even know if it's related to lambda-calculus, modal-Β΅ calculus, or whatever!
So, some highly speculative google-scholaring:
> [1] This article proposes a new arithmetic for fuzzy numbers called Ο-calculus developed at the LAMIH laboratory (D. Roger and J.-M. Lecomte, 1996). For this algebra, the modeling used for the representation of fuzzy numbers is the distribution function instead of the classical membership function. New functions (square, square root, power, exponential, Neperian logarithm and trigonometric functions) are defined in this paper. With the aim of handling simply Ο-calculus arithmetic and of comparing it with those of the intervals theory (R.E. Moore, 1966) and the Zadeh's extension principle for fuzzy numbers (L.A. Zadeh, 1965), a toolbox for Matlab has been set up. Also, several examples and an application of automatic control illustrate this algebra.
Aha! So, maybe it's a fuzzy number system -- where you have inherent uncertainty on everything. That's cool, and useful, and something I can totally see the point of (not least in an OO context -- everything has to be an object, as a fuzzy number is a generalization of a regular, real number in the sense that it does not refer to one single value but rather to a connected set of possible values, where each possible value has its own weight between 0 and 1; and that weight is called the membership function -- and a function with some data is basically an object!). Maybe that's what it means. Maybe.
More googling.
> [2] THE Ο-CALCULUS β A HYBRID EXTENSION OF THE Ο-CALCULUS TO EMBEDDED SYSTEMS. [...] The Ο-calculus is a hybrid extension of Milnerβs Ο-calculus [17] which allows processes to interact with continuous environments. We choose the Ο-calculus to extend to the hybrid setting because it has already been shown to be a rich language in which many interesting discrete concurrent phenomena can be expressed: a language for, and theory of, communicating processes which can reconfigure themselves; a language in which distributed objects and classes can be defined; and a language and theory capable not only of expressing communication, but arbitrary computation, in that the Ξ»-calculus of Church can be translated into it. This all suggests that successful hybrid versions of the Ο-calculus and other process calculi will have novel and elegant ways of expressing hybrid systems β possibilities for distributed control which would be awkward, if not impossible, to express in current formalisms.
Then again, maybe not! I'd love someone to explain what this is all about, ideally relatively simply.
[1] http://dx.doi.org/10.1109/ETFA.2006.355426
[2] https://www.eecs.umich.edu/techreports/cse/02/CSE-TR-458-02....
The telegram chat thing is probably a reference to languages like Elm who keep the community discussions on Slack and other proprietary platforms which require login to view.
[r] > circle
mul 2 3.14 r > perimeter
mul 3.14 r r > area
circle 30 > c
( Which would be like c=new circle(30) )
https://www.yegor256.com/2020/11/24/objects-without-methods....
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.
Re: Atomicity failure:
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.
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.
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.
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.
^W
There's nothing inherently wrong with writing a programming language on top of the JVM or JVM-based build tools. It's a time tested platform in very widespread use, and in many instances the JVM is an excellent target to get things going.
The derision emanating from the low effort comment you submitted is misguided and / or misplaced. This is coming from someone who admittedly kind of enjoyed bashing on the ridiculousness of Java in the early days ('90s & '00s), but along with the JVM, it's grown into an incredible ecosystem and generally valuable resource to Get Stuff Done.
Having used Maven a bit in the past, I agree, it was awful. Simple tasks were complicated and error-prone, complex tasks were impossible.
It seems reasonable to ask why a trivial example program needs a huge boilerplate XML file.
- It's parsed into an XML document.
- And: There are a number of XSL transformations that need to be done with the XML document in order to make it ready for compilation.
- Plus: Then transforming the XML document into a collection of .java files.
But hey, if this are the tools you are familiar with why not use them for you pet toy.
Building something can show that an approach is possible, but not why you think it's preferable.
For what it's worth, Alan Kay himself has said things like, "I invented the term Object-Oriented, and I can tell you I did not have C++ in mind." He has declined to formally define what he means, but has said, "OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things."[1] Even without a formal definition, most languages purporting to be OO clearly fail a common sense interpretation of his criteria. Kay himself mentions Smalltalk and Lisp being the only systems he's aware of that meet his criteria; I tend to think Erlang is spiritually close, though would have to defer to Alan (I find it interesting, too, that the first Erlang VM was written in Prolog).
[0]https://www.yegor256.com/2017/07/18/sexual-harassment.html
For what it's worth, I suspect Yegor's view is somewhat closer to Erlang as well, given both end up collapsing into a model of both functional purity and message-dispatching, if I understand them both accurately.
Which should be obvious sign that Kays criteria for OO does not match the common usage of the term, and as such not very useful.
IMO "objects := algorithms + data structures" has run its course and hasn't succeeded.
"I once used an ORM to get some work done and stuff, and it wasn't entirely awful" is probably worthy of excommunication or burning at the stake for heresy. More likely, just insults that I'm not a real professional or something. I get enough of that in my own head from time to time.