Good news: the universe is written in LISP. Bad news: with no comments.

Well, it's kind of a machine code for a self-modifying compiler, so there's that.

I'm still waiting for the slackers at CERN to finish decompiling it.

that's great, could read the source code on how to unify gravity and quantum mechanics for all energy levels? vibeing to a nobel price will be cool...

Game developers sometimes make the “randomness” favor the player, because of how we perceive randomness and chance.

For example in Sid Meier’s Memoir, this is mentioned.

Quoting from a review of said book:

> People hate randomness: To placate people's busted sense of randomness and overdeveloped sense of fairness, Civ Revolutions had to implement some interesting decisions: any 3:1 battle in favor of human became a guaranteed win. Too many randomly bad outcomes in a row were mitigated.

https://smus.com/books/sid-meiers-memoir/

Some threads on randomness and perceived fairness in video games can be found here on HN too, for example https://news.ycombinator.com/item?id=19399044

The original link being discussed in that thread is 404 now, but archived copies of the original link exist such as for example https://archive.is/8eVqt

The 8-ball joker is even more BS. I think I’ve only seen it trigger once ever.

For a small while I've had the idea of a [game engine/fantasy console/Scratch clone?] that comes packed with a bunch of example games. The example games should be good enough that people download it just to play them, but they are also encouraged to peek into their source code. I'd hope for it to be a sneaky gateway into programming.

For that, I'll keep this in mind: "Unlucky players may look at the source code of a chance-based effect to check if the odds are actually as stated."

I’ve 100%’d Balatro and wheel of fortune is quite strong. It’s never worth taking before you’re at max interest though.

I'm really curious how they do version control.

The Steam version was created by one guy, but the platform ports have a couple different authors. The Google Play and Xbox PC versions, for instance, have divergences.

I wonder how the ports influence the upstream and each other. How do they keep the codebases in sync, while also accounting for platform differences?

yep that works

It's not really tables all the way down - Lua has datatypes like nil, boolean, number, string, table, userdata + lightuserdata, functions, coroutines. I think that's the entire list, actually.

So a table is a hashtable. Just about anything can be a key to the hash - a number, a string, a boolean, another table, a userdata. I can't recall if functions and coroutines can be keys but I suspect they could. I definitely know that nil can't be an index.

In Lua - all iterators are implemented as a function + state + current key. When you write "for x in (whatever)", that (whatever) is really a function call like func(state,key). Lua calls it repeatedly to traverse the loop.

Lua will take the first returned value and use it as the new key in the next call to func(). Once the function returns nil as the first value (or just returns no values) - the loop stops.

