Hacker News Reader

Comment by pmoriarty | Hacker News Reader

The objections the author had way back in the day are no longer the objections programmers of mainstream languages have to Lisp today.

Today the objections I hear are more along the lines of:

1 - All those parenthesis. (Still a top objection)

2 - Lisp doesn't look like or work like what I'm used to.

3 - Lisp doesn't have as many libraries as the most popular mainstream programming languages.

4 - There aren't nearly as many Lisp programmers, so it'll be hard to find more to join your project/company if you use Lisp.

5 - There aren't nearly as many Lisp jobs, so why bother learning Lisp if you're going to have a hard time finding work using it?

6 - Lisp is ancient, and anything that old is useless and primitive compared to new and shiny languages.

View on HN

Using Lisp (in the form of Racket) for many years in a production environment, I've observed:

1. People do complain about the parentheses but they generally get to work dealing with them right away. It's the loudest complaint, but it doesn't really even slow people down.

2. This is a similar complaint, and does scare people off from jumping in if they have a real choice.

3. Racket in particular solves this one to an extent. We've used it with Redis, JSON, MySQL, Perforce, etc etc productively. More commentary below, though...

4. This one is a non-issue as far as I've seen. If you hire someone who can program, then can quickly learn and be productive in Lisp.

5. This is tied in with 4, a non-issue.

6. This is an issue with perception. The problem is more that people believe they know something about Lisp because they've heard of it, and they come in with the expectation that it'll be weird or difficult, which is a bit of a speed bump to getting to work right away.

Ultimately the biggest issue we've seen is that the broader ecosystem of organizations using Lisp (or Racket) in production environments is missing. As such, there are many sharp corners that you have to file off yourself as you deploy your usage. Useful resources like Stack Overflow just don't have the answers prepackaged because it's likely you're the first to use Perforce to deploy a precompiled version of your Racket application on Windows (for example).

It's easy to underestimate just how much work people have put into making ecosystems in C++, Java, and Python contain all the pieces, experience, and knowledge you'll need to solve your particular problems quickly and effectively.

Another pieced missing along with that ecosystem: outside of the implementation of the language itself, no one has taken an application of significant size and age and added a major feature to it. This is something that happens in production all the time -- and it happens on a schedule with a budget. Virtually no one using a small or academically minded languages ever does this, though. And it's not until you try that do you discover all those sharp corners and missing support tools and libraries.

The hesitation I'd have with Lisp(s) as an outsider, which ties in to number 3, is that the language itself is compact, elegant and extensible. It's the opposite problem to C++ (the language is too large) - the language is too small and it encourages you to build other languages inside it. So it'd be very hard to share code with others because as soon as you start building abstractions your language and worldview diverges from everyone else's version of lisp - to use a library you have to learn someone else's mini-language. Maybe this is an invented concern though, did you find integrating other libraries a problem?

Did you have any problems with development speed or performance in production or was that fine?

With Racket, at least, the language encourages you to build very small pieces and assemble them into larger systems. It's fairly straightforward to connect the pieces together to share code.

It does also encourage you to create mini-languages, but our approach was usually a large amount of modular Racket-y code with many fairly thin layers of syntax transformation used in each mini-language case. In that sense the problem of mutually incompatible languages didn't really arise (in fact, separate mini-languages coincided with separate usage areas quite well).

Performance was an issue, and we generally needed to use the precompilation feature of Racket to be successful. The issue we ran into is that Racket's precompilation system produces fairly fragile and coupled binary files -- and is generally difficult to separate cleanly from the execution environment.

"Lisp is small" without being specific about the dialect is meaningless.

ANSI Common Lisp's one and only 1994 standard is over 1000 pages long. The Scheme reports are a lot smaller, though growing. I think still under 100 pages.

I developed a Lisp dialect that has a dense reference manual that is over 530 pages long with no table of contents or index.

I think that objection is likely true of scheme. Scheme is like the Assembly language of lisps. To build it up to the level of usefulness requires a lot of wheel re-inventing, and those wheels are likely to be not quite standard.

Clojure and Common Lisp are larger languages and don't really suffer this problem.

However, mainstream machine languages have defined orders of evaluation and specified results.

That's not really the case for R6RS, and now R7RS Large.

Both of those have huge swathes of libraries and make the language quite large.

7 - It's too easy to make a mess. And the mess made by brilliant people who are looking for any excuse to put higher order metaprogramming and functional concepts into production is considerable.

8 - It has consistently lost in the marketplace in the last 20 years. We had most top CS grads in North America groomed on SICP at one point in history. You'd think many of them would want to use Lisp in production. Many of them did. Now MIT uses Python to introduce programming, and Lisp code bases tend to be (horrifying) legacy systems. Virtually no startups base the core of their business on Lisp anymore, and it's not because the technical founders aren't aware of it.

(Lots of skunkworks Clojure projects are out there bearing load though.)

