Hacker News is written in Arc, same as it ever was. It's a good day when I get to spend a few hours working on it.

More importantly, would you please not start programming language flamewars on HN? What you posted here reads like a caricature of the kind that was tedious 15+ years ago. As a community, we've come pretty far in clambering out of that swamp, so I'd not like to fall back into it.

A state of the art compiler [1] in quantum computing has not been rewritten in its 8 years of existence. This is accompanied by a quantum computer simulator that runs on the world's biggest supercomputers. [2] Multiple quantum computing companies use Common Lisp, and their software was written in a fraction of the time and resources taken for competing companies to do the same in either C++ or Python.

Things like Coalton [3] really make Lisp stand out. What other language is able to add Haskell-quality types to their language?

Lisp is not popular, so it doesn't have as much labor going into it, but for the work that does, remarkable results are achieved. Lisp does have a lot of the dubiously claimed power, but that power still requires reasonable engineering work to achieve—work that a lot of hobbyists are unwilling to do in their free 4 hours on the weekend.

[1] https://github.com/quil-lang/quilc

[2] https://github.com/quil-lang/qvm

[3] https://github.com/coalton-lang/coalton

> their software was written in a fraction of the time and resources taken for competing companies to do the same in either C++ or Python.

Can you clarify what Python and LISP software (with the same scope) are you referring to?

Lisp software like QUILC (linked) and Python software like Qiskit.

They have the role of taking general quantum programs (usually called "quantum circuits"), and translating+optimizing them for a particular quantum computer architecture (i.e., one that might only have a small number of supported quantum operations).

It's analogous to a language like C having a compiler (written in Lisp or Python) for ARM and x86.

How long did it take to develop both (sorry, but quick googling doesn’t make it clear)?

I hesitate to give quantitative estimates without citations, but to throw a bone, something like: <2 years for Lisp by a small team of 4 relative newcomers. >4 years for Python by a larger team of >10 expert people. The software still does not have feature or performance parity.

"Until now"? Do you really think that this is the first time a Lisp has been used to write an application? Is that because this is the first time you're hearing about it?

The first link is ancient, because CL has fallen into relative disuse, but that doesn't mean Common Lisp was without a purpose until quantum computing became a possibility: https://franz.com/success/ https://common-lisp.net/lisp-companies

You'll notice that most of these aren't user-facing applications or they're extremely specific to a particular industry. Common Lisp itself was standardized largely due to the demand of the US Department of Defense so they would have a single, combined dialect of Lisp for DoD/DARPA projects. That's the sort of language this has always been (entirely out-of-sight, and also for most of its life it was prohibitively expensive). It's similar to Ada, in that sense.

Python obviously does run on those same computers, yes, but most Common Lisp implementations have the benefit of compiling to machine code, while Python is interpreted.

Would you please not post in the flamewar style to Hacker News? You've done it more than once in this thread, and we're trying for the opposite here.

https://news.ycombinator.com/newsguidelines.html

That's not a good reason to post flamewar comments!

Btw if you mean https://news.ycombinator.com/item?id=41206866, that was itself a flamewar comment of exactly the kind we don't want here.

Not sure if it's "impossible to believe," but I suppose everyone else is lying too.

I searched through dtic.mil w/ Google and there's a great amount of reports that detail DoD-funded research and projects that involved Common Lisp. This one is the most unambiguous:

https://apps.dtic.mil/sti/tr/pdf/ADA303486.pdf "The Composite Warfare Model (CWM), a Navy simulation used successfully by the Space and Naval Warfare Systems Command (SPAWAR) and others, uses a fairly radical decomposition in which most attributes and methods are in their own class. Objects may have hundreds of super- classes. Written in Common Lisp, CWM is "linguistically advantaged" for this approach; ..."

An amount of those could've never been used (some are just proposals, and I'm not reading more or searching to see if they went anywhere) but some of them certainly were. It's mostly simulation and planning software, perhaps not mission-critical (I'd think garbage collection would be an obstacle there).

> While I can believe DARPA has/had some connection to lisp (because of early expert systems) it's nearly impossible to believe the actual military has any lisp code anywhere.

It may be hard to believe, but just 7 or 8 years ago while working for DOD my colleagues the next aisle over were maintaining Lisp systems (the whole org was focused on maintaining systems, so I can offer little insight into new work, but probably not much in Lisp). So perhaps it's impossible to believe, but it's true.

