Re Lisp's superiority - Lisp was certainly a superior language when it was devised many decades ago, but over time much of its comparative advantage has been absorbed by other languages. Starting in the 90s when productive, GC'd scripting languages like Python started being prominent this trend accelerated.

For a nice discussion of this see https://norvig.com/Lisp-retro.html

[1]: https://letoverlambda.com/index.cl/guest/chap5.html#sec_

[2]: Compiler macro chapters aren't free, but I guess read-time is covered here https://letoverlambda.com/index.cl/guest/chap4.html#sec_1

[3]: https://irreal.org/blog/?p=809 / https://web.archive.org/web/20140711171755/symbo1ics.com/blo...

    typedef struct {int v[4];} Vec;
    Vec get_vec(void){return Vec {3,2,1,0};}

    typedef struct {int v[4];} Vec;
    Vec get_vec(void){Vec v={{3,2,1,0}}; return v;}

C is a much simpler language than many people assume -- of course, it can get really hairy and complicated especially when you need to do dynamic memory management, but that's not what the GP was asking for in this case.

You really think that when they mentioned the dynamically allocated `Vec` in Rust (which has fixed-sized arrays) and "manual memory management" in C, what they were actually talking about was a static array?

    Vec get_vec(void) {
        return (Vec){ { 3, 2, 1, 0 } };
    }

    Vec get_vec(void) {
        return (Vec){ .v = { 3, 2, 1, 0 } };
    }

I'd love to see 10 lines of Rust that showed me something that:

1. I can't easily do in Lisp.

2. Actually matters in practice.

[0]: https://www.gnu.org/software/emacs/manual/html_mono/eww.html

1. https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp

2. https://elliottslaughter.com/2011/06/blackthorn-3d

  - Last updated in 2020 https://bitbucket.org/elliottslaughter/blackthorn-engine-3d/src/master/

4. https://github.com/BradWBeer/clinch

5. https://github.com/Shirakumo/trial

  - This has games released on Steam built in it

7. https://github.com/lispgames/lispgames.github.io/wiki

https://nyxt.atlas.engineer/

otoh how much rust is there in firefox? a:

https://4e6.github.io/firefox-lang-stats/

These questions are so silly. Nobody's written a web-browser in Rust, Python, Ruby, Java, Clojure, Haskell, Erlang, Typescript, Javascript, etc. but that hasn't stopped anybody from using them.

Just admit you don't want to learn Lisp.

in 1986 ?

> don't think it's suitable for all tasks

to this day im yet to see an example of a software engineering problem that lisp is not suitable to solve. if you have such an example ready i would be genuinely curious. otherwise its just a thought from a very common and lazy misunderstanding of what lisp actually is

im talking about computational problems. things that are non-examples include such things as business sense/requirements, availability of programers, availability of ready made libraries/frameworks, or claims of apparent unsuitabilty in large teams

I mean, OP asked for a 10 line program showing something that can't be done easily in Rust and actually matters, so he seems to believe 10 line programs aren't trivial.

That said line counts are an awful metric because I could just cram an entire library definition in a single line as if it were minified JS.

There are a lot of video interviews with the creators. I found them extremely interesting.

https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp

https://www.reddit.com/r/lisp/comments/fayhw2/how_crash_band...

https://www.ptc.com/en/products/creo/elements-direct

