That thread on Twitter was really sad to see. Setting aside the rather disturbing emotional content and just focusing on a key issue, I think it's important to clarify for *everyone* that Erlang, and thus LFE, are not just "regular" programming languages.
Erlang can't really be compared to other programming languages. People get fed up with it when they try to use it, not only because of the syntax, but because there seems to be all sorts of boilerplate and "weird" tasks that one has to perform, often perceived as needless overhead. There is a lot of temptation to hide this behind convenience functions, macros, etc.
The thing is, Erlang is a language of distributed, communicating Erlang processes running as part of Erlang systems. The traditional concepts in general programming very often can't simply be applied. As Robert has tried to explain many times, this is why there is no gensym in LFE. How does one define gensym in the context of distributed processes? Define it in such a way that it is useful in all the contexts of the language?
So that is the overriding view which every decision about the language is made. Questions like "Does it hide or obfuscate core Erlang concepts or capabilities? Will if cause developers to misinterpret the language or distributed systems? Will it lead them down incorrect conceptual paths? Will it lead to incorrect, fatally flawed software?
I think this approach to a distributed language design is not only reasonable and desirable, but necessary. If one needs gensym and one is not writing distributed systems, or will only use gensym locally (yikes! now you have to be EXTREMELY careful about how you deploy your code and which code publishes to other nodes, etc. HERE THERE BE DRAGONS), then you can write one. I think I've seen two different implementations for gensym in LFE. Hell, make a library that offers this (but there better be a whole slew of DANGER warnings in the README ...)
The desire to make LFE more like Clojure, while I do understand the love that many have for Clojure's syntax (you're talking to the guy that originally wrote the clj library), Clojure doesn't actually have an answer for syntax + distributed systems.
Ages ago Rich Hickey talked about the possibility of supporting distributed nodes in Clojure at the language level (even pointing to the possibility of using JInterface from Erlang) ... but you'll note that he still hasn't done this. It's a tricky problem, and to make it actually part of the language, he'd have to change many, many things. Essentially creating a new language.
Akka and Quasar/Pulse are good examples of what wiring for distributed notes in Clojure is like ... each provides a very different approach, but use of each in Clojure diverges pretty far from standard Clojure idioms (and even sytnax). Pulsar gets really close to LFE, actually ... seeing how much they were inspired by (and directly copied) Erlang (up to and including behaviours), this makes sense. The fact that, even in Clojure, Pulsar is verbose should give some hints to the complexity of the underlying technical hurdles that have to be overcome and can't be hidden with sugar.
Anyway, the point with all that is that even while trying to support distributed nodes and all the complexity, configuration, options, contingencies, failure conditions, ability to respond to these, etc., in Clojure, you end up with a whole mess of new stuff ... that is really not pretty (e.g., not simple and elegant like standard Clojure). And that's what you get when you decide to take a bite out of the programming for communicating, distributed nodes. You get a whole new world. And a whole new type of programming. Syntax that makes it pretty is necessarily going to be hiding many things that will eventually need to be uncovered and used directly by the programmer. You don't want to set up a world view for new programmers that they are going to have to completely tear down in order to build things that the language was really designed for.
This is one of the reasons that I argue in favour of banishing all "Hello World" BEAM examples that don't involve genserver and supervision trees. That way, from the very start, all new BEAM devs would be faced with the reality of the situation: BEAM is for distributed systems. All that "boilerplate" actually means something, and will change depending upon the type of nodes/systems you are building.
I'm sorry that some of you hate that LFE is not Clojure. Unlike Robert, I really do like Clojure :-) But I don't want LFE to be Clojure -- I really love it the way it is (modulo the occasional miscellaneous feature addition/minor tweak). I find it an absolute joy to write in.
Fun story: I was asked to join a company a few years back, but they still wanted to do the full interview/hire process with me. They did a technical live coding interview for part of it, where the candidate can choose any language. I chose LFE and they were both Clojure programmers. It was the single most AMAZING and fun interview I've ever had (in fact, one of the all-round best programming experiences of my life, period). For an hour, I live coded LFE, solving all sorts of problems for them (and very quickly -- we got more done than they usually saw). At the end, they had TONS of questions for me. They were *fascinated* by LFE. They'd never seen anybody write in it, much less write so quickly and solve problems in such a concise manner. I did not try to emulate Clojure -- I simply used LFE as it is, with its own strengths and features. Obviously, a complete joy for me to write in -- but even more importantly, when used to best effect, something that seasoned Clojure programmers could not only appreciate, but be amazed by.
d