Live data from Hacker News

Lisp Flavoured Erlang

lfe.io

31–40 of 46 posts

Re: Lisp Flavoured Erlang

#31
post #12

Earlier quoted context omitted.

Erlang Copied Scala's Actors & Erlang's VM is almost a Clone of the JVM - Apr 01, 2011 Erlang was released in 1986, Java in 1995, and Scala in 2004. I wouldn't be surprised if LFE were older than Scala.

According to Wikipedia, work on BEAM started in 1992. Still earlier than Java. LFE appeared in 2008, so it's newer than Scala.

BEAM was just one of a series of virtual machines that implement the Erlang language, so it's not really fair to compare it to Java (just as HotSpot was built a few years after Java).

Re: Lisp Flavoured Erlang

#32
post #20

As a Clojure fan, I tried using this, but I got the impression it has learned next to nothing from Clojure, so I ended up going with Elixir instead. Particularly: - No data structure literals (?) - (except e.g., '(1 2 3) for lists) - Manual module exports, instead of just having 2 versions of def - Other small syntactic annoyances, like plain parens everywhere, instead of brackets in some cases like Clojure, and atom…

There is also Joxa, a somewhat Clojure-inspired Lisp on the BEAM VM: http://joxa.org/

Note that other languages on BEAM are much more "first-class" than other languages on the JVM, meaning interoperability is usually a lot easier.

Re: Lisp Flavoured Erlang

#33
post #28
post #25

Earlier quoted context omitted.

I can't prove that it should. Just providing a list of initial impressions from someone who has been using Clojure for a while, FWIW. It's necessarily subjective. Seems like it would be a good idea though, since Clojure is a new lisp that has gotten a decent amount of traction in industry.

I think a lot of that has to do with Java interop. I could be wrong but IMO the language features people rave about are all balanced by warts. I like Clj and I like CL and many Schemes. Diversity is cool.

I agree that java interop is a big deal, but mainly to library writers.

End users, I think, end up using clojure wrappers around java libs instead of java libs directly.

For end users (application writers), the single most important thing are the easy to use yet very powerful data structures.

Re: Lisp Flavoured Erlang

#34
post #27

Earlier quoted context omitted.

I am a fan of clojure. I'm interested in LFE, but I've been focussing on learning Haskell lately, and don't want to switch gears yet. The big thing that I miss in clojure are the data structures, and the ease of use of those data structures. Specifically vectors and maps. These exist all over the place, but no where (in my experience) are they as pain-free as clojure. That combined with their immutability (yet easy t…

> Specifically vectors and maps. These exist all over the place, but no where (in my experience) are they as pain-free as clojure. You don't use vectors very much on the BEAM in general, so I wouldn't consider this very important. Maps are more popular, but have a complicated relationship with records and records have, due to historical reasons, not seen much light on the BEAM in general until lately. Tuples, which y…

I prefaced with clojure fan to give context for my post. As a clojure fan, my point of view is going to be from a clojurist. It's a clue as to how to remove bias.

I don't think everything should be like clojure, I just think clojure gets datastructures right in ways that I haven't seen in other languages. I don't think I insisted on everything, or anything, being like clojure.

Right now my dream language would be mostly haskell with clojure maps. Next year it could be something different.

Re: Lisp Flavoured Erlang

#35
post #20

As a Clojure fan, I tried using this, but I got the impression it has learned next to nothing from Clojure, so I ended up going with Elixir instead. Particularly: - No data structure literals (?) - (except e.g., '(1 2 3) for lists) - Manual module exports, instead of just having 2 versions of def - Other small syntactic annoyances, like plain parens everywhere, instead of brackets in some cases like Clojure, and atom…

LFE does have data structure literals for some of the main data types in Erlang. You have #() for tuples, #M() for maps, and #B() for binary syntax. Clojure additionally has syntax for vector literals, but vectors don't seem to be used very often in Erlang, though there is an Erlang module for dynamic arrays which is accessible in LFE. If you felt so inclined, I believe you could extend the LFE reader to add syntax for arbitrary data structures.

I'd guess that the manual module exports are a design decision inherited from Erlang, where you specify exported functions with the -export() macro.

As for the rest of the syntax; it appears (to me, at least) that LFE doesn't deviate terribly much from traditional Lisp syntax, while still being transparent about the underlying Erlang data types being used. Clojure took the opportunity to introduce a more opinionated Lispy syntax. This really boils down to personal preference.

All in all, I think that the various design decisions of LFE and Clojure make a lot more sense when you consider their respective host languages/VMs.

Re: Lisp Flavoured Erlang

#36
post #20

As a Clojure fan, I tried using this, but I got the impression it has learned next to nothing from Clojure, so I ended up going with Elixir instead. Particularly: - No data structure literals (?) - (except e.g., '(1 2 3) for lists) - Manual module exports, instead of just having 2 versions of def - Other small syntactic annoyances, like plain parens everywhere, instead of brackets in some cases like Clojure, and atom…

In general, it seems like the authors of Elixir were able to capture more of the cool things about Clojure than LFE. Check out some of the top level functions in Elixir:

  update_in
  put_in
  get_in
http://elixir-lang.org/docs/stable/elixir/Kernel.html#update...

These are basically right out of Clojure. It may seem like a small thing, but consistent, well thought out functions like this makes working with immutable data structures much easier.

Re: Lisp Flavoured Erlang

#37
post #18

Earlier quoted context omitted.

I am a fan of clojure. I'm interested in LFE, but I've been focussing on learning Haskell lately, and don't want to switch gears yet. The big thing that I miss in clojure are the data structures, and the ease of use of those data structures. Specifically vectors and maps. These exist all over the place, but no where (in my experience) are they as pain-free as clojure. That combined with their immutability (yet easy t…

> The big thing that I miss in clojure are the data structures, and the ease of use of those data structures. Specifically vectors and maps. These exist all over the place, but no where (in my experience) are they as pain-free as clojure. I'm not sure I understand. Why do you miss them when you have them in Clojure? Is it a typo and you meant to say LFE? By the way one of my biggest productivity boost for me is the h…

Erlang supports hot code swapping, so I am guessing that LFE would as well.

Re: Lisp Flavoured Erlang

#38
post #36
post #20

As a Clojure fan, I tried using this, but I got the impression it has learned next to nothing from Clojure, so I ended up going with Elixir instead. Particularly: - No data structure literals (?) - (except e.g., '(1 2 3) for lists) - Manual module exports, instead of just having 2 versions of def - Other small syntactic annoyances, like plain parens everywhere, instead of brackets in some cases like Clojure, and atom…

In general, it seems like the authors of Elixir were able to capture more of the cool things about Clojure than LFE. Check out some of the top level functions in Elixir: update_in put_in get_in http://elixir-lang.org/docs/stable/elixir/Kernel.html#update... These are basically right out of Clojure. It may seem like a small thing, but consistent, well thought out functions like this makes working with immutable data s…

Protocols are another major concept that Elixir lifted straight from Clojure. IMO one of the nicest ways of doing ad hoc polymorphism.

Re: Lisp Flavoured Erlang

#40
post #36
post #20

As a Clojure fan, I tried using this, but I got the impression it has learned next to nothing from Clojure, so I ended up going with Elixir instead. Particularly: - No data structure literals (?) - (except e.g., '(1 2 3) for lists) - Manual module exports, instead of just having 2 versions of def - Other small syntactic annoyances, like plain parens everywhere, instead of brackets in some cases like Clojure, and atom…

In general, it seems like the authors of Elixir were able to capture more of the cool things about Clojure than LFE. Check out some of the top level functions in Elixir: update_in put_in get_in http://elixir-lang.org/docs/stable/elixir/Kernel.html#update... These are basically right out of Clojure. It may seem like a small thing, but consistent, well thought out functions like this makes working with immutable data s…

"update", "put" are already available in Erlang[0] and work with nested records[1] if I understand correctly. Likewise, it seems that LFE has map-update for the same use cases[2].

[0] http://erlang.org/doc/man/maps.html

[1] http://erlang.org/doc/reference_manual/records.html#id86378

[2] https://github.com/rvirding/lfe/blob/develop/doc/user_guide....

Post reply on HN