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

141–150 of 170 posts

Re: Lisp-stick on a Python

#141

Post by crdrost »

hamandcheese wrote: post #76
crdrost wrote: post #67

Earlier quoted context omitted.

I mean the famous example is of course, (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))))) which uses a Lisp to define itself. This means roughly that if you understand…

> This means roughly that if you understand enough Lisp to understand this program Any recommendations on good resources for learning Lisp to a degree that this program is understandable?

Oh what a fun question!

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

Re: Lisp-stick on a Python

#142

Post by kazinator »

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…

In about one line of Lisp we can make an object with referential cycles in it, without declaring that we would like to abandon safety. We can have that object printed in a notation from which a similar object will be recovered, with the same cycles in the same places. All of this matters in practice.

Re: Lisp-stick on a Python

#143

Post by imaltont »

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

I don't think you know just how modular a Common Lisp environment is. Sure there is some hot reloading that sometimes works and you can change the value of variables, maybe even jump back and forth in your stack trace. Rarely does it do any of them as well as Common Lisp though, where the only thing that doesn't dynamically update when you change something is struct-instances and macros. Functions, variables/values, classes (including instances) can all change as you want it without restarting anything. When something goes wrong, like errors or exceptions, you can modify some code, restart some where on the stack, ignore it and continue execution, insert dummy value or insert a placeholder function.

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

Re: Lisp-stick on a Python

#144

Post by kazinator »

p-e-w wrote: post #71
yyyk2 wrote: post #69

Earlier quoted context omitted.

Any sort of self-referential data structure, e.g. doubly linked lists.

Those can be implemented in Rust very easily by wrapping the recursive reference in a (safe) pointer type such as Box or Rc.

Well, which one? And how does that interoperate with code that chose the other?

Re: Lisp-stick on a Python

#145

Post by alexeiz »

Hylang is fun and everything, but they make a lot of breaking changes in minor releases. It was "(import [module [function]])" in 0.20 and now in 0.25 it's "(import module [function])" and the old code doesn't compile anymore.

Re: Lisp-stick on a Python

#146

Post by jlarocco »

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

Earlier quoted context omitted.

> Or a web browser https://nyxt.atlas.engineer/

this uses a C++ rendering engine

Here's a browser written in pure Common Lisp: https://closure.common-lisp.dev/

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.

Re: Lisp-stick on a Python

#148

Post by jnxx »

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…

Lisp is both low-level and high-level at the same time. Common Lisp has more than the power of modern Python and Go combined, and the language is concise - it has about a tenth of Python's size.

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/

Re: Lisp-stick on a Python

#149

Post by jnxx »

merlincorey wrote: post #85
jxy wrote: post #57

Earlier quoted context omitted.

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;}

Yeah, there is nothing complicated about returning a static array in C. 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.

But you need dynamic memory management for side-effect-free functional programming.

Re: Lisp-stick on a Python

#150

Post by [deleted] »

jahewson wrote: post #70
aidenn0 wrote: post #66

Earlier quoted context omitted.

I haven't used VS in a decade, but you needed to restart your program after changing the code. 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).

No you don’t. Edit and continue in Visual Studio even works with C++ and it worked 20 years ago. It’s improved a lot recently.

[deleted]
Post reply on HN