Many of my colleagues there (who had been DOD employees for decades) got their start in the "AI Lab" there doing Lisp programming in the 80s.

I have a few thoughts, but in reverence to your sincerity I will offer the example of Google Flights, which as far as I know is still written in Common Lisp.

Now as for my thoughts: every so often when Lisp comes up there is someone who asks 'give me some examples of companies which use Lisp/software written in Lisp' followed by someone giving some examples. That's all good and well but then someone chimes in with the... rebuttal? 'Well, if you have to stretch so much to give examples of Lisp being used that means that it's a dead language not worth using.' ...Or, well, some variation on that theme.

Of course I'm not saying your question is the lead-in to another exchange like this, but after seeing it a few times I get a bit tired of that back-and-forth and it makes me less eager to engage in discussion. I also don't really see the logic behind 'which companies use Lisp?' 'Here are companies that use Lisp:' 'Aha! If you have to list companies that use Lisp it means it's a dying, terrible language!' Imagine that exchange in a discussion of Rust or Python or Kotlin or whatever.

Anyway, sorry for the derailment, just had to get that off my chest. But yeah, Google Flights, ITA Software, just one example of CL in use at a larger player.

I tried Lisp several times.

I really want to like it. Its interactivity is only matched by Smalltalk.

What are the problems I found? First, macros are nice. But they are difficult to write and potentially difficult to grasp. I think you should avoid them almost all the time.

Also, I found that regular Lisp (yes, I know with macros you can change that) is less readable than Python, for example. I struggle to read math with logic in Lisp (inwards-outwards) way more than left-to-right.

Also, the superior interactivity means you have an image. But when I create software I organize things in files, I run them from scratch. In Lisp everything becomes (or tends to become) kind of a stateful environment. It takes more reasoning to reason about current state.

I would say that Lisp is good at two things: DSLs and ast manipulation is way easier than in other languages. If you need that, it is nice. Also, highly experimental interactive programming to try ideas is good with this interactivity. However, creating a system where a level of interactivity for your needs can be created is not super difficult, so you can have a very interactive Python env. for example, except that the object system in Lisp is a bit more interactive. But, do you need that?

All in all, Lisp is a language I struggle reading, powerful for ast manipulation and DSLs, but the macro/DSL parts are what also prevents it from being easily picked-up by teams. In fact, I would forbid macros by default unless carefully approved for "regular" Lisp programming as done in most software products. It can obscure the code quite a bit.

I like Clojure, I like Janet lang and I like Lisps for embedding. Also, I do know the power of having a running server and being able to enter and live debugging it, but, is this practical? At the end you want a commit somewhere, a CI pipeline to be run to verify your software, etc. So I am not sure if when programming in Lisp one of the problems I find is that I should change my mindset but I am not successful at it.

> Also, the superior interactivity means you have an image. But when I create software I organize things in files, I run them from scratch. In Lisp everything becomes (or tends to become) kind of a stateful environment. It takes more reasoning to reason about current state.

Interactivity has nothing to do with an "image". An image is a dump of the memory heap. That's a feature found in several, but not all, Lisp implementations. There are Lisp implementation which support image-based development (like Interlisp). But I doubt that you have used that.

What many Lisp systems actually often are: they are interactive with a resident language environment. There are many examples for non-Lisp implementations of that idea: APL, BASIC, Prolog, Smalltalk, Python, Ruby, R, ...

Still, software in most Lisp projects is organized in files. Something like Common Lisp includes a compiler, which compiles files and a loader which loads files (compiled and source). But the Common Lisp runtime usually includes a compiler and an interpreter and one then can develop the application interactively while it is running. The code is still written in files.

> but the macro/DSL parts are what also prevents it from being easily picked-up by teams.

That's a myth. Actually macros are BEST used in teams.

Small teams of 5 to 100 people can easily define/use language extensions, document them and reuse them in their application software. Larger Lisp software benefits most from macro definitions, since they enable development of portable language extensions incl. embedded domain specific languages, without the need for low-level implementation hacking. -> the result is very compact user level code.

> Interactivity has nothing to do with an "image". An image is a dump of the memory heap. That's a feature found in several, but not all, Lisp implementations. There are Lisp implementation which support image-based development (like Interlisp). But I doubt that you have used that.