SICP uses Scheme, which is not Lisp. It was taught at an introductory level because some concepts of computation can be taught nicely with Scheme, up to making a compiler for another language (perhaps a "real" language in the student's minds?), but it doesn't actually teach you Lisp, and I imagine leaves a bad taste in many students' mouth at the nonsense no-for-looping-no-mutation they had to suffer through which isn't a requirement in Lisp (nor necessarily in Scheme). SICP doesn't even have something as quick to go through as e.g. this series http://malisper.me/2015/07/07/debugging-lisp-part-1-recompil... to get a feel for what it's actually like to work with Lisp.

Clojure has been very successful though it seems like your point #7 would apply more-so to it (since Lisp isn't as functional oriented) unless you mean crazy-in-production things like closures and mapping functions. =P I don't even think you can call all that many Clojure projects skunkworks ones, because the language is quite visibly successful. Something like https://www.ptc.com/cad/elements-direct/modeling you might call a skunkworks success for Lisp...

Not only does SICP use Scheme, but it uses a really old and primitive Scheme, so that's what a lot of students who've only had exposure to SICP think all Schemes are like -- almost a toy language. They usually have no idea what a modern, full-featured Scheme like Chicken Scheme or Racket is like: light years ahead of the Scheme used in SICP, with a rich ecosystem of libraries.

"SICP uses Scheme, which is not Lisp." --- is that a "no true Scotsman" argument or do you just mean "Scheme is not Common Lisp"?

I mean Scheme is not Common Lisp, and Common Lisp is Lisp. Both are "a Lisp" (as is Clojure), or perhaps "a dialect of Lisp", but it's questionable if that really means anything beyond s-exps and macros.

Why does Common Lisp get the distinction of being the "true Lisp" and not Scheme? Scheme precedes Common Lisp by almost a decade

This Lisp I code is from 1959/60.

http://bitsavers.informatik.uni-stuttgart.de/pdf/mit/rle_lis...

Page 101:

    DEFINE
    (((COLLAPSE,(LAMBDA,(L),(COND,((ATOM,L),(CONS,L,NIL)),
    ((NULL,(CDR,L)),(COND,((ATOM,(CAR,L)),L),(T,(COLLAPSE,
    (CAR,L))))),(T,(APPEND,(COLLAPSE,(CAR,L)),(COLLAPSE,(CDR,L))))))))

This is the Common Lisp version. Formatted, comma removed, DEFUN instead of DEFINE.

Other than that the code is unchanged. It still works in Common Lisp.

    (DEFUN COLLAPSE (L)
      (COND ((ATOM L) (CONS L NIL))
            ((NULL (CDR L))
             (COND ((ATOM (CAR L)) L)
                   (T (COLLAPSE (CAR L)))))
            (T (APPEND (COLLAPSE (CAR L)) (COLLAPSE (CDR L))))))

    CL-USER 191 > (collapse '(1 2 (3 4) ((5 6) 7)))
    (1 2 3 4 5 6 7)

Common Lisp is backwards compatible to Lisp I and Lisp 1.5 in many ways.

Code like that can be relatively easy ported to Scheme (naming and syntax is slightly different). There are examples which are more difficult. But generally simple (!) Scheme is not that far away from that old core.

Naggum has a pretty good answer for that, linked in the other comment branch: http://www.xach.com/naggum/articles/3224964049435643@naggum.... You could also argue based on things like Common Lisp can run LISP code from 1960 with a very small driver, or the general history of code porting and sharing, as done here: https://news.ycombinator.com/item?id=9387131#9404543

I read that answer, I didn't find it helpful on two points.

1. There's this really nice analogy about German and English languages, but it doesn't have any specifics. In particular, the crux of his entire argument is in this statement

> The two languages and their attendant communities have drifted so far apart that there is nothing of value in their intersection.

Which he simply states as fact without any sort of follow up or justification. And I disagree. Consider this Common Lisp snippet from Wikipedia computing the answer to the birthday paradox:

  (defconstant +year-size+ 365)

  (defun birthday-paradox (probability number-of-people)
  (let ((new-probability (* (/ (- +year-size+ number-of-people)
                               +year-size+)
                            probability)))
    (if (< new-probability 0.5)
        (1+ number-of-people)
        (birthday-paradox new-probability (1+ number-of-
  people)))))

Literally replace "defconstant" with "define" and "defun birthday-paradox (probability number-of-people)" with "define (birthday-paradox probability number-of-people)" and that's valid Scheme.

I'll readily admit they are two different languages, but pretending they are as different as C and Python or something is absurd.

2. Even if you convince me these two languages are so different, there's nothing here to convince me Common Lisp deserves the title of the "real Lisp" or "true Lisp". Scheme can also run LISP code from 1960 with a very small driver.

Is it that absurd? Where is Scheme's CLOS, condition system, built-in debugging framework, and batteries-included standard library? Type declarations? Dynamic scoping? Multi-methods?

Maybe Racket (or Chicken or Chez or Guile or...) has all of these things, Racket is pretty awesome, but those things aren't standardized, whereas I can get those things in Lisp regardless of if I use SBCL/Clozure/clisp/etc. Maybe it's closer to the difference between C (with a bunch of different compiler extensions) and C++ than C and Python, but it's a pretty big difference.

Ultimately I think the claim of Common Lisp being the "true Lisp" is simply that deciding such a thing was the whole point of Common Lisp. Without a standard, you're left with someone writing http://wiki.call-cc.org/eggref/4/multi-methods#examples (or http://wiki.call-cc.org/eggref/4/fast-generic) and someone else writing https://docs.racket-lang.org/multimethod/index.html and neither being able to share code with each other. Most code isn't as trivial as the birthday paradox.

Would you want to try writing a (R6RS) Scheme driver for that 1960 code and see how straightforward it is?

Where do you slot https://en.wikipedia.org/wiki/Dylan_(programming_language) ? Should it be in the running for "the true Lisp"? If not why not?

I agree they are pretty different languages, and you give some solid points as to why: CLOS, dynamic scoping, multi-methods, etc. My point was your link mentioned exactly none of those examples, in fact gave no examples at all, and so wasn't very convincing.

The second point that the argument that Common Lisp is the "true Lisp" because that's why it was made is a faulty syllogism. Just because that was their goal of creating Common Lisp doesn't necessarily mean that is the case.

And Common Lisp isn't the only language with a standard: Scheme had an IEEE standard less than a year after ANSI Common Lisp, and has several RnRS updates since then.

Long story short, I don't think any language should be considered the "true Lisp". Maybe the original Lisp, but even then only as a technicality. And trying to declare a language as the "true Lisp" comes off as a little insulting to related languages and a little bit arrogant. It implies, to a certain degree, that you look down on other languages as lesser, inferior, failed attempts to reach the true zen of Lisp. I'm sure you didn't mean it that way, but as a fan of Scheme (and Common Lisp too!) it reads that way.

Maybe there's no platonic ideal Lisp, and that's the problem, since the thing that makes programmers feel good is some vague sense that there is such an ideal. A sort of god. ;) On the level of communication and definitions though, it seems totally reasonable to me that if your goal as a community of all sorts of versions/dialects of Lisp is to unify into one standard, then you get to call your new unification the Lisp.

I see your point about arrogance, though I think the insulting tone could be turned around easily -- you have these Lisp-like languages that don't even have Lisp in their name nor a lot of Lisp's crucial features trying to appropriate/claim an inheritance on all the hard work and glory and name recognition that went into Common Lisp and its predecessors. Let them have their name. I'm a pretty big fan of Clojure (and do like what Racket is doing when I read up about it) but imagine trying to sell Clojure to an old Lisp hand with "it's like Lisp" and watching them type (inc "a") vs (1+ "a"). https://pastebin.com/kBfNvxei vs https://pastebin.com/hPB2cy1X and there's no contest. (You might win them over with further persistence but they'll probably be wondering where all their favorite parts about Lisp are in this so-called Lisp-like.)

>Is it that absurd? Where is Scheme's CLOS, condition system, built-in debugging framework, and batteries-included standard library? Type declarations? Dynamic scoping? Multi-methods?

Does Lisp from 1960 have these things? Then I guess it isn't really Lisp?

How I see it, Lisp 1.5 was Lisp, but as time went on and many 'versions' of Lisp for different systems with different capabilities came into being, there was no longer really a singular Lisp. Then there was a great unification that spit out Common Lisp, and that became Lisp. So if Lisp 1.5 was released today as something new, it wouldn't be Lisp, but merely another Lisp-like. It's too different. No one today thinks that if you drop "Lisp" in a conversation you really mean Lisp 1.5. (Maybe if you write it as LISP...) It's either going to mean Common Lisp, or maybe a reference to the vague Lisp Family. I don't think Lisp will ever be synonymous with "Scheme".

Maybe you'd appreciate some Lisp history, to also answer your question about "what other dialect[s]"?

http://www.paulgraham.com/thist.html

http://lispm.de/30ycltl

I do know some of the history. I was just asking those questions as a challenge. Regarding the question of the other dialect, the parent used the term as a way of distancing Scheme from what I assume is the one true Lisp: Common Lisp. But the point the passage they had an issue with noted two dialects. The other, of course, being that one true Lisp.

The way I see it, the things that make Lisp "Lisp" are not exclusive to either one. One might say that the intersecting characteristics aren't interesting, but these characteristics are what Lisp is truly about.

SML and Caml are both ML. Haskell 98 and Glasgow Haskell are both Haskell. Dyalog APL and APL2 are both APL. And so on.

He was just giving those as examples of ways in which Scheme and Common Lisp differ. Which is a fair point. Of course it does raise the question: are those features essential attributes of the Platonic ideal that is True Lisp, or simply nice addons Common Lisp provides?

Yeah, that's what I was getting at.

No, but the Common Lisp of 1984 has much of the Lisp of 1960. It's backwards compatible in many ways.

> Even if you convince me these two languages are so different, there's nothing here to convince me Common Lisp deserves the title of the "real Lisp" or "true Lisp"

It's the lineage of Lisps where Common Lisp is in, which is Lisp:

Lisp I, Lisp 1.5, Standard Lisp, Interlisp, Maclisp, New Implementation of Lisp, ZetaLisp, Spice Lisp, Common Lisp, Emacs Lisp, ISLisp, ...

Those are all compatible to some extent and share a common core. Code moved a lot along these dialects. Macsyma had been written in Maclisp, moved to Zetalisp, then to Common Lisp. Reduce was written in Standard Lisp and then was ported to Common Lisp (without adoption). Hemlock was written in Spice Lisp and moved to Common Lisp. LOOPS was written in Interlisp and then moved to Zetalisp and later Common Lisp. CLOS was written in Common Lisp and was moved to Emacs Lisp and ISLisp. Even much of Common Lisp was moved to Emacs Lisp. ISLisp can be implemented as a package in Common Lisp relatively easily (Kent Pitman did this to check that ISLisp is compatible and has nothing which is not 'easily' implementable).

It was also usual that some Lisp implementations ran multiple Lisp dialects side by side, sharing everything: data, memory, I/O, ... For example Interlisp-D had a Common Lisp implementation side-by-side with Interlisp. The Symbolics Lisp Machine ran Zetalisp and four variants of Common Lisp side-by-side.

Then there are a lot of derived languages which either have different syntax, different semantics, different data structures, etc.

Examples are Logo, MDL, Scheme, Racket, Dylan, ML, Clojure, Javascript and a bunch of other languages.

Scheme initially shared some code with Lisp. Dylan tried it with a Lisp transpiler, ML initially was written in Lisp, ...

> Scheme can also run LISP code from 1960 with a very small driver.

The old Scheme is relatively near the Lisp mainstream, the newer Scheme less and less. Twenty years ago there was some code sharing between Lisp and Scheme, now almost none.

For me there are two definitions of Lisp:

* the main line compatible and sharing Lisps

* the general abstract family of Lisp which share an undefine subset of a set of features: lists, s-expressions, lambdas, parentheses, ... But you can find lots of languages in the larger Lisp family which have only a rough subset of this, like Javascript or Logo.

So when somebody says "I am going to write some Lisp now", in your mind they are always going to write Common Lisp?

I'm guessing the latter.

> SICP uses Scheme, which is not Lisp.

Wikipedia [0]:

> Scheme is a functional programming language and one of the two main dialects of the programming language Lisp.

[0]: https://en.wikipedia.org/wiki/Scheme_%28programming_language...

Keyword: dialect. But Erik Naggum, 2002 [0]:

> The "Lisp" Scheme is a dialect of is no longer the current meaning of "Lisp". It is somewhat like calling English a dialect of German because of ancient history that has since between invalidated by each of their separate evolution, Fahrvergnügen, Weltanschauung, Kindergarten, and Pennsylvania to the contrary notwithstanding. There is also a very limited value in talking about "Germanic languages" in terms of your actual ability to use any of the Germanic languags. You do not order the "vertebrate" in a restaurant, but generally choose between fish or bird or meat. In other words, there is a time when an abstraction and a commonality has completely ceased to be valuable.

[0] http://www.xach.com/naggum/articles/3224964049435643@naggum....

I think Erik Naggum was a bit imperialistic in wanting 'Lisp' to mean Common Lisp. One nice thing Clojure did was to revitalize the Lisp-as-language-family meme.

I feel like there should be a "No True LISP" fallacy in CS...

It expresses pretty much all of the core principals of a LISP. If it looks like a LISP, thinks like a LISP, behaves like a LISP; then do you really gain anything by trying to separate from other LISPs?

Is Python a LISP? Is JavaScript a LISP? Is Java a LISP? What do you mean by LISP, by its core principles? What does a different set of core principles look like that lends itself to a different family? I threw in my vague classification above: sexps and macros. But you can have macros without sexps, and sexps without macros (lots of "toy lisp interpreters" do that), are they LISPs? Lastly one wonders why we don't go calling all these C-like languages ALGOLs. What do you gain by trying to separate from other ALGOLs?

Or less extremely, why don't we consider Python and Ruby to be the same family, or Java and C#? Those pairs are arguably more similar than the pair of Common Lisp and Scheme.

Is Picolisp a Lisp? Is Newlisp a Lisp? Is Emacs Lisp a Lisp? Maybe it's because I first learned programming in the 1980s in BASIC, but I'm pretty used to the idea of programming languages having dialects. Apple ][s, Commodore 64s, and Atari 800s all supposedly were programmable in BASIC, but it didn't mean you could take a program written on one and expect to run it without changes on another.

Surely that's the whole point - it's a dialect, so it has the same core but not 100% so you have to translate some of it to get to the other.

The dialects of Dutch in Belgium contain completely different words and phrases - but the core is still Dutch.

But for large parts of the speech they are recognisably similar.

So I'd say yes all the lisps you mentioned are dialects of Lisp. You can't run one directly in the other, but they are reconisably similar programming constructs.

Sorry - I think I was just proving your point...

> Lastly one wonders why we don't go calling all these C-like languages ALGOLs.

Referring to the broad Algol-family isn't uncommon (well, at least, I do it quite a bit.)

> Or less extremely, why don't we consider Python and Ruby to be the same family, or Java and C#? Those pairs are arguably more similar than the pair of Common Lisp and Scheme.

Java and C# are frequently described as being part of a single close language family (much closer than the broad Algol-family; sometimes in an intermediate-breadth family that also includes ), and Ruby and Python are much less similar than Scheme and Common Lisp.

Lastly one wonders why we don't go calling all these C-like languages ALGOLs.

We sometimes do though, don't we? Not that terminology, but I often see the people talking about "curly brace languages" or "C/C++/Java/C#".

Sure, we see there's a grouping, and might identify it when trying to create a cluster, but it's not as pervasive as the Lisp Family meme. When Clojure came out, it was advertised as "a Lisp" (not "Lisp", but "a Lisp"). When Go came out, it wasn't advertised as "an ALGOL", or "a curly brace language". What makes so many programmers want to associate only good qualities with this floaty abstraction of "Lisp" (that isn't simply Common Lisp) such that the arguments over how Lispy Clojure/Scheme/EmacsLisp/whatever inevitably keep happening, such that things can advertise as "a Lisp" and get attention despite not having some pretty core Common Lisp functionality? The only other language I see something similar to that is with Python. Go programmers say it's like programming Python but loads faster and with type security, Nim programmers say it's like programming Python but loads faster and with type security, I may have even heard something similar from an OCaml user once, but you look at either of them and they're both missing key Pythonic features.

Edit: In hindsight at the end of the day I should have been more careful with the "Scheme is not Lisp" (at least I didn't say "Scheme is not a Lisp") comment...I'm only continuing these threads because I read the original submission pretty close to when it was posted and back then I only knew a bit of SICP, tried enough Lisp to duplicate some SICP examples, and was frustrated with the Lisp-2 syntax along with what I perceived as a REPL freakout on any error so I put Lisp aside. It would have been helpful for someone to tell me "Scheme is not Lisp" back then and get me to actually explore all that Common Lisp has to offer.

What is the other dialect?

To be fair, all code bases tend to be horrifying legacy systems if you wait long enough, and "long enough" is pretty much always shorter than the amount of time you'd want the system to still be in use.

I strongly suspect that it is possible for a language to be too powerful.

The more capacity a language has to let you do wonderful things, the more capacity it has to let you do truly awful things as well. ("With great power comes great responsibility" and all that).

Also, something about the expressivity of the code means that your code is wonderful, but other peoples code is potentially a nightmare.

> 1 - All those parenthesis. (Still a top objection)

If you actually count parens fairly you will find that Lisp has no more than any other language, it's just that other languages use a mix of parens, square brackets and curly braces whereas Lisp only uses parens. Also, if you really don't like parens, you can get rid of a lot of them using macros. See e.g.:

https://github.com/rongarret/ergolib

and in particular the binding-block (BB) construct.

> 2 - Lisp doesn't look like or work like what I'm used to.

Neither does anything else until you get used to it.

> 3 - Lisp doesn't have as many libraries as the most popular mainstream programming languages.

That used to be one of my objections, but it's simply not true any more. And with Quicklisp accessing the (very large) collection of available libraries is incredibly convenient. (Thanks Zach!)

> 4 - There aren't nearly as many Lisp programmers, so it'll be hard to find more to join your project/company if you use Lisp.

That becomes a self-fulfilling prophecy. But it's no harder to create new Lisp programmers than it is to create new X programmers for any other value of X.

> 5 - There aren't nearly as many Lisp jobs, so why bother learning Lisp if you're going to have a hard time finding work using it?

Because knowing Lisp is a huge lever for learning other languages. Once you know Lisp everything else becomes a lot easier to learn (but a lot more frustrating too because now you will be aware of the shortcomings of other languages).

> 6 - Lisp is ancient, and anything that old is useless and primitive compared to new and shiny languages.

Chasing the shiny new thing is usually a mistake. Most old things suck simply because most things suck in general. But the things that don't suck continue to not suck even after they become old. In fact, standing the test of time is one of the defining characteristics of non-sucky things.

The part about lisp being primitive was rather silly. Many languages don't have anything close to what Lisp has in its macro system, not even other functional languages, even in those languages with temperating systems. Perhaps Perl 6 comes close (I haven't had the chance to use p6 macros yet) but to say that lisp is 'primitive' is rubbish, unless you're going to claim that case insensitivity is enough to declare a language primitive.

>> 1 - All those parenthesis. (Still a top objection)

> If you actually count parens fairly you will find that Lisp has no more than any other language

Bull. For example, compare the Lisp factorial function from the article:

    (define (fact x)
      (if (zero? x)
          1
          (* x (fact (- x 1)))))

with the corresponding F# implementation:

    let rec fact x =
        if x = 0 then 1
        else x * fact (x - 1)

That's 7 vs. 1 pair of parens.

Also, the problem isn't just that Lisp has so many parens, but that they nest so deeply and quickly. Five nested levels of parens for factorial alone.

F# and all ML derivatives are an aberration because they use juxtaposition to denote function calls. That eliminates a lot of parens but personally I find the result less readable.

But compare to, say, C where no one complains about the parens:

    int fact(int n) {
      if (n==0) {
        return 1
      } else {
        return n*fact(n-1);
      }
    }

That's six pairs of parens. The only reason it's not more is because some function calls in C are disguised as operators, and those just happen to be the functions that factorial uses. If we wanted a semantically equivalent function that handled bignums you'd have to write:

    bignum fact(bignum n) {
      if (bignum_is_zero(n)) {
        return n;
      else {
        return bignum_multiply(n, fact(bignum_subtract_1(n)));
      }
    }

Now you've got nine parens. But still no one complains about C because of that.

> F# and all ML derivatives are an aberration because they use juxtaposition to denote function calls. That eliminates a lot of parens but personally I find the result less readable.

It makes a lot of sense when all functions are curried. Parenthesised function calls treat all of these as different things:

    f(a, b, c, d)
    f(a, b, c)(d)
    f(a, b)(c, d)
    f(a, b)(c)(d)
    f(a)(b, c, d)
    f(a)(b, c)(d)
    f(a)(b)(c, d)
    f(a)(b)(c)(d)

If functions aren't curried, then these all mean different things. When functions are curried, all of these have the same semantics (call `f` with `a`, call the result with `b`, call that result with `c` and call that result with `d`); ML's juxtaposition syntax makes these semantically-identical expressions syntactically-identical too:

    f a b c d

You can curry in Lisp too, and if you do you can get rid of all but one of the unnecessary parens as well.

    (curry f a b c d)

Only if you assume that curly braces function as parens in C, which isn't true.

It's not an assumption, it's a fact. Curly braces serve the same function in C as (some of the) parens do in Lisp.

Yeah, you know what else I'm realizing? All the different kinds of punctuation let my eyes skim over different parts of code so easily, and lisp doesn't give me that.

You know how, when you're reading natural language, you don't actually read individual letters, not once you have any reading fluency? That's how I read code, too, I'm realizing. When I see the parentheses in C#, my brain just goes "oh that's a method/function call" and I can either skip over the contents of the parens or read them if I need to. Reading comprehension is pretty quick.

Looking at all the parens of even that simple lisp factorial, and I realize that I'm feeling a lot of cognitive load that would simply never go away, because the punctuation doesn't let me filter any of it out. I'd have to read everything more carefully.

> Looking at all the parens of even that simple lisp factorial, and I realize that I'm feeling a lot of cognitive load that would simply never go away, because the punctuation doesn't let me filter any of it out. I'd have to read everything more carefully.

Completely the opposite here.

Parens means function call or list. Lists usually denoted by a quote first.

I don't read the parens, I skim everything, reading words. And the punctuation is really simple.

For example:

    if (number? a)
      + a b
      error "Not A Number" a

I stripped most of the parens there, (like Wisp [0] does), because I don't really see them. I see function call and arguments, because there isn't anything else.

Scheme has the very least syntax out of just about any programming language I've used. It has a tiny cognitive load compared to most.

[0] http://dustycloud.org/blog/wisp-lisp-alternative/

>You know how, when you're reading natural language, you don't actually read individual letters, not once you have any reading fluency?

As difficult as it is to imagine, you can indeed achieve fluency in reading Lisp code. Like with everything else, it takes time and practice.

Focus on the words, not the punctuation, just like you do when reading natural language.

You get used to reading lisp, the same as you get used to reading all that boilerplate syntax.

You can replace parens with indentation, yes. There are lisps that do this, like WISP for guile,which provides "implicit parens through indentation".

Then you get the same amount of parens as fsharp. It is even standardised as an SRFI (although not widely.implemented)

Try putting the closing parens on a line aligned with the opening one, as if they were K&R style closing braces (ignoring that open-paren goes before keyword/func-name, rather than after)

    (define (fact x)
        (if (zero? x)
            1
            (* x (fact (- x 1)))
        )
    )

Square brackets work in some dialects, as well:

    [define (fact x)
        (if (zero? x)
            1
            (* x (fact (- x 1 ]

Almost all Lisp code will put the closing parens all together at the end. And the idea is to not care about how many there are by using an editor that provides the appropriate assistance.

> by using an editor that provides the appropriate assistance.

To spell it out: this means Emacs with Paredit, or an imitation thereof.

Having to depend on an editor to make your code legible seems like a bad thing.

Especially since most IDE's seem to go out of their way to make sludge out of the text, unless you have hours to spend training each one, and can figure out how to do so...

... until your coworker edits the file in the out of the box IDE and munges it.

I guess now-a-days, our languages and frameworks are so ugly they need a "bag" over their [inter]face while you are doing them :-)

Why? (And what language do you use where you don't have to rely on the editor to format your code?)

To me, that's a sign that maybe a language has too little syntax.

I can read C++, Javascript and PHP just as well in plain text because the other non-paren elements provide necessary contextual cues, along with nesting. Syntax coloring is helpful, but it shouldn't be necessary.

I can at least understand nesting closing parens on their own lines, the way Roboprog did above, but throwing all of them on a single line just seems like needless noise.

It's not something we ever really think about. That list of closing parentheses just signals termination of the top-level S-expression.

And there's virtually nobody coding in a Lisp that doesn't use a structural editing mode (like Paredit or SmartParens). E.g., any time you type "(", you get "()", enforcing balance.

What we rely on is proper indentation to indicate the important groupings.

Exactly. IMHO, this is quite similar to Python indentation rules, except it is up to writers of Lisp code to be disciplined enough to maintain the proper indentation.

Hmm, my editor does it for me.

Wait, even Lisp does that for me, because it has a built-in source code pretty printer:

Call the pretty printer to format this mess:

    CL-USER 41 > (let ((*print-case* :downcase))
    (pprint '(defun add-text-padding
    (str &key padding newline)
    "Add padding to text STR. Every line except for the first one, will be
    prefixed with PADDING spaces. If NEWLINE is non-NIL, newline character will
    be prepended to the text making it start on the next line with padding
    applied to every single line."
    (let ((str (if newline (concatenate 'string (string #\Newline) str) str)))
    (with-output-to-string (s) (map 'string (lambda (x) (princ x s) (when (char= x #\Newline)
    (dotimes (i padding) (princ #\Space s)))) str))))
    ))

It prints wonderfully formatted and indented code:

    (defun add-text-padding (str &key padding newline)
      "Add padding to text STR. Every line except for the first one, will be
    prefixed with PADDING spaces. If NEWLINE is non-NIL, newline character will
    be prepended to the text making it start on the next line with padding
    applied to every single line."
      (let ((str
             (if newline
                 (concatenate 'string (string #\Newline) str)
               str)))
        (with-output-to-string (s)
          (map 'string
               (lambda (x)
                 (princ x s)
                 (when (char= x #\Newline)
                   (dotimes (i padding) (princ #\Space s))))
               str))))

Now one would only need to fix this beginner level code.

No. Our editors auto-indent the code for us. This is one of the reasons Lisp syntax is better than python. Python syntax does not have enough information to auto-indent so it really is up to the programmer. Not so with Lisp.

I hate when I code python and refactor stuff, moving stuff around and such, that I cant just copy/clip around and then do a final 'indent all my work correctly' like I can in a language like lisp.

I am kind of developing a grudge against whitespace sensitive languages. Not because it forces the programmer to indent properly, but because it disables my editors abilities to do it for me.

Actually, Python has the equivalent of open-parens: the colon. What it doesn't have is close-parens, but if you use emacs then it will outdent on PASS and RETURN statements. In my personal coding style I always put PASS statements at the end of block so my code auto-indents properly. Hard-core Pythonistas hate this, but I really don't care what they think.

Actually I write Lisp code, but I use neither Paredit nor SmartParens. I don't automatically balance my parentheses.

Thanks. Almost nobody liked my comment (downvoted), but it sure kicked off a long discussion :-)

I haven't done any actual Lisp since the 80s on a CDC Cyber mainframe and a dedicated expansion card on an Apple II, so I'm "a wee bit" out of date.

I'm very visual / "geometric", so I like to see the "shape" of things. I can't stand looking at stuff "formatted" (?) in the typical enterprise java (8) "staircase of doom" with minimal whitespace, incredibly long lines, with a few arbitrary line wraps that indent to random spots way off on the right.

I swear, many programmers have never considered how newspapers and textbooks are formatted. They don't sprawl text endlessly across even if the paper is wide, they keep it reasonably narrow so your eye can follow it.

Seriously, if you would have showed me the text of the code I'm working on now when I was a year into college in the early 80s, I think I would have changed my major.

To any lisp enthusiasts who wonder why the language family isn't more popular: this is 99% of why. You have to use an editor where "copy" is called "Kill-ring-save" is invoked with "Meta-w". Any attempt to use any other tool will be met with incredulous responses to "just use Emacs".

It's such a shame because the development environment for Lisp could be so much better than other languages. It could be mindblowingly futuristic, instead of mindblowingly archaic.

I've just started using Clojure (another Lisp) and I use IntelliJ IDEa with the Cursive plug-in, with par-infer to deal with the parens.

It works like a charm. I can have a REPL and my code right in front of me, I can cmd-down to go to a function definition, and it's overall a very pleasant developer experience.

Now, I did experiment with Emacs, so I do understand what you're talking about -- kill-ring-save and the related key bindings made zero sense to me, and I was having trouble doing things I'd do easily in IntelliJ.

> You have to use an editor where "copy" is called "Kill-ring-save" is invoked with "Meta-w"

You are misinformed. I'm using a GNU Emacs (-> Aquamacs) on the Mac and cut/paste/copy are invoked with the usual command keys. But usually I use the LispWorks editor, which is also in the Emacs family, and even there cut/copy/paste is the usual command sequence... Both editors are built with excellent Lisp support. One is written in C + Emacs Lisp and the other one in Common Lisp.

> mindblowingly archaic

You haven't even understood the old part, how would you be able to deal with the futuristic part?

> You haven't even understood the old part, how would you be able to deal with the futuristic part?

"You haven't used a PDP-10, how would you be able to deal with a smartphone?"

He didn't talk about old technology like 'smartphones', which existed as products (Nokia Communicator, ...) 20 years ago, but claimed that much better 'futuristic' IDEs for Lisp are possible, though what he claims may currently only exist in his imagination...

Any large piece of software will have its own terminology (car, cdr, frame, window, buffer, yank, kill, meta, ...). It is a shame that people would rather fixate on these superficial things instead of the minimal effort to get familiarized.

I've been programming in Lisp for 17 years now. I've always done it in Vim.

my sincerest condolences

+1, couldn't agree more. Especially about Quicklisp: Zach had an idea, implemented it, and made the lives of most CL programmers easier.

To me the hard part about lisp is that every programmer that uses lisp tailors it so to their own taste that it can become quite hard to read the 'top level' of a lisp program without first having gone through all the lower layers. It is as if every project in lisp somehow magically develops its own DSL. That's a high hurdle for newbies to clear.

Sounds like a common objection to C++, where the language is so large that every team chooses its own subset of features they'll use, and ignore the rest :)

That's much less of a problem, because if you know the whole thing, then any subset of it is also known. It only becomes a problem if you need to change the code, because then you have to be aware of the subset to restrict yourself to.

C++ actually has a similar problem with developing idiosyncratic in-house solutions to common problems - it's not uncommon to find hand-rolled collections, reference-counting pointers etc, especially in older codebases from before STL and Boost became more widely accepted. But because the language doesn't offer anything close to the flexibility of Lisp macros, those idiosyncrasies are also much easier to parse.

I don't know anyone who claims to know the whole of C++.

Knowing the language itself is not that hard. It's big, but manageable. Obviously there will always be corner cases where you need your language lawyer hat (and the copy of the Standard), but those exist for pretty much any language.

The library is more complicated, especially once you get to iostreams and locales. But also less of an issue in this scenario.

> It is as if every project in lisp somehow magically develops its own DSL. That's a high hurdle for newbies to clear.

I'm not sure it is, most Lisp code I've seen is very readable, and you don't need to understand the internal most of the time.

Like in Scheme, if the function name isn't followed by a !, then you can assume that it is functional, so you don't need to worry about anything other than input and output.

So you end up with DSLs like:

    > (read-html (string-as-port "<h1>Hello, World!</h1>"))
    = '(h1 ("Hello, World!"))

It's a DSL, it's created a non-standard list at the end, an X-Expr, but it's readable, and predictable, without me trying to work out the internals of how a string-port functions, or how read-html works beyond it reads from a port.

Does the other way really scale though?

I mean, the "state of the art" is to have readable code everywhere. What readable really means is "have each component defined in terms of the standard library". This involves a lot of repetition and a lot more code, with the advantage that any part of the program can be understood by a new programmer.

The Lispy/Bottom Up way is to write a language, then solve your problem in terms of the language you just wrote. Only at the very low levels are you really dealing with standard library stuff. The advantages are obvious, but the disadvantage of this is you have to learn the DSL as well.

Have you experienced both approaches?

Fortunately, JEE & Spring are MUCH easier to get started with :-)

Let them eat COBOL...

Cobol, that's where you get your CICS! The original heavyweight framework, callbacks and all. Loads of fun.

> The objections the author had way back in the day are no longer the objections programmers of mainstream languages have to Lisp today.

> Today the objections I hear are more along the lines of:

> 3 - Lisp doesn't have as many libraries as the most popular mainstream programming languages.

Amusingly one of the "objections" to Common Lisp when it was standardized was its absurdly large library. Things sure look different today.

I have to say though that many languages have a large number of libraries, the quality is, naturally, variable.+ The real library strength of a language is the power of its standard library. (Admittedly some of that can come via lore or acculturation, e.g. numpy. On the other hand, what legs will, say, react have? Who knows?)

+ no examples because I have no desire to insult anyone -- rather thanks for releasing your code!

The number of bad libraries doesn't affect the number of good libraries, so that is still an important distinction. Also, if an average quality library is good enough that I don't need to spend a few weeks doing it myself, that's still a bonus.

To be fair, the one time I decided to do something biggish and kinda important in Lisp, I stopped at #3. Not exactly because "it does not have many libraries", but because "library for X, Y and Z are not there and I don't want to write them".

Oddly, Haskell has a similar problem, but going through C code by the FFI does not feel like a problem. I don't think why it does in Lisp, it may be just a matter of better documentation.

Clojure has a good selection of libraries, and similarly can call into any Java library pretty easily.

There's also Hy (hylang.org) which is kinda Clojure-in-Python giving you access to the Python library ecosystem.

The only difference of using Hy instead of Python are the macros though. What can you do easily with macros that is cumbersome to do with regular Python?

Macros aside, Hy removes the single statement limitations of Python lambdas and the reliance on indentation. The fact that it's a Lisp also introduces a higher level of composability.

I can vouch for rackets FFI, for what it's worth.

I'm working on FFI for TXR Lisp. Until this morning, it was in the stage of "collection of working API functions, written in C, exposed with Lisp bindings".

I have almost everything I want working, including callbacks. There is a decently rich type system which supports pointers that annotate data passing directions for automatic malloc and free, and this works in both directions: out calls and callbacks (closures).

I support by-value passing and returning of structures. And also of C arrays! Even though C doesn't have by-value arrays. You see, my FFI type (array 42 int) is actually equivalent to the C type struct __anon { int __anon[42] } and not the C type int [42].

Just this morning, between 6 and 6:45 a.m I wrote a partial implementation of the FFI declaration language. Here is what it looks like, with actual output:

Load the under-construction FFI macros:

  (load "ffi")

Define a show macro for showing an an expression and its value as expr -> value:

  (defmacro show (expr)
    (let ((val (gensym)))
      ^(let ((,val ,expr))
         (format t "~s -> ~!~s\n" ',expr ,val)
         ,val)))

Now the FFI test. Some structures we need, and declarations of FFI typedefs for them giving type info. The above typedefs aren't required; we we could just write out the (struct ...) syntax inline in the later FFI declarations.

  ;; Lisp struct representing C struct ldiv
  (defstruct ldiv nil quot rem)
  ;; FFI typedef for it
  (deffi-type ldiv (struct ldiv (quot long) (rem long)))
  
  (defstruct pipe nil rfd wfd)
  (deffi-type pipe (struct pipe (rfd int) (wfd int)))
  
  (defstruct dirent nil
    ino off)
  (deffi-type dirent (struct dirent
                             (ino int)
                             (off int)
                             (nil (array 62 int))))
                             ;; the member named nil here is anonymous padding

Now, declare some FFI functions. Very succinct and expressive:

  (with-dyn-lib (libc "libc.so.6")
    (deffi c-abs "abs" int (int))
    (deffi ldiv "ldiv" ldiv (long long))
    (deffi c-getenv "getenv" (buf 3) (str))
    (deffi c-getenv-2 "getenv" str (str))
    (deffi wcslen "wcslen" ulong (wstr))
    ;; Two ways to call pipe: using a pointer to two-int
    ;; structure, or an int[2] array. They are binary identical.
    (deffi c-pipe "pipe" int ((ptr-out pipe)))
    (deffi c-pipe-2 "pipe" int ((ptr-out (array 2 int))))
    (deffi c-read "read" int (int buf int))
    (deffi c-read-str "read" int (int (ptr (array 10 char)) int))
    (deffi opendir "opendir" cptr (str))
    (deffi readdir-r "readdir_r" int (cptr (ptr-out dirent) (ptr-out cptr))))

Finally, the test: with two lines of interactive input from the TTY to satsify two read calls from file descriptor 0. For both of these, I enter the text abc[Enter]:

  (show (c-abs -42))
  (show (ldiv 47 6))
  (show (c-getenv "HOME"))
  (show (c-getenv-2 "HOME"))
  (show (wcslen "foo bar"))
  (let ((pi (new pipe)))
    (show pi)
    (show (c-pipe pi))
    (show pi))
  (let ((pi (vector 2)))
    (show pi)
    (show (c-pipe-2 pi))
    (show pi))
  (let ((buf (make-buf 5 #xa0)))
    (show buf)
    (show (c-read 0 buf (length-buf buf)))
    (show buf))
  (let ((str "xxxxxxxxxxx"))
    (show str)
    (show (c-read-str 0 str 10))
    (show str))
  
  (let* ((de (new dirent))
         (dp (cptr 0))
         (dir (show (opendir "."))))
    (show (readdir-r dir de dp))
    (show de)
    (show dp))

Output:

  (c-abs -42) -> 42
  (ldiv 47 6) -> #S(ldiv quot 7 rem 5)
  (c-getenv "HOME") -> #b'2f686f'
  (c-getenv-2 "HOME") -> "/home/kaz"
  (wcslen "foo bar") -> 7
  pi -> #S(pipe rfd nil wfd nil)
  (c-pipe pi) -> 0
  pi -> #S(pipe rfd 4 wfd 5)
  pi -> #(nil nil)
  (c-pipe-2 pi) -> 0
  pi -> #(6 7)
  buf -> #b'a0a0a0a0a0'
  abc <-------------------------------------- TTY input
  (c-read 0 buf (length-buf buf)) -> 4
  buf -> #b'6162630aa0'
  str -> "xxxxxxxxxxx"
  abc <-------------------------------------- TTY input
  (c-read-str 0 str 10) -> 4
  str -> "abc\nxxxxxx"
  (opendir ".") -> #<cptr: a34e118>
  (readdir-r dir de dp) -> 0
  de -> #S(dirent ino 669944 off 1)
  dp -> #<cptr: a32a258>

Look what is happening in (c-read-str 0 str 10). We pass in a Lisp string which contains "xxxxx...". Magically, it becomes "abc\nxxxxxx..." after the read, as if we were working in C. This is because the type for the parameter (ptr (array 10 char)). The FFI framework recognizes arrays of char and makes them correspond to strings in a two-way manner.

That's a great look-and-feel :)

How does memory management work? Do you have self-destructing structures (AKA automatic pointers) on the Lisp side?

It's all manual memory management in the FFI layer, driven by the semantics of the type expressions. The type expression syntax is compiled to a tree of objects. Those objects are walked before and after a FFI call to do the right actions related to memory management, encoding and decoding. Any temporary buffers needed by FFI are cleaned up by it. The Lisp objects going in and out are stock Lisp objects without any special memory management related to FFI.

6: Lisp is ancient. It really is.

Also on the front page of HN today: SQL is 43 years old.

So, exactly what is the problem with being ancient? Nobody objects to SQL on those grounds. So I suspect that 6 is really "I want to object, and I found a plausible-sounding reason to do so". (It could be people who actually evaluate stuff based on how new it is. But I'd prefer to think that there aren't people who really evaluate languages that way...)

1) You can become familiar with the parentheses. One might say, "all that white space" about Python, but that doesn't make Python any less powerful a language.

2) It does not look like what you're used to, but it certainly can work like you're used to since it is a multiparadigm language. Of course, programming Lisp like you program C or Python loses a lot of the power.

3) As a Lisp programmer, this is my biggest gripe.

4-5) True. If you aren't a contractor/freelancer that can choose your tools, Lisp is a hard sell.

6) Lisp is ancient. That said, the rest of the programming world has yet to catch up to the some of the concepts in Lisp like conditions or CLOS. Many of the "advances" in the new shiny languages have been in Lisp for decades.

1. Lisp have less symbols than other language

  (defun averagenum (n1 n2 n3 n4)
     (/ ( + n1 n2 n3 n4) 4)
  )

  function averagenum(n1, n2, n3, n4){
    return (n1 + n2 + n3 + n4)/4
  }

Lisp 9 vs 13 JavaScript(excluding keywords and return)

2, 3 ,4 , 5, 6 -> Chicken and egg problems, Lisp is not popular enough an this makes things difficult.

Lisp real issues are:

  1. Fragmentation: Scheme, CL, Clojure, ELisp, Racket...
  2. Tooling: package manager, build system, support outside emacs.
  3. Concurrency and safety: some do better than other but added to late.

True, but the issue is that most academic and vast majority of paid coding roughly looks like the JavaScript example (C/C++/Java/JS/etc) - so to most the Lisp style looks odd and hard to parse, not the raw symbol count.

Lisp style is more elegant, almost everything is either data or function. Other languages you mention are massively more complex and difficult to understand. For me C++ is some kind of clusterfuck of symbols/keywords/operators and plain magic.

After you learn prefix notation, Lisp is super easy. Unfortunately in the world were "worse is better" we discard beautiful and smart: Smalltalk, Lisp and ML. Instead we build our towers of Babel using PHP, JavaScript and C++.

It is so ridiculous that people choose to spend whole career using PHP because it is easy learn.

It is not.

When it comes to learning anything, we humans have a massive tendency to prefer that which is familiar. This means that when a human is faced with an obstacle and must choose between:

- An unfamiliar tool or paradigm which is custom built to solve this and all future problems (should they arise) such that time and effort is saved

- A familiar tool which has been extended this one time to solve this one problem, and which can be inellegantly extended to solve future problems potentially at the cost of time and effort

People will almost always pick the later.

Yes.

If you introduce basic Lisp like (+ 2 2) to kids that don't know infix arithmetic yet, it's very revealing.

I find the argument that Lisp needing fewer symbols means that it's simpler to be suspect. Imagine if we took English, and replaced all punctuation with parentheses. Would it be "simpler"? In some very academic way, probably. I'm not at all confident it would actually be easier to read.

This is really something that needs input from people who professionally deal with the way our brains process visual information, especially text. It might be that there's value in having more varied and fancy punctuation, e.g. because the differences between ( and [ and { serve as anchor points for visual pattern matching.

It would be interesting to have an experiment whereby people not previously exposed to any PL have to analyze a code snippet in, say, Lisp vs JS vs Python side by side, and discover its structure (e.g. by drawing it as a block diagram).

For me it's not the paranthesis, but that Lisp posts always show low level code. At least half of my programming is tying together high level services and libraries. I know how I can express those concepts succinctly in Java, C++, JS, Swift etc. I'd love to see some examples of Lisp for something like a REST controller, where I call services, repositories etc.

> At least half of my programming is tying together high level services and libraries. I know how I can express those concepts succinctly in Java, C++, JS, Swift etc. I'd love to see some examples of Lisp for something like a REST controller, where I call services, repositories etc.

You should look at Racket. Racket is a Scheme-like[0] Lisp that aims to be "batteries-included". It includes things like a web-server out-of-the-box.

[0] it is technically a hybrid of R5RS and R6RS, so pedants can argue over whether it is really "a Scheme" or not.

> whether it is really "a Scheme" or not

It's not and it's not about being pedantic. Racket changed its name nearly a decade ago and, at that point, it already wasn't Scheme either.

I have a post about where Racket (and Clojure) come from: https://klibert.pl/posts/clojure_and_racket_history.html

> I'd love to see some examples of Lisp for something like a REST controller, where I call services, repositories etc.

Not exactly what you're looking for, but take a look at my post: https://klibert.pl/posts/racket_quickie.html

It shows a little JSON-based REST service which stores a list of messages and allows listing them and adding to them. With more URLs you'd likely use something like this: http://docs.racket-lang.org/web-server/dispatch.html for dispatch, instead of hand-coded function.

It's notable for only using stdlib, no additional packages (beyond purely syntactic, Clojure-like, `~>` support).

To be honest, the APIs exposed in the stdlib feel kind of awkward - like using SimpleHTTPServer in Python. Still, it's just a couple of lines and easy (automatic, in this example) in-process concurrency is not bad.

I have written an example web application for my cloud computing lecture. The code is not pretty nor 100% functionally and there are some bugs, but it shows how my applications work. It's just for demonstration purposes and therefore kept simple.

https://github.com/dak0rn/Zwitscher

Feel free to shout me questions or remarks.

Edit: Here's a simple endpoint that uses a service which then works with the database;

https://github.com/dak0rn/Zwitscher/blob/master/src/zwitsche...

As a response to your objections,

1) It's just a syntax thing... It's still possible to make an understandable program through good style

2) I don't have anything.

3-6) I've heard Racket is a good spiritual successor to Lisp, complete with external libraries and a broad(er) userbase.

For (2) ("Lisp doesn't look like or work like what I'm used to") I have something:

* Lisp does look quite a bit like stuff you're used to:

  foo(bar(arg,          (foo (bar arg        <foo><bar>arg
          arg2),                  arg2)                arg2</bar>
      xyzz());               (xyzz))              <xyzz/></foo>

* Lisp does actually work a lot like stuff you are used to: evaluation of argument expressions to argument values, which are passed by value: much like C or Java. Functions return a value or multiple values.

It has familiar features like mutable lexical and global variables, control constructs for selection and iteration and so on. There is even a form of goto.

Aggregate objects like structures, class instances, lists, vectors and so on are actually referential values, like in many languages.

It is said that Javascript is a dialect of Lisp. If you understand how Javascript evaluates expressions, that goes a long way toward Lisp. Ruby is sometimes called MatzLisp, after the surname of its creator, for very good reasons. Lisp has inspired many features found in other languages. The comma, ?:, && and || operators in C appear to be Lisp inspired, as is the very idea of "expression statements": for instance when we call a function in C as a statement, it is an expression with a value, which is discarded, just like in Lisp.

Lisp lists lack encapsulation; they are not opaque bags with which you do things like (add list item). That takes getting used to: always capturing the result value of a list construction. It doesn't take that much getting used to for programmers coming from C, who understand a bunch of ways of representing lists, including representations in which a null pointer represents an empty list.

A container-like list data type is easily written in Lisp, either as a function-based ADT with a couple of functions around small state struct (or perhaps cons cell or vector), or full blown OOP.

> Lisp lists lack encapsulation; they are not opaque bags with which you do things like (add list item). That takes getting used to: always capturing the result value of a list construction.

You're conflating two properties: lack of encapsulation and functional update. It's true that lists expose their internal structure as conses, and it's also true that they're usually updated functionally (requiring, as you say, capturing the result), but these properties don't have to go together. It's entirely possible, and arguably desirable, to have functional collections -- where instances are immutable, but which provide operations for creating new instances from existing ones -- which are also opaque data types; see for example FSet [0]. Conversely, it's possible to have fully-mutable lists that expose their internal structure; you just have to wrap each list in a mutable cell. It would be ugly, and I don't know why you'd do it, but it's entirely possible.

[0] https://github.com/slburson/fset

You're right; encapsulation doesn't mean mutable state; it means combining code and data (making a capsule).

Lisp list aren't ... whatever you call those stateful collection things that you can mutate with a list.add(42) type code that people are used to in a lot of scripting languages nowadays. That will trip up people who are used to that sort of thing.

Yeah, back when I tried Common Lisp #3 was a stumbling block. I hear Clojure solves that problem pretty well, maybe because it's a little more mainstream than other lisps and also because my understanding is it's pretty easy to work with existing Java libs from Clojure.

I guess the stuff about parentheses that's highly confusing in Lisp is that x is different from (x). Outside of that, it's just ordinary grouping.

In JavaScript it's confusing that these are different:

  function(x) { return x; }
  function(x) { return x; }()

To reduce confusion, JavaScript programmers follow the Lisp convention and put parens around expressions like the latter. Once you take the 5 minutes needed to get used to the difference between x and (x) it's actually less confusing than popular alternatives.

> All those parenthesis. (Still a top objection)

I'm glad for its parens. Would never have checked out Haskell (and gotten into purity&lazy-eval) if Lisp's syntax was like Haskell's (no mandatory braces except by choice, no mandatory parens except by choice --- indent is enough and in practice we all mostly end up indenting all code in all languages anyway, so.. works for me)

The parenthesis go away pretty fast once you start writing. I remember it took me a day or so. Mind you I mostly work in Clojure where parentheses are not used everywhere (function airity is described using a vector [ ] for example).

You left out a rather glaring objection:

7 - Lisp has a tendency to lure programmers up the river of insanity [0] due to the sheer power of macros (particularly reader macros). This can leave the rest of the team (or any successors) struggling with a mountain of technical debt. Overall, I think the power of Lisp makes it difficult for a community to organize without a BDFL to keep everyone on the same page.

[0] http://tvtropes.org/pmwiki/pmwiki.php/Main/RiverOfInsanity

Yeah, this seems to be a common objection, but in my experience of actually having used a lisp (Clojure) in production, this was never a problem. Sure, you'll likely still end up with some technical debt, but no more than the Java project's we had at the same company. And not because of macros.

When people first learn about macros, they go crazy trying to do all kinds of things that weren't possible without macros. But once developers gain a little experience with macros, they learn to use them judiciously and tastefully.

Clojure has a BDFL (Rich Hickey) and it lacks reader macros. It's kind of the exception that proves the rule.

To be fair, though, the macro-based River of Insanity newbie Lispers sometimes travel down is rarely based on reader macros.

I think one problem with certain 'declarative' styles, is that imperative code is, in a sense, temporarily ordered.

When you lose this, you need to replace it with some other enforced order, that helps you navigate the code.

Think how much debugging is based on locating buggy code by walking through the execution path and/or data-path. When you lose that kind of strictly linear execution, you still need a layer of heavy modulation to compensate.

Consider reaching a state of https://www.emacswiki.org/emacs/DotEmacsBankruptcy you can easily modify the editor in any way from any file, so you really need to use in-build tools to navigate how the environment is affected by the config files.

_My_ main objection to lisp is that it's confusing.

I don't mean the syntax is hard to grasp. I mean the way it looks. It becomes very confusing when the program grows in size.

This is not unique to Lisp. It applies to all dynamic languages that don't have strong tooling support (IDE's with intellisense).

(Maybe I am wrong about Lisp being dynamic; my only experience has been with "arc"; and I have had someone tell me before that common-lisp has static types)

I used to be happy about programming python and javascript in a plain text editor (vim).

However, as I was doing my first intermediate size project, I realized that I've hit a limit.

My project was in Javascript (frontend) and I couldn't keep track of what was going on anymore. Each unit of code is understandable on its own but the whole thing is a mess to look at. When I need to change the inputs or outputs of a function, I have no idea if I've done it correctly or not; due to the lack of type checking.

I absolutely need to make sense of what is what. Having everything look the same makes me confused. And I've come to realize that tooling support is of the utmost importance. Having an editor like vim with cool tricks is nice, but what I really need is to "rename variable" or "rename function" automatically across all usages in the project.

If every feature of a programming language syntax can be used in about 100 kilobytes of code, and your project is 3000 kilobytes, that's a 30:1 "sameness ratio" at best. If you use every language feature in that program, any 3% (if not more) of your program will look the same as some other 3%.

Most programs don't exercise every language feature throughout most of their code, so their pieces look even more self-same than that.

In Lisp, we have to learn to factor in the identity of the operators into what is "same": learn not to see (defclass bear (animal) ..) as being the same "same" as (block foo (init) ...).

When you're reading Lisp code, you're seeing chunks like this:

    xxxxxx xxxxxxxxxxxxxxxxx
       xxxxxx xxx xxxxxxxxxxxxxxxx
              xxxxxxx xxxxxxxxxx
                xxxxxxxxxxxxxxxx
              xxxxxxxxxxxxxx
                xxxxxxxxxx

You have to train yourself to see the upper left corner of this blob before any other processing:

    (defun xxxxxxxxxxxxxxxxxx
       xxxxxx xxx xxxxxxxxxxxxxxxx
              xxxxxxx xxxxxxxxxx
                xxxxxxxxxxxxxxxx
              xxxxxxxxxxxxxx
                xxxxxxxxxx

The meaning of the rest of it depends on that one; it has to look different from other blobs that have something else in that corner.

I never thought that I would miss writing C, but writing Python in a fairly large system, I miss the type checking.

Some of the ease of use of dynamicity is paid back in the added costs of writing more tests.

In my experience a big downside of highly dynamic languages that let you hack the language itself, including Python and Lisp, is that they give programmers quite a bit of room to shoot themselves in the foot by designing language-altering atrocities. On the Python system I currently work on, I've found atrocious uses of metaclasses that make classes behave in unintuitive ways.

Don't get me wrong, I love using Python and Lisp for my own projects, and I don't like Java very much, but I've come to appreciate its one big advantage for large software systems: it limits the damage that can be done by mediocre programmers.

> When I need to change the inputs or outputs of a function, I have no idea if I've done it correctly or not; due to the lack of type checking.

Well, the good news is Common Lisp has runtime types and some implementations even support limited forms of compile time checking.

The Common Lisp Object System allows you to use classes. One then gets nice runtime errors.

    CL-USER> (defmethod add ((a number) (b number)) (+ a b))
    #<STANDARD-METHOD COMMON-LISP-USER::ADD (NUMBER NUMBER) {1003ECEF53}>

    CL-USER> (defmethod add ((a string) (b string)) (concatenate 'string a b))
    #<STANDARD-METHOD COMMON-LISP-USER::ADD (STRING STRING) {1003FDC323}>

    This works then:

    CL-USER> (add 1 2)
    3

    Now this will get a runtime error, because there is no method for these arguments:

    CL-USER> (add "1" 2)

One can also declare types. For example that something is an integer or a subset of integers...

    CL-USER> (defun baz (a)
               (flet ((foo (a b)
                        (declare (integer a b))
                        (+ a b)))
                 (foo a "b")))

The SBCL compiler then complains, that above code has a type error:

    ; in: DEFUN BAZ
    ;     (FOO A "b")
    ; 
    ; caught WARNING:
    ;   Constant "b" conflicts with its asserted type INTEGER.
    ;   See also:
    ;     The SBCL Manual, Node "Handling of Types"

This could be simply familiarity. Back in the 80s I wrote a large system (100s of Kloc) in Common Lisp (Cyc) and it was clear and easy to follow...for a Lisp programmer.

I don't say "familiarity" as some sort of insult. I find human-generated Lisp, Forth, Postscript, and TECO clear. I find APL code impenetrable, but I know my APL-using friends (well, some Well Street variant) find it as clear as a bell. And machine-generated C code is, well, opaque.

Now what I like about the lisp syntax is precisely what (if I understand you correctly) don't: it fades into the background so I can concentrate on the algorithm. This means the C/C++ code (mostly C++ these days) I write for myself or in my small workgroup is visually unlike traditional style guides:

    node*
    foo(node& first, node& last){
      if(first_fails_qualifier(first))         return nullptr; 
      if(last_fails_qualifier(last)  )         return nullptr;
      if(!some_other_precondition(first, last) return nullptr;

      // OK, we have valid arguments
      ...do some processing on the args...

      return (wanted_first_p() ? &first : &last);
    }

I find the aggressive use of { on its own line distracts; you want the interesting stuff in your fovea (so the preconditions are easy to scan; the algorithm is set apart, and the return clearly returns one type, doing a late discrimination).

but YMMV

Have you tried Cursive for Clojure lately? It does a lot of the things really well

They are IDEs, and if you think about it for a minute, Lisp languages have to be the easyest to implement IDEs for, as their syntax is exactly the AST and easy to parse.

> if you think about it for a minute, Lisp languages have to be the easyest to implement IDEs for, as their syntax is exactly the AST and easy to parse

I wouldn't think the parsing stage has ever been the top bottleneck or chief complexity/complication for IDE/tooling developers..

Learning lisp or functional programming is more of a conceptual experience than a practical one.

That is not to say it is not practical to learn lisp, but the state of the programming world as it is today makes it so that it is less practical to learn lisp than it is to learn about say something like java.

If you ever have to write JavaScript, a fairly practical and widespread language, the functional paradigm proves to be highly useful.

But luckily in newer versions, sane features like modules are introduced that are syntactic sugar over the trick with closures that have to be used to fake them. And things like Promises instead of passing callback functions everywhere.

The functional paradigm in Javascript is used everywhere because that's all there was.

I have used javascript extensively. I can tell you the functional paradigm is almost NEVER used in javascript. Javascript just contains libraries, features and concepts brought over from functional programming but I have never seen anyone program javascript functionally..

If a single one of your functions in javascript contains more than one imperative procedure you have exited the functional paradigm.

Reply on news.ycombinator.com