Hacker News new | comments | show | ask | jobs | submit login
The Axis Of Eval: Why I ignore Clojure (axisofeval.blogspot.com)
35 points by Torn on Sept 20, 2010 | hide | past | web | favorite | 80 comments

What an interesting perspective on language development.

It's funny how the biggest detractors of clojure seem to be those that should be cheering it on, the people that use LISP.

Clojure is a lisp, like it or not, sure it's not common lisp or whatever other dialect you prefer, but that shouldn't matter too much.

LISP used to be leading, now it is lagging and this person seems to be somehow proud of the lag.

LISP is as much a way of thinking as it is a programming language and Clojure is representative of that way of thinking. The implementation details are really just that, details.

So ignore clojure - and any other modern attempt at bringing LISP in to the mainstream - and decades from now you might wish that you had not, because you lost your chance at shaping the future of the language that you profess to love so much.

We're detractors because we care...

I like Clojure, I've used it for a number of projects. I've given money to rhickey. I think it is very promising.

It has a lot of good ideas and it is very refreshing to see people tackling current issues in a dialect of lisp. It is also nice to see a lisp with market traction.

That said, there are a lot of things that are 'unproven' about it.

It isn't clear that shared state immutability and transactions are 'the way' to tackle concurrency.

It isn't clear that Clojure's macros are really better than Common Lisp's macros.

It isn't clear that we really want to be tied to the JVM/NET architecture.

(Or that the concessions made to do so are reasonable... stack traces, tco).

I think I could go on if I wanted to.

A large number of features implemented in Clojure are still research topics...

It grates me when proponents of Clojure tout it as 'a modern dialect of lisp,' implicitly asserting that other lisps are in some way decrepit, aging relics from the 80s.

The truth is that Clojure is modern compared to almost ANY programming language, calling it 'a modern dialect of lisp,' while potentially true, is doing a disservice to Clojure, as well as to other lisps which are under active development.

Why is naming something 'what it is' doing it potentially a disservice?

What arguments are there to say that clojure is not a modern dialect of lisp?

The JVM came about pretty recently (on the LISP timescale), software transactional memory has been around for a while but afaik no mainstream lisp-like language implements it, and so on. That all says 'modern' and 'new' to me.

I'm not versed enough in Lisp or clojure to make any statements about the macro issues.

What bugs me about clojure is on a completely different level, all those 'x done 'in clojure'' articles that really do nothing to advance the state of the art, as though doing something 'in clojure' somehow makes it worth writing about.

And then there's the 'one man show' feeling that is still very pervasive.

It is the tight coupling of the terms that is doing the disservice.

It is a modern language. -> T.

It is a lisp. -> T.

However, I only hear, 'It is a modern dialect of lisp,' when I am being told why I should switch from Scheme or CL to Clojure.

This is a non-argument (there is no spec for what a 'modern' language includes). It also has the implication that whatever I am using is in some way non-modern. (Which is an odd attribution for something which is actively developed and I do my daily coding in). Is Java modern? How about Python? Scala? Ruby? It seems like a weird non-category. When I boot up sbcl, it isn't like i'm programming in lisp 1.5.

New would be cool, or saying it has modern features, also good.

Gonna make a new spec for Common Lisp, Common Lisp the Ancient Language.

Transactional memory has been provided by several of the CLOS object databases. There have been logical language extensions to Lisp which see their data as in a database with transactions (Ap5 would be an example).

The JVM does not bring that much new to the Lisp world. What is new in the JVM nowadays is the concurrent GC and the JIT. Lisp runtimes prefer precompiled code. What the JVM lacks for example is easy code loading (think class loading in the JVM), instruction set optimized for Lisp and dumped images.

Clojure combines STM, concurrency etc. in a clever way and with the focus on pure FP. It's not that elements of that did not exist before, but the combination in Clojure seems to be novel.

There are plenty of people in the Lisp community cheering Clojure on too. Rich Hickey's talk at Boston Lisp Users had about 60 people there.

Lisp has a smaller community than other languages, but it's still a big, diverse community.

We switched from LISP to Lisp shortly after mankind killed the last dinosaurs, btw.

Chalk that up to the age of the stuff that I've been reading recently (LISP 1 and LISP 1.5 manuals).