Actually I was unconsciously talking about the typical Common Lisp implementations I have used.

> Still, software in most Lisp projects is organized in files.

Yes, sure, but I am not sure the combination of image, promoting interactive development mixes well with do a git commit and typical CI pipelines. Interactivity encourages a flow where you "instantly see" results and experiment, whereas a compile-edit-runtests follows more naturally with more structure in test cases, etc.

Of course they have their uses, and their very useful use cases. But I do think they should not be abused and I also think they should be the last thing to use, when nothing else will work.

ECL and ABCL are Common Lisp implementations. They are both interactive and both don't use images.

Unless one saves and load images, one is not using image-based development. All one is using is the interactive nature of Lisp, via a dialog interface, here a REPL. Lisp uses late binding, which makes it possible to update function definitions in interpreted and compiled software.

The base for interactive Lisp development is:

* a procedure to read data

* a procedure to evaluate data as code: EVAL

* printing

* a Read / Eval / Print loop

* additionally Lisp provides an incremental compiler and a file compiler

* LOAD to load code

Still a typical Common Lisp application or library consists of files. ASDF is the moral equivalent of "make" and runs the file compiler. Quicklisp will transfer Lisp software in the form of files to your local machine, compile the files there and load them.

So far we have not used "images". If you check the ANSI Common Lisp standard, there is not a single word about "images" in the standard definition.

> That's a myth. Actually macros are BEST used in teams.

When there are some and well-known, yes. Start to develop macros where you do not know how arguments are evaluated or when, half of which you do not know and good luck figuring out how to use and combine things with functions/macros in other places.

They are totally double-edged and in many occasions more trouble than people would admit bc they fall in love with them and how terse they can look. However, scaling this without additional walls and freely is, in my experience, very difficult.

> Start to develop macros where you do not know how arguments are evaluated or when, half of which you do not know and good luck figuring out how to use and combine things with functions/macros in other places.

I would guess a team would be so clever to develop maintainable macros.

In many places it's actually the very idea not to know how the thing is evaluated. One writes more descriptive software and does not specify execution details.

You can write unmaintainable software in many ways. Macros are a tool for code generation. How to write and use them can be learned, just like people learn to maintain large class libraries in Java.

Really, there are many of examples of Lisp code bases which make heavy use of macros and where the code was written by tens to hundreds of people.

For example much of the user facing Lisp functionality itself is macros.

Something like CLOS has much of its functionality exposed to the programmer as macros, which sit on top of functions and OOP. It's a domain specific extension to Common Lisp for OOP.

GUI libraries use macros, tools for 3d modeling use macros, ...

Whenever groups of people use code, macros are a tool to provide common language extensions. Like any tool, it needs to be learned how to use it.

> You can write unmaintainable software in many ways. Macros are a tool for code generation. How to write and use them can be learned, just like people learn to maintain large class libraries in Java.

Macros are inherently more complex: they can transform ASTs, they can evaluate in several ways, they can inject variables in the same scope, they caan use the surrounding scope in surprising ways.

Functions have very well-defined input and output marks on it, which gives more structure.

I think you will agree that while macros are more powerful, it is way easier to write code more difficult to maintain and look at than with functions.

> Really, there are many of examples of Lisp code bases which make heavy use of macros and where the code was written by tens to hundreds of people.

I wonder when why people move to "inferior" languages like Python, Java or Go. Because they give you MORE structure, not construction material. The construction material can be used in so many clever ways that it is not even funny.

If there is a reason why people move to less powerful languages for team development that is because in some ways you find it easier.

In theory, Lisp is super powerful. It is true, I do not deny that. But it looks to me like macros are most of the time more trouble than not. With higher order functions and without macro abuse you can have more structure and code that maybe is not as terse or "good" at some point, but clearly readable and without any suprise in scope, hygiene or many things that can go deeply buried.

I would not remove macros from Lisp, though. But their use should be limited. I heard some reports (sorry I do not remember the source) that macros usually end up in DSLs that only the makers understand or that are at least difficult to understand for others. For sure there are ways to mitigate it with better docs and others, but they are still macros.

> Something like CLOS has much of its functionality exposed to the programmer as macros, which sit on top of functions and OOP. It's a domain specific extension to Common Lisp for OOP.

