Hacker News Reader

Comment by pTymN | Hacker News Reader

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.

View on HN

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.

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.

Maybe they have. What system are you using?

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.

Correct me if I'm wrong, but Parenscript doesn't abstract away HTML, CSS, JavaScript, it just lets you write HTML, CSS, and JavaScript using a Lispy language.

This is very different than abstracting away HTML, CSS, and JavaScript, which is where I think the real problem is.

I shouldn't have to learn 3+ of different languages (HTML, CSS, JavaScript, etc), AND 3+ different variations of each (Mozilla, WebKit, IE, etc), AND multiple versions of each, AND another abstraction layer (Parenscript) just for basically macros, just to write a web application.

It seems to me we've had this discussion before! No, it doesn't abstract these things away in the sense that compilers abstract away machine language. That is, you still have to know about them. Is that what you mean?

If so, it's a fair distinction. Probably it would be more accurate if I said abstract over rather than abstract away. We can get rid of a lot of repetition this way, but not a lot of the details that remain after that. Still, that's a big deal; better than anything else I've seen by far. So while "abstract away" may be an overstatement, I think that "just lets you write HTML, CSS, and JavaScript using a Lispy language" is an understatement. It doesn't just let you write those things - you don't need Lisp to do that. Similarly, saying "just for basically macros" (my emphasis) reads like an oxymoron to me. Macros are a big deal!

If you can do better, I definitely want to know. But my definition of "better" includes being usable in a standard browser, and "usable" includes performant.

Weblocks does this (sort of). I've just read about it, not actually used it much.

http://www.defmacro.org/ramblings/ui-dsl.html

I can't help but think that people who want to replace HTML+CSS+JS haven't written a widely used web application before, because the idea seems so absurdly impractical and would become such an incredible time sink.

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 think even just MzScheme could become viable if the untyped stuff gets a bit more polished and there is just a lib everyone can agree on called "pragmatic.ss" that pulls in the relevant SRFIs.

Most of lisps problems these days stem from social issues and logistical issues. The core tech is excruciatingly sound, and the language itself is great.

To someone out in the startup circles, it almost seems like Lisp and Scheme focus more on being a standard than being a pragmatic and global platform. While noble, this is not the path to massive popularity. Some people might be okay with that, but it seems to me like you could serve both goals and end up with an overall better product.

should be unified under one syntax, which then compiles

You do get that this is exactly what Lisp hackers who build web apps do?

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.

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

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.

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#Debu...

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 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.

"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.

What makes Lisp a "smart" language?

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.

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.

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.

Good point!

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.

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.

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...

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.

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

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.

As far as I can tell, you're talking about your experience of what's easier and harder. Your experience is not "the brain".

Certainly if you're habituated to the object-model style of programming, other forms of abstraction may seem weird. The irony here is that twenty years ago, the people making your kind of argument were directing it all against objects.

As a side note, treating programming objects as if they were physical objects works as long as there's a good fit between the two. As soon as you need the objects to behave in ways that physical objects don't (and believe me, in any complex OO system, you will), you find yourself tied up in knots that it will take a lot of thinking to extricate yourself from. (Speaking of complexity that isn't intrinsic to the problem...) Not accidentally, the tools that people reach for then tend to be ersatz versions of metaprogramming (reflection, code generation), and Greenspun is off to the races...

"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."

It's not. It's just a matter of practice. Most people find OO modeling natural (even when it is extremely tortured and difficult) because they've acquired a comfort with it born of many hours of practice. You might argue that you're not referring to familiarity with the paradigm, but I think you are, and don't realize it.

I assure you that a functional style has equal power to abstract as a OO style. You're right, our brains have a good ability to think of things as sets of objects. But the lisp style leverages the linguistic propensity to give words special significance. We're also very good at learning languages and parsing sentences in context, so the lisp linguistic style leverages similar natural cognitive abilities.

I am familiar with functional programming. In fact, for some reason recursion and higher-order functions always seemed easy to me (unlike pointers and virtual methods), but I think that's a quirk of my brain. Many other people seem to have a lot of trouble with the idea that you can just make a recursive call and trust that it's going to do what it is supposed to.

Not me personally, though.

But the lisp style leverages the linguistic propensity to give words special significance. We're also very good at learning languages and parsing sentences in context, so the lisp linguistic style leverages similar natural cognitive abilities.

Linguistic processing does require more cognitive effort, especially when it involves something like a macro that can change the context in which it is invoked. For exactly the same reason, most people are more productive with a graphical user interface than with a command-line one. This is directly related to the fact that abstract linguistic processing is more difficult than manipulation of the tangible, physical objects you find in a GUI.

Most people find OO modeling natural

I can't resist pointing out again how laughable this sounds to anyone who remembers the long debates about how hard it is to "think in objects" and how objects "would never work for the masses". (Actually, that was right, because the "most people" in question are still largely writing much the same code as they always did and always will; now they just surround it by "public class".)

I'm not disagreeing with you at all; I just feel compelled to make sure that somebody else sees this irony!

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.

right. to me macros are just a different style of function. i don't see why people would be spooked by them

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.

...

Reply on news.ycombinator.com