Lisp Flavoured Erlang(lfe.io) |
Lisp Flavoured Erlang(lfe.io) |
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 to transform) is a really significant win for productivity.
As I've looked for other languages to learn, those sorts of easy to use and highly productive datastructures has been a top criteria.
Haskell has them, but I wouldn't put them on the easy to use list yet. However I'm still learning, and it might just come down to familiarity.
Chicken Scheme has them as an egg, but the syntax makes them far more encumbering than clojure.
If LFE has the same unencumbered immutable datastructures for maps and vectors, well, that would be exciting to me.
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 you could use as vectors, sort of, can be written as follows:
(tuple 'hey 'ho "let's go") <-> #(hey ho "let's go")
Tuples are infinitely more important than maps on the BEAM and so they deserve special syntax.
I think insisting that everything should be like Clojure is a great way to not really see anything different. While I understand that your idea is that "everything else should see what's so great about Clojure", maybe you could take that to heart as well.
Edit, addition: I wonder what the stats on posts starting with "I'm/As a Clojure fan..." are. If someone is an Archlinux user, a vegan, a crossfitter and a Clojure user, which do they tell you first?
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 hot code swap which works in Clojure seamlessly. In java you can't do this wihtout JRebel for example. What is the case with LFE?
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 atoms (like keywords in clojure) started with "'" rather than ":"
LFE macros deliver true homoiconicity to Erlang. It is a Lisp 2, and supports function and macro definitions at the REPL.
I prefer it to Elixir, because I prefer Lisp. Robert has also created a Lua 5.2 written in pure Erlang.
Evidently, Erlang's actors and BEAM VM were influenced by the JVM and Scala, so I guess doing a JVM Erjang was in the cards. [1]
[1] https://www.infoq.com/news/2011/04/erlang-copied-jvm-and-sca...
EDIT: Oh wait, I got myself baited.
[0] Source: the original author of AKKA admitted it on a Java conference I attended.
Erlang was released in 1986, Java in 1995, and Scala in 2004.
I wouldn't be surprised if LFE were older than Scala.
There are literally thousands of companies in the world using a bird in their logo, but they are not all the same company/organization/concept.
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.
Completely agree it boils down to personal preference.
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.
update_in
put_in
get_in
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.
[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....
Note that other languages on BEAM are much more "first-class" than other languages on the JVM, meaning interoperability is usually a lot easier.
I think that's a feature, since Clojure basically has no Lisp compatibility at all. No prior Lisp code runs in Clojure as it has zero backwards compatibility. Clojure has randomly renamed concepts which were known in Lisp already or removed them. Lists are no longer lists, ATOM means something entirely different, etc etc.
Though the compatibility of LFE with other dialects isn't that great in general:
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.
"Maps are more popular, but have a complicated relationship with records and maps have, due to historical reasons, not seen much light on the BEAM in general until lately."
The correction is that maps are the rarer thing, whereas records are more common, due to their lightweight implementation (tuples).
But its more likely to be a typo :-)
[1] https://github.com/rvirding/lfe/blob/develop/doc/lfe_comp.tx...
Having said that, they all support interactivity via a shell, including dynamically defining functions and tweaking the runtime. LFE does a better job at functions than Erlang; I'd wager Elixir too, but haven't looked closely at it.
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.
LFE appeared in 2008, so it's newer than Scala.
The BEAM VM was being worked on in 1992 a year after work on Java in 1991.
You're right. What I meant by "still earlier than Java" is "still earlier than first public Java version", so there was no possibility to borrow anything.