Yes: well-known, a few and well-documented. Now give that power to literally every programmer and let them use it freely. Then the cognitive overhead is unavoidable, like with anything else. But with macros things can get way more obtuse than with functions and a few pre-made mechanisms in a language that everyone understands.

Have you worked on a professional software engineering team where every member was able to do things "freely"? That's a project management failure, not a language failure.

Usually there are rules. But it is way easier to gollow Java or Go than Lisp full of macros or random memory-management C++ bc those are possible. In Java it is just more restricted , hence more streamlined.

Your fear of macros is natural, since they are not typical for a programming language. It is expected that a newcomer to Lisp is likely to have a hard time grasping macros.

You should not be disregarding one of the most powerful features of Lisp due to a lack of understanding. Imagine if a Haskell programmer rejected typeclasses because they are initially difficult to write and potentially difficult to grasp.

If you want a taste of the power of Lisp macros, check out "Monad Macros in Common Lisp" by David Sorokin (https://cl-monad-macros.common-lisp.dev/monad-macros.htm).

> Your fear of macros is natural, since they are not typical for a programming language.

Not natural actually, but coming from experience in reading and using. You think it is great for using until you have to use the macros from others or other people your macros and there is a somewhat lack of docs, which is a common thing in real life.

Funny, a macro serves the job you seek:

    (loop :for x :below 10
          :do (print x))

This is a macro that presents a new abstraction/concept that's not "in AST format". It's a concept that's presented in syntax similar to any of the stock imperative languages.

That's the raison d'etre of macro: to expose these concepts/abstractions/etc. in a direct manner.

There are bad macros, to be sure, which are half-baked and underdocumented. That's no different a criticism from Python functions being 500 line god functions with boolean input flags, etc. Both cases are cases of bad code.

The loop macro one remarkably flexible Lisp macro. One that it could do so many things that I just let it go. Probably I did not code enough Lisp, but I am not sure it is a good idea to go so complicated.

Python as an example, iteration is a concept: go over a range of things. Complemented with comprehensions that can transform/filter with regular syntax that is always the same (if, f(x) or whatever).

Comapre it to this: https://lispcookbook.github.io/cl-cookbook/iteration.html

Is that worth the trouble, seriously? For sure it is super powerful (Python looping is quite powerful also). But what is the cognitive overhead of that, with custom syntaxes included?

That cookbook article is a bad example, especially for normal users, since instead of explaining idiomatic cases of iteration, it explains several iteration constructs (where some are extremely complex) in one article: loop, iterate, for, mapcar, series, transducers

Built-in, of those above, are mapcar and loop.

Python iteration isn't so much about ranges, I thought. See: https://kinsta.com/blog/iterables-in-python/

> The second approach is Lispy, but that shifts the responsibility of creating abstractions to users.

"You" can provide those syntax abstractions as macros. "You" can also use them yourself. But they then can be embedded in Lisp, you don't need to provide a new programming language version or even a new language & implementation with those abstractions. The user may be sophisticated enough to provide his/her macro abstractions.

Despite enjoying programming in a LISP - Clojure, I would agree that static typing and programming for the masses as opposed to programming for the ivory-tower hackers has kicked languages like Common LISP to decay in the waste bucket.

I wish someone invented a statically typed LISP with great ergonomics, tooling, packaging, modularization and mobile+desktop+WASM support.

I also think LISP missed out on data-science and ML - that was one field that LISP vendors had a chance to take the throne, but Python won the game since LISP never bothered to participate.

How about a type system more expressive than Haskell 95, completely interoperable with Lisp? [1]

What you suggest exists, but it's not the reason people turn away from Lisp. Lower hanging fruit exists. "I have to learn Emacs? No thanks." itself is an impassé for a vast majority of people who might be a candidate to try Lisp.

[1] https://github.com/coalton-lang/coalton

I disagree with any notion that Lisp would be better with static typing. Types are (mostly) for the compiler to worry about :) . But if you want a statically-typed version of Common Lisp, there are probably a few libraries that can give you that.

