6 ms·
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. Particular
by i_s 10y ago
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 atoms (like keywords in clojure) started with "'" rather than ":"
- hashkb 10y agoWhy assume every new lisp should borrow from Clojure? I think the extra parens types are annoying and unnecessary, personally. Clojure is pretty different from most lisps, maybe lfe is going for wider appeal?
- i_s 10y agoI 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.
- hashkb 10y agoI 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.
- DigitalJack 10y agoI 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.
- tazjin 10y agoThere is also Joxa, a somewhat Clojure-inspired Lisp on the BEAM VM: http://joxa.org/ 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.
- zcam 10y agoJoxa is kind of dead (sadly).
- rkallos 10y agoLFE 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.
- i_s 10y agoGreat to hear that the map literal is there. Completely agree it boils down to personal preference.
- i_s 10y agoIn 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_in/3 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.
- rozap 10y agoProtocols are another major concept that Elixir lifted straight from Clojure. IMO one of the nicest ways of doing ad hoc polymorphism.
- junke 10y ago"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 http://erlang.org/doc/man/maps.html [1] http://erlang.org/doc/reference_manual/records.html#id86378 http://erlang.org/doc/reference_manual/records.html#id86378 [2] https://github.com/rvirding/lfe/blob/develop/doc/user_guide.txt https://github.com/rvirding/lfe/blob/develop/doc/user_guide....
- lispm 10y ago> but I got the impression it has learned next to nothing from Clojure 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: http://lfex.github.io/hyperpolyglot/ http://lfex.github.io/hyperpolyglot/