Hacker News Reader

Comment by submeta | Hacker News Reader

Honestly curious why Lisp has so much admiration and praise on HN. I played around with Scheme some long time ago, read SICP, learned a lot. And I know Lisp inspired many programmers like the founder of Ruby. But I would not think of Lisp when it comes to solving day to day problems. I rather pick Python because it helps me solve all kinds of problems. There are many more solutions I can think of (Ruby, Node, Go, even Perl).

View on HN

What made it click for me is the nature of scheme: a few, very well thought out abstractions, that compose well to build a really neat language. I never really made friends with other languages. Where scheme composes the primitives for problem solving, I find that languages like python or ruby provide either one way for each different thing, or a very large hammer for every problem you might find, be it list comprehensions or generators or whatever OO voodoo you can come up with.

The feeling I got when learning scheme was that of liberation. People have that epiphany all the time, but with different languages and techniques. For me it was scheme.

And of course, I could never be bothered with syntax. If something becomes too verbose in scheme, I write a macro to simplify it. The only thing I need to know is whether something is a function or a macro. After 3 years of writing python on and off, I still manage to mess up syntax unless I think very hard before writing.

I am however not a programmer, and of average intelligence. In fact I am on the very top of the bell curve, looking down on the rest of you.

> a very large hammer for every problem you might find, be it list comprehensions or generators or whatever OO voodoo you can come up with.

List comprehensions, to me, are what makes Python a productive (or the most productive) prototyping language. It allows me to think and program in mathematical relations without much fuss. Add to that nice sets and dicts (needed for asymptotic efficiency), and I can easily forgive it that it is built on an everything-is-an-object paradigm (there are few things I detest more than OOP).

I've never truly understood why you need the meta-capabilities of LISP. I much more need a syntax that does not hide what happens (procedure call, list indexing or at least "indexing"). Macros amount to code generation. Code generation is mostly bad, it typically means the problem wasn't thought through, and that there is a lack of clearly defined building blocks. So far I've only ever generated a few C structs and enums, but I'm not sure it was an entirely good idea. It was super easy to generate from Python, anyway.

Code generation is great. If you have a well understood domain, Lisp macros allows you to construct an effective DSL so that your programmers no longer have to write "lisp code" but to program in the new language. We do this today using functions/methods, but the issue tends to be that besides understanding these functions, we need to learn how to orchestrate them and write boiler code all around them. A good DSL hides all that. The issue as I've observed is that when most people create a DSL, they really forget that they have indeed created a new language and don't document it enough. The consumers of the DSL because they can read lisp code, don't focus and live in the DSL layer but wish to peer below then get terrified when they see the macros. Most developers get terrified when they peer one level below. Have you seen the bytecode generated by python or asm code by C? Do you think those are bad because those are code generation that don't look the way you think they ought to?

> We do this today using functions/methods, but the issue tends to be that besides understanding these functions, we need to learn how to orchestrate them and write boiler code all around them.

