Live data from Hacker News

A road to Lisp: Why Lisp

scotto.me

281–290 of 322 posts

Re: A road to Lisp: Why Lisp

#281
post #220

Can I write a game using OpenGL in Lisp?

Yes. Kandria [1] is a great example of someone doing exactly this. There's a bunch of information on the development here [2] and the code is open source [3]. [1] https://kandria.com/ [2] https://reader.tymoon.eu/article/413 [3] https://codeberg.org/shirakumo/kandria

Interesting. I didn't thought it's possible.

Re: A road to Lisp: Why Lisp

#282

Earlier quoted context omitted.

You're wrong on every count about my experience. And once again, please: I'm just saying that stages in Read-Eval-Print-Loop does have differences in homoiconic and non-homoiconic languages. THAT'S ALL I SAID. There's zero controversial taste in that statement. None. I'm not bashing on Ruby, or Python, or any language you favor. I'm not telling you to use this or that. I'm just pointing out at specific differences th…

So if you implement a non-homoiconic language in SBCL or Racket does the REPL blow up? Is Rhombus language a psy-op?

Implementing C-like language in Lisp runtime - your interpreter reads C-like source, parses it to your own AST structs, and evaluates those. The host being homoiconic says nothing about the guest. You would have to write a guest REPL anyway (if you want one).

Rhombus built on Racket, yes, means it reuses Racket's machinery: the macro expander, the module system, the compiler, the runtime. But it doesn't mean it inherits Racket's parenthesized syntax.

Racket's expander does not operate on text. It operates on syntax objects (shrubbery). It has its own REPL, because the Read stage has to parse shrubbery syntax, not s-expressions. So, my original point stands - REPLs do have differences for homo and and non-homoiconic PLs.

Re: A road to Lisp: Why Lisp

#283
post #271

Earlier quoted context omitted.

Da fuk you're talking about? Where the heck am I being an asshole? I have not used a foul language or insult in this thread once, even when someone accused me of being in a cult. Don't patronize me, even if you bought a moral authority on a discount - I'm not your fucking child. No matter how many times you say "please" and call me "asshole" I won't correct anything in my behavior because there's nothing to correct t…

High testo, huh.

Oh wow, how quickly you changed from being "a good citizen containing an asshole" to being an asshole on your own. Good job, keep checking your mailbox, your medal should arrive shortly.

Re: A road to Lisp: Why Lisp

#284
post #243

Don't miss out, we had new excellent editors and tools being released in the last months: Mine: a complete, single-download application that comes with everything needed to experience the interactive and incremental development programming workflow, including hot-reloading and on-the-fly debugging. For CL and Coalton. https://coalton-lang.github.io/20260424-mine/ OLIVE: a new hand-made plugin for VSCode. ICL: a new R…

I can't find the source for `mine`. Do you have a link?

Looks like Mine is part of Coalton's repo. https://github.com/coalton-lang/coalton/blob/main/mine/READM...

Re: A road to Lisp: Why Lisp

#285

Earlier quoted context omitted.

> Your wording sounds like it implies that Lisp "got stuck" somewhere in the past, no? Pretty much. See pg's famous "Blub Paradox" where he sees Lisp as the top of a tower of lesser languages. He doesn't recognize that Lisp might at best be called a limit ordinal, to use math jargon. That is, Lisp is just another Blub, and the Lisp zealots haven't figured that out. You don't necessarily want to keep going further and…

pg's notion was psychological, not about languages per se: a programmer sitting in language X can't perceive power above X, only below. It's about a fixed vantage point. Your "Lisp is just another Blub" would be true if Lispers were stuck looking up from Lisp-as-it-was and failing to see higher. If Lispers were trapped in the Blub position, they couldn't have deliberately imported ideas that sit "above" classic Lisp.…

I'm unfamiliar with Coalton but the Blub article describes the proverbial smug Lisp weenie. I'd agree with you that #notalllispers.

Re: A road to Lisp: Why Lisp

#286

Earlier quoted context omitted.

Language design has almost nothing to do with language popularity. People learn JavaScript or TypeScript because they want to write web apps. Swift or Objective C to write iOS or Mac apps. SQL because there’s a database they need to get data out of. Python because there’s a machine learning library they need to use. Etc etc. Language design is far down the list of priorities.

That's fair, but I was responding to the claim that you don't need to make a trade off. If that were true, then Haskell would be much more popular. Clearly there's a trade off or else everyone would just use Haskell.

