Hacker News Reader

A few additions:

* The parenthesis do require that you have at least a moderately capable editor to navigate them effectively. You can start coding things like PHP, Perl, Ruby, Python, etc... with a pretty crappy editor and do ok.

* NIH - bingo! Lisp has always struck me as being very insular, with a very strong 'turtles all the way down' mentality. "It would really be best if the OS were written in Lisp too...", whereas the "scripting" languages are very promiscuous in terms of what they will interact with and run on. This has led them to focus on doing what they are good at, and calling out to C or other languages for what they are not so good at, which is ultimately more productive than rewriting existing systems just so that they'll be 100% in your language of choice. (Yes, sure, not everyone in the Lisp world is like that, but I get that general feeling).

>> The parenthesis do require that you have at least a moderately capable editor to navigate them effectively.

I disagree, with a caveat--writing code using a terrible editor requires knowledge of the indentation rules for the language, regardless of whether that language is a lisp, Perl, Ruby, etc.

However (the caveat), although the indentation rules for Perl, C, Python are relatively simple (indent after a '{' or ':', line up arguments), each function/macro in a lisp can have different indenting rules (e.g. in CL compare `let' to `multiple-value-bind' to functions, to lists, to the various `with-*' macros, etc).

Once you know the library for a specific implementation, the indentation rules become more obvious; at this point, using (e.g.) Notepad isn't particularly terrible (until that knowledge is acquired, though, yikes).

Notepad is exactly what I'm talking about. With Perl, C, and Ruby, at least, there really aren't any indentation rules - your program will work fine even if you don't put any in at all, or do a hacky job of it. With Lisp, especially when modifying someone else's code you're stuck counting parens.

Oh, also a weird (maybe crackpot?:-) theory of mine: parenthesis, graphically, don't form a nice, rigid vertical line, but sort of point diagonally, possibly making it just that much harder to see how they line up. In any case, 4 or 8 space indented C/Tcl/Ruby/whatever code is certainly more obvious to the eye.

Lisp was my favorite language when I studied (hrm, long ago).

IMHO, there is quite a lot of support for the argument that modern day scripting languages are getting closer and closer to becoming lisps, except for syntax and the macro system. (Maybe Perl 6 will have meta-language power enough to equal the macro system? I should start learning it.)

I've never really understood why there are no successful projects to transfer code between the S-EXPR parenthesis-based syntax and some Algol-like notation; if that managed to also copy comments between the formats and auto formatted well, it would be an easy introduction for new lispers.

Isn't Dylan a sort of lisp-without-parens?

Except for the lisp macros, I think it lacks the eval-print-loop? (Quite logical, since it was done for Newton from the beginning and not comiled in the native environment, I think.) That loop is part of what makes scripting languages and lisp so productive.

You should really look into Nu, the language I mentioned in my parent post. It is a "glue" language for Objective-C and allows you to write code using typical lisp prefix-notation (+ 1 2) or infix (1 + 2). Reason being ObjC is mostly object oriented with infix & named parameters, so it fits in both worlds.

For example, if you're typically a lisp guy, you would probably write code like this: (init (alloc ApplicationDelegate))

But if you're an ObjC person, you'd do this: ((ApplicationDelegate alloc) init))

And strangely, if you replaced the parentheses with normal square brackets, you'd be looking at syntactically correct ObjC code! In Nu you can mix and match your sexprs and algol-like notations as long as you know what you're doing. The finished code would be something a lisp developer and ObjC developer could both understand without knowing too much of the underlying details.

Nu looked cool. (I thought from browsing that it should be some Lisp-like macro lib; a guy I knew used something like that for assembler, started early 80s. PDP-10. :-) )

Interesting idea to level a scripting language on using the message passing mechanism of Obj-C -- and so integrate the resulting code with the compiled Obj-C!

Thanks for making me look!

> IMHO, there is quite a lot of support for the argument that modern day scripting languages are getting closer and closer to becoming lisps...

Yes, but, I'm sorry, not every computer science advance came from Lisp. (Not singling you out in particular, berntb.) Insisting otherwise makes one sound condescending, fanatic, and/or naive. There are good ideas in Lisp, yes, but there are also good ideas in ML, Lua, Awk, SQL, Smalltalk, Prolog, Haskell, SNOBOL, etc.

Lisp is cool as a clean embodiment of the Lambda calculus and all, but if people stopped treating it like it were a divine revelation, other people would perhaps stop getting the impression that Lisp users are [insert torrent of unflattering adjectives].

