5 ms·

Lisp (any lisp, be it lisp-1 or lisp-2) are currently fighting a fight on multiple fronts. From one side, each iteration of Python or Ruby gains new ground as t

• kylec 18y ago
  While I hear many people complaining about the "awkward" and "hard-to-read" syntax, it's rare to hear someone compliment the syntax of lisp. I am a big fan of the Lisp syntax because it's so simple and consistent - probably a relic of its roots in lambda calculus. Not having to worry about operator precedence is a huge bonus in itself - I don't know why on one hand people cling to PEMDAS, logic, assignment, etc having a complicated hierarchy of precedence and on the other reject lisp because it's too "foreign".
  • michaelneale 18y ago
    I agree - I think the other strength of it is that macros are less messy then a language with infix operators/functions. There is something nice about a language (lisp) that doesn't look like anything else, in an artistic sense (not sure if that counts for much). I think when most people complain about the parens, they are really complaining about the endless ))))))) at the end of an expression.
    • anamax 18y ago
      Interlisp had the last part correct. [ was a special open paren and ] closed all open parens back to (and including) the most recent [.
      • michaelneale 18y ago
        Nice - I remember someone saying that that in emacs you could have it format it using indentation and now show the parens (or maybe it wasn't emacs).
        • silentbicycle 18y ago
          It was Emacs: http://www.emacswiki.org/cgi-bin/wiki/UnParenMode http://www.emacswiki.org/cgi-bin/wiki/UnParenMode
    • dlweinreb 18y ago
      In practice, it's just not a problem, because your interactive development environment takes care of it for you. I think the idea that anyone should be expected to program by using something with the power of Microsoft Notepad is an obsolete view. GNU Emacs with Lisp mode makes it very easy to work with the parentheses. Meanwhile, we have no "dangling else" problem. Also, we have no need to memorize C's 15 levels of operator precedence, so when you see an expression, you never have to puzzle over how the items are grouped. In simple cases of C expressions, of course, it's easy, but it can get complicated. See "Java Puzzlers" by Josh Bloch and Neal Gafter to see how C/Java-style syntax can get you into trouble and fool you. There are pros and cons to each approach (C/Java and Lisp). I've used all of them extensively, and I prefer the Lisp way.
      • stefano 18y ago
        I agree that it's not a problem, but for newcomers all that parenthesis accumulation is quite problematic. I speak out of my personal experience: I've abandoned lisp even before learning something about macros because I couln't stand the parenthesis. I gave a second chance to Lisp some time ago, years after my first attempt. I've walked through Seibel's book entirely and know I love Lisp, but the parenthesis give a really bad first impression, they only make sense after you get to know the language better.
  • prospero 18y ago
    Clarity and unambiguity aren't necessarily the same things. The human brain can handle huge amounts of ambiguity, and our spoken languages reflect this. A programming language is meant to be a bridge between our ambiguous thoughts and the unambiguous calculations of a computer. S-expressions constrain the format of the programmer's dialog with the computer, making it simple and monotonic. For some people this will add a new level of clarity to their work, but for other people it will just limit what they can easily express in code. High-level languages like Ruby may contain lossy abstractions that obscure the low-level workings of the machine, but Lisp is another lossy abstraction that has the potential to obscure the high-level, abstruse workings of our own minds. Both of these abstractions can be valuable, but neither is without its shortcomings.
    • blasdel 18y ago
      Bravo! People tend to boggle when I decry Lisp as being hopelessly low-level. Sometimes ambiguity can be free, allowing indifference to how the machine works, without obscuring it at all. A good example is classical Hindley-Milner type inference (the algorithm that adds type annotations to plain System F code): it is fairly easy to construct oddball statements where annotating the types is undecidable or would cause resource exhaustion. But it turns out that for the known examples, it would be either impossible to decide the types in any form, or it would take O(c^n) bytes to enumerate the annotations. So effectively there is no downside to the ambiguity -- the ambiguous statements are already infeasible for other reasons. Everybody Wins!
      • ced 18y ago
        People tend to boggle when I decry Lisp as being hopelessly low-level. Intriguing. I'm not really convinced by your example though. In the spirit of conciseness is power[1], can you provide a short program that should be formally expressible in a good enough language, but isn't concisely in Lisp? Or maybe your definition of low-level is different from mine? [1] That's the PG version, of course.
        • prospero 18y ago
  • mixmax 18y ago
    You have an interesting point here that is not often discussed. I am pretty new to programming, which means that I'm not stuck in conventions about how code syntax is supposed to be. On this background I find lisp pretty easy exactly because the syntax is so simple. To me lisp is like chess: It's easy to grasp the basic rules, but hard to become a master.
    • eru 18y ago
      Then Scheme is like Go. Interesting like Common Lisp, but more beautiful.
  • silentbicycle 18y ago
    I agree. I wish ML used s-expressions. Also, you might like this presentation, "The Swine Before Perl" by Shriram Krishnamurthi (of PLT). It's a great thing to show people who wonder how you could think Lisp has a good syntax: http://www.cs.brown.edu/~sk/Publications/Talks/SwineBeforePerl/ http://www.cs.brown.edu/~sk/Publications/Talks/SwineBeforePe... (Also: SK's book is great.)
    • blasdel 18y ago
      ML and it's successors do not want for s-exprs. They force an inappropriate fundamental data type on everything, and are only of benefit if you want to fiddle with the insides of extant functions. Use composition like a real FPer. Learn that there's so much more to data than lists + atoms.
      • silentbicycle 18y ago
        > They force an inappropriate fundamental data type on everything, and are only of benefit if you want to fiddle with the insides of extant functions. Please explain. (And I know composition, etc. I also use Haskell and Forth.)
        • jlouis 18y ago
          I think what is meant is that the list is the primary data structure for everything in lisps. Fortunately, it is not the only data structure in lisps. I dislike constructs where eg. a graph edge is built as: '(GRAPH-EDGE <source-vertex> <target-vertex>) whereas in ML you would write type edge = { source: Vertex.t; target: Vertex.t } which is not a list, but an entirely different representation. In Common Lisp the representation could of course be a CLOS object or a DEFSTRUCT (I think, my CL-fu is definitely not that good). As for the composition, lisps are lacking (nice) currying which is one of the basic building blocks when constructing combinator-libraries.
          • silentbicycle 18y ago
            Ah, I misread it as that ML "force[s] an inappropriate fundamental data type on everything", not s-expressions.
  • etal 18y ago
    I once scribbled down some Scheme on a napkin during a conversion with my sister, a non-programmer. (God knows how it came up, but anyway, it did.) She looked at it, and said two things: 1. So many parentheses! 2. You made a mistake right here.
• brlewis 18y ago
  Lisp will have played its major part when other languages have real macro systems.
  • andreyf 18y ago
    Why can't macro systems be part of an IDE? Is there anything macros do that can't be done at compile-time? Startup idea: web-based language-specific IDE, with a simple interface for sharing/voting on macros between users.
    • PieSquared 18y ago
      The lisp macro system can more or less be done at compile time, yes, but that's not the problem with other languages. The format of lisp makes it especially easy to do macros - code is data! Here's an example. Take, for example, this class declaration: (defclass dog (animal) ((size :accessor dog-size) (name :accessor dog-name :init-form "Fido"))) How do you make that into data? Easy. Just quote it: '(defclass dog (animal) ...) Now take the equivalent in Java: public class Dog { int size; String name = "Fido"; } How do you get that into data? Well, I suppose the best you could do without modifications to the core language is just put it in a string. But then to do something useful you'd have to do so much tedious string parsing it wouldn't be worth it. I suppose you could invent a special ParseTree class or something, and a quote operator, and etc etc, but that wouldn't be nearly as easy as Lisp makes it. What the previous poster was saying is that once other languages have a code representation that is easy to work with as data, and can manipulate that code as data at compile-time to produce complex macros, then Lisp might fade. (At least that's how I understood it, correct me if I'm wrong.)
      • lallysingh 18y ago
        Or: 1. Allow a factory for Class. 2. Make Method contain the full body contents as a list of statements, and give them a factory as well. Then it's a matter of reasonable constructor syntax.
        • 18y ago