Yeah, the dinosaurs were still alive, then.

I figured 'go to the source' is the best way to really understand what's going on, and it's been quite the eye opener to see 'simple' lisp next to all the superstructure that has been placed on top of it since then.

I'm not sure if I should recommend anybody to go the same route (since I'm still very much a FP/Lisp newbie, so my words carry little to no weight at all) but it worked well enough for me that stuff made more sense after doing that.

Sure, it makes sense if you are interested in that stuff. There is a wealth of material. More than a person can read in a lifetime. But it may be more important to hack the new stuff, otherwise you get sucked into that Lisp thing. Like me.

I actually have the blue book open in my pdf viewer right now. I jumped back into it after I re-read Gabriel's Design of Parallel Languages few days ago.

Most of us are not Ents. We don't have decades to wait and see how a language feature "plays out". Rather, most of us have projects that we need to work on NOW, and if a language comes along with features that help us solve hard problems, it would be a good idea to take advantage of it. Who cares if "the greater Lisp community" will approve of it or not?

(By the way, "Lisp community" is a bit of an oxymoron, IMHO; everyone seems to be stuck on his own island.)

> We don't have decades to wait and see how a language feature "plays out"

I think the difference of perspective comes from the different nature of the work Lisp is being used for.

If your job is to create the next version of Lisp, it makes sense to watch how that new feature of Clojure plays out.

On the other hand, if your job is to deliver a nice application to users who need it, you don't really care about how that feature will look 20 years from now - you use it if it makes your problem simpler to solve.

That said, I wish application developers were less susceptible to language/library/framework fashion. I dread to support (and enhance) Java apps that rely on a stack of frameworks like the developers were playing some buzzword bingo game with the product.

I would also not care. If people like Clojure and its Java integration? So what? More power to them. Rich and his friends are doing a good job. Still there are enough people to prefer other Lisps - enough that ten Common Lisp implementations are maintained, twenty Schemes, many versions of Logo, ...