(The Scheme community is generally much better about this than the Common Lisp community, but the Scheme community at large also seems to spend more time trying to actually move the language forward rather than insisting that some old standard has everything people will ever need.)

Your point say something about the scars you got from your educational environment? :-)

AFAIK, not even the lisp snobs would argue that everything worthwhile happened in lisp; they argue that most of the lisp characteristics was copied by everyone. For some values of "most", it seems like a very good argument.

Dude, I was a history student. :) (I taught myself to program with library books and a C-64, starting when I was five or so.)

Just, it boggles my mind how many ideas from barely ten years ago seem completely unfamiliar to most programmers. As Steve Yegge put it, "Oh, right, I keep forgetting: you were born in nineteen-ninety something, and you're nineteen, and I'm ninety-something."

I'm only 27, but I'm starting to feel like I'm at least one programmer-generation back (and, occasionally, the cranky old man yelling, "get off my lawn!"). I find a lot of inspiration in the 70s-80s Unix-era books, for example. While some of the surface details have changed, those guys wrote lucidly about ways to design useful systems without them growing into impossibly tangled monstrosities (even before C++...). A lot of issues programmers struggle with today have been mulled over for decades, and there's a lot of good advice if you look. The field hasn't changed that much.

I see ideas that keep getting rediscovered, and sometimes it's really sad how few stick. Lisp had a lot of great ideas in it, yes, but it's not the only old language that did, and the way it gets exalted that way touches a nerve of mine sometimes. (FWIW, the second paragraph in my response above was saved right as the edit window closed. I was still rewriting it, and it sounds harsher than I would have kept.)

Yeah, the standards seem to be lower in general. Probably because the barriers to entry are lower. (-: As an oldie, I try to be humble by remembering the Flynn effect. :-)

And then...

Be happy kid, it gets worse. :-)

Exercise, take vacations and make certain you relax enough (a meditation-course is good; there are non-religious ones). Also, be careful with your teeth; an infection I had no other effects of, made me chronically tired for a long time and really destroyed my life (I thought I had burned out).

And work with stuff you care about, otherwise you'll probably hate yourself and everyone else.

Most other stuff you seem to know.

Sorry for that, but a 20-something trying to sound world weary needs a pat on the head. :-)

Maybe Perl 6 will have meta-language power enough to equal the macro system?

Not only does it have full-on raging macros, you can redefine the languages own syntax inline. Check out one of Larry's recent talks about STD.pm (here's a Google Tech Talk from last year, which is nowhere near as funny as Larry usually is, but is still quite informative: http://www.youtube.com/watch?v=JzIWdJVP-wo )for a real "when you see it, you'll shit bricks" moment. Perl 6 is far more intimidating than I ever realized. They seem to have looked at everything good about Perl (and a handful of other languages) and said, "Let's do a lot more of that." It's somewhat scary how much more of "that" they've done. So, there's macros from Lisp, lazy evaluation from Haskell, redefine-able grammar and syntax from I dunno where, a new regex language, etc. It takes TMTOWTDI to obscene new heights (kinda like Lisp). If power is the sole determining factor in what language you choose, there's a strong case to be made that Perl 6 is the one you want. I don't know that I entirely buy that (if I did, I guess I'd be using Lisp), but I'm hopeful that the real result of Perl 6 will be a language as capable as Lisp with a community and library culture as strong as Perl 5.

What I meant was, will it be as easy to use as lisp macros?

To take most everything good existing and sum it, is how you make Perls. :-) I'm not arguing here, I do Perl today.

You should have put the content of the last sentence first; too few will read it.

I agree that the "crazy parentheses" might not be the core reason people who hate Lisp hate Lisp, but it certainly doesn't help advocacy for management types. It's definitely knee-jerk, but lots of people make their decisions in a "blink" and it definitely helps when code looks like "User.find_or_create_by_name(john)". Usually the people who hate lisp, have never done a significant project in it, and never will simply because of the syntax. In a way, it's like trying to learn Korean as an English speaker. Korean is a very modern alphabet based language, but the random strokes in their alphabet would probably make anyone take one look and say "jeez, that looks chinese to me"

Sounds like reaction to Lisp syntax is a good heuristic for choosing managers not to work for.

