Hacker News Reader

All you professional programmer-types seem to have forgotten that solving problems (even if they’ve been solved a thousand times before) is FUN.

I wrote a custom-made script parser... knowing full-well there were many libraries available. (For a goofy program I wrote available at cycell2d.com) Why? Because I enjoyed it!

> If we are parsing S-expressions... why not embed Scheme already?

This sort of nonsense is a good example of how some projects die due to absurd feature creep that no one at all can possibly justify. Who in their right mind would ever want to embed a full blown scripting language if your usecase is... Open a file and input data?

If you want to input data following a document format, you parse the document format. That's it.

> Who in their right mind would ever want to embed a full blown scripting language if your usecase is... Open a file and input data?

Because embedding a mature, well written dependency that fully satisfies all your requirements might well be easier from a technical standpoint. It's certainly likely to reduce your comparative future maintenance burden given that the upstream community is healthy and functional.

> Because embedding a mature, well written dependency

What? Are there no mature well written parsers?

Don't be ridiculous.

I thought the comparison was between embedding a Scheme or implementing your own sexp parser from scratch. Of course embedding a good sexp parser is also a valid option to consider, I'm not that dense.

Granted that in this particular case the point seems to have been the exercise of implementing the parser itself so embedding a dependency wasn't a valid approach to begin with.

At the top of the page, Ben writes that he's a "Functional Programming Enthusiast", so he'll at least have a vague familiarity with Scheme and similar languages, even if he doesn't use them.

S-expressions are a widely used standard data format and are not exclusive to Lisps. If this is just to read in configuration files, and the resulting data structures never change after they're read in, he can get away with using calloc instead of a garbage collector, and null-terminated char * C-style strings.

Lisps (including Scheme) have more heavyweight implementations of strings and symbols than Ben has here, with an extra level of indirection: a symbol's name slot points to a string struct, which contains a pointer into an array of chars and a length. He can get away with a null-terminated char * and a struct containing an enum to distinguish them. For Lisp programming, the extra complexity is essential but for reading a config file into a game written in C, it's accidental. I don't know what kind of game he's writing but presumably it isn't anything like Abuse or Crash Bandicoot.

In the first paragraph, he writes, "I turned away from XML because I'd rather be as library independent as possible." This implies that he might have considered embedding a Lisp but decided against it for the same reason.

...and this is how we get unnecessarily bloated software with ungodly dependency chains and complex build systems.

Sometimes a purpose-built module that addresses the need and maintains simplicity is preferable over complexity in the interest of some future potential feature that nobody has asked for yet, and may never ask for.

Those Scheme interpreters are tiny!

I can guarantee you that a game will need a scripting language. Better get that done already.

That's if you prefer Scheme. You could use Lua too.

>I can guarantee you that a game will need a scripting language. Better get that done already.

Myself and thousands of people before and after me have written games without a scripting language.

You _can_ write a game without any scripting language support whatsoever. You could also write the whole game in assembly if you so desired.

However, if every single time you want to change any piece of logic in your game, you have to do the edit/compile cycle, your development will be extremely slow. Especially if you compare with the ability to change code while the game is running.

Not having all the game logic in C or what have you makes the game easier to mod too.

Fast iteration can be achieved with compiled game logic as well, it all comes down to how things are factored in your project.

An excellent example most with OpenGL experience may be familiar with is supporting hot reloading of GLSL for fast vfx development iteration. It's a compiled language, it gets compiled at runtime without significant delay, and most of us making games have created simple tools to support live editing of GLSL, maybe even supporting it in-game for dev builds.

The demoscene has even turned it into a form of competitive performance art:

https://github.com/Gargaj/Bonzomatic

Edit:

Forgot to mention Casey also goes through support of hot-reloading game logic using C in the Handmade Hero series on YouTube.

>However, if every single time you want to change any piece of logic in your game, you have to do the edit/compile cycle, your development will be extremely slow. Especially if you compare with the ability to change code while the game is running.

1. I'm working on a game in Unity right now that takes about 10 seconds to compile and reload the assemblies for the scripting language (only about 2 seconds of that is actual compilation, the rest is time that would be applicable to an interpreted scripting language).

2. I've built games in C where the entire project took 4 seconds to compile. Incremental compilation and modular architecture can get that down to near instantaneous for most changes.

>Especially if you compare with the ability to change code while the game is running.

Take a look at handmade hero for an example of an architecture that allows you to hot-reload C code while the game is running.

>Not having all the game logic in C or what have you makes the game easier to mod too.

That's completely architecturally dependent. You can make a game easy to mod for non programmers by storing data in a human readable/editable format. If you want to make it easy for players to write code there's a lot more work that needs to be done than just using a scripting language. For most games worrying about allowing modders to easily edit code is premature optimization.

> For most games worrying about allowing modders to easily edit code is premature optimization.

I was involved in a game project that died extremely quickly a few years ago. The project lead made every decision re: architecture, tooling, etc. somehow involve worrying about modding. As a result, we ended up with nothing to show since everything got derailed by a bizarre obsession by one person with modding before we even had anything to mod. I believe that person doesn't take lead roles on projects any longer...

You could just expose the logic as DLLs though

> I can guarantee you that a game will need a scripting language. Better get that done already.

Is that really so certain?

http://www.youtube.com/watch?v=y2Wmz15aXk0

The issue with scripting engine for game is that for game your almost certainly need scripting engine with completely different semantics than whatever existing implementation will provide. Ie. you either need to save the state or replicate it over network, both with reasonable performance. And looking at various AAA games (from modding standpoint) there is embedded Lua or Python that mostly only changes state of some lower level VM, which more often that not is itself turing-complete.

