A Personal Lisp Crisis

Over the past 7 months or so, in addition to learning and using Common Lisp, I have been giving thought to the social issues affecting Common Lisp and its community. Over the past two months, I have been working on two projects, described below, to try to address the issues that most affect newcomers.

To gain perspective on the causes and social context surrounding these issues, I have been studying Common Lisp's history, reading (among other things) the historical accounts of Richard Gabriel, Guy Steele, Kent Pitman, and others. (I can recommend, for example, The Evolution of Lisp, A Pattern of Language Evolution, A Critique of Common Lisp, Common Lisp: The Untold Story, and of course Lisp: Good News, Bad News, How to Win Big.) I have also been reading Common Lisp the Language, 2nd Edition and the Common Lisp HyperSpec, scrutinizing every inch of the language itself.

My research has given me a broader and more informed perspective than I had before. Before, I could see that the social climate surrounding CL was slowing its adoption rate and holding back progress, but I assumed its roots were healthy and strong. But now, it seems that CL is subsisting mainly on a fleeting aura of mystique, while other languages are surpassing it both technically and socially. That situation is untenable. Unless something changes, I don't see how CL can have much of a future, except as an amusing curio for fans of antique computer technology.

If that was the only thing I had realized, it would have just strengthened my resolve to address the issues head-on. But, I also realized than CL is not the culmination of Lisp's evolution, it is merely one box in a vast flowchart. It is a long-lived and popular dialect, and its creation was a significant milestone in Lisp history, but aside from historical interest CL is not an especially remarkable Lisp. It is a middle-of-the-road dialect, just as you would expect from something designed to be a compromise among numerous competing dialects.

CL is a fairly solid practical language, but it could have been much better. Inter-dialect politics, and the need to appease established interest groups, prevented the language from reaching its potential when it was created. Similar attitudes have prevented the core language from being cleaned up in the past 20 years, and likely will continue to do so indefinitely. There has been some activity building improved languages on top of CL, but there are better languages (particularly Scheme) to be foundations for that.

These realizations prompted a crisis for me. A month ago, I was ready and willing to dedicate myself to building a place for CL among a new generation of programmers. But now I'm not so sure. On the one hand, I have invested a lot of time into CL already, and it's not a bad language, just not very exciting or inspiring. I could learn to live with it, and even smooth out most of its warts. On the other hand, there are certain attitudes that I find extremely demotivating and frustrating, and those attitudes seem to be more prevalent in the CL community than in many other languages' communities.

To put it simply, the CL language and community both fall far below their potentials. It might be possible to shift the culture in a more positive direction, but that would require a sustained effort by many people, and would probably involve frequent stressful confrontrations with the “worst offenders” in the community. There are decades of inertia and ingrained attitudes that would not be easily changed.

The reward for all that effort would merely be preserving a lackluster language, a “fixer-upper” that would require further effort to turn it into something really worth using. And even if the core language were changed, CL would lose its mystique and become “just another Lisp”, unable to use longevity or historical significance as a crutch. It would have to compete with other languages solely on its actual merits, which nowadays are not as strong as CL proponents like to believe.

I enjoy a good challenge, but this seems more like a fool's errand. There are other languages with healthier communities, more momentum, cleaner cores, and features on par with CL. So I have to ask myself, why bother with CL?

I would love to discover some factor I have overlooked, some redeeming quality that would make CL worth fighting for. But the harder I look, the less likely that seems.

The Next Generation of Common Lispers?

There are numerous issues affecting CL, but one that I thought I might be able to make an impact on was its low adoption rate. CL has a smaller user base than many other languages, as well as a smaller influx of new users, and (I suspect) a lower retention rate among those new users. This issue has many underlying causes, most of them social. There are a few technical issues, but they would be easily solved if the social issues did not prevent it.

(Some CL proponents insist that a low adoption rate is not a problem. The usual argument is that it is better to have a small number of highly skilled and intelligent users than a large number of mediocre users. But that is a false dichotomy, a cop-out to avoid actually addressing the problem. And even if it were logically valid, it is based on the assumption that CL is attracting and retaining users based on skill and intelligence. I would argue that the social climate surrounding CL merely favors people with certain personality traits, regardless of skill or intelligence.)

Many people in the CL community have long had an attitude of, “We do not need to make an effort to attract the next generation of programmers, or to make things easier for them. CL is so amazing that the best programmers will naturally seek it out and devote themselves to learning and using it.” That attitude may have been justified at some point in the past, but it is certainly not anymore.

