Live data from Hacker News

Eolang, an Experimental Object-Oriented Programming Language Based on 𝜑-Calculus

github.com

31–35 of 35 posts

Re: Eolang, an Experimental Object-Oriented Programming Language Based on 𝜑-Calculus

#31
post #16

Earlier quoted context omitted.

"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 c…

> Even without a formal definition, most languages purporting to be OO clearly fail a common sense interpretation of his criteria. 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.

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.

Re: Eolang, an Experimental Object-Oriented Programming Language Based on 𝜑-Calculus

#32

Earlier quoted context omitted.

"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 c…

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 functio…

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.

Re: Eolang, an Experimental Object-Oriented Programming Language Based on 𝜑-Calculus

#33
post #6

> 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 mos…

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.

It's not a parody, the author, Yegor Bugaev, is very serious about it. He published several books on his ideas.

Re: Eolang, an Experimental Object-Oriented Programming Language Based on 𝜑-Calculus

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

Re: Eolang, an Experimental Object-Oriented Programming Language Based on 𝜑-Calculus

#35
Re: No mutability

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.

Post reply on HN