A big thing is that v0.8 adds the (foo:bar 1 2 3) syntax; I tried using LFE for a while a few years ago and just found the (: foo bar) syntax too cumbersome. I think I had meant to hack it into LFE but in the meantime I discovered that Erlang's native syntax, while perhaps idiosyncratic in some ways, is pretty nice for daily use.
The big advantage of LFE would be macros, which otherwise have to be done with parse transforms in vanilla Erlang. (I understand Elixir also has macros, but sad to say I haven't gotten to dig into it yet.)
Now that I know LFE has the namespace-style syntactic convenience, I'm going to have to try it again.
A few years ago I wrote a minimal lisp in erlang using pg's paper. I called it erlisp[1]. I did it in order to learn Erlang while reading the original Seven Languages in Seven Weeks book.
If you want to learn the basics of a language, I highly recommend writing a lisp in it using only the Roots of Lisp paper and the target language's reference guide. It's a fun challenge.
I was pretty disappointed when I found LFE's insistence on staying very close to Erlang's semantics had forced it into implementing a Lisp-2. It's a very odd mix for FP.
Joxa deviates a bit further from some of Erlang's semantics, but in a way that allows it to express FP concepts in a much more streamlined way. Really intriguing design.
@technomancy, Hey man! Good to see you here ... but not even a little love for a Lisp-2? ;-)
We've chatted about this before, and I guess I just got used to (funcall ...) in CL. There's no question, though, that being able to call functions without that is very clean.
You know, if you squint just right, the name/arity uniqueness in Erlang is a pretty nice match for a Lisp-2 ;-)
I found that being a Lisp-1 made it inconsistent so I went with Lisp-2. Why should I be able to multiple functions with the same name but different no of args at the top-level (which you can and is commonly used) but not in local functions? Lisp-2 gives you the same handling for local functions and top-level functions.
To be honest, I left FP for a long time after learning lisp, and erlang is what brought me back.
The erlang syntactic is really quite good. IT's new, yes, it's not lisp, it's not C, you have to learn a new syntax. Get over yourself, it's not that hard.
And once you learn it, it's nice and consistent and comprehinsible.
But elixir is even better. Elixir brings a lot of great features to erlang, while retaining interoperability, and one of the things about elixir is its syntax is much nicer (in my opinion) and it's certainly more accessible to most people.
We do at http://cargosense.com/ and it's been an excellent choice. Elixir is totally compatible with existing erlang code, which means we've been able to leverage erlang libraries, OTP supervision practices and so without any trouble at all, while still getting excellent macros, protocols and so forth. I'm a particularly big fan of Elixir's lazy collections called Streams, and the ability to build your own. We've written a library for interacting with DynamoDB and Amazon Kinesis that uses these to handle the pagination of those resources behind the scenes so that when you're using the library you can just treat the resource as an ordinary collection and take as many as you like.
We're using the Phoenix framework http://www.phoenixframework.org/ as a backend for a web app written in Angular, and also as part of a data publication service. Phoenix makes a couple of great design choices influenced by its erlang heritage. Most notably it is really just one of the erlang "applications" you run, so it doesn't dominate or dictate the rest of your project structure. You can easily integrate it as just the web component of an application that has behind the scenes data processing or whatever else it is you'd want to do.
The only gotcha we've run into so far is that a lot of erlang libraries expect strings for configuration text (list of chars) whereas the convention in Elixir is to use binaries.This hasn't resulted in any real issues though, just a perplexed minute from time to time.
If you have any particular questions I'd be happy to try to answer them.
Erlang dates back to Ericsson's CSLab in 1986. It's explained in good detail in this thesis by Joe Armstrong[0]. From that paper, the first significant production use came in 1995 with the Ericsson AXD301 switch.
I know you guys take your FP pretty seriously. The closest I get to FP is Javascript applications, but when someone says "list-flavored" anything, my brain autocorrects to "shit-flavored". Unfair as it might be...
))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
Fair enough. Now, I use Clojure(Script) which is somewhat less paranthesy than your average Lisp, but I see far fewer stacked parens there than in the equivalent JS.
Yep. Cool stuff indeed. I did the traditional "write a LISP interpreter in ML" and I found some great things in ML. However nothing about LISP made me happy. It seemed like a cumbersome pain. I have never used Clojure before. I'll check it out. I still don't think it will be awesome enough to make me really learn it over Erlang.
Sad to see my comment down voted. It was mostly a joke.
I used Common Lisp during University, and mostly found it to be in my way. Although I might not have been a good enough programmer by then, to be fair. ML, on the other hand, I loved. I've been meaning to try out Haskell as I hear it is the spiritual successor of ML.
Clojure has many of the conveniences of a modern language, such as data type literals, to mention something incredibly basic but essential. I. e., everything is a "sequence" underneath, sure, but you can still write [1 2 3 4 5] and get yourself a vector/array type of deal. Thus it manages to dispel some of the dusty feeling I got from Common Lisp.
The big advantage of LFE would be macros, which otherwise have to be done with parse transforms in vanilla Erlang. (I understand Elixir also has macros, but sad to say I haven't gotten to dig into it yet.)
Now that I know LFE has the namespace-style syntactic convenience, I'm going to have to try it again.