Hacker News Reader

Comment by jrockway | Hacker News Reader

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.

View on HN

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

Good point!

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.

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!

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.

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

Reply on news.ycombinator.com