There's a perception on websites like HN and Reddit that Common Lisp is super hard to understand and it's this exclusive thing, but I feel the exact opposite way. I think people think it's this exclusive thing because 1. they never used it 2. their only perception of a Lisp is a Scheme (which is not Lisp, because it's Scheme), which is a bit of an ivory-tower hacker language, to be honest, because it gives you so little to work with (and it's intentionally less flexible, less friendly to use, in the name of simplicity). I think Common Lisp is very much not.

Common Lisp tends to be written in this pretty verbose style (with long, descriptive names for everything, since a name can be anything up to 1024-characters) that utilizes the fact that functions, variables, etc are in different namespaces pretty heavily (so you can freely reuse names of existing things, in a scope, where appropriate), because the point is that the code will be read by humans first and machines last. Reliance on context is thought of as a bad thing by a lot of programmers, but humans are very good at resolving things by context, and Common Lisp's syntactical regularity makes it very trivial to know what things are what.

Macros are difficult to write for a beginner, but there are really only a few rules to keep in mind when writing basic ones (which are most of what many will write). Other people's macros end up being readable, even when you don't quite know what those rules are, because they're written in a descriptive way.

It's common to see people say something along the lines of "Lisp encourages programmers to write their own mutually unintelligible dialects of the language to solve their problems" but I find it pretty easy to read other people's (contemporary) code in Common Lisp. I do find it quite difficult to read Scheme code that comprises of a million nested lambdas all with vague, single-letter variable names, though.

I've no idea what Clojure is like, so maybe that's massively more complicated and that's coloring your perception, but I don't know. I think Common Lisp has pretty good ergonomics as-is (except all the legacy, leftover bloat in the standard, and awkwardness that arises with CLOS not being as well integrated with the rest of the language as it could).

>I do find it quite difficult to read Scheme code that comprises of a million nested lambdas all with vague, single-letter variable names, though.

There's no reason to write Scheme code like that. Or in Common Lisp, or any other language with lambdas.

Are you implying CL was a language for 'the ivory tower'? That couldn't be more wrong.

> "Hacker News later got rewritten entirely in another language"

AFAIK Hackernews is still written in Arc.

> "Okay, if Lisp is so powerful as you say it is, then give me one example where Lisp is used? More importantly, give me one example where Lisp was used and didn't get rewritten in another language later?", I hear no concrete example given by the Lispers.

Maybe the problem are statements like that, which sound a bit like trolling, which people are tired of? There is more than one example of software written in Lisp and still maintained in Lisp.

In my experience, it's just not that good? I programmed professionally in Lisp (Racket to be specific) for a couple years and while I was initially enthusiastic about it, my enthusiasm for it diminished over time.

The heavy line noise in service of an easy to understand macro system just isn't worth it (moreover, a lot of languages have advanced macros these days without S-expressions).

Looking back, I think I was so into Lisp because I just wanted to feel superior and better than the dirty Java or Python programmers?

> easy to use macro system

Just curious: what macro system were you using with Racket? There are, like, 3 big ways to build macros in Racket:

1. Macros by example with `syntax-rules`. This was taken from Scheme and is the original hygienic-by-construction system. Limited in power though.

2. `syntax-case`, which gives you full procedural macros but is a little unwieldy at times.

3. `syntax-parse`, the glorious, most powerful macro system of the three.

I know, it’s confusing.

> Looking back, I think I was so into Lisp because I just wanted to feel superior and better than the dirty Java or Python programmers?

tbh, Paul Graham's articles on Lisp have done more harm than good to programmers. Calling Lisp a "secret weapon" that supercharges your startup and gives you immense competitive advantage is unrealistic and lacks concrete evidence.

The problem is that those essays were written right after the 1990s when Common Lisp was much more ahead of other languages and when static typing hadn’t yet taken the form that is popular today. Back then, your alternatives were C/C++/Java/Pascal/Perl, and Python and Ruby were the novelties that were still much slower than CL and as I understand it had inferior tooling.

Since then, the landscape has changed.

I agree with this. But CL programmers seem to think Lisp is timeless and its best days are ahead of it still. I wonder if they're already awesome programmers and that's why they pick Lisp for maximum freedom (macros?). Most people aren't wizards, and can't (nor do they want to) invent small DSLs on the go.

With great power comes great responsibility, and most people don't want that responsibility.

I can assure you that most people are not considering Lisp and thinking, "huh, this is too much responsibility, so not for me."

Lisp has a higher barrier to entry compared to Python or Rust or other languages available. For that simple reason alone, it's not used. None of these imagined reasons about the theoretical power or anti-power of macros, or being a wizard, or whatever are part of the calculus of choosing a language.

Learning Lisp has a tricky part, and one of my classmates in undergrad despaired of ever learning it, but surely Rust is harder to learn than Lisp, which makes me wonder what you mean by "Lisp has a higher barrier to entry".

You have to first install a Lisp compiler whose REPL is so spartan than even using arrow keys causes errors in your terminal. You have to learn Emacs. Figure out wtf SLIME and Paredit are from docs written in piecemeal plaintext READMEs. Then learn from a book that's older than you that makes no reference to any of the tools you just labored over installing. Then get a bunch of conflicting information about proper Lisp style from random patches of internet.

Who has time for that these days, except for the very determined and dedicated?

I think Lisp is a superlative language with excellent tools—once learned. But it hasn't had its UI revolution from anybody who cares enough to do the work.

I've been writing Lisp for 40 years, and still haven't started using SLIME or Paredit.

And the reason it is called "style" is that it is not essential to actually getting things done.

Style is not essential to getting things done, but it's essential to building a community and having labor be multiplicative in its impact. Lisp is a language ripe for expressing a personal style, and that's antithetical to collaboration in a variety of ways. It can be managed, if the community can rally around a common set of principles.

I likewise have written Common Lisp for decades. But I also get paid to do it, manage a team that does it, and see immense value in doing these extra things that hackers don't much care for, such as:

- making Lisp compatible with other languages through ABIs

- developing stylistic guidelines

- developing systems for static typing in Lisp to assist long-term development and maintenance of Lisp code

- etc.

So does style or the lack of any of the aforementioned bullets "block" the ability to "get things done"? Strictly speaking, no, but it inhibits outside interest in your project.

> Lisp is a language ripe for expressing a personal style, and that's antithetical to collaboration in a variety of ways.

I concede that point. Also, I'm the only user of most or all of the Lisp I've written over the last 40 years.

IDK why you're being downvoted. The things you mentioned are actually true and I've faced them too.

Lisp early on exposes its dual nature of code and data. Even in interactive environments. This ever-present meta-level is unusual.

None of the assignments my classmate struggled with required him write code that processes code, so I don't think that was the source of his confusion.

My guess is that it has more to do with the fact that CONS takes a whole list as an argument, then returns a different whole list, which superficially seems too computationally expensive to do in a loop.

> None of the assignments my classmate struggled with required him write code that processes code

That's not what I meant. What Lisp with s-expressions already makes more difficult is that the data syntax is used to express programs.

    (defun foo (list1 list2)
      (quote (defun foo (list1 list2) (list list1 list2))))

-> A symbol can be an identifier and just a piece of data.

Above, the first DEFUN is a standard identifier of the programming language Common Lisp. The second DEFUN is just a symbol.

The first DEFUN form is a program. The second DEFUN expression is just data. Thus it makes no sense to indent the second DEFUN expression like a program. We don't know if it is a program, it could be just anything.

-> A list can be data and a program.

This specific double nature of built-in data structures, here symbols and lists, is already a hurdle to get over.

The developer has to know which lists are data lists, which are forms and which are expressions in inside a form.

    (cond ((quote (a))))

->

    (cond ((quote (a)))) is a form, which is meant to be evaluated

    (a) is data

    ((quote (a)))  is a clause of COND, which is neither data, nor a form to be evaluated

Thus the user has to understand that in Lisp these lists serve different purposes. Which is which depends on the context and the Lisp syntax & evaluation rules.

This then even may make functions possible which contain their own definition as data:

    CL-USER 9 > #1=(defun foo (list1 list2)
                     (quote #1#))
    FOO

    CL-USER 10 > (foo '(1) '(2))
    #1=(DEFUN FOO (LIST1 LIST2) (QUOTE #1#))

> "Hacker News later got rewritten entirely in another language".

When did that happen?

It never happened.

https://news.ycombinator.com/item?id=23483715

I think behnamoh confused HN with Reddit, which was actually rewritten from Common Lisp to some other language (and the original Common Lisp version is still available in the source code form).

That is a very generous interpretation considering the lead in to the claim that I quoted is:

> "Hacker News was built in Arc, which is a Lisp"

and the follow-on is:

> HN is such a simple website by all metrics, and the fact that CL/Arc was dropped in favor of another language further confirms my belief that Lisp's days in industry are almost over.

He gets the right language for HN (Arc, still the language of the site), and not the Reddit language (CL as you point out, which was dropped for Python, and Arc was never used).

It's not very generous, but actually plausible. Maybe your memory doesn't mix up objects (?), but other people's memories certainly does. (There is even a verb for it: mix up.) HN and reddit are basically the same, and it is very plausible that they got mixed up, and the rest is just derived.

I basically agree with you, but one answer to your challenge is Emacs. However, I’m sure it wouldn’t use anything like Elisp if written anew today.

We live in a world where people ship browsers with their applications, and use interpreted languages for numerical research.

Lisps are considered powerful, as you can easily mold them into new paradigms. That’s not really much of competitive advantage in the real world, where it’s usually better to use boring and dependable tools. Especially since most good features have eventually made their way to mainstream languages.

I like Lisp, but if it was as powerful as the advocates say it was, they'd be running circles around everyone else shipping powerful software. I haven't seen many powerful pieces of software in my everyday life that is written in Lisp.

What I find most interesting about this comment of yours is the sour grapes. Can you shed a little light on where your resentment is coming from?

I'm uninclined to make any effort to convince you otherwise until you provide even a hint of a reason why I, or anyone else, should believe you have any willingness whatsoever to allow yourself to be convinced.

I think you have to consider that these conversations are taking place in public. When people reply, they're not necessarily replying to convince the person they're speaking directly to (this is often impossible), but rather to convince the reader.

I also didn't get the impression that the parent comment was being unreasonable or resentful. Lisp is often portrayed as being special and a secret weapon. It's reasonable to question that given how little it ends up being used in comparison.

Emacs and Autocad.

AutoLISP is used as the main scripting language for AutoCAD, a popular CAD software used worldwide.

https://en.m.wikipedia.org/wiki/AutoLISP

https://en.m.wikipedia.org/wiki/AutoCAD

Been writing elisp in Emacs for a couple of years now.

Emacs is an amazing piece of software and its heyday lisp was revolutionary. These days though I don’t see what it offers over other general purpose languages.

GNU Emacs wasn't written for Lisp. It was developed as an extensible text editor. Its extension language was also the implementation language for a large part of the software. Much of the application domain of GNU Emacs has nothing to do with Lisp. People edit their files with it or integrate with tools.

Not sure this makes any sense. Not sure what emacs does could have been as easily done in other languages.

>Every time people ask: "Okay, if Lisp is so powerful as you say it is, then give me one example where Lisp is used?

maybe you didn't look enough, even on hn, let alone outside it. because, as just one example,

https://en.m.wikipedia.org/wiki/ITA_Software

has been mentioned, maybe multiple times before, here on HN, in reply to questions such as yours.

(it was sold to Google for 700 million a few years later, according to the above page.)

another example is by the founder of the very site that we are talking on: hn. it was founded by PG, who also co-founded Viaweb. See

https://paulgraham.com/avg.html

which is another article that has been mentioned many times here on hn.

Viaweb was later bought by Yahoo for 40 million, iirc, and became Yahoo Stores / Shopping.

such questions as yours have come up many times before in the past on hn.

so it looks like you might not have read them. you could have used the search function at the bottom of the main hn page.

>More importantly, give me one example where Lisp was used and didn't get rewritten in another language later?", I hear no concrete example given by the Lispers.

how is this point more important? it may be, but explain why. and again, did you search enough, before asking?

(and the argument here is about the power of the language, not about the business issues (like hiring) surrounding it.)

I don't think it has to be more important.

an app getting rewritten in another language could be (and often is) due to non-technical reasons, such as management not understanding the power of lisp, or relative shortage of lisp programmers. the same kind of things happen with clojure, ocaml, etc.

I tried to get it out to as many channels as possible, all the ones I knew about -- the common Lisp subreddit, discord, irc, the fediverse, telegram cl group, and matrix. I also sent two reminders in those places :) I'm sorry if I didn't reach you though. What channel did I miss?

Reddit-wise, you posted on /r/Common_Lisp but not /r/lisp, which has a lot more subscribers and activity.

http://planet.lisp.org/ is the canonical lisp revival place to announce lisp related things. a very small subset of lispers hang out on places like reddit, discord or telegram

Add the mailing lists for the main implementations.

You could even have posted to comp.lang.lisp.

I was just curious, where the survey was posted. It seems I missed it, when a link to it was posted it here on HN.

In any event, I thought it would be worth documenting such for any survey.