Indeed, there is no Lisp community. The fragmentation was enough for me to lose interest in the language and several of its dialects (heavily influenced my switch from emacs to vim, too :(), as well as functional programming in general. I wish the Lisp crowd (?) would seriously reconsider their views on matters like this.

So you lost interest in Linux as well? There are probably more different Linux distributions than Lisp dialects. Which shell do you use? How about a C like language? C? Why not C++? Or D? ATS? You've decided on a scripting language? TCL? Perl? Rebol? Python? Ruby?

You try to make interesting points, but let me give you some indicative examples:

- C has a very strong community, and people who don't like C go out there and create their own dialects or substitutes (like Go) without constantly harassing on each other. I won't go as far as saying nobody would insult me there as you're doing here, but at least there's some mutual respect that is driven by the interest for the language. The same could be said for the Python or Ruby (and no, I haven't decided and I won't, I use the right tool for the job) communities, but I have not had that experience with Lisp/Clojure/Scheme fans.

- The various communities around Linux distributions similarly bash on each other, but thankfully I'm not in as much of a loss there as I were back in high school with no clue about what Lisp even was. I can safely ignore their rants because in that context, I can judge for myself. When it comes to Lisp dialects, I don't know my way around and the community made it hard for me to learn anything concrete.

See, in many a case, it is difficult to get into a discussion without encountering some bizarre religious argument about "which shell do you use" or "why not C++?", similar to several recurring themes here in HN (see the recent "C is a macro assembler" arguments). Not only are such arguments unhelpful, but they're a waste of time for anyone who wants to delve into a subject. While the above may be anecdotal evidence drawn from personal experience, I see others share my view, and I don't believe in coincidence.

Let me make that clear: I like Common Lisp and use it. I'm not a Clojure user. But I also think Rich does an excellent job and his work on Clojure is brilliant. It's just that it is not exactly for me. If you look around in the Lisp community there are very very few people who don't have a lot of respect for Clojure.

Perl, Python and Ruby all have outstanding communities.

Would you care to argue that the Lisp community is better than any of these?

Yes, I would argue. It's refreshing to drop in #lisp and ask any technical question, of whatever magnitude, and get answers immediately.

I recommend that place to any intelligent students, researchers, language weenies, compiler hackers and system engineers. Just be informed and don't ask opinionated, loaded questions.

Elsewhere? meh, I am left to think my present company has just been introduced to computing by its $LANG_MANUAL.

There is also a lot of childish fucking around and casual piss-taking that doesn't happen among Lispers. If you expect an standing ovation because you pushed something to github, fuggedaboutit. No one will be retweeting wisdom, no one will like you on facebook, you will not be blogged about ..

Ever wonder why Lispers, and most adult programming communities don't have "Rock Star" celeb provocateurs?

There is also a lot of childish fucking around and casual piss-taking that doesn't happen among Lispers.

Maybe not anymore, but that stuff used to happen very regularly on comp.lang.lisp during the years I paid attention to it (2003ish through 2006ish, maybe).

CLL is the elephant graveyard of Lispers. It's where old hackers go to die.

It's a messy place to be, but there are some ivory treasures to dig up.

We've entered the hypothetical realm here..clearly some people have had different experiences when it comes to interacting with "Lispers". Maybe they asked the wrong question or they acted like jerks, who knows.

And most adult programming communities have something worse than the "Rock Star" stereotype: the "Authority". For Lisp in particular, there are plenty who struggle for that title.

PS. Indeed, "I pushed 20 of my projects to Github"...who cares, is anyone of them any good?

No, I was just say that you have to make a choice. Since Perl, Ruby and Python are all completely incompatible and share no code. You can look at Lisp and choose Racket and be happy, for example.

Lisp Archipelago?

I have a perspective on this: I have been using Clojure for work over the last 5+ months but I am also setting up my laptop to finish writing a Common Lisp book while I travel over the next month.

Using Clojure is definitely a nice experience and I am really excited by the future of Clojure as the infrastructure for the language evolves.

However, after hacking Common Lisp for a few days, I have to say that the tools are so very good.

I find myself preferring Clojure the language but prefer the tools and programming environment of Common Lisp.

Are you talking about Emacs or non-Emacs environments, when you say you prefer Common Lisp's?

I keep trying to tame Emacs enough to use it for Clojure and find I spend too much time on Emacs and not enough on Clojure, which is what motivates me in the first place.

After a few false starts with emacs as an IDE I finally learned it via other uses.

I recommend using Emacs for a more simple task. I started reading my mail via Wanderlust (wl-beta package on debian) and using ERC to connect to freenode (Now running rcirc.)

I know how irc works so my attention wasn't split too much and I was able to pick up the emacs stuff quickly. Now I've expanded it to be my python IDE.

I use Emacs for both.

I'm glad that so many people find Common Lisp useful and practical.

I just wish they realized that at this point, nobody else ever will. It's showing it's age. It's incredibly idiosyncratic. Noone new is ever going to start loving it.

Clojure may only be a blip on the radar in the grand, glacial evolution of LISP, but it's really, really nice that there's a featureful, modern lisp that a 21st century developer can actually pick up, use, and enjoy.

Hopefully, no one will read the cutest programming book since Starting Forth, Conrad Barsk's "Land of Lisp":


It does indeed look like a great book - but it doesn't really change the fact that Common Lisp is fragmented and dated.

Really, LispWorks has its IDE ported to GTK+ and looks very nice under Windows, Mac OS X and Linux/FreeBSD. Got concurrency, too.

I'm also looking forward to see the ARM port of Clozure CL mature with the alpha version already running on an iPad.

But the mere fact that you actually need to point out that it (can) have basic cross platform compatibility and concurrency is proof that it's getting dated. Modern languages assume that.

And that's only in the commercial implementation.

If you compare the features of LispWorks or Allegro CL with Clojure you will find that Clojure has a very long way to go to match those offerings. Clojure 1.2 can't even display errors without exposing its Java nature. For a start it lacks the error handling infrastructure of Common Lisp and the tools that implementations provided on top of that.

No, concurrency is also supported by free CL implementations - like CCL.

I fully admit that Clojure tooling isn't where it should be, yet. But it will be.

But the fact is that despite its lack of mature tools, Clojure is more newbie-friendly than CL. That should give CL advocates pause.

As for running on Java, yeah, that's part of what it (currently) is. It's a strength and a weakness at the same time.

Once Clojure becomes self-compiling, we might see that change. I'm actually working on a toy Clojure->LLVM compiler for my own education. There are enough people who love Clojure but have a distaste for Java that I expect we'll see a native version of Clojure in the next few years.

Is it more 'newbie' friendly? The tools are bare bones. Make a syntax error and you get a Java error. On error you are thrown to the top level. Open the debugger and you see Java internals. On Emacs it reuses CL's SLIME, which is not known to be newbie friendly. Otherwise one has to use a Java IDE, which are not known for their interactivity.

What does it make Newbie friendly? I was just seeing a video of Robert C Martin explaining Clojure - he looks like a Lisp newbie to me. Half of the time he was spending in a primitive REPL in a Terminal. Is that Newbie friendly? Maybe because one does not get distracted with slightly better REPLs, a SLIME REPL or even one of the other advanced REPLs? Then he was using Intellij. Is that more Newbie friendly? Perhaps to developers coming from Java?

I wonder how many of you are using Clojure like a Lisp (with its interactive development tools), and how many are using it like typical scripting language?

Anyway, I expect Clojure to improve on that front over time. But, as time goes by and the compiler is written in Clojure, the REPL gets improved, it has some better error handling, it gets real error messages, etc etc. ... it then will no longer be the sexy small Lisp which you have seen grow up. It will be a Lisp implementation like many others with all its complexity.

> But the fact is that despite its lack of mature tools, Clojure is more newbie-friendly than CL.

As a newbie, I have to disagree. Clojure has a ton of syntax to get used to, and to make it useful, you have to learn all the neat Java libraries on top of it. I found more resources and nice explanations for aspects of CL, and when I compare it against Clojure, I find I miss a lot of the nice functions and tools for CL.

Here is a fun newbie point on it: In the first hour of playing with CL, I learned how to debug it. Not so with Clojure. Trace? Step? Maybe I should be using harder-to-find online tutorials for Clojure?

Anyway, it boils down to opinion as to what is "easier". I was looking for something with batteries included that would compile to a distributable executable and be super flexible; CL fit the bill with the sbcl implementation. It successfully pulled me away from other fun languages, like Erlang.

If you're partial to the JVM, you can use ABCL:


I am in the middle of porting it to Android, but as is, you can use it to write anything non-mobile/embedded, and it can call Java libraries just as well as clojure.

> But the fact is that despite its lack of mature tools, Clojure is more newbie-friendly than CL. That should give CL advocates pause.

This is very fuzzy terminology. What defines newbie-friendly? I can get an "enterprise-quality" Common Lisp environment and language for free. Likewise, the CL standard is also freely available and meticulously cross-indexed. As an added bonus there are countless Common Lisp books available on every imaginable topic. There are also numerous package managers (including the exciting http://quicklisp.org) at my disposal. And for the cherry on top there are luminaries like Ranier Joswig and Xach Beane willing to take their free time to answer my idiotic questions.

This, to me, is the very definition of newbie-friendly.

I think you missed the point. There is not even (yet) a de facto standard for concurrency on lisps.

There are bordeaux-threads and portable-threads, and they mostly work, but I usually just fall-back on limiting my threading calls to a small number of functions and then manually adding #+ stuff to get it to work when I want to port to a new CL.

People really expect some form of threading/concurrency to be standardized across implementations.

The CL community has been occasionally successful in making new de-facto standards (Gray streams, ASDF, and to a lesser extent MOP), so there is hope.

We need not guess -- these things can be measured. Here is a graph with a language people will pick up and use, versus one they will not.


The Lisp process to which the author refers is not as stately and merit-based as he implies. In Scheme, the r6rs process was very difficult and divisive, and many people voted in favor of it while very publicly holding their noses. The r7rs process, if carried out as planned, will attempt to avoid the same kind of damage and will result in two language: a sparse core language and a featureful "practical" language. That larger more featureful language will be the one that is more useful outside of language research, and it is also the one that will change more over time, shielding the core language from the need to change. Scheme purists can stick with the core. Non-purists can embrace the featureful languages such as r7rs-plus (or whatever it will be called), Racket, and Clojure. Anointing CL or Scheme (core) as the final arbiter of the value of a language feature is tantamount (bucket list item #73: use "tantamount" in a sentence; check) is OK if it works for you, but it certainly wouldn't work for a lot of working programmers.

[OT aside/ignore]

"Anointing CL or Scheme (core) as the final arbiter of the value of a language feature is tantamount (bucket list item #73: use "tantamount" in a sentence; check) is OK if it works for you, but it certainly wouldn't work for a lot of working programmers."


To check it off the bucket list, I believe that you have to use it properly. It has to be tantamount to something.

Sheesh. I interrupted myself with my parenthetical expression and didn't finish the tantamount thing. Worse, now I don't remember what it was tantamount to.

I guess the thing that annoys me more than anything about this blog is that the author often has great posts, but is a tangle of contradictions. For example, Clojure is bad because it ignore Common Lisp (nevermind that many of its features are inspired by CL). History is good and we should stop trying to create new things. The blog author is also creating a new Lisp. People should stop creating minimal Lisp implementations (history is now bad?). The more you read this blog the more these types of things pop up. However, I get the impression that often he's taking the piss and that's why I continue to read.

Don't take it too seriously. It's a kinda stupid rant. (I wrote it.)

A very ... let me say, ahistorical rant, starting at the very beginning:

"Lisp gets lexical scope right, for example, simply because we have a head start of decades over the [line out]competition[/line out] others."

Case in point: LISP didn't get this right in 1958 while apparently in the same year (as I read Wikipedia) ALGOL did. This caused a lot of grief which wasn't resolved until 1983 when Common Lisp adopted Scheme's ALGOL inspired lexical scoping. And Emacs Lisp and AutoLISP (AutoCad), two very big (in terms of real world usage) Lisps are dynamically scoped.

Lisp has much to be proud of, but this could easily be the single worst aspect of it historically.

ALGOL did, but it had it easy, because it was not providing closures and garbage collection. When ALGOL had lexical scoping, these things were unresearched. It took a while in the Lisp and FP community to solve this (see the FUNARG problem).

LISP wasn't providing closures at that point (1958), was it?

I've read that the LISP community was the only major part of the FP community that had trouble with this and that the other parts were always confused about why this caused such consternation with LISP.

No language had lexical closures in 1958. ALGOL had lexical scope, but not closures. So their part was easy. On a language level all the consequences were explored with Scheme in the 70s. Before that their were individual solutions found to create closures.

Read the history of the FUNARG problem (1970).

FP languages came up later. The first ML appeared in something like 1972/1973. I'm not sure if that had lexical closures. I doubt that. The Lisp community was one active part of the FP community that detected the problem and eventually found a solution. Scheme was the first language to demonstrate that (1975). Other FP languages also went that route (ML, where the first ML was implemented on top of Lisp, IIRC). The MacLisp branch took some time to adopt lexical closures. First a special construct was introduced to create a closure. In some other implementations the compiler was using lexical scope, but not the interpreter. Common Lisp was then in 1984 the next major Lisp dialect that settled for lexical scope (incl. closures) for both interpreted and compiled code.

The Lisp community (other than Scheme) had substantial code at the end of the 1970s, so there was some reluctance to move to lexical closures. Lexical closures also made the implementation a bit more difficult. The interpreter is simpler without them. There were also performance issues to overcome.

This seems to be exactly what the author is talking about. Lisp gets lexical scope right exactly because it did it wrong for about 20 years.

I'm not sure I would agree, however I'm not familiar enough with Common Lisp's lexical scoping to be absolutely sure (actually, I've never programed in a lexically scoped Common Lisp, just an early IBM-PC interpreter that was dynamic, and that for only a few months).

Common Lisp seems to be missing a number of things I like in Scheme for this sort of thing; my impression is that for understandable reasons the introduction of lexical scoping to mainline Lisp in Common Lisp was done with an eye towards minimal breakage of all that great software that had been developed in the previous 25 years.

Would you mind explaining it further? I took it to be from the perspective of the history of programming languages. It sounds like you think that Clojure can't be regarded as an important Lisp at this time because it's only been around for a few years and it will take decades before we have enough perspective to know whether any of the ideas in Clojure will turn out to be significant. How does that sound?

This is very different to my perspective. I like Clojure for two reasons:

1) It's a Lisp (and I rather like many Lisp features) 2) It's an accessible Lisp. I found it to be easier for me to learn get stated with than Comon Lisp which I had previously tried to learn and had not gotten far with.

One consequence of 2) may be that Clojure will turn out to be rather significant, regardless of whether any of its individual features are all that great. Clojure may succeed because it is an accessible Lisp.

