rvirding

5 ms·

1.
by rvirding 1y ago
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 still exists, had a very simple Elixir interface modul
2.
by rvirding 3y ago
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 start looking at problems/tests with lots of inherent c
3.
by rvirding 4y ago
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 system for solving them. As we went along our "language
4.
by rvirding 4y ago
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 extremely lightweight concurrency were a critical part of attac
5.
by rvirding 8y ago
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 lisp syntax to clojure syntax. But clojerl does give you t
6.
by rvirding 8y ago
I am a big fan of Prolog and concurrent logic languages as well.
7.
by rvirding 8y ago
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 first high-level language I learnt. So LFE is an attempt to get
8.
by rvirding 8y ago
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. :-)
9.
by rvirding 10y ago
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 which Elixir and its libraries make full use of. Th
10.
by rvirding 10y ago
Much of that blog/description is broken and it is not describing LFE as it is, or ever was in fact.
11.
by rvirding 10y ago
No, they are the same, there is no basic difference at all.
12.
by rvirding 10y ago
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 Erlang VM, is designed to run Erlang so it is difficu
13.
by rvirding 10y ago
Yes "Indeed".
14.
by rvirding 10y ago
There are other languages, just read the reference.
15.
by rvirding 10y ago
I of course prefer either LFE or Erlang, they are much simpler, Elixir has a bit too much fluff for my liking.
16.
by rvirding 10y ago
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 scalability. This is not surprising as no language is good a
17.
by rvirding 10y ago
In many cases this article shows a lack of knowledge of how Erlang programs are written.
18.
by rvirding 10y ago
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. So most of the compiler is in Erlang. It also uses a signific
19.
by rvirding 10y ago
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. Also this means that I can only sometimes refer to
20.
by rvirding 10y ago
Actually no, it is completely different internally with different properties.
21.
by rvirding 10y ago
Written by the same author no less. :-)
22.
by rvirding 11y ago
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. :-) * I am just going to ...
23.
by rvirding 11y ago
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 at the base level. It is concurrency, fault tolerance and s
24.
by rvirding 11y ago
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 of the dynamic code handling which allows you to reload any m
25.
by rvirding 11y ago
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[ ]. It does however have support for decent pattern matching
26.
by rvirding 11y ago
Yes, there are list comprehensions but they return the list of values: (lc ((<- x (lists:seq 1 10))) (lfe_io:format "~p" x))
27.
by rvirding 11y ago
There have been "hints" that why don't I implement JS on top of erlang as well. Would love to try, and some of the problems have been solved in my luerl implementation, but the main problem is time, the lack of it.
28.
by rvirding 11y ago
Main issue is that luerl does support metatables. That caveat was written ago and I can't remember what it was I didn't support then. But as I said now it works.
29.
by rvirding 11y ago
Because it is! :-) For better or worse I am the Robert Virding. Actually there is only one Robert V in the world at the moment, me, there aren't many Virdings. :-)
30.
by rvirding 11y ago
I don't know of any rules in Prolog surrounding indentation and the only whitespace rule I know of is that you cannot have whitespace between a functor and the left paren of its arguments. What have I missed?

More ›