berlinquin

Fun project! I had a similar project a while back, but my medium of choice was the Uno card game. I called it UnoScript [1] and it had similar mechanisms as color was an important factor. I also ended with a stack as the main part of the language, where different colors/combinations of cards could read from/modify the stack. Interesting how similar constraints can lead to some similar design choices!

[1](https://github.com/berlinquin/UnoScript)

Is this written up anywhere? I.e. anywhere that walks thru a sample business model?

Have been using a version of this recently: with C++ in Visual Studio you can add `#pragma region X` that will let you expand/collapse regions of code in the same file. Can be useful for top-level organization.

And within labyrinths, the Library of Babel is a good place to start. Circular Ruins and the Pierre Menard/Don Quixote one are favorites.

"I am a sick man... I am a spiteful man." A good hook, but I had a tough time finishing Notes. The narrator really shows that yes, he is in fact a sick and spiteful man. Not one I'd want to pick up again.

I got pulled into Dostoyevsky through Brothers K, which led me to Notes eventually.

Do you know what translation of Notes you read? I think I read P&V, and if I read it again I'd want to try something else

Thanks for sharing. I've looked at getting a PowerPC dev board, but didn't find anything at a reasonable price. I never made the connection that microwatt plus and FPGA would get me there.

Unrelated, but thank you for your blog! I check in occasionally, mostly looking for a reason to justify buying one of the Raptor machines at work. I really enjoy the articles on qemu/virtualization.

Cool project! I'm familiar with column, and this looks like a good replacement.

Curious, how do you handle formatting on cells with long strings that need to overflow to multiple lines? As soon as you try to optimize the column widths for table length, you start hitting an NP-hard problem.

https://quintenkent.com/content/column-problem.html

I can make sense of nested Python list comprehensions if I read them as shorthand for nested for loops, in which case you need to define variables in the outer loop before you can define dependent variables in the inner loop.

e.g. with your example above,

  for xs in xss:
      for x in xs:
          x

What's confusing about the syntax is that `x` in your example above comes first, whereas in actual nested loops it comes last. So maybe:

  [for xs in xss for x in xs : x]

Could be alternative syntax that moves `x` to the end?

The author of Longitude gave some good examples of the human cost of the Longitude problem: a ship running aground and sinking, or sailors dying from scurvy because they traveled too far in the wrong direction. So an economic and military problem, and also one felt directly by anybody at sea.

Beat me to it...

I just finished Longitude and it was a great read! Harrison is an interesting character since he really spent his whole life working on the same problem of keeping time at sea. A whole lot of perseverance.

The grasshopper escapement was invented by John Harrison, who built the first clocks that could keep time at sea. These were used to calculate Longitude. There's a nice short biography called Longitude that covers his story.

TIL Ice IX is a real thing, though less catastrophic than expected

Thanks for naming "model-based testing"--added to my vocabulary. I was thinking more about this, and I would expect very little overlap in the bugs that you could expect to catch with model-based testing vs. fuzzing.

For example, if I get an error with TLA+--e.g. some state reaches deadlock, or there's an invariant that's violated by some behavior--it takes me a good deal of interpretation to see if there's actually a problem, or if just need to update my spec.

With fuzzing, it seems like the errors would be pretty clear to interpret. e.g. uncaught exceptions, or out-of-bounds memory accesses are clear problems with an implementation, and I would think takes less interpretation.

First time reading about compiler fuzzing, but seems like there's some parallels with TLA+.

With TLA+, you could check a compiler's specification before you implement it. Then, once you've implemented it, you could do fuzzing on the actual program.

I wonder how much overlap there is between bugs you could catch with TLA+ vs fuzzing.

I can second Lamport's series of video lectures. I worked through them recently and found the teaching and the examples to work through very engaging.

Thanks for sharing. I have a debian box that I try keep as standard as possible, and I think this setup would fit my environment well.

GEB is pretty dense. Comparing GEB to short stories by Borges, I feel like Borges is able to capture the same ideas (recursion, infinite permutations) in a more engaging way and at a fraction of GEB's length.

I can recommend anything by the Argentine author Jorge Luis Borges. He's primarily an author of short stories. Of those, The Library of Babel is how I was introduced to him.

There's a cool programming project already based on this short story that I've enjoyed exploring: see https://libraryofbabel.info/

And looks like there's a link to the story on archive.org: https://archive.org/details/TheLibraryOfBabel/