> EO is based on π-calculus (if you want to see its description, join this Telegram chat: @polystat_org).
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"
This means "find an object called 'stdout'"; it must have exactly one attribute that was set to NULL ; and make a copy of the "stdout" with that attribute set to value "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.
And the "Semantics" section straight up reinvents their own flavour of a G-machine... very fancy indeed.
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.
> Because putting this description into a doc/MATHS.md file inside the repo itself is too easy.
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.
> In order to compile this program, put it into src/main/eo/main.eo and then create a file pom.xml with this content (it's just a sample):
> <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.
I think it's supposed to be a parody? It's some made up OOP version of lambda calculus.
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.
The first line creates an βabstractβ object named circle. It is abstract, because one of its attributes r is βfreeβ. Itβs not specified in this object and thatβs why the object canβt be used as is, it has to be copied with r specified. For example, this is the circle c with the radius 30:
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.
Any language built around one idea to the exclusion of others is necessarily a toy.
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.
Is this Java hate? Please chime in if I'm missing something, otherwise..
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.
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.
"OOP" is itself such an overloaded term that a Smalltalk coder and a C++ coder and a Python coder can each say she works with objects, and yet have entirely different design and organization. By formalizing his definition of OO, Yegor (who is a firebrand for sure[0], but says enough interesting things that I've read a couple of his books and several blog posts) is dispensing with "no true Scotsman" fallacies: if he claims language <X> is not OO per his formal definition, we can take it or leave it.
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).
Yep, that's the kind of thing I try to consider in this subject. I think his take is intriguing and distinct enough to possibly have merit, but it's difficult to discuss it directly with the creator because... well, it's hard to discuss benefits and difficulties with a firebrand.
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.
Totally agree. I'm reluctant to join the Telegram thing because A) Telegram and B) I can't imagine a discussion going over any one of the Sacred Programming Opinion Landmines.
"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.
I think that the argument is that even the "common usage of the term" means a lot of different things to a lot of different programmers/computer scientists/etc.
The more interesting question to me is whether there is still something to the ideas that he originally called "object-oriented" that has possibly been lost. The term itself has been overloaded into oblivion, but message communication, vigilant protection of internal state and late binding all the things might still be a good idea.
IMO "objects := algorithms + data structures" has run its course and hasn't succeeded.
Well yes. Early in the day I had a brief affair with Eiffel. But alas not practical. On the do not list the one I'm most suspicious about is no mutability. I'm willing to listen; looking forward to more here. C'mon we're gonna toss btree, hashing etc?
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?"
Building something can show that an approach is possible, but not why you think it's preferable.
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!".