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
A road to Lisp: Why Lisp
281–290 of 322 posts
Re: A road to Lisp: Why Lisp
#282Earlier 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?
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
#283Earlier 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.
Re: A road to Lisp: Why Lisp
#284Don'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?
Re: A road to Lisp: Why Lisp
#285Earlier 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.…
Re: A road to Lisp: Why Lisp
#286Earlier 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.
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
#287Earlier 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.
Re: A road to Lisp: Why Lisp
#288I've been wondering - Is lisp (common lisp, clojure, scheme) easier for iterative work with LLMs?
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
#289Earlier 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.
Re: A road to Lisp: Why Lisp
#290Earlier 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.
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.