These days, there are numerous languages whose technical merits are on par with CL, and many of them have more positive social climates, more forward-looking attitudes, and more effective ways of welcoming, supporting, and educating new users. CL is barely competitive from a technical standpoint, and significantly outclassed from a social standpoint.

Aside from a few unusual features, the only significant attraction CL seems to have left is the exaggerated mystique created by the writings of Paul Graham and other vocal Lisp advocates. Even that won't draw new programmers to CL for much longer, especially with languages like Clojure and Racket offering the “Lisp Experience” with more useful and relevant built-in features, better community management, and more momentum.

“Handling Newbies Effectively”

The first project I planned to release was a paper highlighting and analyzing the various social issues affecting CL newbies, and offering practical advice for addressing those issues. These issues include not only the apathy (and occasionally outright hostility) that many oldbies show toward newbies, but also the inadequate social framework the community has in place for welcoming, orienting, supporting, and educating newbies.

For example, CL has no central location where newbies can find reliable information, documentation, or other learning resources. Instead, information is scattered across the web, with no way for newbies to know if it is up to date and reliable. (I'm sure many CL proponents are now itching to “correct my ignorance” and explain that CL is just a language standard with many different implementations, which is why there is no central website. Well, guess what? Newbies don't know or care about that. They want reliable and helpful information, not excuses for why the community is so disorganized.)

There are also not many good places for CL newbies to get support from other Lispers. The only well-established venue I know of that caters to newbies is LispForum.com, and it does not seem to get much promotion or attention from the broader community. So instead of newbies finding someplace where they are welcome, they usually end up someplace where they are barely tolerated, such as the #lisp IRC channel or comp.lang.lisp newsgroup. Those are probably the two least hospitable places for newbies, yet they are the two most popular and widely promoted venues, so many newbies end up there anyway (much to the vexation of some oldbies). Granted, #lisp and comp.lang.lisp can be great if you need answers to specific technical questions, but they are really lousy if you need orientation, advice, encouragement, or other forms of “hand holding”.

I have also observed many negative social attitudes which, while certainly not universal among CL programmers (and not unique to the CL community), are prevalent enough that they affect the entire community, and make the social climate less hospitable to newbies. A few of the most common and most harmful attitudes are defensiveness, nitpicking, zealotry, arrogance, lack of empathy, and social dominance based on a narrow set of values. Social dominance is an especially significant factor, because it means that the “alphas” in the community cannot be censured for bad behavior, unless those behaviors are truly egregious. (For example, if an alpha were to provide a newbie with “sample code” that would in fact delete all files on the newbie's computer, the worst reprimand the alpha can expect is a few people saying, “Tsk tsk, you know you shouldn't do that”. But just as many people would consider it an amusing prank, albeit cliché. They might even congratulate the alpha on teaching the newbie a lesson, thereby negating any reprimand the alpha received.)

The paper I've been working on goes into much greater detail, and gives more examples of challenges newbies face. But, I have started to doubt that publishing it would help the CL community at all. Many of the most serious social issues that affect the CL community are older than CL itself. Many people over the years have pointed them out, yet the same issues remain. So what good would it do to point them out again? The people whose attitudes and behaviors are most harmful, are the least likely to listen. The people who would listen, have probably heard it before. Why bother?

Yet, it's obvious that the situation cannot possibly improve if no one speaks out. Sweeping things under the rug doesn't make them go away. As uncomfortable as it may be, the only hope for addressing the issues is to start discussing them openly. Indeed, perhaps the most important social issue affecting the CL community is widespread complacency and apathy, which prevent the other issues from being addressed.

I will probably publish my paper eventually, because the same issues affect many tech-oriented communities to some degree. The CL community may be too far gone, but my paper might do some good elsewhere.


The other project I have been working on is CLUEL, the Common Lisp Usability Enhancement Layer. Whereas my paper would highlight the social issues and challenges newbies face while learning Common Lisp, CLUEL would directly tackle the problems that make the language itself unnecessarily difficult to learn and use.

About two months ago, I described some of the historical baggage that makes CL harder to learn, and adds to the mental burden on all CL programmers without adding any real value to the language. Since that time, I have spent over 100 hours poring over the CL language (not including the time spent researching CL's history, writing about social issues, or planning CLUEL's project infrastructure). I have personally looked up the documentation for every one of the 987 symbols in CL. I certainly can't remember every detail, but I can truthfully say that I have some knowledge of the purpose of every single function, macro, special operator, global variable, and constant in standard CL.