That doesn't follow.

For one, there might be trade-offs against dimensions other than safety and expressiveness. Performance, corporate support, libraries, popularity, learning curves, similarity to other languages...

For two, popularity is simply not strong correlated to quality. Popularity is a social function driven by, well, social factors. It's heavily path-dependent and noisy. There is absolutely no guarantee, not even close, that the "best" thing in any sense will be the most popular, or popular at all.

Re: A road to Lisp: Why Lisp

#287
post #253

Earlier quoted context omitted.

I've always wondered what would have happened if the first "Interface Builder" >Jean-Marie Hullot created "SOS Interface" in Lisp for the Macintosh while working at INRIA (1984) which was the first modern "interface builder." https://denninginstitute.com/itcore/userinterface/GUIHistory... had become a mainstream Mac product rather than being co-opted for NeXT and use w/ Objective-C. LISP clicked with me (when taking…

GUI: MCClim, but it's a bit rusty/Motif like/Tk Life. Deploy: SBCL can build standalone binaries I think.

If SBCL can build stand-alone binaries using MCClim, I know what my next personal project will be.

Re: A road to Lisp: Why Lisp

#288
post #25

I've been wondering - Is lisp (common lisp, clojure, scheme) easier for iterative work with LLMs?

I use LLM_based coding agents frequently with Lisp languages and my way of working is different with Lisp languages: 1) if generated code ever has a syntax error, I like to quickly fix the syntax error myself. 2) for some reason I usually prefer to run tests myself in another terminal (with Python, Typescript, etc. I let the coding harness run tests).

I haven’t let coding harnesses run REPLs. When I do let a coding harness run tests I specify in, for examp,e, my Common Lisp skills file to run ‘sbcl -load …” so bash test commands are one liners.

It would be interesting to work on skills and a harness to use REPLs - nothing bad about that idea, I just haven’t tried it.

Re: A road to Lisp: Why Lisp

#289

Earlier quoted context omitted.

pg's notion was psychological, not about languages per se: a programmer sitting in language X can't perceive power above X, only below. It's about a fixed vantage point. Your "Lisp is just another Blub" would be true if Lispers were stuck looking up from Lisp-as-it-was and failing to see higher. If Lispers were trapped in the Blub position, they couldn't have deliberately imported ideas that sit "above" classic Lisp.…

I'm unfamiliar with Coalton but the Blub article describes the proverbial smug Lisp weenie. I'd agree with you that #notalllispers.

Most Lispers I met do actively write in multiple languages all the time. They tend to borrow ideas from other PLs instead of loathing everything else that's not their favorite. They prefer Lispy syntax, but won't reject a language to achieve a goal - they'd pick everything - runtime, tooling, etc. and try to find a Lispy syntax that sits atop. While preserving all the remaining semantics. And then they'd argue that syntax does not make a language. Perhaps, Lispers are the largest demographic of polyglot programmers in the global community.

Re: A road to Lisp: Why Lisp

#290

Earlier quoted context omitted.

I wrote GGP as a Lisp user and enjoyer—not pretending to deep experience, but definitely am well acquainted. And neither the REPL nor live reloading are important differentiators. Neither is the ability to attach a REPL to a running program: plenty of languages have that built in (Erlang, Ruby), and many others support it through popular third party tooling (e.g. Pyrasite for Python, and—ironically—the class executor…

Homoiconicity is a "uniquely Lisp" feature and it doesn't seem like you've fully grokked the implications and differences between homoiconic and non-homoiconic. I'm not making this up - every step there in Read-Eval-Print-Loop does differ. That is easily verifiable info.

Eval differs very slightly from, say, an interpreter with a very non-syntactic AST, due as you say to homoiconicity. Neither read, print, nor loop differ in any Lisp-specific or qualitative way. And the differences in eval’s behavior don’t change anything significant about the REPL user’s experience (other than that they’re writing Lisp). So what do you mean?

Specifically, cached state and behaviors still need to be reconciled with new inputs/overrides during “eval”, and no Lisp has an easy answer to those (neither, as far as I know, does any other language). Avoidance of closure state via late binding and a convention of reliance on very simple data structures help Lisp’s REPL/hot-patch story, and that is indeed nice, but it’s far from “guaranteed ease/safety of REPL patching” or a totally different paradigm.

Post reply on HN