Show HN: Micropolis/SimCity Clone in Emacs Lisp (github.com)
This is a little game implemented over a week of tinkering and targeting Emacs.
The point is both to have fun with this kind of simulations, and also explore the "functional core / imperative shell" approach to architecture. I also developed a tile and tile effect definition DSL, which makes this even easier to extend. From this point of view it's a success: easy testing, easy extension,
Gameplay-wise the simulation is too simplistic, and needs input from people interested in this kind of toys. The original Micropolis/SimSity is the last time I built a virtual city.
21 comments
[ 3.6 ms ] story [ 48.9 ms ] threadI’ve been doing my own exploration of terminal ASCII games via Dwarf Fortress instead of SimCity. I’ve learned that letting a coding agent play is an interesting way to get feedback as well :)
https://github.com/brimtown/claude-fortress
Here, the point was to have everything in emacs completely, and also see if the architectural contraints make sense for elisp (and they do)
And have some fun, of course.
Finally RMS can play SimCity.
https://www.masteringemacs.org/article/fun-games-in-emacs
https://medium.com/ssense-tech/a-look-at-the-functional-core...
The idea being that business logic gets written in synchronous blocking functional logic equivalent to Lisp, which is conceptually no different than a spreadsheet. Then real-world side effects get handled by imperative code similar to Smalltalk, which is conceptually similar to a batch file or macro. A bit like pure functional executables that only have access to STDIN/STDOUT (and optionally STDERR and/or network/file streams) being run by a shell.
I think of these like backend vs frontend, or nouns vs verbs, or massless waves like photons vs massive particles like nucleons. Basically that there is no notion of time in functional programming, just state transitions where input is transformed into output (the code can be understood as a static graph). While imperative programming deals with state transformation where statically analyzing code is as expensive as just running it (the code must be traced to be understood as a graph). In other words, functional code can be easily optimized and parallelized, while imperative code generally can't be.
So in model-view-controller (MVC) programming, the model and view could/should be functional, while the controller (event handler) could/should be imperative. I believe that there may be no way to make functional code handle side effects via patterns like monads without forcing us to reason about it imperatively. Which means that impure functional languages like Haskell and Scala probably don't offer a free lunch, but are still worth learning.
Why this matters is that we've collectively decided to use imperative code for almost everything, relegating functional code to the road not taken. Which has bloated nearly all software by perhaps 10-100 times in terms of lines of code, conceptual complexity and even execution speed, making perhaps 90-99% of the work we do a waste of time or at least custodial.
It's also colored our perception of what programming is. "Real work" deals with values, while premature optimization deals with references and pointers. PHP (which was inspired by the shell) originally had value-passing semantics for arrays (and even subprocess fork/join orchestration) via copy-on-write, which freed developers from having to worry about efficiency or side effects. Unfortunately it was corrupted through design by committee when PHP 5 decided to bolt-on classes as references rather than unifying arrays and objects by making the "[]" and "." operators largely equivalent like JavaScript did. Alternative implementations like Hack could have fixed the fundamentals, but ended up offering little more than syntactic sugar and the mental load of having to consider an additional standard.
To my knowledge there has never been a mainstream FCIS language. ClojureScript is maybe the closest IMHO, or F#. Because of that, I mostly use declarative programming in my own work (where the spec is effectively the behavior) so that the internals can be treated as merely implementation details. Unfortunately that introduces some overhead because technical debt usually must be paid as I go, rather than left for future me. Meaning that it really only works well for waterfall, not agile.
I had always hoped to win the internet lottery so that I could build and test some of these alternative languages/frameworks/runtimes and other roads not taken by tech. The industry's failure to do that has left us with effectively single-threaded computers which run around 100,000 times slower today (at 100 times the cores per decade) than they would have if we hadn't abandoned true multicore superscalar processing and very large scale integration (VLSI) in the ...
I never intended this project be something like a wonder of 3dfx or something. In fact, the hope was to discuss implementation details.
Either way, for those interested: screenshots of both the terminal and graphical version are now included in the README.org.
>Is the Emacs Lisp version fun enough to be worth adding to Emacs?
I mean, this version is a boring, I was just looking into architecure and visuals, and how these could be structured in Emacs Lisp. I never expected people to be so curious about it.
But I think it should be possible to port the whole thing with some limitations (turn-based, as emacs is not really good for live rendering and simulation).
Don> Do you abstain from web browsers still, or do you have a good way to read web pages without using non-free software?
rms> I can view many web sites with IceCat, but some sites refuse to work since I have enabled LibreJS and am connecting via the Tor network.
Don> PS: Could you please verify this stolen sperm quote?
>"If I'm the father of Open Source, it was conceived through artificial insemination using stolen sperm without my knowledge or consent." — RMS (2016, Web Summit)
rms> I really said that, probably several times. Alas, I don't remember when or where.
https://news.ycombinator.com/item?id=3159210
https://github.com/ddol/rre-rms/blob/master/rider.txt#L652