In the same way that researching Lisp history has given me a better understanding of CL's origins, scrutinizing the language itself has given me a better understanding of how inconsistent and crufty it is. Depending on how forgiving you feel, there are between a few dozen and a few hundred examples of features whose names are inconsistent, obscure, misleading, or otherwise poorly chosen. There are numerous features that are redundant, obsolete, or rarely needed, yet they are given the same prominence as the most essential parts of the language, because everything is lumped together in a single package.

Frankly, CL is just not a well designed language. That fact is not a reflection of the people involved, who as individuals were quite intelligent and capable. It merely reflects the process used to design the language. Considering that CL was debated in committee for 10 years, with numerous competing interest groups each tugging in a different direction, I'm impressed that it didn't turn out even worse than it did. (I'm even more impressed that the whole standardization process didn't fall apart entirely. Although I sometimes wonder if that might have been preferable in the long run.) However, there is a big difference between a language being “not bad, given the circumstances” and it being “well designed”.

The most obvious solution to the problem of it not being well designed, would be to revise the language standard to make it better. But that would be a futile and misguided effort. Even if you could get enough people in the CL community to agree that revising the standard was worthwhile, there would be just as much debating, bickering, and nitpicking as there was during the original standardization process. A committee is just not a good mechanism for designing a coherent language (or much of anything else, for that matter).

A better approach, more practical and more likely to yield real improvements, would be to create a new package (or multiple packages) that can be used as a test bed for experimenting with the language. It's easy to start, you don't have to create widespread consensus, and it doesn't disrupt anyone who doesn't want to use your package. This approach has been recommended by quite a few knowledgeable people, including Peter Seibel at ILC 2010 (near the end of his talk). This also harkens back to the tradition of prototyping new dialects on top of existing dialects (although I do not consider CLUEL to be a new dialect).

That approach is exactly what I had planned for CLUEL. The process I used for creating the proof of concept was something like this, although with lots of jumping back and forth between steps:

  1. Partition all standard CL symbols into packages based on a theme or concept. At last count, I had tentatively settled on 22 packages: core, general, types, cons, sequence, array, string, stream, file, read, write, symbol, package, clos, structure, hash-table, math, bitwise, condition, debug, host, and time. Some symbols belong to more than one package.
  2. For each package, partition the symbols into layers based on how useful they are:

    • Symbols that are “often useful” stay in the main packages, which are available by default when using CLUEL.
    • Symbols that are “sometimes useful” are moved to the extra packages, which can be included when needed.
    • Symbols that are “rarely useful” are omitted from CLUEL entirely, but could still be accessed via the standard CL package if desired.
  3. For each symbol in CLUEL, decide whether its name is sufficiently meaningful, memorable, and consistent with the rest of the language. If it is not, give it a new, better name. (I developed a way to easily create aliases for existing functions, macros, special operators, global variables, and constants.)

    This involved a lot of jumping back and forth, because renaming one symbol might affect the consistency of other symbols. Or, I might discover some pattern or naming convention that affects symbols I had already processed, so I would have to go back and rename them.

    This step also involved a lot of consulting the documentation to make sure I understood exactly what an operator did. That led to a few surprises. For example, I didn't realize that ldiff and tailp are so closely related. Indeed, their names suggest that they are entirely unrelated, which is a sign that they are poor names (or at least, ldiff is). Those functions were likely invented independently, and they make sense individually, but when you put them together their names (and argument orders) are inconsistent.

  4. Define a handful of new functions and macros to improve consistency, “fill in the gaps”, or improve usability in other ways. For example, there is no non-destructive sort function in standard CL, so I added a simple one. It may seem counterintuitive, but adding a new function in cases like this can reduce the cognitive load for users, because it makes the rules and patterns more consistent, with fewer exceptions to learn and remember.

    Another way to improve consistency and reduce cognitive load is to consolidate many similar functions into one generic function. For the proof of concept, I experimented with this for accessing containers (consolidating nth, elt, aref, svref, char, schar, and gethash) and counting their contents (consolidating length, array-total-size, and hash-table-count).

