Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lisp-stick on a Python

docs.hylang.org

Post reply on HN
Print view View original

121–130 of 170 posts

Re: Lisp-stick on a Python

#121

Post by xigoi »

jxy wrote: post #57
p-e-w wrote: 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;}

Now do an array whose size is not known at compile time.

Re: Lisp-stick on a Python

#122

Post by xigoi »

flohofwoe wrote: post #98
p-e-w wrote: 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…

> whereas in Rust you just return a `Vec` and everything is taken care of 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.

How would you do it without a heap allocation?

Re: Lisp-stick on a Python

#123

Post by NavinF »

medo-bear wrote: post #89
NavinF wrote: post #87

Earlier quoted context omitted.

> you needed to restart your program after changing the code 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.

whats your etc.? in common lisp i can pretty much redefine the WHOLE compiled program at runtime. boasting about redifining variables to someone using lisp is a big LOL moment. as far as interactivity and debugging is concerned, besides smalltalk, its not nearly as good in any other language as it is in common lisp

Very cool, that's definitely not a common feature in every other debugger /s

Re: Lisp-stick on a Python

#124

Post by lispm »

jahewson wrote: post #72
jlarocco wrote: post #59

Earlier quoted context omitted.

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.

This a trick question because 10 line programs are trivial. Please show me a high performance hardware-accelerated 3D game engine written in lisp. Or a web browser.

or a CAD program...

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

that's C + several million lines of Lisp

Re: Lisp-stick on a Python

#125

Post by coutego »

p-e-w wrote: 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 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 this breath of fresh air.

Re: Lisp-stick on a Python

#126

Post by cb321 »

TurboHaskal wrote: post #113
p-e-w wrote: 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…

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, 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.

Re: Lisp-stick on a Python

#127

Post by lispm »

NavinF wrote: post #123
medo-bear wrote: post #89

Earlier quoted context omitted.

whats your etc.? in common lisp i can pretty much redefine the WHOLE compiled program at runtime. boasting about redifining variables to someone using lisp is a big LOL moment. as far as interactivity and debugging is concerned, besides smalltalk, its not nearly as good in any other language as it is in common lisp

Very cool, that's definitely not a common feature in every other debugger /s

Your C++ debugger let's you redefine an arbitrary C++ class in a running program and the existing program and data is changed. /s

Re: Lisp-stick on a Python

#128

Post by medo-bear »

freilanzer wrote: post #119
jimbob45 wrote: post #64

Earlier quoted context omitted.

Doesn’t VS do that too though? Also if you’re talking about performance or memory profiling, why are you using a Lisp in the first place?

> 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

Re: Lisp-stick on a Python

#129

Post by flohofwoe »

xigoi wrote: post #122
flohofwoe wrote: post #98

Earlier quoted context omitted.

> whereas in Rust you just return a `Vec` and everything is taken care of 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.

How would you do it without a heap allocation?

Since the OP wanted to return an array, the correct answer would probably be to return a simple native array, not a complex stdlib container:

    pub fn get_array() -> [i32;4] {
        return [1, 2, 3, 4];
    }
In C one needs to wrap the array in a struct type to work around the pointer decay:

    struct IntArray4 { int items[4]; } get_array(void) {
        return (struct IntArray4) { .items = { 1, 2, 3, 4 } };
    }
Both solution don't use heap allocation but pass around the array data by value on the stack or packed into register and should compile to the same assembly code (ABI differences aside).

That's also one of the rare cases where Rust code actually turns out more simple and readable than the C equivalent ;)

Re: Lisp-stick on a Python

#130

Post by abdulhaq »

medo-bear wrote: post #103
abdulhaq wrote: post #102

Earlier quoted context omitted.

this uses a C++ rendering engine

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.
Post reply on HN