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

A Lisp adventure on the calm waters of the dead C (2021)

mihaiolteanu.me

Post reply on HN
Print view View original

11–20 of 33 posts

Re: A Lisp adventure on the calm waters of the dead C (2021)

#11

Post by PaulHoule »

qsort wrote: post #8
PaulHoule wrote: post #4

Earlier quoted context omitted.

In languages like Java (or C) you can build S-expression like structures like so Variable x = newVariable(); Expression = add(x,literal(5)); x.set(15); System.out.println(eval(x)) // prints "20" and it is not that hard to either serialize these to code or run them in a tree-walking interpreter where quote() and eval() imply an extended language where you can write functions that work on Expression >. Type erasure cau…

I have done something exactly like this in production for a system that turned natural language into SQL. This was pre-LLM, so we had models that produced intent and keywords as structured output and we had to turn it into queries for several backends. The project didn't work out for a variety of reasons, but technically it was beautiful: it produced query plans that in many cases were identical to those from the que…

Two good examples of "builders to SQL" are

https://www.jooq.org/

and

https://www.sqlalchemy.org/

JooQ isn't everybody's taste but I use it for my job and I think it's great particularly in that you can reuse expressions and write generators for complex queries. We have a powerful search interface that combines full-text with other kinds of queries ("Is about topic T", "Data was collected between S and E") that is beautiful. I think it's funny how JooQ has that lispy f(a,b) style (no accident it is like ferocity) and how Sqlalchemy is really fluent and takes advantage of operator overloading.

Re: A Lisp adventure on the calm waters of the dead C (2021)

#12

Post by PaulHoule »

Jach wrote: post #10
lproven wrote: post #2

Previously: https://news.ycombinator.com/item?id=28851992 https://news.ycombinator.com/item?id=44359454 No comments on any of them. It sounded of interest to me, but I read it and closed the tab within a page or so as it wandered off into tech arcana. Shame. There may be an interesting idea in here but it's phrased in terms I think few will be able to follow and understand. I did not finish it but I saw no mention of…

I don't think you're missing much. Yeah, the main point seems to be that if your language has closures, you suddenly can express a lot of things that were out of reach before. Not a new insight. But there's another point I think that is hinted at on the topic of control abstractions. Or at least I'm reminded of the topic. It's better and more succinctly and explicitly talked about in an early chapter of the free book…

There's closures and there's being able to transform the expression tree.

Graham's On Lisp is a really interesting book

https://paulgraham.com/onlisptext.html

which is allegedly about programming with macros but I'd say 80% of the time he implements something with closures and then makes a macro-based implementation that peforms better. That 80% can be done in Python and the other 20% you wouldn't want to do in Python because Python already has those features... And if you wanted to implement meta-objects in Python you would do it Pythonically.

Graham unfortunately doesn't work any examples that involve complex transformations on the expression trees because these are hard and if you want to work that hard you're better off looking at the Dragon book.

You can work almost all the examples in Norvig's Common Lisp book

https://www.amazon.com/Paradigms-Artificial-Intelligence-Pro...

in Python and today Norvig would advocate that you do.

Re: A Lisp adventure on the calm waters of the dead C (2021)

#13

Post by PaulHoule »

molteanu wrote: post #6
PaulHoule wrote: post #4

Earlier quoted context omitted.

In languages like Java (or C) you can build S-expression like structures like so Variable x = newVariable(); Expression = add(x,literal(5)); x.set(15); System.out.println(eval(x)) // prints "20" and it is not that hard to either serialize these to code or run them in a tree-walking interpreter where quote() and eval() imply an extended language where you can write functions that work on Expression >. Type erasure cau…

The solution, which I often seen in practice, is to eventually write code generators, which is what Lisp macros are, after all. I've seen it in C and wrote a big piece about it that was posted here some time ago[1], about the extra tools, code generators, special formats and standards employed and needed to make up for C's deficiencies (in respect to meta-programming, at least). Everywhere I see code generators it me…

I don't see code generation as a bad smell at all.

At my job we use the JooQ code generator which is well integrated with maven and either IntellJ IDEA or Eclipse so autcompletion "just works". In modern Java you can pack up a code generator as a maven plugin [1] and put something in your POM that runs the generator. It's easy. There are other ways to hook the compiler too, see the controversial

https://projectlombok.org/

Lisp does come closest to a "language construction set" that lets you bend a language to your will. I think a compiler could be built for a language that looks more conventional that would be just as malleable, maybe even more malleable, but a generation of system programmers were traumatized by slow C++ builds and want to have nothing to do with a compiler which could be slow, even if you could make up for the slowness by having dramatically less code.

[1] A maven plugin is just a Java class which can do everything in the ordinary Java way which gets dependencies injected by the maven runtime. It's a common rookie mistake to try to solve problems by writing XML. I mean, if you can write a POM that makes existing plugins do what you want go right ahead, but if you can't just write your own plugin.

Re: A Lisp adventure on the calm waters of the dead C (2021)

#14

