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

Show HN: Rust but Lisp

github.com

Post reply on HN
Print view View original

41–50 of 79 posts

Re: Show HN: Rust but Lisp

#42

Post by stevefan1999 »

Greenspun's tenth rule of programming is an aphorism in computer programming and especially programming language circles that states:[1][2]

Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

Maybe we should one day include Golang or Rust to it

https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

Re: Show HN: Rust but Lisp

#44

Post by kibwen »

stevefan1999 wrote: post #42

Greenspun's tenth rule of programming is an aphorism in computer programming and especially programming language circles that states:[1][2] Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. Maybe we should one day include Golang or Rust to it https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

Greenspun's tenth rule was formulated in a time before things like first-class functions were commonplace in industrial languages. Rust supports not just functional programming idioms but outright Scheme-style macros, it's out of scope for Greenspun's.

Re: Show HN: Rust but Lisp

#45

Post by kibwen »

ecto wrote: post #23

Readers may enjoy my lisp, Loon, which takes heavy inspiration from Rust https://loonlang.com/guide/ownership

Agreed, a Lisp built around the concept of ownership is much more interesting than just a way to write Rust via S-expressions.

Re: Show HN: Rust but Lisp

#47

Post by thatxliner »

For everyone who is shaming on the project for "not implementing enough," then you can definitely help me with it.

For everyone who is shaming on the project for being "LLM slop," sure but that's the reason why something like this can exist in the first place. The point isn't to be a finished, production-ready product. The point is to be an interesting work, and just a sly bit silly

Re: Show HN: Rust but Lisp

#48

Post by jaggederest »

gleenn wrote: post #28
jaggederest wrote: post #18

Unfortunately, given the clear LLM basis of this project, s-expressions aren't a great choice. I've found coding agents struggle really hard with s-expression parentheses matching. Much better to give them something more M-expr styled, I think a grammar that is LL(1) is probably helpful in that regard. Basically the more you can piggyback on the training data depth for algol-style and pythonic languages the better.

That has definitely not been my experience as of late. I have produced multiple, largeish Clojure projects with AI that have been perfectly formatted and functional. Perhaps you were using an older or possibly smaller model? I am admittedly using Claude with higher end models and mid to high effort but it has been working great for months for me at this point.

Nope, but to be fair when you're working on your own novel S-exprs you don't have LSPs to guide the coding agent. I imagine that it works a lot better in the context of a known and understood language environment like Clojure, CL, scheme, etc. The other option would be to write an LSP in a non-S-expr language to ensure that no turn can end with mismatched parens, for example.
Post reply on HN