Humans already control the weather: https://en.wikipedia.org/wiki/Cloud_seeding.

We already have an example of humans sabotaging the measurement of weather: https://news.ycombinator.com/item?id=41684440. Two ranchers sabotaged weather monitoring stations in order to fraudulently collect millions in drought insurance. One of the farmhands involved ended up dead.

And we have an example of prediction markets attempting to manipulate reporting of events: https://news.ycombinator.com/item?id=47397822.

I have a hard time believing weather prediction markets will be net beneficial. The incentive for sabotage & manipulation up and down the chain seems likely to lead to worse weather predictions overall.

Honorable mentions might go to PICO-8's flavor of Lua (C-like but clearly designed to create a specific type of game and have a specific developer experience) and Excel (used for developing & balancing game mechanics, but usually replaced in the final product).

So much power! And right in line with Perl’s mantra, “there’s more than one way to do it.”

Unfortunately, our codebase contained more than one way of doing it. Different parts of the code used different, incompatible object systems. It was a lot of extra work to learn them all and make them work with each other.

It was a relief to later move to a language which only supported a single flavor of object-oriented programming.

You can acknowledge the problems more directly: "I get it, we don't have enough chairs so Wednesday is likely to be a challenge." or "I know mandatory 9-5 is going to disrupt your commute."

A bonus of the more precise approach is you can follow up with "do you have other issues with the new policy that I may not know?"

This article is a perfect example: it says syncing is a challenge for local-first apps, logical clocks and CRDTs are the solution, and then just ends. It ignores the elephant in the room: CRDTs get you consistency, but consistency isn’t enough.

Take a local-first text editor, for example: a CRDT ensures all nodes eventually converge on the same text, but doesn’t guarantee the meaning or structure is preserved. Maybe the text was valid English, or JSON, or alphabetized, but after the merge, it may not be.

My suspicion, and I might be going out on a limb here, is that articles don’t talk about this because there is no good solution to merging for offline or local-first apps. My reasoning is that if there was a good solution, git would adopt it. The fact that git stills makes me resolve merge conflicts manually makes me think no one has found a better way.

What made it click for me was http://www.exemark.com/FORTH/eForthOverviewv5.pdf, specifically sections 2.3 "Loops and Branches" and 5.3 "Structures". With a slight simplification, if/else/then branching is defined in 7 words.

Two primitive words, branch and ?branch (in python because I know it better than assembly):

  def branch():
    """ branch is followed by an address, which it unconditionally jumps to."""
    ip = code[ip] # Get address from next cell in code, jump to it.

  def branch_if_zero():
    """ ?branch is followed by an address. ?branch either jumps to that address,
    or skips over the address & continues executing, depending on the value on the
    stack."""
    if stack.pop() == 0: # Pop flag off stack
      ip = code[ip]      # Branch to address held in cell after ?branch
    else:
      ip += 1            # Don't branch, skip over address & keep executing

  : >MARK    ( -- A ) HERE 0 , ;
  : >RESOLVE ( A -- ) HERE SWAP ! ;

  : IF   ( -- A )   COMPILE ?branch >MARK ; IMMEDIATE
  : ELSE ( A -- A ) COMPILE branch >MARK SWAP >RESOLVE ; IMMEDIATE
  : THEN ( A -- )   >RESOLVE ; IMMEDIATE

> But if you don't know how to make a game, where does the knowledge come from?

If you're at the stage where you feel like you don't know how to make a game, you might find value in doing the exercises from the book "Challenges for Game Designers" by Brathwaite & Schreiber.

"Challenges for Games Designers" by Brathwaite & Schreiber. This was by far the most helpful, as it laid out a process of finding & refining fun game ideas.

"Game Feel" by Swink. Examines why jumping feels better in Super Mario than Donkey Kong, why Street Fighter feels the way it does, etc. This way of breaking down & examining mechanics was eye opening and can be applied to other kinds of games.

lostgarden.com, especially https://lostgarden.com/2008/12/06/post-it-note-design-docs/, which describes a process for rapidly iterating on ideas, and https://lostgarden.com/2006/10/24/what-are-game-mechanics/, which introduced me to some of the fundamental building blocks of game mechanics.

Resources which helped me later:

I found "Art of Game Design" to be helpful later, when working on making a good game into a great game. The different lenses were great for finding areas where I could improve a game.

https://www.youtube.com/watch?v=Fy0aCDmgnxg really drove home how important polish is. This was useful after I had a game which was already a bit fun.

Finally, an observation & a suggestion, if you're open to them: You admit that you don't know game design, yet you're attempting to innovate by removing limits. This seems like an enormous challenge for a beginner, like someone who doesn't know how to play an instrument attempting to make a new style of jazz.

I think you'd have more success if you learned to play the instrument first: Practice by making a lot of small games. Spend 2-4 days on each, no more. Learn to use prototypes to explore the design space, searching for ideas with a glimmer of fun. When you find one, iterate on it to see if you can refine it into something more fun. As your game design skills improve, your ability to innovate will improve too.

[0] https://incompetech.com/music/royalty-free/music.html

[1] https://heatleybros.bandcamp.com/music