
Elena Programming Language - theBashShell
https://elena-lang.github.io/
======
nine_k
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.

~~~
mumblemumble
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."

------
jimbob45
Is there anyone that doesn’t immediately scroll past the elevator pitch to the
code examples when looking at a new language?

~~~
zadkey
Yep, that was the first thing I did.

For me, "Yeah it sounds cool, but let's see some code" is my usual response to
new programming languages.

------
Aperocky
It seems the language (at least in implementation) is closely coupled with
Visual Studio and Windows?

~~~
MrMorden
The website may be out of date; current binaries are supplied for Linux and
Windows... but only x86 32-bit.

------
amitport
Can anyone describe a use-case for "first class messages"?

~~~
ww520
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.

~~~
zelphirkalt
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.

~~~
bjoli
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)

~~~
zelphirkalt
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.

~~~
bjoli
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!).

The link is
[https://hg.sr.ht/~bjoli/megacut/](https://hg.sr.ht/~bjoli/megacut/)

Btw, the link for guile-for-loops should be updated in your list:
[https://hg.sr.ht/~bjoli/guile-for-loops](https://hg.sr.ht/~bjoli/guile-for-
loops)

~~~
zelphirkalt
Thanks! I'll get to it later : )

------
jupp0r
> 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.

------
ncmncm
Front page doesn't say whether it has obligate GC, which nowadays I guess
means yes.

~~~
arakov
I can't imagine a modern language without GC. So yes, it has. Destructors are
not yet implemented,though I do plan them.

~~~
ncmncm
I can. Do you consider Rust not modern?

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.

~~~
arakov
as much as I can see, Rust is a special case. So I mean most of the modern
languages. After all I consider C++ modern as well :)

~~~
ncmncm
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.

~~~
arakov
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 :)

------
shureluck
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.

------
adhoc32
"A variable name can contain any UTF-8 symbols (except special ones, white-
spaces; the leading character cannot be a digit) and is case-sensitive."

This is terrible.

~~~
kungato
How is this terrible? Isn't this pretty standard in all big languages?

~~~
wjsetzer
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.

~~~
duckerude
Since PEP 3131
([https://www.python.org/dev/peps/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".

------
whynotwhynot
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](https://news.ycombinator.com/item?id=24201754)

What new ideas does Elena introduce?

~~~
mcintyre1994
I heard a good podcast about pony recently:
[https://corecursive.com/055-unproven-with-sean-
allen-1/](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.

~~~
brabel
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).

~~~
anentropic
Any language with an explicit `end` keyword can't claim beautiful Python-like
syntax :P

Pony is still pretty cool though

------
maitredusoi
TLDR; >Supported platforms

>

> Windows

> Linux

Sorry guys, not for me ...

------
The_rationalist
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.

~~~
anentropic
It seems like languages which compile to C have better interoperability,
nearly all mainstream languages have some form of C-FFI

JVM languages are in a silo off to the side where they only interop with each
other