Post by fifticon »

I see mixed comments, so let me add some praise. I am one of countless, who match his intro-filter: repeatedly hearing 'enlightened' people lament that the vast masses don't "get" lisp and FP, and repeatedly attempting/failing to pick up the red string myself.

background - I am a computer science major with 30+ years experience. I did do a mandatory class of 'implement your own lisp' many eons ago. It just never really 'clicked' for me. I do, by accident, assimilation and lazyness,employ FP style designs in my software. And I guess fp techniques gradually rub off on me from e.g. javascript, lambdas,closures, and map-filter-reduce. in particular, lambdas are useful to me. But I am one of the guys who continue to read the "let me tell you what monads really are", and every time I fall off the bicycle. So, well, I appreciated this 'Xfor 5year olds" :-)

Re: A Lisp adventure on the calm waters of the dead C (2021)

#15

Post by molteanu »

PaulHoule wrote: post #13
molteanu wrote: post #6

Earlier quoted context omitted.

The solution, which I often seen in practice, is to eventually write code generators, which is what Lisp macros are, after all. I've seen it in C and wrote a big piece about it that was posted here some time ago[1], about the extra tools, code generators, special formats and standards employed and needed to make up for C's deficiencies (in respect to meta-programming, at least). Everywhere I see code generators it me…

I don't see code generation as a bad smell at all. At my job we use the JooQ code generator which is well integrated with maven and either IntellJ IDEA or Eclipse so autcompletion "just works". In modern Java you can pack up a code generator as a maven plugin [1] and put something in your POM that runs the generator. It's easy. There are other ways to hook the compiler too, see the controversial https://projectlombok…

> I don't see code generation as a bad smell at all.

Well, exactly!

> At my job we use the JooQ code generator...

And in Lisp one would use the...Lisp code generator. That is, the macro. And the beauty of it is that it doesn't work with pure strings but 'understands', parses, manipulates the code as expressions in its own language. That is, it has at its disposal the entire language for manipulating those expressions.

And I think that is one of the "aha" moments. At least, it was for me. When you realize the reason for having those code generators, regardless of the project and language, in the first place. That is, something missing from the language. Some extra feature that can't be implemented. Some solution that works really close to 99%, but not beyond. Something that one would like to express, but can't. Some piece of code that you want to be parameterized like you would a function, some piece of code that you want to use in multiple places but you don't want to write the same boilerplate or copy/paste it all over the place with the risk that when you modify something, you'll need to modify in all those places. Or some piece of code that you want to be auto-generated when you build/deploy/etc.

The examples are countless. The world of meta-programming offers enough of them. The article gives the control statements as an example, as a hint to build the appetite, as is suggested in the intro, in fact.

Re: A Lisp adventure on the calm waters of the dead C (2021)

#16

Post by Jtsummers »

PaulHoule wrote: post #12
Jach wrote: post #10

Earlier quoted context omitted.

I don't think you're missing much. Yeah, the main point seems to be that if your language has closures, you suddenly can express a lot of things that were out of reach before. Not a new insight. But there's another point I think that is hinted at on the topic of control abstractions. Or at least I'm reminded of the topic. It's better and more succinctly and explicitly talked about in an early chapter of the free book…

There's closures and there's being able to transform the expression tree. Graham's On Lisp is a really interesting book https://paulgraham.com/onlisptext.html which is allegedly about programming with macros but I'd say 80% of the time he implements something with closures and then makes a macro-based implementation that peforms better. That 80% can be done in Python and the other 20% you wouldn't want to do in Pytho…

Norvig put PAIP up on Github a while ago: https://github.com/norvig/paip-lisp

Re: A Lisp adventure on the calm waters of the dead C (2021)

#17

Post by jmkr »

fifticon wrote: post #14

I see mixed comments, so let me add some praise. I am one of countless, who match his intro-filter: repeatedly hearing 'enlightened' people lament that the vast masses don't "get" lisp and FP, and repeatedly attempting/failing to pick up the red string myself. background - I am a computer science major with 30+ years experience. I did do a mandatory class of 'implement your own lisp' many eons ago. It just never real…

I think Lisp is more on the liberal arts side of programming languages.

That the "enlightenment" of Lisp is that you can use functions everywhere. Write macros that look like functions and modify behavior, and build your code as a language.

Things like monads are more on the evolution of functional languages, and I also fall off the bike. It's as difficult as you want it to be, and I find scheme and lisp to be easier high level languages than javascript or python and makes more sense.

The forward and preface to SICP is good reading.

https://mitp-content-server.mit.edu/books/content/sectbyfn/b...

The Dan Friedman books are pretty good in general: "The Little Schemer," and the sequel "The Seasoned Schemer" which are both more "recursion" books. He also has another book "Scheme and the Art of Programming." Which I think is a great comp sci book that's not too difficult and doesn't seem too well known.

How to Design Programs is supposed to be a pretty good comp sci intro:

https://htdp.org/2024-11-6/Book/index.html

Re: A Lisp adventure on the calm waters of the dead C (2021)