A good manager will either 1) research more thoroughly and come up with a more sensible reason to not use Lisp (there are many reasons not to use Lisp for many kinds of projects) or 2) delegate technical decisions to the technical people he hired and trusts to make those decisions (with some way to hold them accountable for meeting objectives).

(In the following text, replace "you" by "I")

"A community that has a deeply ingrained culture of NIH."

Lisp is a NIHer's heaven. I know something about it, I've just spent 3 years learning new stuff and reimplementing the universe with it (I'm not done yet. Give it some decades...). Learning Lisp is a friggin' Pandora box. It gives you absolute power (that corrupts you absolutely), it makes you discover crazy powerful and sometimes hard to implement paradigms (ex: Dataflow), and of course you have to try to implement them so you simply never get anything done. Sure, you do things The Right Way, but the investment in implementation and learning time is absolutely prohibitive. Gotta admit I'm not sure if Lisp made me a NIHer or I was just drawn to Lisp because I'm one but Lisp sure is an aggravating factor for that.

A few days ago I finally decided to STOP LEARNING and STOP REIMPLEMENTING THE UNIVERSE for a few months so I can finally launch my startup (some utility site for a niche MMORPG).

Same experience with Lisp / Scheme here. There's a truly awe-inspiring amount of computer science research published about Scheme, in particular. I learned a TON, but I also learned that if I'm actually trying to get stuff done, I'm better off using something else, such as Lua or Python.

Lua, while even more Scheme-like than Python, was designed primarily for use as an embedded scripting engine in another languages (typically C or C++). Instead of putting effort into making Lua clones of typical libraries, they worked on making re-using other languages' existing libraries quite easy. It seems to stand the whole NIH thing on its head, too. (Though, languages such as Chicken Scheme that compile to C can inter-operate better than most.)

it's just not a very intelligent argument, and can probably safely be dismissed as merely uninformed.

Do you mean that people who hate lisp because of its parentheses are uninformed; or do you mean that thinking that this is the reason people hate lisp is uninformed? The first is about languages; the second is about people.

Assuming the latter, what's the evidence? Many people complain about parentheses, so it seems that it is an active reason, but without a rigorous survey ("Why do you hate lisp?"), it's hard to know.

The issue with parentheses is not about "hate" at all, but confusion. If you are 100% determined to learn something no matter what, you can probably learn it. But in reality, when you start to learn something, you are also assessing if it is worth the effort of learning.

The context of my first experience with lisp was that it was supposed to be more "mathematical" than other languages - and so I assumed the parentheses were used as they are in expressions, that is, for grouping. But they aren't used in that way in Lisp - they mean function call, like f(x), but with yet another syntax. So, my 5 minute cursory foray into Lisp ended with me concluding that Lisp was unexpectedly inconsistent. Since that's against my usability values, I didn't spend further time on it (since then, I have spent further time).

I didn't hate the parentheses; I just found their meaning elusive.

Do you mean that people who hate lisp because of its parentheses are uninformed; or do you mean that thinking that this is the reason people hate lisp is uninformed?

Both, actually. But moreso the folks who complain about parentheses. I suspect that anyone who uses that as their reason for not learning or liking Lisp simply would never consider Lisp long enough to know anything more about the language. I just think it's more likely because they like "industry standard" languages, and have no obvious on-the-job use for Lisp, but they don't want to say "I am intellectually incurious about languages and different programming paradigms". I think those same people would never learn Lua or Haskell, despite a distinct lack of crazy parentheses.

Many people complain about parentheses

Many people complain about significant whitespace in Python and sigils in Perl. Either one has orders of magnitude more developers and more code being written in it on a daily basis. It is a triviality, and the kind of folks who pick out trivialities to complain about are not the kind of folks you can convert. They're not going to learn your favorite language, unless you make it look exactly like their favorite language. Since Lisp can't look like Java or C# or C or Visual Basic or PHP, without losing a lot of what makes Lisp Lisp, that's not a useful pursuit.

So, I'm simply saying that talking over parentheses over and over again is ignoring the real problems and focusing on the one that everyone knows won't change. It's a perfect flame war talking point, but it's not what's keeping people away from Lisp.

Yes, I can see parentheses as a convenient catch-phrase. While it's less familiar than indentation in Python, you're right that people complain about that too, but it hasn't stopped adoption.

Unfortunately, I think the community is about as likely to change.

Unfortunately, I think the community is about as likely to change.

I agree. They've had longer than anyone to figure out the "community" thing, and they've self-selected into near obscurity.