What I don't like about Clojure is that it leaves out some features which I love about other Lisps. See this post:


That's the fastest I've ever seen an author of such a Common Lisp rant point out that you're not supposed to take it too seriously.

(By "such a rant", I mean the tradition of rants which purport to turn Common Lisp's negatives into positives, where the smugness is joyously dialled up to 11.)

It's not a CL rant.

I've read your blog, so I'm aware that you don't consider it such, just as the creator of Clojure might take issue with your claim that "Clojure ignores Lisp." But it shares many family resemblances with the Common Lisp rant. For instance:

* It typically subsumes Scheme, Interlisp, etc into "Lisp". (Regardless of whether, in other contexts, the author argues they're not Lisps.)

* Others are dismissed as "unwashed masses", while the "so many smart people" in the Lisp community obviously thought of your new innovation and either dismissed it or had other things to do than implement it.

* It purports to turn a commonly-believed negative into a positive.

* Uses questionable but nuanced logic.

* The author seems to at least partially believe in the rant's gist, as far as anyone can tell.

I'm not necessarily arguing it's a bad thing, just a tradition that people might want to keep in mind with a dose of humor.

That's because only CL can go to 11 all the other Lisp can only go to 10. Unless you defmacro 10 to be 11

EDIT: I guess I have terrible humor ;p Moving it to reddit

This article makes it seem like Lisp is in a state of continuous evolution. In which case I don't see a good enough argument why Clojure isn't part of that.

Even more so, it kinda reads like there's one huge mainstream evolutionary branch of Lisp since time immemorial, and off-shoots are quickly reabsorbed into this. Never mind the multitudes of lisps and especially the constant Scheme-CL schism…

I understand perfectly why fans of Common Lisp won't switch, but considering CL as the head of a constantly evolving Lisp with a capital L seems a bit silly.

There's either no "Lisp", or Clojure is as much a part of it as CL is.

> This article makes it seem like Lisp is in a state of continuous evolution. In which case I don't see a good enough argument why Clojure isn't part of that.

That's because the author isn't saying that. The point is more like this: Clojure is a series of new mutations, and they haven't been around long enough yet to tell whether any of them will survive natural selection. We can't tell Clojure's good ideas from its merely new ideas at this stage; we have to wait for evolution to take place. That doesn't mean Clojure is doing something wrong (after all, "Everyone should be writing new Lisps!"). I think the author is just saying it's not worth getting too excited about until we know what it's doing right.

The problem with evolution in general is that it doesn't select the best approaches, it selects the most popular ones. So if you ignore the current 'mutations', you're basically trust that the community will "do the right thing". Which I regard as rather optimistic (as is the assumption that it always did this in the past).

> The problem with evolution in general is that it doesn't select the best approaches, it selects the most popular ones.

Not sure what you mean by this. At least in a biological setting, natural selection selects for `adaptive' features, i.e., those which best solve some problem that an organism has. (OK, it's more complicated than that, but let's take that as a working definition.) It does not select `popular' features. Rather, features become popular because they are adaptive and hence selected for.

Now, programming language evolution may not always work like biological evolution, and in both cases there may be other selection pressures at work. But I don't see a reason to think that, insofar as programming language evolution is like biological evolution, the `natural selection' of language features by the community would favor what's arbitrarily popular, instead of what's best at solving a common problem.

The main branch is Lisp, Lisp 1.5, MacLisp, Lisp Machine Lisp, Common Lisp. The evolution of that branch is now more in libraries and with individual implementations. It also got excellent implementations where all the low-hanging fruit is gone (Means easy improvements are no longer possible). For the community it is more difficult to improve the SBCL compiler, because it is already a substantial Lisp program. Still, if you look at the repository quite a few people add improvements to it.

There is Scheme, where there is still some research and evolution going on. See the work on R7RS and implementations like Racket.

I am not really sure whether this is an interesting critique from a broader Lisp perspective, or a stunningly epic troll to get traffic by enraging Clojure folks.

From my point of view:

* Other LISPs I have tried are not very amenable to practical usage in a modern software ecosystem. Not impossible, just a difficult fit. Could this be fixed? Sure. Why hasn't it been fixed? No idea.

* Clojure is a very practical LISP today, which drops very easily in to a modern software ecosystem.

> or a stunningly epic troll to get traffic by enraging Clojure folks.

You'll be forever wanting if your goal for website traffic revolves around enraging Clojurians. First of all, there are not enough of us (yet), and second we tend not to get drawn into these types of arguments. I guess we're too busy trying to build a great programming language. ;-)

The entire article rests on the false premise that Clojure is not a Lisp.

Depends on what you define to be Lisp.

If Lisp is the line of Lisp, Lisp 1.5, MacLisp, Lisp Machine Lisp to Common Lisp, then Clojure is not in that line. In Common Lisp I can run 50 year old code with relatively little change. CAR, PROG, ..., are still there.

If Lisp is the larger family of widely incompatible languages like Logo, Dylan, Racket, Arc, NewLisp, then Clojure is a part of that family. But they share very little - not even the syntax. Clojure is completely incompatible to any of them - but that's true of each other.

Yeah, I am a big-umbrella Lisper. I am confident any Lisp programmer can pick up Clojure and be productive in it within a week.

Dylan, Logo, Racket .. used them all three. Arc, I use it several hundred times a day, but never wrote a line in it. Clojure, a good Lisp.

NewLisp? No thanks.

Yes, that jumped out right away. Really weird.

A lot of programmers are either inapt or inept at making their own "batteries"; let's call them b-group programmers. Clojure's main draw over lisp (as I see it) is the JVM and all of the work that a-group programmers have contributed. It's lisp, with most[1] of the allure of an almost mystically powerful succinctness, but with batteries included.

I contend that while batteries are, in the short term, a big help to the b-group it would be better for the programmers to look into whether or not they have what it takes to move into the a-group. One will never fail to learn a ton walking the hallowed halls of the a-group's code trying to figure out how that formerly black box does it's magic.

Where I currently work, for better or worse, the micro-development manager has forbidden the use of JavaScript libraries. The net effect has been that some developers have left/been let go and the ones of us that have stayed have had to learn to roll our own.

pg said it best: "Powerful libraries are a cheap way to make a new language the language du jour. (Think Rails.) They're not the critical ingredient if you're trying to make something to last; they may even hurt."

[1]: no CLOS, no Tail Call Optimization, etc...

> Where I currently work, for better or worse, the micro-development manager has forbidden the use of JavaScript libraries. The net effect has been that some developers have left/been let go and thous of us that have stayed have had to learn to roll our own.

I don't think that kind of 'NIH' is very productive in the longer term but it must be a great place to work if you're encouraged to re-invent the wheel.

Most places would try to avoid such a waste of resources. Maybe there would be a way to convince him of rolling your own company specific OS?

As we are now discussing my current employer and boss's decisions third party -- and given the accessibility and permanency of the web -- all I am comfortable saying is that, in the long run, having stronger developers that throughly know their code-base can be a huge win.

Yes, I agree, it can be. It very much depends on the circumstances though, for most companies rolling your own ORM, framework, javascript libraries, database and so on are simply not an option, they'll be hard pressed to keep up with the demands of running their business.

Great stuff can come from that though, for instance, Django.

Maybe that's why a lot of things like 20% projects, in-house text processing capabilities (troff), and PARC projects come from large, established companies.

Java-Batteries. Other people don't use Java batteries. Personally I prefer a Lisp that shows real error messages (not Java mumble mumble) and shows Lisp objects and Lisp functions in a debugger. I also prefer to have a nice Cocoa binding over a Swing binding.

Yes, Java-Batteries -- and all the cognitive dissonance that implies.

Well, I'm just going to wait and see how that entire new fangled computing thingy plays out over the coming centuries. If it's any good, it will become part of evolution and our genes will use it eventually ;-)

Feels like a rant. Which doesnt even point out what exactly is wrong and how could have been done right.

Applications are open for YC Summer 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact