Viewing profile — rvirding

The reason for calling it Luerl was that it was/is an implementation of Lua on Erlang. It is Dave who has been working with a more serious Elixir interface. The original one, which…

I would be very interested about the architectural possibilities of the BEAM you mentioned. Also the speed of the BEAM is not as bad as is often mentioned, definitely not when you …

I think the thing to remember that it all started as an interpreter written in Prolog in which we could develop our ideas on what the real problem was and the right semantics of a …

OTP came much later than the design of the language. The language was designed around our I ideas of what the problem really was and the best way of solving it. The massive and ext…

I am not really a fan of clojure and I much prefer the Erlang concurrency model to the options that clojure gives you. I don't agree with Rich Hickey here. And I prefer classic lis…

I am a big fan of Prolog and concurrent logic languages as well.

Well, I do of course see the beauty of the Erlang language; it is a simple, concise and consistent syntax. However, I also like Lisp being an old lisper. Lisp was actually the firs…

No, I did not know of Scheme's original goal, and we had never heard of the actor model when doing Erlang. And we wouldn't have cared either. :-)

Well, it's a skin on the rocket that will make it big. While they generally say that Elixir runs on top of the Erlang VM there happens to be a big fat Erlang/OTP layer in-between w…

Much of that blog/description is broken and it is not describing LFE as it is, or ever was in fact.

No, they are the same, there is no basic difference at all.

They are not only similar they are in fact the same. Elixir compiles down to Erlang and the Elixir libraries are built using Erlang and OTP "underneath". Also the the BEAM, the Erl…

Yes "Indeed".

There are other languages, just read the reference.

I of course prefer either LFE or Erlang, they are much simpler, Elixir has a bit too much fluff for my liking.

Erlang, and hence Elixir, was never optimised for raw computation, it's all about the massive concurrency (we can handle literally millions of processes), fault-tolerance and scala…

In many cases this article shows a lack of knowledge of how Erlang programs are written.

Actually the Elixir compiler does NOT compile directly down to the BEAM, it generates Erlang AST which is then passed into the Erlang compiler which then generates the BEAM code. S…

I just felt that as you can many functions with the same name but with different arities (number of args) at the top-level why shouldn't I be allowed to have it deeper down as well…

Actually no, it is completely different internally with different properties.

Written by the same author no less. :-)

I do want to point out that LFE has been release ready and of production quality for a long time but I tend to suffer from a "Jag ska bara"* syndrome which has delayed things. :-) …

One major difference between the JVM and the BEAM is the type of application they target. The BEAM is designed to implement Erlang so it supports everything necessary to run Erlang…

LFE macros can have variable number of arguments. The compiler does very little in helping with this as there are in principle no inter-module dependencies. This is a requirement o…

Some limitations (?): are no global data; no shared data; all data is immutable; the modules are different from CL packages; functions can't have variable number of arguments[ ]. I…