Live data from Hacker News

Lisp-stick on a Python

docs.hylang.org

131–140 of 170 posts

Re: Lisp-stick on a Python

#131
post #52

I've been hearing claims my entire programming career about how Lisp is supposedly "superior" to mainstream programming languages, but I've never seen a concise code example that actually demonstrates this. For instance, it's easy to demonstrate how Rust is superior to C: Just show a short piece of code where an array is returned from a function. In C, this will involve raw pointers and manual memory management with…

Considering Lisp was here first, shouldn't the real question be "why use Rust/C++/Python when there's Lisp?" You can't even create a real closure in Rust. 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.

(Tongue-in-cheek)

    #![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
To be fair, Rust is improving over time, as of I think last year you now have to explicitly have that first line to allow the overflow? This behavior is somewhat annoying to replicate in Lisp if you aren't familiar with type declarations and suppressing the debugger:

    (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).
A bit more work and you could muffle the compilation time warning too. As for how important this is, I'unno, personally I prefer to have my math Just Work by default -- (expt (expt 2 64) 64) or #I((2^^64)^^64) -- and I like by default being given the chance to fix things and continue/restart via the debugger rather than panic.

Re: Lisp-stick on a Python

#132
post #57
post #52

I've been hearing claims my entire programming career about how Lisp is supposedly "superior" to mainstream programming languages, but I've never seen a concise code example that actually demonstrates this. For instance, it's easy to demonstrate how Rust is superior to C: Just show a short piece of code where an array is returned from a function. In C, this will involve raw pointers and manual memory management with…

Just in case people don't know about C. This is a short piece of code where an array is returned from a function. typedef struct {int v[4];} Vec; Vec get_vec(void){return Vec {3,2,1,0};} Edit: alas, I've been writing too much C++. The following is correct C. typedef struct {int v[4];} Vec; Vec get_vec(void){Vec v={{3,2,1,0}}; return v;}

In C99 or later you can also write it as:

    Vec get_vec(void) {
        return (Vec){ { 3, 2, 1, 0 } };
    }
...or I would probably prefer designated init to make the initialization a bit clearer:

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

Re: Lisp-stick on a Python

#133

Earlier quoted context omitted.

so what ? the parent asked for a web browser. nyxt is rendering-engine agnostic by design otoh how much rust is there in firefox? a: https://4e6.github.io/firefox-lang-stats/

the hard part about a web browser is the rendering engine, which is why it was raised as a challenge. Sticking a Lisp front end over an existing rendering engine doesn't answer the challenge.

then he didnt ask the right question. nyxt is a browser in every sense of the word. anyway there is no reason lisp cant be used for making a good rendering engine

Re: Lisp-stick on a Python

#134
post #52

I've been hearing claims my entire programming career about how Lisp is supposedly "superior" to mainstream programming languages, but I've never seen a concise code example that actually demonstrates this. For instance, it's easy to demonstrate how Rust is superior to C: Just show a short piece of code where an array is returned from a function. In C, this will involve raw pointers and manual memory management with…

My relatively amateur take is that the REPL and the debugging experience seem powerful. I would like to know how they compete with other languages.

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. :)

Re: Lisp-stick on a Python

#135
post #126

Earlier quoted context omitted.

There is something I saw on the wild here https://github.com/Shinmera/legit/blob/master/repository.lis... which I thought was pretty cool. 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 | |----------------------------+--------------------------------…

Nim has `quote do:` with a kind of ghetto quasiquoting as well as genAST (and other things) to lessen the burden, but it is always simpler to write boring code (and better unless you have a burning need for The Fancy). 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, comm…

> 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?

Re: Lisp-stick on a Python

#136
post #126

Earlier quoted context omitted.

Nim has `quote do:` with a kind of ghetto quasiquoting as well as genAST (and other things) to lessen the burden, but it is always simpler to write boring code (and better unless you have a burning need for The Fancy). 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, comm…

> 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?

This is the latest for Scheme according to Wikipedia's Offside Rule article [1]:

    http://srfi.schemers.org/srfi-119/srfi-119.html
I have not read this "Wisp" spec lately, but IIRC it has many back references to prior attempts..at least in the Scheme community..not sure about the common-lisp community.

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))
with an example call:

    strp sTm,sUs,sSy,sUt,sRS,sIn,sOu,mjF,mnF,swp,vsw,isw,isr,ixr,idr,nsg,msn,mrc
which will expand to code like:

    let sTm = sTm.strip
    let sUs = sUs.strip
    ...
Maybe that's one man's "syntax soup", but I don't think it's so bad. (My 3 letter idents are probably worse!)

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

Re: Lisp-stick on a Python

#137

Earlier quoted context omitted.

> Also if you’re talking about performance or memory profiling, why are you using a Lisp in the first place? Why not? CL is very performant. You'd probably be surprised. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

SBCL can get much faster results than what i can see there via use of SIMD procedures. i think in some tests it beat rust on spectral norm calculations

One can read the paper 'Closing the Performance Gap Between Lisp and C' written by one of the authors of the sb-simd package

https://zenodo.org/record/6335627

Re: Lisp-stick on a Python

#138
post #57
post #52

I've been hearing claims my entire programming career about how Lisp is supposedly "superior" to mainstream programming languages, but I've never seen a concise code example that actually demonstrates this. For instance, it's easy to demonstrate how Rust is superior to C: Just show a short piece of code where an array is returned from a function. In C, this will involve raw pointers and manual memory management with…

Just in case people don't know about C. This is a short piece of code where an array is returned from a function. typedef struct {int v[4];} Vec; Vec get_vec(void){return Vec {3,2,1,0};} Edit: alas, I've been writing too much C++. The following is correct C. typedef struct {int v[4];} Vec; Vec get_vec(void){Vec v={{3,2,1,0}}; return v;}

[deleted]

Re: Lisp-stick on a Python

#139
post #52

I've been hearing claims my entire programming career about how Lisp is supposedly "superior" to mainstream programming languages, but I've never seen a concise code example that actually demonstrates this. For instance, it's easy to demonstrate how Rust is superior to C: Just show a short piece of code where an array is returned from a function. In C, this will involve raw pointers and manual memory management with…

Well, you need to think that LISP was a thing already before 1960. The only competitor at the time was FORTRAN. Even C was introduced more than 10 years later. 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 la…

SBCL probably does more type checking that one thinks. It catches many useful type errors and warnings, especially since we get them instantly, after we compile a function with a keyboard shortcut.

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!)

Re: Lisp-stick on a Python

#140
post #52

I've been hearing claims my entire programming career about how Lisp is supposedly "superior" to mainstream programming languages, but I've never seen a concise code example that actually demonstrates this. For instance, it's easy to demonstrate how Rust is superior to C: Just show a short piece of code where an array is returned from a function. In C, this will involve raw pointers and manual memory management with…

I have no idea what you can or can't easily do in Rust. Here is something many languages can't do succinctly, without closures and code-as-data. From Paul Graham's book, On Lisp, modified to work with Lisp code as keys.

  (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))
In use with code as the key:

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