#18

Post by molteanu »

jmkr wrote: post #17
fifticon wrote: post #14

I see mixed comments, so let me add some praise. I am one of countless, who match his intro-filter: repeatedly hearing 'enlightened' people lament that the vast masses don't "get" lisp and FP, and repeatedly attempting/failing to pick up the red string myself. background - I am a computer science major with 30+ years experience. I did do a mandatory class of 'implement your own lisp' many eons ago. It just never real…

I think Lisp is more on the liberal arts side of programming languages. That the "enlightenment" of Lisp is that you can use functions everywhere. Write macros that look like functions and modify behavior, and build your code as a language. Things like monads are more on the evolution of functional languages, and I also fall off the bike. It's as difficult as you want it to be, and I find scheme and lisp to be easier…

If we're naming names, for me personally, Lisp in Small Pieces by Christian Queinnec tops my Lisp books list. But, yes, only after perusing the SICP and The Little Schemer first.

"Liberal arts," nice :)

Re: A Lisp adventure on the calm waters of the dead C (2021)

#19

Post by smcameron »

Jach wrote: post #10
lproven wrote: post #2

Previously: https://news.ycombinator.com/item?id=28851992 https://news.ycombinator.com/item?id=44359454 No comments on any of them. It sounded of interest to me, but I read it and closed the tab within a page or so as it wandered off into tech arcana. Shame. There may be an interesting idea in here but it's phrased in terms I think few will be able to follow and understand. I did not finish it but I saw no mention of…

I don't think you're missing much. Yeah, the main point seems to be that if your language has closures, you suddenly can express a lot of things that were out of reach before. Not a new insight. But there's another point I think that is hinted at on the topic of control abstractions. Or at least I'm reminded of the topic. It's better and more succinctly and explicitly talked about in an early chapter of the free book…

There's an upside to C's limitations. Several times I've seen expressed the notion that "every big Lisp project uses its own dialect of Lisp". This is less true in C, I think, because it doesn't have the power (ignoring preprocessor abuse, which does happen, see Bourne shell source[1]). C++ has a bit more power, and there we see projects tend to use their own subset of C++.

In both Lisp, and C++, taking some isolated snippet from a codebase, you can't quite really be sure what it's doing without reading the rest of the program because of what might be called the "excessive" power of the languages.

In C, it is much more likely that you can look at an isolated snippet of code from some codebase and be reasonably sure about what it is doing, and be able to extract this snippet more or less as-is, and re-use it in some other, unrelated code base. At least, this has been my experience, ymmv.

[1] https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/sh

Re: A Lisp adventure on the calm waters of the dead C (2021)

#20

Post by molteanu »

smcameron wrote: post #19
Jach wrote: post #10

Earlier quoted context omitted.

I don't think you're missing much. Yeah, the main point seems to be that if your language has closures, you suddenly can express a lot of things that were out of reach before. Not a new insight. But there's another point I think that is hinted at on the topic of control abstractions. Or at least I'm reminded of the topic. It's better and more succinctly and explicitly talked about in an early chapter of the free book…

There's an upside to C's limitations. Several times I've seen expressed the notion that "every big Lisp project uses its own dialect of Lisp". This is less true in C, I think, because it doesn't have the power (ignoring preprocessor abuse, which does happen, see Bourne shell source[1]). C++ has a bit more power, and there we see projects tend to use their own subset of C++. In both Lisp, and C++, taking some isolated…

Well, yes, an often heard, and reasonable argument.

But then what happens in a reasonably sized C project is that other tools are brought in to fill the gaps. Tools like code generators (see some other comments on this post), for example, which are necessarily written in a different language and, most importantly, come with their own terminology and way of doing things. Which, in the end, becomes an extra mental load, the kind that you've rightly mentioned. Only you've partitioned or spread that load horizontally in multiple little pieces as opposed to building abstractions on top of each other.

Or, each piece of code is understandable by itself, but one has to read dozens of such "little islands" to make sense of what the code is achieving since, by necessity, you need to have many such pieces to achieve something meaningful. The alternative being the abstraction pyramid which does more with less code. The downside being, there is an upfront investment in understanding those abstraction layers before one can juggle with them, so to speak. In your example, the upfront investment is less so, but every-time you must do something meaningful, including reading the code, you pay the penalty of not having powerful enough tools. As an example: engineers go to universities to study calculus, physics and material science so that, with these, they can better plan and build a highway (let's say). There is a huge upfront investment in that, let's say 16 years of study. Versus, use our shovels and buckets and start building right away. That is easy to learn. You learn it in a day. You start building right away. Everyone can supervise and, thus, understand the work because it is straightforward. 1 day upfront investment. But the later will advance at a horrible pace. There is no way to visualize what you're doing. There is no study beforehand. Maybe the hill will collapse and you need to start over. Maybe the two ends of the road will not meet where you'd expect to. Maybe the materials crack after a week. Maybe the road is not even, so you start over. Etc, etc.

Post reply on HN