Why Lisp Is Unpopular

Unless you're implying that each Lisp interpreter is its own language, I don't think your contention really applies. If I learn Lisp on Lispworks, and go sit down at GNU CLisp, I'm not programming in a different language - I'm using a different sub-set thereof. When I sit down to a Ruby program, and then switch to a PHP script - there are fundamental differences between the two languages that transcend the library or features either provides.

Ralphc's point wasn't about there being a clear winner in the dynamic language space, but that each of the languages mentioned had one canonical interpreter.

Perl, PHP, Python, and Ruby are all interesting failures. They are important for their effect on languages that will last longer (Lisp, ECMAScript) though.

Edit: I don't mean these are "failures" now, just that they're doomed in the long run. Does anyone think they'll be able to stand any of these languages in 2018? I don't they'll have evolved much by that point either. The older a language gets, the harder it is for it to evolve. And if it tries to make too big a leap, people simply don't go for it (PHP5, Perl 6).

Make it: 3 months full time, plus whatever amount of time is needed to become deeply conversant with all the underlying lambda calculus concepts.

"The weedout process has worked its magic again ;P"

Please don't call me a weed.

You point out that the more effort you expend, the better you get. The problem is the rate of reward. Getting a productive lisp environment is hard work. Competing implementations, sometimes-compatible libraries, very little documentation -- these are things that make lisp, holistically, hard to adopt. Every other production language makes it easier to get to the programming. I can't think of a worse-supported production language than lisp.

Also, the benefits you mention are either not that uncommon, or that valuable. The only thing lisp has as a unique feature is it's macro system, thanks to it's syntax. It's the only thing that can't be adapted straight into another language. Otherwise, the features you mentioned are basically available elsewhere; Visual Basic has closures. C++ has multiple inheritance. Python has multimethods. Ruby has class redefinitions.

The thing is, I wanted to believe. I stocked up my library with PCL, SICP, the little schemer, and On Lisp. I learned emacs. I stuggled with asdf. What I found, though, did not seem to live up to the promise of a hidden pearl.

I would take 3 months to learn a new language, but then my startup would be dead.

I picked up Python in a day. I'm quite proficient at it a year later. A simple syntax + a great standard library is the best way to get things done, if not the best way to learn to write software.

m-x slime (starts slime and sbcl) c-x-2 (split window in two; one for coding one for REPL)

..open a file at the top window by pressing c-x-f and typing in hello-world.lisp <enter>

..yay, start coding..

c-c-c to eval forms c-c-k to eval/compile the entire file q to close down "popups" (exceptions .. etc.)

yawn .. what's the problem? .. are somewhat, "limited"?

You can use CUSP (an Eclipse plugin which provides similar functionality to SLIME for EMACS), and the commercial impls have their own (admittedly EMACS-esque) IDEs. There's even a SLIME-derived plugin for vi! It really is worth the effort to learn EMACS, though.

I'm unconvinced that installing lisp libraries is so very horrible; I've had far more trouble with python ones, myself.

Clozure Associates has an open source Common Lisp with an IDE for Mac OS X. We're also working on the documentation. We're specifically working to remove the speed bumps for new Lispers. Check out http://www.clozure.com/clozurecl.html. We plan to have IDEs for other OSes too in the future.

Hi, Ken. Thanks for the reply.

I think what's happening currently in programming is that lisp-isms are filtering through to other languages. What used to be unique lisp-juice is available more generally, so the switch to lisp isn't perhaps as compelling.

Anyway. I'm off to write that metacircular evaluator in c# ;)

It may well be that it only really becomes apparent on larger projects. It's hard to get to that point, though, and maybe that's why the takeup is low.

OTOH, some languages are particularly good on small things, but don't offer much help for large problems.

The best demonstration of that "big system" effect that I've seen, that's easy and small enough to read and comprehend, is the database[1] or unit testing[2] chapters in Practical Common Lisp. They show good examples of using macros and HOFs to completely remove boilerplate code, and that it's simple enough to do it for even simple boilerplate.

[1] http://www.gigamonkeys.com/book/practical-a-simple-database....

[2] http://www.gigamonkeys.com/book/practical-building-a-unit-te...

