Make a game with Hoot for the Lisp Game Jam
spritely.institute
spritely.institute
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.)
(And hope that was meant to be "shoutouts" and not "shootouts" ;) !)
[0]https://www.eriksvedang.com/carp
Edit: It is indeed dormant[1].
[1]https://github.com/carp-lang/Carp/issues/1460#issuecomment-2...
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...
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.
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.
Any corporate developer knows the pain of actually being allowed to upgrade toolchains, traditionally lagging behind several years behind lang v-latest.
Handling upgrades is like doing the dishes, it has to be done, there's no use complaining about it.
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.
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.