There are two functions - pairs and ipairs - that really just return the built-in next function with a starting key. pairs returns (lua's next(), the table, nil), and ipairs returns (next(), the table, 0).

(there's a bit more to it than that and some under-the-hood changes between Lua versions but we'll just go with that explanation).

Lua repeatedly calls that next() function with the table and previous key.

Say you had an array like table like { [1] = some_value, [2] = another_value }.

When you write something like "for i,v in ipairs(a_table)" that roughly expands to:

  * pairs() returns next(), the table, 0. 
  * Lua calls next(table, 0) and next returns (1, some_value)
  * Lua calls next(table, 1) and next returns (2, another_value)
  * Lua calls next(table, 2) and next returns nil.

So - when is a table an array?

When you can iterate through it with sequential, integer keys.

Note - you don't necessarily need to use ipairs to iterate. Lua also has a numerical "for" loop so you could do that. Or - if you want to start your arrays at 0 instead of one you can write your own ipairs() like function in just a few lines of code. Observe:

  local zpair_it = function(table, key)
    key = key + 1
    if table[key] then
      return key, table[key]
    end
  end

  local zpairs = function(table)
    return zpair_it, table, -1
  end

  local tab = { [0] = 'yay', [1] = 'huzzah' }
  for i,v in zpairs(tab) do
    print(i,v)
  end

There - now instead of using ipairs(), you can use zpairs() with zero-based indexes.

As far as using like objects, that's getting into metatables and stuff but - basically lua has a syntactical sugar to make object-orientation nice.

If you write "obj:func()" - that's the same as writing "obj.func(obj)" - assuming "obj" is a table, Lua will fetch the "func" key from the table, then call it as a function with "obj" as the first argument (this can be referred to as self within your function definition).

If Lua tries to fetch "func" from your table and it doesn't exist - it will check to see if your table has a metatable defined with an __index metamethod (or table) and pull func from that. So - your table could just have your object's actual state data on it, and functions are referenced in a separate metatable.

Observe:

  local dog_methods = {
    bark = function(self)
      print("bark bark I'm a",self.breed)
    end
  }

  local dog_metatable = {
    __index = dog_methods
  }

  local huskie = setmetatable({
    breed = 'huskie'
  }, dog_metatable)

  local collie = setmetatable({
    breed = 'collie'
  }, dog_metatable)

  huskie:bark()
  collie:bark()

huskie:bark() is equivlanet to huskie.bark(huskie). bark doesn't actually exist on huskie, but huskie has a metatable with an __index table where bark is defined. So the function call is really more like dog_methods.bark(huskie).

Anyways wow that was a lot. Highly recommend going through the Lua manual. It's not a long read.

Tables are kinda-sorta hashes that can hold anything, not unlike JavaScript objects. The array use case is just a table with automatically assigned numeric keys.

If you're going to use a table as an array, use it as an array:

    local l = {[0] = 'a', [1] = 'b', [2] = 'c'}
    for i = 0,#l do
      print(l[i])
    end

    .. prints:

    a
    b
    c

Lua haters usually don't get past their misunderstanding of tables, but its really quite unfair on the language and those who have used it quite well to do big things ..

I've always assumed that there is some technical reason for Lua being 1 indexed, rather than it being a design choice.

Either way, I think it's a nitpick to complain about. I've written a decent amount of Lua and there's only been a handful of times where 1-indexing was even relevant to me.

Cool stuff!

There are arguments for why 0-based indexing is _better_, unrelated to pointer arithmetic. https://www.cs.utexas.edu/~EWD/transcriptions/EWD08xx/EWD831...

> we had better regard —after all those centuries!— zero as a most natural number

Of course, a counter argument is that we've already made the mistake of indexing with 1 in natural language (first, second, ...). That decision is not free of annoyances, though: the 19th century are year numbers 18xx, floors below the first have a varying names when they could have been negative numbers, etc.

The reasoning is to be consistent with C and it's more than enough reasoning for me. I don't know if 1-based indexing is fundamentally better. However, I know the probability that I will need to use other languages in the future is 100%, and they'll use 0-based index.

It's like right-click-to-select.

Due to the embedded nature of Lua, it’s often impossible or difficult to use libraries. And I don’t want to reimplement basic functionality every time I start a new project.

Alright, here is Janet, which is designed to be embeddable just like Lua:

  (set enemies (filter |($ :alive) enemies))

Though JavaScript has QuickJS, which is also lightweight.

[dead]

A JIT is a double edged sword, it _can_ make your code faster, i remember in the early days of smartphone gaming, developers often had to manually "warm up" the JIT to prevent stutters during gameplay

It still is an issue nowadays https://discussions.unity.com/t/app-needs-warmup-first-slow-...

Similar story with the GC, it's nice to have, until it causes you problems (wich it will), so you end up having to avoid using it and instead rely on manual techniques

JIT and GC aren't the panacea people make them out to be

Optimized abstraction layer is still an abstraction layer. The web is like two or three of those.

Love2D uses Luajit and directly calls established game libraries. The CPU usage should be far better for 2D games, luajit is faster than a browser's javascript jit. You can also create single exe games that are a few megabytes and not a few hundred megabytes.

Explain this to electron haters.