Metaprogramming capabilities. Most people seem to prefer keyboard macros or cut-n-paste to actually writing language-level macros.

Anyway, Lisp (and many other languages) gives you a lot of tools to make programming more thinking-intensive and less typing-intensive. Since typing is easy and thinking is hard, it follows that many people will prefer the language that makes you type.

JMHO.

Sure. Nobody would ever write a macro to solve a problem.

No wait: on second thought, I surrender to how completely dumbfounded I am by this comment.

I'm calling Kenny...

Or what happens in that subroutine.

Or the performance characteristics of that library.

Or the fencepost cases of a loop.

Or which exceptions to handle.

...

Maybe it's just because I've been using Common Lisp exclusively for a year, but what's so hard about macros? Especially, using them (as opposed to writing them).

You don't have to think about how the macro is written or what it's expanding into when you use it, you just have to know the semantics of the macro. "When I pass such and such, it will produce code that evaluates this in that way". Similar to a function or a language primitive right? If you're writing a for loop in Java, do you have to care how it's implemented in the JVM?!

As for writing macros: you're writing a function that takes an AST and returns an AST to use as replacement. This function will be called at compile-time to change your nice high-level macro call into lower-level code. There are a couple pitfalls (variable capture, multiple evaluation) but they're always the same and you'll learn about them quickly enough that it will become a sixth sense.

Maybe they have. What system are you using?

I'd tend to agree on those who want to replace HTML/CSS/JS with some other abstraction. What I'm suggesting is that they're arbitrarily divided and should be unified under one syntax, which then compiles into the served "bytecode." JSON would probably make the most sense. But, as you suggest, it would take some time to get it right. So I'm sticking to doing it by hand, all divided up, for now. Maybe after our startup launches...

I can't help but think you haven't written a sufficiently complicated client side web application.

CSS is very difficult to replace with an abstraction because it's too quirky. Compiling a high level language down to CSS without human intelligence is so difficult, it's completely impractical.

HTML, on the other hand, is easy to abstract. I'm glad I did it in Weblocks, it saves me an enormous amount of time. ASP.NET uses this strategy (use the DataGrid control for a while, and then try coding without it).

JS is somewhere in the middle.

Glad I looked back at this thread. Thanks for the tip - I will check it out.