that's C + several million lines of Lisp

    #![allow(arithmetic_overflow)]
    fn main() {
        let x = 1073741823;
        println!("x = {}", x*3);
    }
    
    # cargo build && cargo run
    thread 'main' panicked at 'attempt to multiply with overflow', src/main.rs:4:24
    note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

    (defun main ()
      (let ((x 1073741823))
        (declare (type (signed-byte 32) x))
        (format t "x = ~a~%" (the (signed-byte 32) (* x 32)))))
    
    (handler-case
      (main)
    
      (simple-type-error (e)
        (format *error-output* "Panicking because of ~a~%" e)
        (uiop:quit 1)))
    
    # sbcl --script main.lisp
    ; file: /tmp/main.lisp
    ; in: DEFUN MAIN
    ;     (THE (SIGNED-BYTE 32) (* X 32))
    ; 
    ; caught WARNING:
    ;   Derived type of (* COMMON-LISP-USER::X 32) is
    ;     (VALUES (INTEGER 34359738336 34359738336) &OPTIONAL),
    ;   conflicting with its asserted type
    ;     (SIGNED-BYTE 32).
    ;   See also:
    ;     The SBCL Manual, Node "Handling of Types"
    ; 
    ; compilation unit finished
    ;   caught 1 WARNING condition
    Panicking because of Value of (* X 32) in
                         (THE (SIGNED-BYTE 32) (* X 32))
                         is
                           34359738336,
                         not a
                           (SIGNED-BYTE 32).

1. Gather assembly level profiling information

2. Redefine & recompile a function

3. Gather new assembly level profiling

I can iterate dozens of times between #2 and #3 in the time of a single incremental production build in rust (debug builds are not useful for gathering profiling data).

Generally speaking it takes less than a second to recompile and load a source file, and it can be done while the program is running.

Also, C++ linkage, while far faster than rust isn't the fastest thing, and compilation can be slow too (particularly with the popularity of header-only libraries).

Wow. No. This is a really basic debugging feature that's been around for over a decade. You can also drag-and-drop the instruction pointer to another line, watch and change variables in real time, etc. I swear, every LISP-related thread has someone touting ancient features as if they are somehow new or unique.

Some form of interactivity with the debugger is common in my experience. The level of interactivity you get with Common Lisp is not.

I found my old VS CDs and the latest version I own is .NET 2003, so I only missed that feature by a single release. I couldn't truly be a smug lisp weenie without some snide remark about how nice it is that blub developers finally got something not quite as powerful almost 40 years after Lisp could do it, so just consider me to have made such a statement.

common lisp can actually be really good performance-wise. its one of the things that made me switch from using python+c/cpp for my numerical work

Why not? CL is very performant. You'd probably be surprised. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

https://zenodo.org/record/6335627

not just functions, but whole classes too

