OK, we see a dynamic, late-binding, object-oriented, interpreted language with a VM.
If I were to try and make this language interesting to the HN audience, I'd start with two items:
* What is interesting in Elena, compared to Python?
* What is interesting in Elena, compared to ES6?
* For bonus points: What is interesting in Elena, compared to Smalltalk?
Without answering this questions, I don't see why I should take a look. And there must be some differences, e.g. around the concept of first-class messages, which apparently are related to Smalltalk.
The overview section in the programming manual perhaps answers the bonus question:
> Why not to treat the message like a normal language element with which different operations are possible : loading, passing, modifying, dispatching? Could we do it without using reflection all the way?
I don't know how the guts of smalltalk are implemented, but, if there's a lot of reliance on runtime reflection involved, then maybe there's your answer.
I think, then, that the answer to the first two is, "It's like Smalltalk."
Edit: you've unfortunately been breaking the site guidelines at a high rate with your recent comments. Could please review them and take the spirit of this site more to heart? We're trying to have a community here that doesn't degenerate to internet default (or worse), and that takes a collective effort.
There's no need to be this harsh. We should always celebrate people making things even if they don't benefit us directly, to me that's even the essence of hacking
Sure, making is good and all, but if you want people to care you should put in effort to make them care. Toy programming languages is a very crowded space.
Sorry, how is it a 'crowded space'? Languages aren't startups, they don't have to compete on a market to be viable (unless they're proprietary of course). As long as someone somewhere has an interest in it, it will live on.
A language needs an active community of many users. In these days, without support for libraries that make software exciting and useful a language can definitely die as a platform. Those are some of the many qualities that persuade users to invest time into learning a new language. Otherwise, they'll go with something already established.
So I disagree, there is definitely competition amongst programming languages.
That is not dead which may eternal lie, and in strange aeons even death may die. Remember that weird language that looked like Java and was used by nobody except script kiddies until the Web exploded? Or that quirky little language with forced indentation that was overshadowed by Perl and Matlab well into the 90s and the 00s? Open source projects don't have the same constraints as commercial ones, they can remain dormant or unnoticed for years before suddenly taking off.
I think it's similar to partial function application. First class message is a partially applied function with some parameters bound and some "parameter holes" left unbounded. When the message is sent to a target, the rest of the parameters are filled in to build the full message to be sent.
In that case, complicate messages with lots of parameters can be pre-built with parameters partially filled in. The pre-built messages can then be repeatedly used subsequently.
I think that's how it works. OTOH, I could have completely misunderstood the first class message idea. Someone more familiar with the language can probably explain better.
Although, could this message thing not be modelled with lambdas taking remaining "holes" as arguments, "formatting" the message, which are given as arguments to functions?
The gain seems smaller than the gain from first class procedures, but it is an interesting idea, which might avoid some lambda wrapping in the code.
I don't think I have to explain this to you (hello fellow guiler!), but in a language with first class procedures and proper macros there doesn't have to be any lambda typing overhead.
I implemented "megacut" in guile, which is a clojuresque lambda shorthand: #%(+ %1 5 (* %2 4)) => (lambda (%1 %2) (+ %1 5 (* %2 4))) in about 30 lines of code (unhygienically, though, but that should be a small fix in a psyntax-based scheme)
Hehe, you are correct, indeed I did not think of macros in the moment.
We do have some megacut wrapping overhead then though ;)
Can you post a link to the macro on the Guile user list? Perhaps someone can rewrite it to a hygienic macro. Some people there very proficient in macrology. I am not that proficient in macrology.
I am also trying to maintain a list of libraries and things for Guile, which I could add this too.
I have written enough macros to be able to do it (among others, the guile-for-loops macros). There are some issues with a macro like this. I can make it quasi-hygienic by hygienically checking for megacut (right now I am just comparing symbols, as returned by datum->syntax).
Doing it in another way than "Any binding looking like %n and %& will be captured and shadowed" is pretty much unsolved using any standard scheme. I could probably hack something together using syntax-locally-bound-identifiers, but then I would have to implement local macro expansion (which is possible. I'm just lazy!).
A first class message is similar to the function to invoke this message. So it is just a special case of first class function. I uses first class messages to implement a dynamic record - http://www.rosettacode.org/wiki/Dynamic_variable_names#Elena
Like (partial) functions as values, you can pass along the message/method, e.g. as a parameter to another function. In other languages, you'd have to create a function for each message/method, and more than one if it's overloaded (although I don't know how Elena handles that).
> ELENA supports rich set of object-oriented features:
> abstract classes, interfaces, singletons, class constants,
> named constructors, variadic methods / constructors and
> class extensions.
Half of these are anti patterns that I appreciate other languages (Go, Rust) leave out (non-virtual inheritance, singletons, ...). Elena announcing them as features makes me wary.
This did make me curious. I couldn't find any explicit discussion of memory management, not even in the constructor section of the programming manual [0]. There isn't a section on destructors. I also searched for and didn't find 'garbage' and 'deallocation' and other similar terms.
Destructors are usually hard to support cleanly in the presence of obligate GC. Given destructors, GC turns out to be unnecessary. Lacking destructors, managing non-memory resources becomes foolishly difficult, particularly across library boundaries.
OK then! I will be interested to see how destructors are reconciled with GC.
Where I have seen GC used in C++ runtimes, it is confined to specific, graph-like structures, where tracking cycles would be messy; or provided to obligate-GC languages being interpreted. In both cases it is always clear whether an object's lifetime is tracked, and the C++ runtime does not see the objects.
I know there are problems with destructors. That's why I didn't implement them yet. But in C# they do exist. And after all you may always use explicit finalizers. I don't think that it makes the concept of obligate-GC invalid.
But after all I don't care much. I'm more interested in other parts of language designs :)
From a quick read-through of the docs, I really love that the language is providing a fresh take on things without the super-junior promise of trying to “solve everything”. I’m impressed and will take a closer look.
Well I used to think that UTF-8 symbols are terrible, until I saw how Julia implement it
Most special symbols have escapable names so for example
Julia have a composition operator (∘)
In the repl or supported editors (atom and vs code), if you type \circ then press <tab> the repl or the editor will replace that with the symbol ∘
Now, I am not saying that this is better than ascii characters, I still prefer ascii characters, and I still find that Unicode symbol even with good editor support are harder to type, and also in some case like in the case this composition operator ∘ hard to read
I just don't think its not terrible anymore, its passable, and I understand why some people might like it more, but good editor support is a must
It is decidedly undesireable for "⋄˄∕≡·‒⁇⁆․⌉⌋"[1] to be a valid indentifier. Especially if, as appears to be the case, "foo[⋄˄/≡·-⁇].⌉⌋"[0] is a valid expression.
I know you can use emoji as variables in Ruby. Unsure if you can in Python.
Imo it's fine to allow Unicode. Latin will still be the de facto standard character set, but it allows international users to code natively and allows for Easter eggs.
Since PEP 3131 (https://www.python.org/dev/peps/pep-3131/) Python supports unicode in names, but only letters, not emoji. I have occasionally used variable names like ϕ when transcribing a formula in toy code.
The unicode is normalized. That can be used for trickery in rare circumstances. "global" is a keyword, but "𝐠𝐥𝐨𝐛𝐚𝐥" isn't, so you can use that if you absolutely require an attribute called "global".
Doesn't Python 3 exactly do this? Not saying I would use non-ascii characters in variable names but presumably populations that don't use the Latin alphabet have different use cases?
Not quite, as it only supports letters. This can be annoying with some mathematical symbols, e.g. IIRC ∇f won't work. Having Greek letters is useful, but I think it should go further, like this, so definitely not terrible.
From a PL design perspective, I'm interested in finding out what new ideas it introduces to an already crowded field?
Rust is good example of a PL design that introduces new concepts (around ownership.)
Pony is another good example of PL design, for the same reason as Rust, but it differs in important ways by introducing Reference Capabilities. I tried to get some attention to it the other day: https://news.ycombinator.com/item?id=24201754
I heard a good podcast about pony recently: https://corecursive.com/055-unproven-with-sean-allen-1/ - it’s about how Wallaroo Labs came to use it. They talk about using it to deal with some really interesting engineering challenges. One of the things that I found interesting is their comparison to Rust was that at least at the time Rust didn’t have a comparable runtime to Pony’s high performance actor based one.
It's a shame Pony does not get enough attention as it's a very nice language that as you say, introduces truly innovative ideas.
I wrote some code in it and it was extremely fast, in the same order of magnitude as Rust/C. But it was quite complex to write, unfortunately, compared to the Rust version (which also guarantees no deadlocks and safe concurrency). On the other hand, the code looked quite a lot prettier due to its Python-like syntax.
Anyway, it's one of those tools I keep in the shed, hoping to one day find a good use for it... just hope it continues evolving (specially running Actors on multiple machines would be a real killer feature - making Pony like a typed Erlang with beautiful syntax).
I'd like to find an excuse to use it for something just to try it out at some point! Being able to run it distributed like Erlang would be really cool, interesting idea :)
"Sean: There was one issue and that was when somebody went to upgrade something and didn’t follow the upgrade instructions. But for the stuff that we built, that was processed at the peak, about 80 million calculations second handling hundreds of thousands of incoming requests a second with packed full of data, which would blow up into like 80 million calculations a second run in for a year. Not one teeny tiny little issue that to me that’s beautiful. That’s beauty to me. Right?"
Just so you know, it appears you've been shadow banned. No idea why. I would suggest joining lobste.rs, an HN clone built out of frustration of HN's lack of transparency on banning.
I've seen a few people on HN offer invites to other users after a conversation regarding the site. I've also seen lobste.rs threads where users suggest preventing new users from joining and even suggesting deleting existing users so they can preserve whatever perceived superiority their site has, so I don't expect them to be very open in general.
The point is also to vouch for someone when an invite is sent. At least in my mind, as in it's officially done, if the invitee misbehaves, it's kind of the responsibility of the inviter. Every profile has who invited who.
Then how does the inviter know, that they can vouch for the invitee? Perhaps no one there knows me. Why would anyone vouch for someone they don't know? Wouldn't that make vouching a useless hurdle?
> Then how does the inviter know, that they can vouch for the invitee?
AFAIK you aren't accountable for your invitees on a day-to-day basis. It just reflects poorly on you if you invite many poorly behaved people - this isn't substantially different from everyday life.
> Perhaps no one there knows me. Why would anyone vouch for someone they don't know?
Some people do invite everyone who asks. They can have their invite rights disabled or in extreme cases be banned from the site. This is relatively rare.
Lobste.rs has a small audience and 3 moderators. The moderation is also much more active than HN - moderators will send private warnings, delete off-topic posts, etc. Moderator actions are publicly visible at https://lobste.rs/moderations. Vouching raises the barrier to entry and allows the moderators to keep up with the workload.
New languages would better be written on the JVM or at least on the coreclr, otherwise they loose all hopes of seamless interoperability with existing production ready ecosystems and therefore loose most hope of success.
If I were to try and make this language interesting to the HN audience, I'd start with two items:
* What is interesting in Elena, compared to Python?
* What is interesting in Elena, compared to ES6?
* For bonus points: What is interesting in Elena, compared to Smalltalk?
Without answering this questions, I don't see why I should take a look. And there must be some differences, e.g. around the concept of first-class messages, which apparently are related to Smalltalk.