Edit: I seem to recall sldb works better with SBCL (which I'm not using). Perhaps that's my problem?

I can explain the antithesis:

1. They fear the unknown; 2. They fear fanatics.

Mac OS is The Unknown to them + Mac users tend to be pretty rabid fanatics = Let's bash them!

I think parens would be less of a problem if the indentation conventions were easier on the eyes. Sometimes you need a ruler to figure out those 1-space indentations.

I think this is a feeble excuse. That is, it's an excuse generated by a lazy mind. The first time I saw Lisp, I was not "primed" to dislike it. It was early in my programming education. I was fresh, as they say. It looked no more cluttered than Pascal, the main language being taught at the time.

Can I write really ugly and hard to visually parse Lisp? Yes. Bad code can be written in any language.

Parenthesis fade into the background with experience (especially if your code is well-formatted), in the same way you start to group things by curly braces in C or Java over time.

No one looks at C code the first time and thinks it's clear to understand.

  (defun test-+ ()
    (let ((*test-name* 'test-+)
          (another-var 'foo))
      (check 
        (= (+ 1 2) 3) 
        (= (+ 1 2 3) 5) 
        (= (+ -1 -3) -4))))

  void test-+()
  {
     *test-name* = test-+;
     another-var = foo;
     assert( 1+2 == 3 );
     assert( 1+2+3 == 5 );
     assert( -1 + -3 == -4 );
  }

The source repository is here:

http://git.jrock.us/?p=Perlisp.git;a=summary

It's pretty useless right now though :) I started rewriting the reader, but didn't like any of the parsing modules on CPAN... so it's sitting at that stage right now. When I get some tuits, I'll probably just port over SBCL's reader, or perhaps emacs'.

Good points. Perhaps the problem is also how lisp is taught? When I learned lisp, the procedural aspects of lisp were shown, but with the understanding that they were bad, and not to be used. Probably because it was shown as a functional language, and was meant to be used as such. Similar to how, say, c++'s functional programming capabilities aren't really taught.

If the indentation is sufficient, why not just remove the parens completely and rely on indentation?

Lisp does have an advantage in being regular, which might not be worth giving up, and Algol descendants are kind of a mishmash, to be fair. To be honest, I'm not enough of a lisp user to be able to know what a good solution is for this one. Maybe changing some function names would be useful.. for example 'add' is better than '+', which I read as 'plus'. Repurposing infix symbols as prefix symbols seems problematic.

If I were redesigning the language, one of the more important things I'd change is the keywords and builtins. For example, head and tail seem a lot better to me than car and cdr. A lot of lisp's keywords and functions come from math, and I'd probably change them to reflect mainstream algorithm design instead.

Ok, I think I get you. But then I think you can't categorize programming languages this way, the default data-structures provided by the language don't characterize it. In fact, it seems to me that you like most JavaScript because it's object oriented, it's dynamic typing and functions are first-class. Features that others languages lack, and not because the "dominant metaphor" is the hash. Casually in JavaScript the objects are built with hashes (at least apparently), and can be easily extended.

It's a fun thread :D

> But, what I mean is the "dominant metaphor," which I suspect is still lists.

That tells us more about the basis for your suspicions than it does about lisp.

It's okay to like javascript more than you like lisp. It's also okay to be mostly ignorant of lisp. However, it's poor form to make up things to "support" those positions.

sets of related closures over common state?

I will second the suggestion of Lua. Here's my raw beginner's introduction to Lua tables:

The basic structure is the hashtable. You can use any first-class value as a key (number, string, function, another table) and similarly any first-class value as a value. Creating a table is done with the table constructor "{ }" ('> ' is the repl prompt):

  > a = { }

So now we have an empty table named 'a'. Let's say we wanted to have a table containing a list of colors - this is represented in Lua as a table with ascending integers as the keys. (Starting at 1, rather than 0, which is a bit unconventional)

  > a = { 'red', 'green', 'blue' }

This is equivalent to saying

  > a = { [1] = 'red', [2] = 'green', [3] = 'blue' }

If we use strings as keys, we start seeing some of the syntactical sugar Lua offers. Let's look at favorite foods:

  faves = { bob = 'pizza', george = 'cake', mary = 'pie' }

Note that no quotation marks are needed around string keys. (Well, unless the key is a language keyword. That's a bit annoying, but is related to the single-pass compilation, which is valuable. { if = 'can't do it' } fails. { ["if"] = "can do it" } succeeds.)

We can use numeric indices along with string ones in the same table:

  mixed = { 'a', 'b', 'c'; state = 'NC', city = 'Charlotte', county = 'Mecklenburg' }

If we want to access values from a table, we can use a subscript notation.

  > print(a[1])
  red
  > print(faves['bob'])
  pizza

Here's a winner though. If we want to subscript a string, we just use the dot notation.

  > print(faves.mary)
  pie

What happens if we subscript a nonexistent entry in a table?

  > print(faves.james)
  nil

No error is thrown, which is handy. Tables are defined as having the unique value nil as the value for all nonexisting keys. In fact, if you wanted to remove an entry from the table, you just set the key to nil:

  faves.george = nil -- the cake is a lie! And the key 'george' is removed.

One nice thing about Lua tables is that they are extremely regular. There aren't special cases in their behavior. They're easy to construct, inspect, and manipulate. They are the fundamental data type of the language, and everything is done in terms of tables. Objects are created out of tables. Namespaces are tables. Modules are tables. Configuration files are tables. It's an extremely clean and convenient design.

In addition to the tables, you get first-class functions:

  > function a() print 'hello' end
  > a()
  hello

Is syntax sugar for:

  > a = function() print 'hello' end
  > a()
  hello

These syntax sweeteners we've seen work together, too:

  > function a.foo() print 'world' end
  > print(a["foo"])
  function: 0x807f2e8
  > a.foo()
  world

Ok, we're almost to objects. The next sugar we see is the ':' notation.

  > a = { color = blue }
  > function a:fave_color()
  >   print('My favorite color is ' .. self.color) -- .. is concatenation
  > end

If a function is defined with the ':' notation then it has an implicit local value called 'self' which is set to the containing table.

  > a:fave_color()
  My favorite color is blue

At this point it's pretty easy to create simple prototype-based objects.

What brings even more power to the table is that we can define custom behavior on each one. We can set a 'metatable' which defines how the table responds to subscripting, the various mathematical operators, and being called in the functional position. In a quick script I worked on I implemented a prototype-based class system in under 20 lines of code, all with the power of metatables. Lua tables are very powerful and though similar to the ones in Javascript are even cleaner and m...

> was only talking about the code itself, the primary metaphor of the programming language, not what the language actually represents. Most langs that I've encountered are structured as semi-formalized strings (i.e. C-derived langs), where as Lisp is structured in "physical" lists.

Huh? Let's review.

>>>If that's true, it follows list-oriented languages are inherently inferior to their hashtable-oriented brethren.

Javascript code is semi-formalized strings or ASTs.

The careful reader has noticed that lists that represent code are ASTs with context-dependent field names. Since the nodes provide the context, said dependence isn't a big deal.

I don't know how many javascript programs manipulate their ASTs. (Lisp programs with macros are manipulating their ASTs.) The vast majority of javascript hash table operations are on data. (Yes, lisp code can be data, but not all lisp data is code.) In that, they're no different than any other language that has decent hash tables, such as lisp.

All the programmers I know who wrote lisp in the 80s, now own software companies or are in management. That may explain some of it.

The problem with the AI winter argument is that it's half an answer that satisfies you enough to stop asking questions. If you invoke the collapse of commercial AI to explain Lisp's current state of disfavor, you then have to explain why the collapse of the dotcom bubble didn't have a similar effect on Perl or Java.

Anthropomorphically, you could say that Perl retreated to its base of support among sysadmins, (Common) Lisp took shelter in big-think research organizations, and Java reinvented itself as New Cobol.

But that doesn't really satisfy either, because it doesn't tell us why nobody tried to similarly re-purpose Lisp. That's especially odd, in fact, because now Everybody Knows that a lisp core is really simple, and Lisp was still on the radar in academia, where people can be rewarded for re-implementing old ideas.

The problem with the AI winter argument is that it's half an answer that satisfies you enough to stop asking questions. If you invoke the collapse of commercial AI to explain Lisp's current state of disfavor, you then have to explain why the collapse of the dotcom bubble didn't have a similar effect on Perl or Java.

Anthropomorphically, you could say that Perl retreated to its base of support among sysadmins, (Common) Lisp took shelter in big-think research organizations, and Java reinvented itself as New Cobol.

But that doesn't really satisfy either, because it doesn't tell us why nobody tried to similarly re-purpose Lisp when DARPA et al lost funding. That's especially odd since Everybody Knows that a lisp core is really simple, and Lisp was still on the radar in academia, where people (called grad students) can be rewarded for re-implementing old ideas.

I think there is a pretty good explanation (with evidence, even!), but it's not a satisfying one in this community: the end of the Cold War caused a major reallocation of scarce resources away from expensive one-off projects for the government, and towards mass-market stuff for consumers and businesses (see below), and Lisp suffered from some initial disadvantages in the new environment:

* Limited availability on PC platforms

* Windows Apps were sexier. The internet was sexier.

* Glut of new CS students while the bubble was inflating were mostly taught in Java. (Many of them are sensitive about arguments that lend further support to the idea that their education has turned out to be less valuable than they thought at the time. That may just be my bias showing, though. I think that Math should be relabeled CS, and that "programming" is for autodidacts and trade-schoolers).

* CS is a new field, and industry tends to dumb down research in new fields for a generation or so after disruptive technical innovations. That way, they get enough of the low hanging fruit that it further disruptive innovation is unlikely and their capital is safer. See below, particularly the chapter on the relationship between GE and MIT before WWII.

Social arguments are hard to make here though, because so many people are so hooked on the "weird and scary and only for elitist pricks" narrative. That's kind of ironic, because high level corporate executives, if they heard the current public stand on lisp -- "it may be really productive, but it's too foreign for most people and I don't feel like learning it" -- could probably force adoption from above, especially now that cost-cutting is the order of the day.

http://www.amazon.com/Leonardo-Internet-Technology-Culture-R...