https://lispcookbook.github.io/cl-cookbook/clos.html#:~:text....

    (define (eval exp env)
      (cond ((number? exp) exp)
            ((string? exp) exp)
            ((symbol? exp) (lookup exp env)
            ((eq? (car exp) 'quote) (cadr exp))
            ((eq? (car exp) 'lambda)
             (list 'closure (cdr exp) env))
            ((eq? (car exp) 'cond) (eval-cond (cdr exp))
            (else (apply 
                (eval (car exp) env)
                (eval-list (cdr exp) env)))))

Indirectly this also means that lisps are very close at hand for “I want to add a scripting language onto this thing but I don't want to, say, embed the whole Lua interpreter” and it allows you to store user programs in a JSON column, say. You also can adapt this to serialize environments so that you can send a read-only lexical closure from computer to computer, plenty of situations like that.

Aside from the most famous, you have things like this:

1. The heart of logic programming is also only about 50 lines of Scheme if you want to read that:

https://github.com/jasonhemann/microKanren/blob/master/micro...

2. Hygienic macros in Rust probably owe their existence to their appearance in Lisps.

C2 asks the same question here: https://wiki.c2.com/?LispShowOffExamples with answers like

3. The object model available in Common Lisp was more powerful than languages like Java/C++ because it had to fit into Lisp terms (“the art of the metaobject protocol” was the 1991 book that explained the more powerful substructure lurking underneath this object system), so a CL programmer could maybe use it to write a quick sort of aspect-oriented programming that would match your needs.

4. Over there a link shows how in 16 LOC you can implement a new domain-specific language to define and run finite state machines: http://www.findinglisp.com/blog/2004/06/automaton-cleanup.ht...

In addition to that, Lisps are sufficiently flexible that before CLOS itself was developed people were extending Lisp in Lisp to try out different object oriented models that fed into what became CLOS. That's hard to accomplish in most other languages, if it's even possible without going to a third party tool or digging into the compiler itself.

Any recommendations on good resources for learning Lisp to a degree that this program is understandable?

But here is Norvig's Python eval for a Lisp:

  def eval(x, env=global_env):
      "Evaluate an expression in an environment."
      if isinstance(x, Symbol):    # variable reference
          return env.find(x)[x]
      elif not isinstance(x, List):# constant 
          return x   
      op, *args = x       
      if op == 'quote':            # quotation
          return args[0]
      elif op == 'if':             # conditional
          (test, conseq, alt) = args
          exp = (conseq if eval(test, env) else alt)
          return eval(exp, env)
      elif op == 'define':         # definition
          (symbol, exp) = args
          env[symbol] = eval(exp, env)
      elif op == 'set!':           # assignment
          (symbol, exp) = args
          env.find(symbol)[symbol] = eval(exp, env)
      elif op == 'lambda':         # procedure
          (parms, body) = args
          return Procedure(parms, body, env)
      else:                        # procedure call
          proc = eval(op, env)
          vals = [eval(arg, env) for arg in args]
          return proc(*vals)

https://sep.yimg.com/ty/cdn/paulgraham/jmc.ps

http://www-formal.stanford.edu/jmc/recursive.html

So, the first thing is, what's the essential difficulty versus the noise: Lisp has two features which enable the evaluator to work. The first is quotation, which means that you can put a little apostrophe before some code and then it saves that code as a data structure, rather than implicitly evaluating it. The second goes by the overfancy name “homoiconicity”, that data structure is actually just singly linked list consumed by “car” (“first”) and “cdr” (“rest”) operations.

You can focus on understanding those two aspects pretty quickly, and then there are many tutorials about building your own Lisp that will get you there in an afternoon, if you'd like.

Or, you can take the royal road to this expression, in all of its cheesy 1980s glory:

https://youtube.com/playlist?list=PLE18841CABEA24090

It's lecture 7A where this specific program gets explicitly dissected by Sussman, wearing a fez. If he seems familiar, you might have watched Strange Loop 2011’s “We Really Don't Know How To Compute”, https://youtu.be/HB5TrK7A4pI

Typedef the array, return that. One pitfall, it's not resizable.

Also Lisp makes it easier to not repeat yourself. It's shorter to create functions, even macros, leading to the ominous "DSL" rabbit hole.

Another superpower is that it has no predefined keywords or operators. So you can redefine everything to whatever unicode you want. Including other languages and writing systems. It's a lot harder to write a programming language/compiler that uses another natural language idiomatically using something more similar to C or Python.

Languages have pedigrees. If you pretend like your company is enamored with javascript you'll get people who love fedoras and call themselves Ninjas. Big teams, single function libraries, lots of code shipped - move fast and break things. Cats pawing at Macbook keyboards. Mumble rap.

If you pretend you love Haskell you'll attract mathematicians in elbow patches. Great stable code will sporadically appear once every couple of years seemingly at random. Genius solutions to neat problems that have nothing to do with what the company is actually trying to accomplish. Ents. Classical music.

If you pretend to love lisp you'll attract people who read PG essays and will quit to start their own companies. Maybe they'll help you close out some tickets in Jira before they bounce if they can get your Rube Goldberg monstrosity working on their laptop. Honey badgers and hamsters. U2.

If you pretend to love latin you might get elected PM.

If you actually learn a few orthogonal languages to cover the very finite amount of paradigms you'll eventually come to realize they are all crap.

If you want to code, code. Don't talk.

as far as writing the actual code, lisp syntax allows me to perform structural editing which to me is just on another level

but as with all things in life, you should try before you buy

The downside is that you just performed a hidden heap allocation. If automatic memory management is desired, a garbage-collected language might have been the better choice in the first place.

    pub fn get_array() -> [i32;4] {
        return [1, 2, 3, 4];
    }

    typedef struct {
        int items[4];
    } IntArray4;

    IntArray4 get_array(void) {
        return (IntArray4) {
            .items = { 1, 2, 3, 4 }
        };
    }

We all know about memoize, but let's say I want to define a global hash-map, where the keys are actual pieces of code and the value the result that would be evaluated when executed. Something like this:

  | Key                        | Value                          |
  |----------------------------+--------------------------------|
  | "hello"                    | "hello"                        |
  | (square 5)                 | 25                             |
  | (factorial 5)              | 120                            |
  | (git-tags "~/foo")         | (list "1.0.0" "0.1.0" "0.0.1") |
  | (make-instance 'singleton) | #<SINGLETON {1301DE5A03}>      |

  (let ((path "~/foo")
        (tags (cache `(git-tags ,path))))
    (format t "Tags of ~a~% ~{- ~a~%~}"
            path tags))

One way to rephrase objections to "all those parens" of Lisp is that the most common style of using it makes it necessary to "write boring code 'in AST'", if you will, and not even in a very nice, commonly accepted 2-dimensional tree notation.

I always wonder how different the history of prog.langs would be if early on one of the many indent/offside rule based 2-D notations had become popular with "boring code" writers in Lisp and not eschewed by "fancy macro writers" in Lisp.

That sounds interesting but is hard to search for, have you got an example?

    http://srfi.schemers.org/srfi-119/srfi-119.html

EDIT: To elaborate on my `quote do:`, this is a little macro to avoid doing many tedious code repetitions:

    macro strp(sVars: varargs[untyped]): untyped =
      result = newStmtList() # strip some string vars; Assume new-scope
      for sV in sVars: result.add(quote do: (let `sV` = `sV`.strip))

    strp sTm,sUs,sSy,sUt,sRS,sIn,sOu,mjF,mnF,swp,vsw,isw,isr,ixr,idr,nsg,msn,mrc

    let sTm = sTm.strip
    let sUs = sUs.strip
    ...

The static typing of Nim (rather than gradual typing defaults like Lisp or Cython) tends to make beginner programs less "performance cringe" (as long as they compile with `-d:release -d:lto`!).

[1] https://en.wikipedia.org/wiki/Off-side_rule

As someone who loves both Lisp and Pascal, I really need to revisit Nim.

https://forum.nim-lang.org/

LISP had garbage collection and was designed for symbolic manipulation. Given that programs were just list of symbols, it was fully meta, from the beginning. This gave it a raw power that was decades ahead of time. Even nowadays, this malleability give Lisp languages the power to provide as libraries things than in most languages would require the modification of the language itself. For example, there is library for Clojure (a popular modern Lisp which runs on the Java and Javascript virtual machines) that adds type support. Think about that. Yes, I know. Mypy adds types to Python, but in the case of Clojure the language and runtime didn't need to be touched at for the library to work. You can basically do whatever you want as a library, because the core of the language is so powerful.

Another distinct characteristic of Lisps was the possibility to treat programs as living things you can just "talk to" through the REPL. Programs are developed in a more "conversational" way than with languages such as Java, Rust, etc. Some would say that this is a superpower and other would say that it's of marginal value. It just depends on the personal preferences.

Now, we are in 2022. Obviously, languages have evolved a lot and they are ridiculously more advanced that FORTRAN. Lisps don't have a clear killer feature that can't be found in some other languages and actually they normally lack some convenient things. There is no type system for Lisps that it's practical, convenient and with tooling support. That is a big disadvantage on an era where programs are big beasts normally done by several people mostly gluing together a bunch of libraries with big APIs that you need to explore somehow. Typed languages with accompanying IDE tooling (i.e. having a language server) offer a much quicker and effective way to develop than spending the day reading API docs.

Now, should you learn a Lisp in 2022? Well, I think there are some advantages of doing so. They have a lot of historical value and their simplicity and power are quite instructive, I'd say. Playing a bit with some Scheme (or Racket) can be very fun. If you are curious about Lisps and also functional programming, I'd suggest learning some Clojure. It's a very nice language and it really changes how you think about things, especially if you haven't been doing "hard" functional programming before.

Clojure general approach and concrete libraries as Reitit, Malli or Specter really can change how you look at things and give you a deeper understanding of other characteristics of your other languages of choice. It's a bit like learning some Japanese if you are a German or French speaker. It can help you understand, for example, how unnecessarily complex your verbal system is and how unnecessarily complex Japanese numbering system is. If you are a fish, it's difficult to understand what water is unless you get out of it. Maybe Lisps can be you this breath of fresh air.

Then we have the new Coalton library, that brings ML-like type checking on top of CL.

(and yes CL still has killer features, and no one brings all of them together!)

The REPL is the center of everything and it enables you to change functions on a running program. Tracing a function (shows function arguments on every call) is a simple as calling trace(function-name). If a program crashes, it does not really crash... it enters some debug mode which offers possible resolutions, including change the function that failed. The REPL can trivially show you the assembly code of individual functions. You can also add declarations for each function with hints for the compiler (and then check the size of the resulting assembly).

I believe this series of articles highlights some of the debugging features.

https://malisper.me/debugging-lisp-part-1-recompilation/

There is also a story called "debugging code from 60 million miles away".

Other things that I did not manage to explore yet are the macros, which allows you to create your own domain specific languages.

My general impression so far is that it is a really powerful language, for lonely hackers. :)

  (defun make-dbms (db &key (test #'eql))
    "Make a database, db should be a list. Test determines what keys match."
    ;;Three closures in a list to make a database.
    (list
     #'(lambda (key)
          (rest (assoc key db :test test)))
      ;;add
      #'(lambda (key val)
          (push (cons key val) db)
          key)
      ;;delete
      #'(lambda (key)
          (setf db (delete key db :test test :key #'first))
          key)))

  (defun lookup-dbms (key db)
    "Return the value of an entry of db associated with the key."
    (funcall (first db) key))

  (defun add-dbms (key val db)
    "Add a key and value to db."
    (funcall (second db) key val))
  
  (defun del-dbms (key db)
    (funcall (third db) key))

  CL-USER> (let ((db (make-dbms nil :test #'equalp)))
             (add-dbms '(+ 1 2) 3 db)
             (lookup-dbms '(+ 1 2) db))
  => 3

Just as examples, Common Lisp supports arbitrarily-long integers, low-level bitwise operations like popcount, rational and imaginary numbers as well as, say, POSIX file operations or easy calling into C functions. It has things like list comprehensions, pattern matching, and dictionaries, and full Unicode support since a long time.

It supports both procedural and functional-style programming, and is, like Rust, a child of the language families which stem from the Lambda calculus, where everything is an expression. The latter is an extremely valuable property because you can replace any expression in lisp code with a function or its value, even if it is an if-statement.

It has still facilities which other languages do not have, like built-in support for symbols, which are used similar to interned strings and keywords in Python.

At the same time, Common Lisp is extremely mature. For example, it is possible to define and use error handlers, which is a generalization of exceptions, and is useful in library code. Or while other languages have only local and global variables, nothing in-between, Lisp allows to define parameters, which are global values, that however can be modified in the scope and call stack of a certain function call, similar as environment variables can be inherited and changed in sub-processes of a program.

And it compiles to quite fast native code, which Python can't.

Here is an introduction to Racket, which is a dialect of Scheme - I think it shows quite nicely the uniformity and simplicity of Lisps: https://docs.racket-lang.org/quick/