Make a game with Hoot for the Lisp Game Jam(spritely.institute)
spritely.institute
Make a game with Hoot for the Lisp Game Jam
https://spritely.institute/news/make-a-game-with-hoot-for-the-lisp-game-jam.html
3 comments
I just wish it was easier to get started with Guile tbh. I'm an Emacs user so I don't have to learn Emacs to use Scheme and I still find the experience pretty bare-bone. There aren't many tutorials about creating Guile projects, writing tests, debugging, etc.
And there’s no step debugger available for guile in Emacs like there is for emacs lisp, Common Lisp, racket, and Clojure which is unfortunate
What is the step debugger for clojure you recommend?
Cider has worked the best for me. I've used Cursive in Intellij but I ran into a lot of issues where it would not trip the debugger for some reason where Cider worked fine.
Cursive, https://cursive-ide.com/
There is step debugging available in Guile plus Geiser, but it's not very reliable. You can call ,next for instance, see: https://www.gnu.org/software/guile/manual/html_node/Interact... https://www.gnu.org/software/guile/manual/html_node/Debug-Co...
Unfortunately the problem is that Guile optimizes away whole chunks of code, and thus debugging information is not as good as it could be, and if you set traps they might be optimized out too. My understanding is that this could be made better, but could use a champion.
(The other trick is to turn off the optimizations when debugging, which is sometimes what I do.)
Unfortunately the problem is that Guile optimizes away whole chunks of code, and thus debugging information is not as good as it could be, and if you set traps they might be optimized out too. My understanding is that this could be made better, but could use a champion.
(The other trick is to turn off the optimizations when debugging, which is sometimes what I do.)
Shootouts to cwebber and Spritely, I love what they're doing to show Scheme off as a modern and practical language.
Thanks! Though definitely the shoutout goes to the Spritely team in general, particularly the Hoot team, and in this case, particularly David Thompson, who put together that lovely game jam template with the breakout clone! :) It's truly incredible working with such a talented team of people every day.
(And hope that was meant to be "shoutouts" and not "shootouts" ;) !)
(And hope that was meant to be "shoutouts" and not "shootouts" ;) !)
Any news on the front of non-GC LISPs? Carp [0] seems to be dormant...
[0]https://www.eriksvedang.com/carp
Edit: It is indeed dormant[1].
[1]https://github.com/carp-lang/Carp/issues/1460#issuecomment-2...
[0]https://www.eriksvedang.com/carp
Edit: It is indeed dormant[1].
[1]https://github.com/carp-lang/Carp/issues/1460#issuecomment-2...
NLnet is funding Pre-Scheme https://nlnet.nl/project/Pre-Scheme/
Interesting, didn't know it was receiving money. Too bad it uses Scheme macros that I can barely stand... it'd be nice to have defmacro/quasiquote/gensym/etc... like some other Schemes provide.
> Any news on the front of non-GC LISPs?
Can't help you there other than suggesting not to rule out LISPs with GC. Rather than making the presence of a GC feature a deciding criteria, I'd try to determine what the maximum tolerable response time would be and whether GC would push beyond that (and whether it'll be possible to mitigate this, e.g. by CONSing less or forcing (small) GC at opportune times). I mean, we're not in the 80s anymore where BASIC programs stalled for seconds to clean up their string space or even early naughts with pre 1.3 Java. There's been a lot of progress on GC mechanism and while the one offered in the LISP system of your choice might not be of the same sophistication as those in a recent JVM, GC gets rarely in the way.
Can't help you there other than suggesting not to rule out LISPs with GC. Rather than making the presence of a GC feature a deciding criteria, I'd try to determine what the maximum tolerable response time would be and whether GC would push beyond that (and whether it'll be possible to mitigate this, e.g. by CONSing less or forcing (small) GC at opportune times). I mean, we're not in the 80s anymore where BASIC programs stalled for seconds to clean up their string space or even early naughts with pre 1.3 Java. There's been a lot of progress on GC mechanism and while the one offered in the LISP system of your choice might not be of the same sophistication as those in a recent JVM, GC gets rarely in the way.
I do agree GC is not a deal breaker: it can be chosen (Nim has three different GC engines, java has several VMs), it can be tuned... But there is still a clear categorical difference between GCed Langs and non-GCed, even if the border has become somewhat porous. And Rust (well, its predecessors) and linear types have shown there is a way forward to manage memory directly without shooting oneself in the foot repeatedly.
https://opengoal.dev/ has reverse-engineered a compiler and runtime for the non-GC lisp GOAL that Naughty Dog used for the Jax and Daxter action adventure games. They have decompiled the game code for all three games.
Tangential rant:
My understanding is that Naughty Dog abandoned GOAL after the Jak games due to pressure from Sony. Sony wanted all of their studios to be able to share source code. [0]
I hate this. Any two organically grown codebases (like, for example, games from different studios) are going to be so different that significant, non-trivial code sharing between them is going to be impossible anyway. Anything sufficiently generic might as be distributed as a precompiled library, and then use the FFI in your language of choice to take advantage.
[0] https://web.archive.org/web/20070720142546/http://lists.midn...
My understanding is that Naughty Dog abandoned GOAL after the Jak games due to pressure from Sony. Sony wanted all of their studios to be able to share source code. [0]
I hate this. Any two organically grown codebases (like, for example, games from different studios) are going to be so different that significant, non-trivial code sharing between them is going to be impossible anyway. Anything sufficiently generic might as be distributed as a precompiled library, and then use the FFI in your language of choice to take advantage.
[0] https://web.archive.org/web/20070720142546/http://lists.midn...
"Add this to the difficulty curve of learning a new language for new hires".
This argument is such a pointy-haired boss argument. Mature applications and systems will be more complicated and take longer to learn than the basics of pretty much any programming language. Grab some juniors and teach them if local seniors don't want to work in the language for a reasonable price.
This argument is such a pointy-haired boss argument. Mature applications and systems will be more complicated and take longer to learn than the basics of pretty much any programming language. Grab some juniors and teach them if local seniors don't want to work in the language for a reasonable price.
Most seniors I know wouldn't balk at learning a new language for a job, because most seniors know what you just stated to be true. It will take much longer to get up to speed on the codebase than it will be to learn the language. Even for "difficult" languages like a lisp or Haskell.
Management and HR seem to assume it will take significantly longer to get up to speed in a new language, but don't seem to care that new hires have to learn all of their weird C++ idioms that have built up over decades like atherosclerosis.
Management and HR seem to assume it will take significantly longer to get up to speed in a new language, but don't seem to care that new hires have to learn all of their weird C++ idioms that have built up over decades like atherosclerosis.
Not to mention working programmers are expected to keep up with changes to C++, Python, Java, JavaScript (and its frameworks), Go2.0, etc., many of which constitute "new language" levels of different, not to mention actual language changes like JS -> TypeScript, or Java -> Kotlin, or ObjC -> Swift, and even occasionally mobile lang -> C++ (maybe just a shared core). There's plenty of evidence that it's not that bad. And meanwhile, Common Lisp hasn't changed, code from the 90s works unmodified, the only things to keep up with really are which libraries and implementation-specific features are new/interesting/in fashion (same as any language ecosystem).
It is quite different, as those are incremental changes, and most of them can be ignored until there is a requirement to use a library or SDK that makes more recent features a requirement.
Any corporate developer knows the pain of actually being allowed to upgrade toolchains, traditionally lagging behind several years behind lang v-latest.
Any corporate developer knows the pain of actually being allowed to upgrade toolchains, traditionally lagging behind several years behind lang v-latest.
I much prefer upgraded libraries and tooling over sticking to deprecated stuff.
Handling upgrades is like doing the dishes, it has to be done, there's no use complaining about it.
Handling upgrades is like doing the dishes, it has to be done, there's no use complaining about it.
Someone has to put the money on the table for those upgrades.
This is the great thing about consulting instead of product development, developers are made constantly aware of their hourly rates.
No budget for spending time on upgrades, no upgrades.
This is the great thing about consulting instead of product development, developers are made constantly aware of their hourly rates.
No budget for spending time on upgrades, no upgrades.
Don't work for people that disallow upgrades and maintenance. Don't make deals with people who don't understand that software is finished when it's dismantled and the code deleted.