If that process seems to involve many subjective judgement calls, that's because it did. But this was merely the proof of concept, to demonstrate that this sort of endeavor is feasible. In the long run, the initial design of CLUEL is irrelevant, because it was intended to be changed soon, with the involvement of more people. The more important aspects of CLUEL, its cultural values, emerged as I was planning the project and working on the proof of concept:

It's important to point out that CLUEL was not designed to be a new dialect, or to ever exist separate from standard CL. Like it says in the name, CLUEL was a “usability enhancement layer”, a more usable and well-designed language interface for writing Common Lisp software. CLUEL would not add any new semantics or functionality to CL, just present (a subset of) the existing functionality in a better way.

A key feature of CLUEL was that code written in CLUEL would be fully compatible with code written in standard CL. So, for example, an application written in CLUEL could use libraries written in standard CL, and vice versa. (Unfortunately, that makes it impractical to address certain fundamental issues, such as the messy semantics of nil.)

I really poured myself into CLUEL. I estimate that over the past 2 months, I've spent over 100 hours studying the CL language and considering how to make it more usable, another 100 hours researching Lisp history and other dialects to see what has been tried before, 60 hours planning project organization and policies, and 20 hours developing infrastructure for packages, aliases, etc.

Indeed, the code for the first iteration of CLUEL, the proof of concept, is about 80% done, and the project planning is about 60% done. But I don't plan on finishing it, or even releasing the in-progress code. It hurts to throw something away after spending so much time and effort on it, but at this point that seems to be the best course of action.

Why? Because CL doesn't seem worth it anymore. I certainly don't want to potentially spend a few years maintaining CLUEL and building up its community, shackling myself to a language I don't really care about. Worse, I suspect that even handing off CLUEL for someone else to run it would be a mistake, because it might prolong CL's decline, and delay a better Lisp dialect with a healthier community from rising to prominence.

I'm not sure what dialect that might be, but the two main contenders, Scheme and Clojure, are both promising. They both have cleaner core languages, more momentum, and (from my initial impressions, at least) healthier communities than CL. I don't know yet how prevalent the negative attitudes I've observed in the CL community are in the Scheme and Clojure communities, but at least they do not seem to be so inhospitable to newbies, which is a good sign.