No, you need to structure your data in a way that there is almost no boilerplate, and only very little glue code (which effectively amounts to "the macro code", with the difference that it's only executed once per data object).

> Do you think those are bad because those are code generation that don't look the way you think they ought to?

Good point, but I have a strong belief that the abstractions offered by C (function calls and good syntax for arrays and records) are sufficient and going up is detrimental for larger systems. I don't code in assembler because typically there is too much redundancy (function call convention) and it's too specific (architecture dependent) and probably too verbose. That said, I'm not strongly against it, but haven't really tried.

Whatever programming language you are using, at some point or at some representation the compiler will start generating code. The difference is that the default code representation of lisp allows it at source level, making writing (and debugging) them a lot easier. An if statement in python generates a shitload of bytecode that the optimizer then does what it pleases to. With lisp you can watch that process by watching the source->source transformations of macros and the optimizer.

Macros allow us to extend the language. It is not just C-like code generation. The loop constructs of common lisp, or the for loops of racket (or my own reimplementation for guile scheme) are macros.

With lisp macros we can express zero cost abstractions that in other languages would have a lot of overhead, and make them feel like a regular language construct (CLOS started like that)

My own racket-like loops for guile generate code that the optimizer can then turn into optimal code: https://bitbucket.org/bjoli/guile-for-loops/overview

The downside being that macro expansion slows down compilation. My workstation can expand about 1000 loop macros/s with guile and a couple of orders of magnitude more using my chez scheme prototype (somewhere above 100k)

> An if statement in python generates a shitload of bytecode

To be precise, it will generate something like 'JUMP_IF_FALSE' which is not exactly a shitload. Not saying the execution will be fast. After all, it's an interpreted language.

> Macros allow us to extend the language.

We're on the same page. What I was saying is: if you need more than function calls and records, chances are you're doing something wrong... the program architecture becomes intransparent. Macros and other conveniences allow for hacks put on other hacks, until you don't understand your program anymore and development eventually stalls.

I once added cooperative multithreading by switching stacks in a C program. It was very easy to do and helpful for that project, but small hacks like this are rarely needed. (And in that instance it could have possibly been avoided, but I wasn't in a position to change the dataflow architecture).

I suspect that is just a matter of taste. I find source->source transformations pretty darn useful. You end up writing boilerplate code in all languages. Being able to just abstract that away is comfortable, and I don't really see the problem (together with what I suspect is the vast majority of lispers).

You can of course provide libraries that "extend" the language, but sometimes you will never be able to lose the feeling of it being bolted on, because the semantics of the la guage doesn't lend itself to that certain way of doing it.

Lisp macros solve that, at least for me. We use them like regular procedures and as long as you keep the simple rule that you sbouldnt make a macro of something you want to compose with procedures, there really isnt much that gets in the way of understanding a program, because most of the time whether something is a macro or not does not matter.

Why do you need the meta-capabilities of lisp? Well, language designers are human and can't predict all the features that you might find useful. Take, for example, list comprehensions.

I added some basic ones to common lisp in a couple of minutes.

  (defun read-comprehension (stream char)
    (declare (ignore char))
    (destructuring-bind (expr for var in list &optional if filter-exp)
        (read-delimited-list #\] stream)
      `(loop ,for ,var ,in ,list
          ,@(when filter-exp `(,if ,filter-exp))
          collect ,expr)))

  (set-macro-character #\[ #'read-comprehension)

  (eval (read-from-string "[(+ x 1) for x in '(1 2 3) if (> x 2)]"))
  ;; => (4)

This looks impressive on the first sight (kudos!). But on the other hand it's still a pretty fragile and unreadable macro, no? And it supports only a very limited form of list comprehensions. Can "destructuring-bind" support them fully?

Yes, it is fragile (less than five minutes, man!) but hardly unreadable to the macro-accustomed eye.

A "real" implementation would do more processing of the forms in the list read by read-delimited-list and perform appropriate checks. This is more to just give you a sense of how trivial it is to extend the language.

I don't actually know python well enough (I had to look up "list comprehension") to say, but I would estimate that it would only take a page or so of code to give you something fully-featured and robust.

In practice, I would never abuse the reader like this when typical "loop" expressions are enough to do these kind of things (and more).

Anyone who would like to use list comprehension forms, or read about how Lisp enables them, might find these papers interesting:

Implementation of a "Lisp comprehension" macro by Guy Lapalme http://rali.iro.umontreal.ca/rali/sites/default/files/publis...

Simple and Efficient Compilation of List Comprehension in Common Lisp by Mario Latendresse http://www.ai.sri.com/~latendre/listCompFinal.pdf

> I much more need a syntax that does not hide what happens

Yes sir!

> (procedure call,

   80febf0:	08 
   80febf1:	c7 44 24 04 01 00 00 	movl   $0x1,0x4(%esp)
   80febf8:	00 
   80febf9:	89 3c 24             	mov    %edi,(%esp)
   80febfc:	89 44 24 0c          	mov    %eax,0xc(%esp)
   80fec00:	e8 cb c8 f4 ff       	call   804b4d0 <__fprintf_chk@plt>

> list indexing or at least "indexing").

Gotcha covered there too!

    80fd7eb:	8d 7c 0e ff          	lea    -0x1(%esi,%ecx,1),%edi

You won't be indexing sizes >8 bytes with your lea. Super annoying with 128-bit SSE arrays - which is pretty much the only reason I write any assembler anymore.

What's special about that? I can't see anything unexpected. Do I miss something here? I don't know (any) assembler well.

> I much more need a syntax that does not hide what happens (procedure call, list indexing or at least "indexing").

Each of those is actually hiding what really happens. E.g. for a procedure call the runtime compares the arity of the call and the called function, inserts each argument into a data structure of some sort, perhaps grafts together environments or does other things on a language-specific basis, performs a jump of some sort, then the called function takes over, and finally stashes its return value(s) in a data structure of some sort and performs another jump.

Even list indexing in a language like Python is relatively complex, involving a lookup of the list length, bounds-checking &c.

> Code generation is mostly bad, it typically means the problem wasn't thought through, and that there is a lack of clearly defined building blocks.

Proper syntactic abstraction is all about building the right blocks for the problem at hand. At the end of the day, all we have are bits of silicon transferring electron: everything above that is an abstraction. A sufficiently-powerful programming language enables the programmer to develop the abstractions he needs for the problem he has.

For Python, I agree to an extent. The machinery is hidden of course. That's the price of the convenience of a dynamic scripting language. But one still can see the relevant things. For example, for a subscripting operation, what counts is often only the mathematical aspect of it: It's a right-unique relation (i.e. a mathematical function) applied to the given element. And it's reasonably fast - even in Python with dicts, we can assume O(1) for most purposes.

It's nice when these important properties are indicated by a visual clue (square brackets).

> A sufficiently-powerful programming language enables the programmer to develop the abstractions he needs for the problem he has.

Sure. And that programming language still happens to be C for many, many purposes.

Code generation is brilliant. Remember that a compiler is a code generator. Using your own code generator allows you to declare what you want at a high level and then generate bug free code that implements it. It is like having a super fast automatic programmer at your side making you super productive.

>Code generation is mostly bad(...)C structs and enums,

C macros (or "C code generation" if you prefer) is very, very different from Lisp macros.

Lisp macros are built into the language, the whole language itself is designed around this capability.

Macros/Code Generation used correctly is exactly the opposite of what you are saying. Macros/Code Generation used correctly forces you to figure out at a much higher level what it is you want to achieve. And declare it in a formal computer readable way.

Looking at a page about list comprehensions in Python.

  S = {x² : x in {0 ... 9}}
  V = (1, 2, 4, 8, ..., 2¹²)
  M = {x | x in S and x even}

Python (from that page)

  S = [x**2 for x in range(10)]
  V = [2**i for i in range(13)]
  M = [x for x in S if x % 2 == 0]

I did not see 10 or 13 in the original definitions

Perl 6 closest syntax to original

  my \S = ($_² for 0 ... 9);
  my \V = (1, 2, 4, 8 ... 2¹²); # almost identical
  my \M = ($_ if $_ %% 2 for S);

Perl 6 closest syntax to Python

  my \S = [-> \x { x**2 } for ^10];
  my \V = [-> \i { 2**i } for ^13];
  my \M = [-> \x { x if x % 2 == 0 } for S];

Perl 6 more idiomatic

  my \S = (0..9)»²;
  my \V = 1, 2, 4 ... 2¹²;
  my \M = S.grep: * %% 2;

Perl 6 with infinite sequences

  my \S = (0..*).map: *²;
  my \V = 1, 2, 4 ... *;
  my \M = S.grep: * %% 2;

---

Python

  string = 'The quick brown fox jumps over the lazy dog'
  words = string.split()
  stuff = [[w.upper(), w.lower(), len(w)] for w in words]

Perl 6

  my \string = 'The quick brown fox jumps over the lazy dog';
  my \words = string.words;
  my \stuff = [[.uc, .lc, .chars] for words]

I wouldn't say Python's list comprehensions are really that big of a selling point. I mean based on what I've seen to understand it the biggest difference is that feature in Python runs from the inside out.

  noprimes = [j for i in range(2, 8) for j in range(i*2, 50, i)]
                         range(2, 8)
                for i in
                                              range(i*2, 50, i)
                                     for j in
              j
             [                                                 ]

Whereas Perl 6 is either left-to-right

  my \noprimes = (2..^8).map: { |($^i*2, $i*3 ...^ 50).map: { $^j }}
                 (2..^8)
                        .map:
                              { |($^i*2, $i*3 ...^ 50)             }
                                                      .map:
                                                            { $^j }

or right-to-left

  my \noprimes = ({ $^j } for ({ |($^i*2, $i*3 ...^ 50) } for 2..^8))
                                                              2..^8
                                                          for
                               { |($^i*2, $i*3 ...^ 50) }
                              (                                    )
                          for
                  { $^j }
                 (                                                  )

Here are a couple other translations using Set operators

  primes = [x for x in range(2, 50) if x not in noprimes]

  my \primes = (2..^50).grep: * ∉ noprimes;

  my \prime-set = 2..^50 (-) noprimes; # a Set object
  my \primes = prime-set.keys.sort;

Also I'm fairly certain Python doesn't have a way of using them on a Supply concurrently.

  # create a prime supply and act on it in the background
  Supply.interval(1).grep(*.is-prime).act: &say;

  say 'main thread still running';
  # says 'main thread still running' immediately

  # deadlock main thread,
  # otherwise the program would terminate
  await Promise.new;

  # waits 2 seconds from the .act call, says 2
  # waits 1 second , says 3
  # waits 2 seconds, says 5
  # waits 2 seconds, says 7
  # waits 4 seconds, says 11
  # and so on until it is terminated

Basically the only selling point of that feature in Python over say Perl6 is that is at times a bit closer to what a mathematician would normally write.

I'm not a mathematician.

To me it seems a bit verbose and clunky. It probably also only works as a single line, which seems odd in a line oriented programming language. Basically it seems like a little DSL for list generation, sort of like Perl's regexes are a DSL for string operations.

Perhaps you may want to reread the last paragraph from the original article. Maybe in a few years the world will have passed you by. Then again maybe not.

Your confusion will go away once you recognize that Scheme is not Lisp. For most purposes, Lisp means Common Lisp, or one of the Lisps that ended up merging into Common Lisp. That means that Lisp does all of these things and more, which you might not expect if you've only seen Scheme/SICP:

* Multi-paradigm programming (functional programming in the immutable sense is not dominant, the Lisp OOP system is top class, mutable state can be everywhere)

* Rich looping mechanisms that don't require tail call contortions

* Explicit typing that leads to optimized code and compile time warnings! (https://news.ycombinator.com/item?id=13389287)

* Warnings at compile time (not run time!) about things like undefined functions/vars/wrong args/unused vars (https://news.ycombinator.com/item?id=14780381)

* A pretty good set of libraries et al that (once you set up quicklisp) are just a function call away from trying out (https://notabug.org/CodyReichert/awesome-cl)

* (edit: one more since I like it a lot) Out of the box the Lisp system contains features you have to get from IDEs in other languages like breakpoints, tracing, inspection, code location questions like "who calls foo"... of course working with that system via emacs or something is nicer but it's basically all there in the base system (http://malisper.me/debugging-lisp-part-1-recompilation/)

I think this comment is unhelpful. The meaning of "Lisp" is a little bit complicated, but I think it can be explained better than this.

"Lisp" has two meanings: (1) ANSI Common Lisp; and (2) the family of programming languages to which ANSI Common Lisp belongs, and which was called "Lisp" many years before ANSI Common Lisp was conceived; that family includes many other languages with quite a bit of variety, including Scheme, Clojure, INTERLISP, T, kernel, picolisp, *Lisp, (the early versions of) Dylan, and many others.

I appreciate the feedback. Maybe my approach could have left out the claim of Lisp == Common Lisp, though I still am amused (as I mention near the end of my later comment) and slightly bothered that such a diverse set of languages (Python too, it's sometimes called an acceptable Lisp) can get called "Lisps" or "dialects of" or "members of the family" rather than an explicitly vague "Lisp-like".

The main direction I was coming from though was that ~10 years ago I was just like the OP, I had read some of SICP and PG's essays and thought I knew Lisp, but no, I just knew a minimal subset of Scheme. Very pretty (https://www.thejach.com/imgs/lisp_parens.png), learned some neat things, but didn't pursue it in favor of practical workhorses like Python et al. I went with the "learn Lisp for the side effects of learning it but don't ever use it" crowd, but I never learned Lisp. It wasn't until much later that I found out Common Lisp was way more than just an ugly syntax change on Scheme that required #' in front of function names. So the features I listed in my comment are really a subset (but a strong one) of the features that would have convinced me ~10 years ago to take a much closer look into actually using Lisp and recognizing I learned something very different.

I get it; you thought Scheme was Lisp and Lisp was Scheme, and want to prevent others from falling for the same misunderstanding. That's a laudable goal.

Lisp is an old family of languages, though. It's been around a long time, and it's explored a broad range of language ideas and a lot of nooks and crannies. There are a lot of Lisps that are pretty different from each other. There's a pretty good list at Wikipedia (https://en.wikipedia.org/wiki/List_of_Lisp-family_programmin...), but it still omits some interesting variants (for example, *Lisp, Kernel, Lispkit Lisp, Connection Machine Lisp, and others). There are greater differences between, for example, Common Lisp and kernel than between Common Lisp and Scheme, but all of them are still recognizably Lisp.

So you're right: you don't want to be fooled into thinking that Scheme is all there is to Lisp. But Common Lisp also isn't all there is to Lisp. Scheme plus Common Lisp plus Clojure isn't all there is to Lisp, either. It's a big space, and there's room for it to grow bigger still without losing its essential Lispiness.

"APL is like a beautiful diamond – flawless, beautifully symmetrical. But you can't add anything to it. If you try to glue on another diamond, you don't get a bigger diamond. Lisp is like a ball of mud. Add more and it's still a ball of mud – it still looks like Lisp."

-- attributed to MIT Professor Joel Moses

To add to the confusion, this Wikipedia article says that Scheme is "one of the two main dialects of Lisp." https://en.wikipedia.org/wiki/Scheme_(programming_language)

Well, it was true, at least until clojure. Now we've got clojure, common lisp and scheme.

Lisp user base is so small enough that these categories largely look pointless to people outside.

For all practical purposes CL, Scheme, Clojure and Elisp are all lisps.

> For all practical purposes CL, Scheme, Clojure and Elisp are all lisps.

Since only CL and Emacs Lisp can and do share actual Lisp code, I call only them Lisp for practical purposes.

For 'unpractical' purposes - they share no source code but are influenced by practical Lisp - , Logo, Javascript, Ruby, Clojure ... are also Lisp.

>>Since only CL and Emacs Lisp can and do share actual Lisp code

But what exactly is 'actual lisp'. I mean what is this strict definition?

Forgive me, I understand calling Scheme and CL as same might feel like saying Java and C++ as same. But one would be right in saying Java and C++ both come from a C based paradigm.

On the same lines one could say CL and Scheme come from lisp paradigm. At this point in time both communities compared to any major language community are so small that one could refer to both as Lisp.

The problem is that both CL and Scheme communities have very little to do with each other.

For practical purposes Lisp dialects are those directly inheriting back to Lisp I from McCarthy. You can run programs from 1960 in Common Lisp with very little changes (unless it uses machine interfaces). To port them to Scheme is possible. To port them to Logo, Clojure, Javascript or other languages considered to be dialects in a wider sense mostly means a rewrite.

Thus for me Lisp means the dialects of Lisp and their respective communities which can share code, libraries, applications by relatively simple ports. For example Emacs Lisp has Common Lisp enhancements, which are semantically very similar. ISLISP could be directly integrated into a Common Lisp - Kent Pitman mentioned that he actually did that to see that they are culturally compatible.

Languages who don't directly share code are maybe part of an abstract family, which has no agreed on definition - thus this is for practical purposes relatively useless.

>The problem is that both CL and Scheme communities have very little to do with each other.

At first I thought this was absurd, but after some time learning Lisp this was more obvious.

Scheme and Common Lisp are built around totally different philosophies, and thus not only the languages diverge, but also the way you program in them.

It's definitely a confusion. The point seems to come up on HN from time to time... I don't care very much about the distinctions but it's still fun to spell out my case for why maybe one should care. "Lisp" has these nice connotations as old-but-gold going back to 1960 and many success stories in real world applications. Common Lisp has a direct lineage to that Lisp, but even ignoring that there's a syntactical lineage too. e.g. You can take stuff from the Lisp 1.5 manual and with very small rewrites have it run on a modern Common Lisp implementation.

    DEFINE (( 
    (LENGTH (LAMBDA (L) 
    (PROG (U V) 
        (SETQ V 0) 
        (SETQ U L) 
    A   (COND ((NULL U) (RETURN V))) 
        (SETQ U (CDR U)) 
        (SETQ V (ADD1 V)) 
        (GO A) ))) ))
    LENGTH (((X . Y) A CAR (N B) (X Y Z))) ; ---> 5

could be rewritten (even if not idiomatic) to

    (defparameter length-cl (lambda (l)
        (prog (u v)
            (setq v 0) 
            (setq u l) 
        A   (cond ((null u) (return v))) 
            (setq u (cdr u)) 
            (setq v (1+ v)) 
            (go a))))
    (length-cl '((x . y) a car (n b) (x y z))) ; ---> 5

Differences: CL doesn't have a special top-level that doesn't need parens. CL doesn't use 'define' (though Scheme does), you'd usually use defun for a function and not use lambda either. CL uses '1+' instead of 'add1'. CL needs a quote (or something else) before the argument to the function to avoid trying to evaluate it. But that's basically it. You can do this for other examples in that manual too, including more complex ones.

To me, a "dialect" implies that you're in the same language but some users of that language just say things a bit differently to each other. "Howdy" vs "Yo". So "add1" and "1+" might be an instance of a dialect change from 1960. For Common Lisp, "sb-ext:run-program" would be the SBCL "dialect" / implementation's way of running an external program while "run-shell-command" might be Allegro CL's. Is Scheme's call/cc a dialect of Lisp60's prog and go? Clojure doesn't have goto at all.. Racket is much cooler than standard Scheme and has nice packages like https://docs.racket-lang.org/control-manual/index.html but is that a dialect equivalent? At what point does the C equivalent of all the above just become another dialect on the way Lisp says it? (And if you're using Common Lisp as the basis Lisp... do Clojure and Scheme have regional dialects that let them say what CLOS says, or what the condition system says, with minor changes?)

As I said at the top I don't think it matters that much, when people talk about "a Lisp" I just assume they mean something with an s-exp syntax and macros, when people talk about "implementing Lisp" I assume they mean "implementing [a] Lisp" but I kinda wish they meant Common Lisp. Such a loose definition raises the question why other langs are described as Algol-like or C-like and never "an Algol" or "a C", or a dialect of either, but whatever.

I think perhaps to some degree, people read "Lisp stands for LISt Processing" and internalize this as a kind of shorthand (in spite of any formal naming), so it becomes natural to call any language that operates primarily through lists, and represents source code directly as nested lists, "Lisp".

As an essayist I've found the abstraction of thinking in terms of "lisp" being about "list processing" to be very helpful when reasoning about and abstracting ideas precisely.

Lisp can have almost zero syntax, so can last a long time and be picked back up quickly, I've found.

This doesn't necessarily mean lines-of-code is the most productive immediately; as much as there is resistance to it from current (i.e., 2018March17) mainstream programmers, hyperdimensional programming (i.e., 2D+, and higher in VR) like with Unreal Engine 4's Blueprint, are likely going to win out with pure advancement of results, perhaps (that is, creating effective art quickly).

Imagine finessing functions of different shapes in VR, rather than lines of text code.

Good list. I'd add macros and the conditions mechanism for error handling. The latter still has no analogue in other languages.

> The latter [the conditions mechanism for error handling] still has no analogue in other languages.

Could you explain this for a non-Lisp person? (I have some understanding of macros already.)

The CL condition system separates the signaling of a condition (of which errors are a subtype), the handling of a condition, and the definition of recovery strategies (restarts).

Instead of unwinding the stack when a condition is signaled, handler code is invoked in the dynamic context of the signal and thus has much more information available to decide how to recover.

If a decision on how to recover can't be made programmatically, the system kicks out to the user where they are presented with the choices you have given them.

See: http://www.nhplace.com/kent/Papers/Condition-Handling-2001.h... for more.

> Honestly curious why Lisp has so much admiration and praise on HN.

Paul Graham and Robert Tappan Morris, two of the founders of YCombinator, love Lisp/Scheme. They got rich by selling their company Viaweb to Yahoo. You guessed it: Viaweb was written in LISP and Paul Graham believes that this was their secret weapon:

> http://www.paulgraham.com/avg.html

Also the software that drives Hacker News is written in Arc, a Lisp dialect that was invented by Paul Graham.

So Hacker News and YCombinator are indeed at least historically very attached to Lisp/Scheme.

Which promptly got rewritten after pg left.

EDIT: From the years being here, and having played with LISP myself, it's a language that appeals to a certain type of programmer, who claim to find it very productive compared to other languages.

And everyone else hates it.

So you pick a LISP language you're severely limiting your hire pool.

>So you pick a LISP language you're severely limiting your hire pool.

I'd rather have 5 very good Lisp programmers than 50 code monkeys.

I'd rather have 5 very good programmers (using ANY language) than 50 code monkeys (using ANY language). The problem with the Lisp programmers is that they very likely would not be able to work as a team.

I think this claim has no base. I've worked with Lisp programmers and there was no special problem doing so.

I might even prefer 5 average lisp programmers to 50 code monkeys.

The whole point of picking Lisp as a language for many people is to have a hiring pool of small but good programmers.

Also Y Combinator is a technique to do recursion on lambda calculus which lisp is built upon.

Haskell (and other functional languages) is also built on the lambda calculus. Lisp isn't special in that regard.

So what? 10000+ companies were successful with software not written in Lisp. Biz success is not decided by the programming language you use.

The OP lists several features Lisp had decades before they were common to find in more widely used languages, so some of it is for historical reasons. There are two things lisps, including Scheme and Clojure have that are weak or absent in most popular languages:

One is macros. Being able to transform code before it is run using the language's built-in data structures provides a solution when the language just doesn't have the abstraction you need. Used properly, this can be invaluable. Used improperly, of course, it can make a mess.

The other is REPL-driven development. Most languages have a REPL, but they don't really embrace it the way Lisp does. I find this frustrating. Why is my editor on my PC not talking to the app running on my Android phone and letting me see its state and make changes in real time?

> Why is my editor on my PC not talking to the app running on my Android phone and letting me see its state and make changes in real time?

All my opinion, of course: The time (cost) required to create such easily available introspection is too high for the comparatively small gains. REPLs in modern languages (when even implemented) are just so often a completely separate mode of operation.

The gains from Lisp-like support of live-environment programming are not small, but they are hard to communicate succinctly. The costs are real, but not onerous for a language designed to support such features.

But a person designing and implementing programming-language tools has to deliberately choose to provide the needed features because implementing them after the fact raises the costs and lowers the benefits. That means such a person must believe that the gains are worth the cost. The only people likely to believe that are people already familiar with those kinds of systems.

On a fundamental level, there's not much difference between Lisps and any other language with real runtime eval. It's just that, say, in your average JS project you're going to have a lot of state all over the place, state that depends on side effects. I don't think Lisps do much to solve that. Clojure helps by discouraging state and side-effects, namespaces let you have everything sort of be a global in a manageable way.

I actually like to use the 'repl' module in nodejs. With a little bit of effort, you can make the dev experience much easier.

The great Lisp and Smalltalk systems are designed from the ground up with the assumption that a programmer may at any point inspect and possibly change absolutely anything in the dynamic environment of the running program. Everything is designed to facilitate doing that with the reasonable expectation that the program will continue to work correctly. Such systems are designed for writing software by modifying a program while it runs.

That basic assumption is a giant knife-switch that pervasively affects everything in the language and environment. Consider, for example, the generic functions CHANGE-CLASS and UPDATE-INSTANCE-FOR-CHANGED-CLASS. Those functions are in the Common Lisp language standard. That makes no sense unless the standard assumes that a Common Lisp system can modify a program while it runs.

Only a minority of programmers want such systems, but to be fair, only a minority of programmers have worked with them enough to understand them.

Not everyone prefers that style of programming, but most programmers will probably never have the opportunity to find out whether they prefer it. I did have the opportunity, and I learned that I did prefer it. I still prefer it thirty years later.

Get back to me with a Clojure or JS environment that does what I miss from a great Lisp or Smalltalk environment. Let me trigger an error and walk the call stack to inspect parameters and intermediate results. Give me a keystroke to get a list of every other piece of code that calls the function with the error--don't make me wait more than about a second for the list. Let me interactively edit the values on the stack in the suspended computation or, better yet, change their types (and have them properly reinitialized), then resume the computation. Let me redefine a function that's on the call stack and then restart the call using the new definition. Let me serialize the entire dynamic state of the program to disk, copy it to a colleague's machine, and start it up to show my colleague the same error in the same dynamic environment. Let me do all of that interactively without needing to leave the original break loop triggered by the original error. Oh, and package the tools as a single modest-sized executable that I can run with a simple command line or a double-click, that launches in a couple seconds or less.

I don't know of such a Clojure or JS environment. If you do, I would be grateful to learn of it.

Sorry to reply to myself, but when I awoke this morning, it occurred to me that above I am describing my daily-driver programming environment from early 1988, Coral Common Lisp (except that who-calls wasn't built in; it was a contrib).

Besides the previously-mentioned features, I could build a windowing UI by dragging pieces together. I could build the resulting native-code app for delivery by choosing "Save" from a menu. I could write WDEFs (the code resources that defined window shape and behavior) and other low-level stuff interactively in Lisp. I could patch arbitrary calls with assembly code written and debugged interactively in the Lisp environment (one of the SK8 authors was previously an assembly-language video-game programmer; he was ecstatic about this feature of CCL).

Comparing my current daily-driver development machine to the one on which I was using Coral Common Lisp in 1988, the new machine has twice the word size, 400 times the clock speed, 16,000 times as much RAM, and 400,000 times as much disk space.

Meanwhile, the development tools are in many ways worse, rather than better.

I haven't used Coral Common Lisp, but I've used SBCL. It does have much of what you're describing, and I do have to wonder why it didn't catch on with a wider audience.

There's a general belief in the tech community that better tech wins. When something works better, hackers will start using it, and if there are incidental barriers, they get solved. None of the explanations I've seen have been satisfactory; I reject the both the idea that Lisp isn't really that big an advantage and that the average hacker isn't smart enough to see it.

SBCL is great. I use it often.

I don't think the proposition that better tech wins passes the laugh test. You could argue that I'm a cynical old curmudgeon, though. I've been writing software for a living for thirty years now.

It's not about hackers being smart enough to see Lisp's advantages. It's about them (1) being the sort of programmer who prefers programming-as-teaching over programming-as-carpentry, and (2) getting enough exposure to live-programming environments to see what the deal is. The important advantages are not immediately obvious. They're whole system synergies, and it takes time and experience to grasp the nature of stuff like that, regardless of how smart you are.

Plus, maybe there are just more carpenters than teachers.

It's not just about having eval(), it's also about having tooling to exploit its capabilities. I'm currently learning OpenGL with CL, and if I make a change to my main loop, I just hit a few buttons to recompile it without interrupting anything. As soon as it's finished compiling my loop silently switches over to it and the output reflects the new version of the loop.

I have a Discord bot written in CL. If I want to add a new command or feature, I write it, hit a few buttons, and it seamlessly integrates with my bot without interrupting anything it's doing.

If I have a problem with a macro, I can hit a button to have it expand right there in my code, and when I see the problem I hit a button to unexpand it.

The editor will even catch errors and ask what you want to do, without interfering with other threads, which has been very useful while developing my bot.

I should point out that clojure-android provides exactly that. The tools are not currently maintained and it is quite difficult to get a development environment set up these days, but once running, it works very well.

It's strange from my perspective to see REPLs as a separate mode of operation. Yes, there's a little overhead, and it's something you might want to strip or disable from a production build, but the overhead is small in the context of a modern application language. Contrast with something like Electron.

This style of development makes the feedback loop between the programmer's mental model of how things work and a reality check extremely tight. It's one of those things like TDD that often changes what kind of programs you write.

Perhaps it has features that Python, Go, Node, and even Perl do not have. The reader is built in the same language as the rest of the compiler which means you can change it: you don't have to fork and compile a new version of a Lisp compiler to parse a completely different syntax or interpret a new kind of grammar. It has amazing error handling in its conditions and restarts system. It has the best OOP system I've ever used: being able to run the game I'm making, change a class definition of an entity and have all the live instances update while the program is running... is quite awesome. It's still one of the best developer-experience languages out there. The tooling is amazing.

The fundamental structures underlying Lisp are quite solid. I like the distinction Phil Wadler makes: Lisp was discovered while languages like Python were invented. Everything in Lisp fits well together. Other languages in this vein are Haskell, SML, OCaml, etc. You can spot these languages because all of their features are usually built from the primitives of the language. An invented language forces the inventor to try and remember how a new feature may interact with all of the others... and sometimes it doesn't work out.

Perl 6 has hygienic macros, so you can count Perl out of that list.

Also Perl 6 is written in itself.

We are getting to the stage now where a lot of languages are catching up with the features that lisp had in the 70's, so the huge benefits of lisp aren't quite as obvious as they used to be.

>so the huge benefits of lisp aren't quite as obvious as they used to be

They still haven't caught up. I don't find any other language that gives at least 3 of these features

- Fully interactive development -- i can recompile/redefine a function while the code is running

- Fully interactive OOP development -- i can recompile/redefine a class while the code is running

- OOP system based on multiple dispatch/multimethods

- true metaprogramming done using the same language's syntax, not a special, cumbersome lib.

- execution speed on par with the JVM and sometimes approaching C speed.

If you find yourself in such a scenario, then you haven't reached the enlightenment level.

Reaching for a "safe and familiar" procedural/imperative language is like most people reaching for a claw hammer when they wish to hammer and nail something in. To most people, it's the same, they are just hitting something.

To a pro, they know when they reach for their claw hammer, a sledge hammer, a mallet, a ball pein, club hammer or cross and straight pein.

If you have a text file that you just need to slice and dice. The tool to use is awk/sed/tr/cut, or perl. Got rules? prolog. Got massive array data? APL. Got multiple massive array data that you wish to combine and separate in various ways? SQL. Surely, you can use python for all those things. But should you?

> If you have a text file that you just need to slice and dice. The tool to use is awk/sed/tr/cut, or perl. Got rules? prolog. Got massive array data? APL. Got multiple massive array data that you wish to combine and separate in various ways? SQL. Surely, you can use python for all those things. But should you?

Arguably, yes, most especially when several of them apply to the same process, rather than to separate pieces of data.

Likewise, an argument can be made that developers should reach for Excel more often, because Excel is what the business world knows and uses.

We have so many great, specialized tools. But the act of development often bifurcates into "problems that don't have to scale, or even present a great interface" and "problems that need extensive customization at every layer and support millions of users" and our stacks reflect that.

So tooling choice is often more dependent on maximizing leverage while setting appropriate cutoff points for scalability - in almost all production scenarios you are better off simply to design the system down to the featureset of available off-the-shelf tooling and anticipate a hard break where it migrates upwards, versus thinking you have to boil the oceans immediately so that all facets can be transitioned smoothly and all features are possible right now.

I'll definitely agree there - especially for admin interfaces. I'm so sick of developers creating extremely rich admin interfaces that use insane amounts or REST services to save and load settings that can really just be an Excel file in the git repo that is loaded by a library. I've seen companies that build $40,000 worth of admin interfaces that ended up being used by a temp to populate some back-end settings. The temp that was hired was probably paid $3000 to do the work, and now the admin interface is going to be retired.

Paul Graham is a Lisper and made his fortune with a Lisp application. Moreover, he wrote a widely-read essay claiming that Lisp was the secret weapon that enabled his startup to outcompete its rivals. In that context, it shouldn't be suprising to find sympathy for Lisp in discussions hosted by Paul Graham's firm.

Lisp is quite practical for solving day-to-day problems, as long as you are a knowledgeable Lisper.

And 10000+ other people/companies have made fortunes using programming languages other than Lisp. So what's your point?

I was replying to submeta, who said:

> Honestly curious why Lisp has so much admiration and praise on HN.

So my point is that Paul Graham says Lisp was important in his success. His success was important in the creation of Y Combinator and therefore of Hacker News. So we should not be particularly surprised that readers of Hacker News include many that are favorably disposed toward Lisp.

submeta also said:

>But I would not think of Lisp when it comes to solving day to day problems.

...so I mentioned that Lisp is quite practical for day-to-day programming, if you know it well. For what it's worth, I've been using it for day-to-day programming for thirty years.

I've been programming for 10+ years, tried many different languages and just don't get the appeal of Lisp. Swift for example is simply more productive and fun to use in most use cases. Same with Haskell.

I don't believe PG's claim that Lisp made a significant difference in productivity for them.

I also don't believe PG's claim. I know Common Lisp, Scheme and Clojure well enough to be able to say that. Also, lots of people/companies made fortunes not using Lisp. So PG's claim proves nothing.

How well do you know lisp?

Hard to tell, not an expert, not a beginner. Enough to conclude that other languages are more productive for me.

>why Lisp has so much admiration and praise on HN. I played around with Scheme some long time ago, read SICP, learned a lot

Just consider that, while being a very beautiful language, Scheme is different to Common Lisp.

If you are faced with doing a production system, you'll feel the benefits of Common Lisp, particularly now in 2018 where the tooling and libs are much better.

Scheme can do everything that CL can do IF you add a ton of extensions and libraries and stick to a particular scheme implementation. So you would have a "custom" platform. Where as with plain-vanilla Common Lisp you would have all these features but in a totally standardized way.

Peter Norvig, a serious lisper, calls Python "an acceptable lisp": https://news.ycombinator.com/item?id=1803815

Regarding that[0]:

At ILC 2002 former Lisp giant now Python advocate Peter Norvig was for some reason allowed to give the keynote address like Martin Luther leading Easter Sunday mass at the Vatican and pitching Protestantism because in his talk Peter bravely repeated his claim that Python is a Lisp.

When he finished Peter took questions and to my surprise called first on the rumpled old guy who had wandered in just before the talk began and eased himself into a chair just across the aisle from me and a few rows up.

This guy had wild white hair and a scraggly white beard and looked hopelessly lost as if he had gotten separated from the tour group and wandered in mostly to rest his feet and just a little to see what we were all up to. My first thought was that he would be terribly disappointed by our bizarre topic and my second thought was that he would be about the right age, Stanford is just down the road, I think he is still at Stanford -- could it be?

"Yes, John?" Peter said.

I won't pretend to remember Lisp inventor John McCarthy's exact words which is odd because there were only about ten but he simply asked if Python could gracefully manipulate Python code as data.

"No, John, it can't," said Peter and nothing more, graciously assenting to the professor's critique, and McCarthy said no more though Peter waited a moment to see if he would and in the silence a thousand words were said.

0: http://smuglispweeny.blogspot.com/2008/02/ooh-ooh-my-turn-wh...

If you read that post he actually didn't say that. He moved from Lisp to Pseudocode to Python for his co-written AI Book (AIMA).

If you also look at the pseudocode or the python code, it's not very Lispy. Python more or less is used on a level of an object-oriented BASIC.

https://www.quora.com/Where-did-we-go-wrong-Why-didnt-Common...

In the above answer to a question in Quora, he seems to suggest that most of the features in lisp eventually got adopted in most other mainstream languages. Or in other words the concept of 'acceptable lisp'.

I get what you are saying, and I feel the same way. But I think what people try to imply here- If you are using Lisp for a certain set of features, most of them are now available else where.

> Today, all those features, except for macros, are common in the popular languages.

But not in the same language and/or less well integrated.

Example: mostly no popular language has flexible macros as tightly integrated in the language as Lisp has. Those who have macros, either have a different view on macros and/or have them as preprocessing steps.

You find very few languages with generic functions. There are lots of attempts to add them to languages like Java, but they are mostly experiments and not used.

Similar for Common Lisp exception handling mechanism. Very few language have that.

More direct influence languages like PERL6, Julia, R etc. look and feel very different from Common Lisp.

Even if you think language have features like Clojure has a REPL - but it lacks the Lisp interpreter, the integrated error handling, the break loops, ...

It's not the number of components, it's the integration. You can bolt wings to a ship, but the thing won't fly well.

Perl is not an acronym, Larry wanted to call it Pearl, but there was already a language by that name.

Also we tend to prefer Perl 6 to be spelled with a non-breaking space before the 6. [U+A0]

Perl 6 has features from many sources, so it is indeed a departure from Lisp.

Sorry, I mis-remembered his position. Thanks for the correction.

I agree. I understand and have programmed in Common Lisp, Scheme and Clojure. And yes I fully understand macros. I even implemented Lisp style languages just for fun (using C++ and Haskell). But I never wanted to use it for production code.

Lisp seems to be optimum for team sizes of one. Maybe two or three if they are very "world view" compatible or have a dominant "alpha" dog. But using it for large scale development?

'One' seems to be false.

You can program in teams with ten or in companies with hundred Lisp developers. Usually the team size does not need to be that large.

Lucent for example developed a Lisp based network switch (similar to what Ericsson did later with Erlang) and they had around 100 developers. It was competing with a much larger team developing a similar product in C++.

ITA had around 100 developers for their flight search in Lisp.

Symbolics had at its height around 1000 employees and my guess would be that 40% were Lisp programmers.

Personally I'd say there would be little problem working in a team with ten Lisp developers - you just have to find or educate them.

I second this, I actually find the whole s-expr thing a bit lacking, now that the Kool-aid faded off.

Ultimately, what I really love are expression oriented languages, and the ALGOL/C and APL families have alternatives with a more succinct and expressive syntax (Perl, K).

One might also argue that Scheme is a poor man's Forth.

That depends heavily on what your day to day problems are.

If you work in a complex or rapidly evolving domain, I cannot think of a better choice than Lisp. If you are doing a lot of text processing or writing CRUD apps, then you will probably not get much benefit.

>If you work in a complex or rapidly evolving domain,

or if you are creating a big system that needs to work reliably and be able to be corrected (patched) while it's operating

Reply on news.ycombinator.com