7 ms·

How to make Lisp popular (or as popular as Lisp will ever get): 1) SBCL working very well on the big three PC platforms. 2) Bindings + easy installation for po

by pTymN 19y ago

How to make Lisp popular (or as popular as Lisp will ever get): 1) SBCL working very well on the big three PC platforms. 2) Bindings + easy installation for popular libraries. 3) Education (pg's articles, everything on planet.lisp.org) 4) Solid debugging, perhaps with things like breakpoints. There is much activity on all 4 problem items that I identified above, so Lisp IS getting more popular. I don't know if programming.reddit.com can be a scientific gauge of how popular Lisp is, but it seems to be mentioned increasingly often. Of all the problems Lisp has, parens are much less than the problem that it takes a gigantic effort to use Lisp with any popular libraries, once you step outside of the way that the larger community is using it.

jrockway 19y ago
I think the problem Lisp has is that very few people are forced to use it. If you look at the average programmer, he doesn't want to think about programming, he just wants to press keys an go home. So a language that requires you to think instead of type is not something that he is going to flock to. I think the sad reality is that most programmers aren't very smart, so smart languages will never become popular. I'm not sure why it matters though, there are plenty of CL libraries (and jobs), so if you like lisp you can get by just fine.
- gordianknot 19y ago
  What makes Lisp a "smart" language?
  - jrockway 19y ago
    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.
    - shiranaihito 19y ago
      Good point!
    - Zak 19y ago
      I suspect there's a good bit of truth in your statement. I feel compelled to point out that it's incredibly short-sighted of programmers to think that way. Programmers spend a lot more time reading code than writing it, and it's hard to read code that doesn't use the right abstractions.
      - euccastro 19y ago
        There's the problem of how you define readability. Many people evaluate it in a per line basis, rather than comparing pieces of code that achieve equivalent functionality. Measuring readability like this is unfair to languages that favor terseness beyond that of natural language. In order to understand good Lisp code you need to learn new tools for expressing procedural concepts. Tools that are better, for that task, than natural language. Most people would think there is no such thing. Most people will always stick to whatever feels more intuitive at each stage of their formation as programmers. This is often a handicap to learning to think in more powerful ways.
- allenbrunson 19y ago
  while this might be true, i think focusing on this stuff is wasted time. i'm not a lisp programmer, but from reading about it here at hacker news, i'm pretty sure that the lisp community would only be hurting itself by taking the average blub programmer into account.
- stevecooperorg 19y ago
  "If you look at the average programmer, he doesn't want to think about programming" This is nonsense. You can't just 'press keys and go home' and make working software. Most of the programmers I've worked with thought a great deal about programming.
- emfle 19y ago
  I think most people prefer languages that let them think about the problem they are trying to solve, rather than think about what the macros expand to, or what happens when they call that continuation.
  - gruseom 19y ago
    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...
    - emfle 19y ago
      The point is that "requires you to think" is not a feature, it is a bug, because that thinking could be put to better use on whatever it is the program is trying to solve. Everything else being equal, this means that language features that can be used without much thinking will do better than language features that can't.
      - gruseom 19y ago
        So programmers who work with objects and methods don't have to think about them, while programmers who work with macros do? Sorry, but this just seems ludicrous to me. Perhaps what you mean is that when a construct is unfamiliar to a programmer then they have to think harder about how to use it? http://www.google.com/search?q=blub http://www.google.com/search?q=blub
        emfle 19y ago
        I am saying that working with objects and methods requires less high-level cognitive processing than macros and continuations, not that you don't have to think about them. This is because the brain can treat the objects largely as if they were physical objects. With macros that is much harder. No, I don't mean unfamiliar. Things like parentheses and prefix notation are unfamiliar to many people, but once learned, they don't require much more cognitive processing than other notation. There are several things in Java that are similarly weird until you learn them.
gordianknot 19y ago
Noise != usage. Don't confuse attention with popularity. I think about the language and post comments about it on forums and read great Lisp code (e.g. Arc), but I'd never actually use it for anything non-trivial. Why? Because I write web apps and existing Lisps don't make that easier or more fun. The only (!) thing Lisp has to do is efficiently and absolutely abstract away XML, CSS, and JavaScript. No Lisp is going to get any uptake otherwise. We could do this with Arc.
- gruseom 19y ago
  I'm interested in why you think that Lisp systems haven't yet efficiently abstracted away from HTML/CSS/JS. I work on such a system every day and the abstractions seem pretty efficient to me.
  - gordianknot 19y ago
    Maybe they have. What system are you using?
    - gruseom 19y ago
      I use Parenscript and LML2. There are a profusion of such libraries (although for CSS I wrote my own simple thing). I'm very happy with the abstractions I'm able to layer on top of them with macros. One thing it took me a while to realize about the Lisp world is why there tends not to be standard frameworks or libraries for some of this stuff. The answer is that, for certain kinds of problems (basically, anything involving metaprogramming), it's actually easier to solve your problem yourself than to learn someone else's framework and then use it to solve your problem. A good example would be unit testing... there are probably a dozen unit testing frameworks, none standard, none much used. The reason is that the frameworks don't add much value over what a programmer can easily do for himself, with all the advantages that implies. I think this may also be why web app frameworks are less prominent in the Lisp world. This is not the case with all libraries, of course. CL-PPCRE adds huge value, to pick an obvious example, but not in the class of problem I'm talking about.
gruseom 19y ago
Solid debugging, perhaps with things like breakpoints I was actually complaining here about this a few days ago. What activity on this item are you referring to? Breakpoints as such are probably superfluous, since it's so easy to insert "(break)". But I wish I could single-step through s-expressions and have them highlighted in the editor, and I wish there were an easier way to inspect state. Actually it doesn't seem that sldb is so far away from what I want (with the exception of single-stepping and highlighting), yet I always find myself reverting to the equivalent of printf debugging.
- coffeemug 19y ago
  You can already single-step and highlight the piece of code you're stepping (assuming you use Slime/sldb). You just need to proclaim a debug level 3 before compiling your software. http://www.sbcl.org/manual/Debugger-Policy-Control.html#Debugger-Policy-Control http://www.sbcl.org/manual/Debugger-Policy-Control.html#Debu...
  - gruseom 19y ago
    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?

by pTymN 19y ago

jrockway 19y ago

I think the problem Lisp has is that very few people are forced to use it. If you look at the average programmer, he doesn't want to think about programming, he just wants to press keys an go home. So a language that requires you to think instead of type is not something that he is going to flock to. I think the sad reality is that most programmers aren't very smart, so smart languages will never become popular. I'm not sure why it matters though, there are plenty of CL libraries (and jobs), so if you like lisp you can get by just fine.

gordianknot 19y ago
What makes Lisp a "smart" language?
- jrockway 19y ago
  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.
  - shiranaihito 19y ago
    Good point!
  - Zak 19y ago
    I suspect there's a good bit of truth in your statement. I feel compelled to point out that it's incredibly short-sighted of programmers to think that way. Programmers spend a lot more time reading code than writing it, and it's hard to read code that doesn't use the right abstractions.
    - euccastro 19y ago
      There's the problem of how you define readability. Many people evaluate it in a per line basis, rather than comparing pieces of code that achieve equivalent functionality. Measuring readability like this is unfair to languages that favor terseness beyond that of natural language. In order to understand good Lisp code you need to learn new tools for expressing procedural concepts. Tools that are better, for that task, than natural language. Most people would think there is no such thing. Most people will always stick to whatever feels more intuitive at each stage of their formation as programmers. This is often a handicap to learning to think in more powerful ways.
allenbrunson 19y ago
while this might be true, i think focusing on this stuff is wasted time. i'm not a lisp programmer, but from reading about it here at hacker news, i'm pretty sure that the lisp community would only be hurting itself by taking the average blub programmer into account.
stevecooperorg 19y ago
"If you look at the average programmer, he doesn't want to think about programming" This is nonsense. You can't just 'press keys and go home' and make working software. Most of the programmers I've worked with thought a great deal about programming.
emfle 19y ago
I think most people prefer languages that let them think about the problem they are trying to solve, rather than think about what the macros expand to, or what happens when they call that continuation.
- gruseom 19y ago
  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...
  - emfle 19y ago
    The point is that "requires you to think" is not a feature, it is a bug, because that thinking could be put to better use on whatever it is the program is trying to solve. Everything else being equal, this means that language features that can be used without much thinking will do better than language features that can't.
    - gruseom 19y ago
      So programmers who work with objects and methods don't have to think about them, while programmers who work with macros do? Sorry, but this just seems ludicrous to me. Perhaps what you mean is that when a construct is unfamiliar to a programmer then they have to think harder about how to use it? http://www.google.com/search?q=blub http://www.google.com/search?q=blub
      - emfle 19y ago
        I am saying that working with objects and methods requires less high-level cognitive processing than macros and continuations, not that you don't have to think about them. This is because the brain can treat the objects largely as if they were physical objects. With macros that is much harder. No, I don't mean unfamiliar. Things like parentheses and prefix notation are unfamiliar to many people, but once learned, they don't require much more cognitive processing than other notation. There are several things in Java that are similarly weird until you learn them.

gordianknot 19y ago

Noise != usage. Don't confuse attention with popularity. I think about the language and post comments about it on forums and read great Lisp code (e.g. Arc), but I'd never actually use it for anything non-trivial. Why? Because I write web apps and existing Lisps don't make that easier or more fun. The only (!) thing Lisp has to do is efficiently and absolutely abstract away XML, CSS, and JavaScript. No Lisp is going to get any uptake otherwise. We could do this with Arc.

gruseom 19y ago
I'm interested in why you think that Lisp systems haven't yet efficiently abstracted away from HTML/CSS/JS. I work on such a system every day and the abstractions seem pretty efficient to me.
- gordianknot 19y ago
  Maybe they have. What system are you using?
  - gruseom 19y ago
    I use Parenscript and LML2. There are a profusion of such libraries (although for CSS I wrote my own simple thing). I'm very happy with the abstractions I'm able to layer on top of them with macros. One thing it took me a while to realize about the Lisp world is why there tends not to be standard frameworks or libraries for some of this stuff. The answer is that, for certain kinds of problems (basically, anything involving metaprogramming), it's actually easier to solve your problem yourself than to learn someone else's framework and then use it to solve your problem. A good example would be unit testing... there are probably a dozen unit testing frameworks, none standard, none much used. The reason is that the frameworks don't add much value over what a programmer can easily do for himself, with all the advantages that implies. I think this may also be why web app frameworks are less prominent in the Lisp world. This is not the case with all libraries, of course. CL-PPCRE adds huge value, to pick an obvious example, but not in the class of problem I'm talking about.

gruseom 19y ago

Solid debugging, perhaps with things like breakpoints I was actually complaining here about this a few days ago. What activity on this item are you referring to? Breakpoints as such are probably superfluous, since it's so easy to insert "(break)". But I wish I could single-step through s-expressions and have them highlighted in the editor, and I wish there were an easier way to inspect state. Actually it doesn't seem that sldb is so far away from what I want (with the exception of single-stepping and highlighting), yet I always find myself reverting to the equivalent of printf debugging.

coffeemug 19y ago
You can already single-step and highlight the piece of code you're stepping (assuming you use Slime/sldb). You just need to proclaim a debug level 3 before compiling your software. http://www.sbcl.org/manual/Debugger-Policy-Control.html#Debugger-Policy-Control http://www.sbcl.org/manual/Debugger-Policy-Control.html#Debu...
- gruseom 19y ago
  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?