[HN Gopher] Make a game with Hoot for the Lisp Game Jam
       ___________________________________________________________________
        
       Make a game with Hoot for the Lisp Game Jam
        
       Author : paroneayea
       Score  : 87 points
       Date   : 2024-05-15 18:32 UTC (2 days ago)
        
 (HTM) web link (spritely.institute)
 (TXT) w3m dump (spritely.institute)
        
       | aredox wrote:
       | 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...
        
         | davexunit wrote:
         | NLnet is funding Pre-Scheme https://nlnet.nl/project/Pre-
         | Scheme/
        
         | randomifcpfan wrote:
         | 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.
        
           | VyseofArcadia wrote:
           | 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.m
           | idn...
        
             | cess11 wrote:
             | "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.
        
               | VyseofArcadia wrote:
               | 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.
        
               | Jach wrote:
               | 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).
        
               | pjmlp wrote:
               | 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.
        
               | cess11 wrote:
               | 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.
        
               | pjmlp wrote:
               | 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.
        
       | Y_Y wrote:
       | Shootouts to cwebber and Spritely, I love what they're doing to
       | show Scheme off as a modern and practical language.
        
         | paroneayea wrote:
         | 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"
         | ;) !)
        
       | NeutralForest wrote:
       | 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.
        
         | BaculumMeumEst wrote:
         | 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
        
           | paroneayea wrote:
           | 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.)
        
           | stephen_cagle wrote:
           | What is the step debugger for clojure you recommend?
        
             | pjmlp wrote:
             | Cursive, https://cursive-ide.com/
        
       ___________________________________________________________________
       (page generated 2024-05-17 23:01 UTC)