(I have heard some CL proponents insist that Scheme and Clojure are not really Lisp dialects, or at least are not as Lispy as CL. I've even given that impression myself on at least one occasion. But that is just ideology, with no grounding in reality. There have been many different Lisp dialects over the past 60 years, on many different architectures, with many different features and syntaxes. There is no rational basis for claiming that CL is a more “true”, “pure”, or “faithful” Lisp dialect than Scheme or Clojure.)

I don't currently have any plans to create something like CLUEL for Scheme or Clojure, for the simple reason that they don't seem to need it. Both languages are much more well-designed, consistent, and usable than CL is. But they are certainly flexible enough to implement a similar “usability enhancement layer”, should I happen to discover that implementing one would be beneficial.

What Now?

Despite my concerns about Common Lisp, I haven't completely ruled it out as a language choice for Ambienome or future projects. I'm keeping my mind open to the possibility that CL has some redeeming characteristic or feature that makes it worth using, maybe even worth fighting to preserve.

Lately, I have been investigating other languages, including Clojure, Racket (a R6 Scheme implemention), and Chicken (a R5 Scheme implementation). Clojure is quite interesting, and there are a lot of cool things being created with it, but I'm concerned the emphasis on functional programming and immutable data structures might make an already ambitious game project even more challenging. Racket is very polished and featureful, with great documentation, but it is licensed under the LGPL. Ambienome would be a commercial game, and although the LGPL probably wouldn't be a problem, there are certain ambiguities that make me hesitate to use it. Chicken is not as polished or featureful as Racket, but the community is quite friendly and welcoming, and its close integration with C might make it easier to use various game libraries or interface with the OS.

I am also considering non-Lisp languages, like CoffeeScript with Three.js (to make a browser game), or even going back to Ruby (perhaps JRuby with LWJGL). If possible, though, I'd like to keep using some Lisp dialect, because I have found Lisp to be conceptually powerful and enlightening.

Maybe, just maybe, I will start to miss something from Common Lisp, something that cannot be easily recreated in those other languages. But even if I don't end up using CL, I don't regret learning it. The experience has been very educational.


Interesting entry, John.

I'm a recent immigrant to Common Lisp country, too, although I'm still living out of a suitcase at the moment, and clearly haven't taken a good walk around yet, as you have done; I'm still half-way or so through Seibel's PCL (having started with The Little Schemer).

I've had my moments of doubt, from time to time, too, in some of the naming inconsistencies and functional overlap. It feels like a compromise in some cases. But really - does it actually matter that there are a couple of ways of similar ways of doing the same thing, particularly when SLIME gives me the facilities I need to sort out what I need and how to use them? At some point, I'm going to gravitate to either "tailp" or "ldiff", and will use that one. Does it harm me that the other is there? It doesn't seem so.

Perhaps it is my keen interest in macros for building functionality in my own unusual domain that Common Lisp strikes me as probably the best tool I'm going to find. You must see some real value in CL, too, if you're willing to invest the time you're talking about into CLUEL. If you didn't believe CL to be a strong choice, why would you commit to improving it?

Keep up your writing - I'm enjoying hearing about your journey.

Ooops. Reading your entry on and off throughout the day yesterday, I seem to have somehow missed the fact that you were abandoning your CLUEL efforts, too.

I'll reiterate my point - I don't really see it as all that significant that that there is some inconsistency and overlap in the language. It's not ideal, but I don't really see how it's an impediment. Effectively, a book like Peter Seibel's PCL *is* a form of CLUEL - a tour of the main features, pointers to what you need most, brief mention of stuff that's less important. Its practical chapters give you insight into how to actually use the material to solve realistic problems, so the most immediately useful subset of the language is naturally enforced. The other parts? You can ignore them until you need them, if ever.

First, let me say that I agree with regarding the cruft of CL and the negative attitudes in the community (though I'd like to think that we're not all bad). Scheme is a cleaner language, the racket community is quite friendly, clojure is quite innovative and gaining traction, yes.

What keeps me using CL is that there are a number of very high-quality free implementations (I mainly use SBCL and CCL) that execute CL code at near C speeds, integrate beautifully with SLIME, &c., plus a body of well written libraries, most of which are available via quicklisp. When I consider racket, I know that I'll miss the performance of SBCL; with clojure, I have to deal with the JVM (slow startup, difficulty integrating my other code in C/asm).

Most experienced lispers deal with the warts of CL by building a library of functions and macros that wraps the underlying language in a layer of personalization. I really like the idea of CLUEL as a pre-made "starter kit" (somewhat like the emacs starter kit) that gives new users a well thought out layer of the type a more experienced user would build over the first few years of using the language. It would be a real shame for you to give up on it!

In any case, I wish you the best whatever you end up doing.

I can't blame you for leaving the CL community. I myself am attached by my job and by mental inertia, as well as by the relative performance of SBCL.

However, there are many people who are making the CL community better. Xach is one of them, with quicklisp. As for cleaning up the language, I believe it is better to provide and document new APIs such as LIL and make them 100% solutions than to vainly try to organize existing APIs.

Chicken is a nice choice, but I believe you are short-selling Racket by rejecting it on license grounds. Many people do proprietary software on top of Racket. Please pick a better reason to reject Racket (or not).

A quick web search will show you lots of people experiencing real issues with the LGPL. It might work for most cases, but then suddenly you're stuck.

There are plenty of thriving MIT and BSD licensed languages and platforms out there, you don't need to force a community's hand for contributions.

Perhaps the Racket crew should reconsider their license choice instead?

You mentioned Clojure, Racket, Chicken, et al., any thoughts on Guile (Scheme) or Lua, both designed from the ground up to embed into C?


I believe I'm one of the few "new" generation of lispers. I started programming with SICP in 2008 and CL was, for most intents and purposes, my first serious language. I recognize that the community has problems though I've felt things are improving along that front the last few years. There is still stagnation here and there and forums that are less than friendly, to be sure. Still I've been optimistic so I'm saddened to hear of your experience.

I, like Jack, keep using CL because SBCL/CCL+SLIME+Quicklisp is just too good a combination to beat....so far. It would be nice if OO wasn't added late in the standardization process. It would be nice if various parts of the language were more consistent. It needs to be the case that people feel supported in trying to use the language. But the way to beat a few jerks with negative attitudes isn't to leave. It's to consistently be helpful and respectful and stick around. Whether I keep using CL or not, I intend to abide by my own code of conduct. If you find yourself hacking CL again, I'll be happy to lend an ear. :)

Happy Hacking,

So why throw away all progress on CLUEL and not let others continue where you left off? I think it would benefit people, including me, to see some other ideas how to improve the standard library and then e.g. make some CDRs out of it.