> I can guarantee you that a game will need a scripting language.

Embedding a scripting language (e.g. Lua) seemed to be very common around 2010, but I get the feeling that it's much less common today.

Has the use of embedded scripting languages in games declined over the last 10 years? Any particular reasons?

s7 scheme is pretty trivial to embed in a c project, it consists of an s7.c and s7.h file that you just add to your source tree, no other dependencies. https://ccrma.stanford.edu/software/snd/snd/s7.html

S7 is definitely the way to go if you want to embed Scheme with the absolute minimum of hassle.

It wouldn't be a C project if it didn't embody Greenspun's Tenth Rule.

Let me google the rule for those of you reading.

"Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."

Because he needs to parse some config files, not embed a second language.

Turing-completeness is not just a benefit, it also puts a huge maintenance cost on you. An S-expression is something you can edit in your level editor, process with a script or do a lot of fun stuff with. It's just data. You can even convert it to JSON, XML or binary if you ever get tired of S-expressions.

Once you are no longer dealing with data, but with actual Scheme code that is no longer the case and it becomes virtually impossible to do anything with the code other than directly editing it in a text editor. It's extremely inflexible and every tiny API change will break everything with no automatic way to fix it.

The author does say the following:

> I'd rather be as library independent as possible, ideally with my SDL being my only cross-platform dependency to worry about.

> If we are parsing S-expressions... why not embed Scheme already?

I agree. I just thought the goal of the author was to produce a game, not to parse S expressions. It’s possible that parsing S expressions is the most direct route to get there. But there may be more direct and simple ways to get there.

> I could telnet and have a REPL, which could be used to replace functions on the fly

I thought you had to restart a scheme’s REPL. Is that just a limitation of Racket?

guile for embedding works really nicely.

Sorry, I keep forgetting about Guile. That thing needs more love indeed.

As a newbie im getting a bit confused. What is the difference between guile and chicken scheme? There's also chez. Im even more confused

These are different implementations. The language spec they follow is slightly different so they are not completely compatible (although I've been able to use some OpenGL-ES Racket code with no modifications in Chicken by using macros).

Where they will differ the most is things like the packaging system (if they have packages, not all Scheme implementations will), as well as their main use-case.

If you are interested, just pick one and start to learn Scheme, using any implementation. Their differences will become apparent quickly.

Thank you. Quite a few options out there in terms of LISPS and a beginner like me can be quite confused. I started looking at SBCL, Chicken Scheme and Racket and since I'm a newbie I'll stick with racket for the learning phase. I seem to like more the uniformity of Scheme over the cl for example. Do people usually specialize in one or the other or use them interchangeably depending on libraries and such? Another slight barrier has been learning Emacs and that's another reason I chose racket. I like what Emacs is capable but I most likely revisit later.

Racket can be a good first choice. I would nudge you, if I may, and if the lisp glove fits, into taking the deep dive into

  emacs + evil (optional) + paredit + SLIME/SLY + SBCL + Quicklisp

There are fully configured starting setups out there for a quick start. That's basically the closest thing nowadays you'll get to experience the interactive power of the ol' Lisp Machines.

That said, you might not always need such large runtimes and other lisps can fit the bill. For example, I usually program in CL (with C FFI) for most projects, but for embedding lisps into existing C programs, Guile can be a joy. Once I was programming servo motor controllers that offered C as one of the programming languages, and I embedded a single C file that gave me a tiny little scheme interpreter and I was then able to prototype motor control algorithms and setting in way less time than before. It's just a game changer for learning about a system when you can get a REPL on it and start rapidly digging and experimenting.

Thanks. I tried emacs+slime+quicklisp on SBCL and it looks interesting but the learning curve is insane, for now I just want to learn some scheme and take it from there. Racket has some interesting libraries to tot with so Im really excited.

They're each different implementations of Scheme, sometimes with different design goals (like embedding or scripting or for standalone programs). Scheme is a pretty simple language (in comparison to many others) and relatively small. There are also several versions (not just implementations). Common ones out there now are R5RS, R6RS (it was considered "big" and was somewhat unpopular), and R7RS. Consequently, different implementations are also conforming to different versions of the spec.

Really, if you're wanting to learn Scheme, just pick one and run with it. For learning purposes they're mostly equivalent if you stick to the more popular ones, but be aware of your learning material and the version of Scheme that they're using.

If you're familiar with other programming languages, it's somewhat like the relationship between different compilers. Though usually they adhere a bit more strictly to the same standards. Since Scheme is such a small language, there's more room for differences between implementations. This mostly doesn't affect you as a learner (most learning materials focus on the core parts of the language which all implementations should be consistent on).

Thank a lot, I decided to give Racket a go. It has a fancy IDE and is battery included

Cool. Racket's a great option, and it's really a multi-lingual environment. Technically not Scheme anymore, but compatible with it in most ways. So any learning material for Scheme will still apply, and you can select different Scheme versions within Racket if the Racket language itself is incompatible with whatever book or similar you're using.

There is a basic explanation that was written by the guile maintainer in 2013: https://www.wingolog.org/archives/2013/01/07/an-opinionated-...

Yes, preferably chicken scheme as the compiled c code is snappier. I was just looking at chicken scheme on a pocketchip, admittedly I am just just scratching the surface with lisps but this is so cool. For learning I find racket to be quite good but chicken seems a lot better at performance. How long have you been a lisper? Newbie here