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

A Road to Lisp: Which Lisp

scotto.me

Post reply on HN
Print view View original

101–110 of 180 posts

Re: A Road to Lisp: Which Lisp

#101

Post by lioeters »

QuadmasterXLII wrote: post #56

The funny thing about Lisp is that writing a Lisp interpreter is significantly fewer keystrokes than correctly installing Common Lisp and its tooling. The ratio of lisps to lisp programmers may actually be above 1.

Literally a comment I wrote then decided not to post.

> The best LISP is the one you create yourself. You learn so much about programming by implementing your own language, and LISP is brilliant for this purpose thanks to its simple syntax and homoiconicity (code is data, data is code). It's also a great way to learn a new existing language, like Rust or Go, by writing a LISP interpreter with it.

Re: A Road to Lisp: Which Lisp

#104

Post by erichocean »

zem wrote: post #94
pjmlp wrote: post #76

Earlier quoted context omitted.

I love the Clojure community, it is the only one that usually talks about the host platform in a symbiotic way, not as if they would be rewriting everything into their favourite language, like in most guest languages communities.

people don't usually think of C as a host platform, but the python community has a similarly symbiotic relationship with C extensions.

Since Java 25/Project Panama, I have that kind of relationship with C from Clojure as well.

Codex can one shot the bindings flawlessly, and the interface is significantly faster for downcalls vs. JNI.

Re: A Road to Lisp: Which Lisp

#105

Post by erichocean »

Jtsummers wrote: post #58
arikrahman wrote: post #54

Earlier quoted context omitted.

Now there's Jank too, the first time a Lisp dialect has reached into native world since Clasp. The way it interops Clojure with the LLVM is unprecedented.

> the first time a Lisp dialect has reached into native world since Clasp. What's that supposed to mean? Many (probably most if we only consider the non-toy ones) lisp implementations are "native" (compiling to native machine code, not interpreted).

You can directly call C++ as C++, not via a C ABI.

Re: A Road to Lisp: Which Lisp

#106

Post by totalperspectiv »

phtrivier wrote: post #66

From my experience, to be happy I would need the perf of sbcl, the syntax, litterals and data structure of clojure, the begginer-friendlyness of drracket, the type system of ocaml, and the dev experience of rust. Does that exist somewhere ? I hope jank gets there. Or maybe roc will. At this point, given the progress and expectations of using LLM, writing code is going to be purely a hobby concern, like carving wood f…

Carp has been slowly inching forward and ticking those boxes

Re: A Road to Lisp: Which Lisp

#107

Post by aptenoforst »

goatking wrote: post #35

I just wish a good IDE existed so I don't have to use Emacs. That's what made me drop lisp in the past. I would be happy with (neo)Vim setup as well, but that was way behind Emacs and broken when I tried.

You have two newish options nowadays

https://coalton-lang.github.io/20260424-mine/ and https://lem-project.github.io/

Re: A Road to Lisp: Which Lisp

#108

Post by loose-cannon »

PaulHoule wrote: post #64

I'm going to take the opposite position that there is much less special about Lisp than people think. Like I have met so many programmers that travel around like itinerant martial artists looking for true functional programming and they never find it. To be specific, you can work all of the examples in Graham's On Lisp in Python except for one of the last chapters where he implements continuations that really need ma…

I thought Scheme was just an educational tool - a minimal language that allows the student to explore language construction & design relatively quickly. I'm not sure I understand your comment about homoiconicity leading people astray. Isn't that the characteristic feature of lisp? Doesn't that dramatically simplify generating code (in principle)?

Re: A Road to Lisp: Which Lisp

#109

Post by SomeHacker44 »

phtrivier wrote: post #66

From my experience, to be happy I would need the perf of sbcl, the syntax, litterals and data structure of clojure, the begginer-friendlyness of drracket, the type system of ocaml, and the dev experience of rust. Does that exist somewhere ? I hope jank gets there. Or maybe roc will. At this point, given the progress and expectations of using LLM, writing code is going to be purely a hobby concern, like carving wood f…

Please say more about the "dev experience of rust." As a long time Lisper and not much of a Ruster, I found the dev experience very painful. Granted, I expect had I continued using Rust that would have abated in tjme. I also disliked Clojure at first until I became comfortable with it and productive, before coming to like and appreciate it.

Re: A Road to Lisp: Which Lisp

#110

Post by PaulHoule »

BoingBoomTschak wrote: post #86
PaulHoule wrote: post #64

I'm going to take the opposite position that there is much less special about Lisp than people think. Like I have met so many programmers that travel around like itinerant martial artists looking for true functional programming and they never find it. To be specific, you can work all of the examples in Graham's On Lisp in Python except for one of the last chapters where he implements continuations that really need ma…

You're really misrepresenting Lisp macros here, being able to rewrite syntax is only one (admittedly important) facet of these. The real thing with CL is that the entire language is available during parsing and macro expansion and that users can hook into these steps to influence them. No artificial limitations like you get in C++'s consteval, you can do everything and anything without having to use a crappy DSL to d…

(1) SBCL is fine in terms of speed so far as I am concerned. But wherever you have software engineering in the large, especially involving C++, you have 40 minute builds and a split between smart people who think that's a problem and smart people who don't.

(2) The trouble with those balls-to-the-walls macros is that systems that use them tend to be "write only", like some guy writes 4000 lines of Lisp that do the work of 80,000 lines of C++ and then he moves on and there is never a version 2.0 but the system gets rewritten in C++, supposedly for performance, but really because they couldn't find anybody who could maintain it. It is really pleasing to see how little code is in Lisp systems from the golden age of AI but... when Yahoo! bought Graham's startup they kept the customers but threw away the code.

You are more likely to be sustainable if you get two people to write 12,000 lines in something like typescript or ML that uses Dragon Book technology to the same end.

Post reply on HN