IMHO, there are already a whole lot of libraries to fill the gaps and/or iron out issues, some of which are recommended by concensus, so for me (who started with CL ~2006) the historic baggage isn't that much of an issue (more like, "huh, that's why it is this way"). In fact, CL was/is the more pragmatic choice for me after starting off with Scheme (which was probably hampered by choice of implementation) where everything seemed to be in its own little package and it didn't feel very cohesive.

Have you read LetOverLambda? Cleared up many things for me. I am working with clojure recently, and I would give a month's payment to work with ABCL instead.

There are a lot of claims here and not much if anything concrete. The Lisp and especially CL macro system and CLOS are not even mentioned. You would think any serious language shakedown by someone that knows CL would at least say something about them.

I can't argue that some of the standard symbols in lisp form an inconsistent set of tools and naming conventions. That is certainly true. Cleaning that up is a good thing.

Wait, you don't care about the language yet you claim to understand it well enough to make it so much better? This seems an odd combination to me.

Scheme today is not as powerful as CL. This includes Racket. Racket feels too insular to me.

Still in love with CL as a language, after 3ish years. I even like the little idiosyncrasies I come across. But I don't have to write in it for a living, or support a significant CL project that people depend on. Good luck!


I feel for you and all the work you have done trying to salvage CL. I am an ex-Common Lisp user. From there I went on to Scheme, but was hindered by the lack of a good interface to other languages, especially Java. I've been tinkering with Clojure since 2010, but I found many in the Clojure community hostile to newcomer (I don't like the word "newbie") concerns and to criticism of their attitude. There's also what I call an "expert's mentality" at work, constantly making the language more powerful (and arcane), while totally ignoring the need to improve the first-time-user experience of Clojure. Clojure has great promise, but without outreach to casual users, I fear it'll never become more than a niche language used by a handful of very bright programmers.

As for my work, I created a beginner's site, http://gettingclojure.wikidot.com/ . I didn't promote it much, but *no one* in the Google Clojure group showed any interest in it.

That said, the Light Table project is way cool. For the first time in almost four years, I'm doing more programming in Clojure than I am fighting the tools for getting code to execute.

Great post! I love CL and really hope that it remains a living part of our history, but Clojure beats it on so many counts that it is hard for me personally to find a reason to continue writing programs in CL any more. (And it should; the designer of Clojure was an old CL programmer who learned from the things which CL got wrong.) 2 things I really miss are multiple return values and the condition-handling system. The other day I was reading some old CL code I once wrote and felt a wave of nostalgia sweep over me...

I got a degree in mechanical engineering so I skipped over all that functional stuff I might have learned in college,... until recently playing around with Clojure. Seems like the best chance for imperative coders to jump ship. See you on #clojure @ chat.freenode.net. The community seems great.

I went through a similar process and ended up building a toy lisp dialect first in CL and then getting frustrated, going through the five stages of grief, and rebuilding it in straight C. It's called, oddly enough, wart. (A longer rationale.)

For example, CL has no central location where newbies can find reliable information, documentation, or other learning resources. Instead, information is scattered across the web, with no way for newbies to know if it is up to date and reliable.

This particular department is something that virtually every language will fail. For example, where's the centralized place where I can find everything I need to know about C++? Yet for all the complaints about C++ (it's too complex, it's changing so half the tutorials on the web are wrong, some popular compilers are bad at following the standard, etc.), nobody ever seems to complain that there's no centralized place with everything you'll ever need to know about C++.

I think this is a slight misidentification of the problem. I think the real problem is that CL doesn't have a BDFL. In the case of languages like Python, it's one person. In the case of languages like C#, it's a company. The "central location" doesn't need to be a location. Clojure is doing better than CL or Scheme because it has a BDFL.

As you note, CL hasn't been updated in decades. That's the sort of thing that can't happen if you have a BDFL, because a BDFL can just say "Hey, I'm improving this, deal with it".

That's why I think something like "CLUEL" would be great. That's the only way a language makes progress: a person decides to make it better. I wouldn't worry about delaying the inevitable death of CL. If other languages can't stand up to "CL with a better naming system", they don't deserve to survive. And while CL has its share of cruft, it also has many tremendously useful features that haven't made their way to other modern languages yet, so it'd be a shame to lose that thread of evolution entirely.

Comments are closed.

Previous post: Ambienome Brain Dump Next post: Atomic Spin Roundup