the-tomster

It's a bit sad that to keep a computer running smoothly you have to jump through these hoops. I end up with applications building up so much crap in my homedir on linux or appdata / winsxs on windows, I wind up feeling like I need to clean things out once every year or two too.

I try to look at a clean reinstall as a good chance to make sure my backups and restore process are working too. Maybe take a chance to experiment with a different distribution or organize things differently, or new bootloader.

I've used Haxe on the web for a minimalist virtual tabletop. Not exactly production, because the only user is probably me... but my gaming group and I have used it weekly for a couple of years now, and I don't need to spend time fussing over it. So production enough.

I've found Haxe to be pretty pleasant in this situation. The only areas I really needed a library were around graphics and input, and Heaps looked more interesting to me than the JS alternatives I looked at.

The language itself feels like a pleasant mush of all the Java-y OO languages, but without the entire kitchen sink included. You've got all the polymorphism and generic typing stuff you'd expect from a java clone, plus algebraic data types, plus the ability to drop to dynamic duck-typing if you have to. And the type inference has worked pretty well for me. Oh, it also has a macro system I've never needed to use.

The tooling situation is good but not great. The compiler's messages have generally been clear. I am using vim + universal ctags for development, and it is fine but not as deluxe as a working LSP. I didn't have any luck getting Haxe's LSP working with vim, but I assume a VS Code based setup is more of a happy path and would have better luck.

Output-wise, the JS it generates seems fine. For my particular use case I care more about the readability and debuggability of the generated JS rather than the size. It has not been a problem to understand where an issue is coming from while looking at the generated JS.

Performance wise, the only issues I've had were caused by my own foolishness in making thousands of draw calls instead of batching things. Other than bugs I haven't seen any performance problems.

When it comes to libraries, you have to contend with both the relatively small size of the community, as well as the difficulty of writing a library that actually supports all of Haxe's compile targets. Haxe errs on the side of pragmatism instead of identical behavior on all of its supported platforms. So often you'll find nasty platform-specific logic in the heart of libraries, and if your target isn't supported then you have to dive in and fix it yourself. It is not a good language for grabbing a few things off of npm or cargo and slapping them together.

They have a "share to facebook" button at the bottom of the post...

Riichi definitely hits a sweet spot in the game design space. Just the right amount of complexity, always something to think about in game, but still fun to play fairly casually. There are many clever little risk/reward tradeoffs built into the rules, and lots of interesting small asymmetries and feedback loops.

MahjongSoul was recently translated to English (https://mahjongsoul.game.yo-star.com/). The heavy anime-girl theming can be a bit unfortunate but it's an excellent implementation of the game and allows you to play matches against bots to learn the game.

Tenhou is the more classic and staid online implementation, and there are browser extensions for Chrome and Firefox to translate it to english. (http://tenhou.net/)

Pilotwings Resort was a launch title on the 3DS. Neat little nod to Pilotwings (SNES) and Pilotwings 64 launching with those consoles. It was really cool seeing it on the 3D screen.

Yes, if he hadn't swung at it it would have been counted as a "ball". If a pitcher throws 4 "balls" in an at bat then the batter gets to move to first base for free (a "walk").

Some people like to have big monitors so that they can fit more code on their screen at once. Instead of getting a bigger screen why not shrink the code?

As a side project I implemented a small text editor in this style. I had a working text editor with the ability to load a file, insert and delete text, scroll around a large file, and save changes. It fit within about 100 lines of concise (but I wouldn't say obfuscated) C.

In the end I decided to reformat it and use my usual style before implementing more features. But it was a good experiment and I now understand the appeal of the ultra-condensed style you see in J, K, some Forth, and some Perl code.

The author says that "all the problems listed here have already been solved" by Rust and Haskell. Great, so let's stop complaining about Go and use those languages instead.

Go has specifically rejected the complexity that these features introduce, both in the implementation of the language and the writing of programs in it. If you want those features, just use a language that has them. Some other people might not care about those features, and prefer the simplicity of Go, and that's fine too.

The problem there is that every application needs to implement a macro recorder, and every application needs to implement history and undo. With small programs that all handle text the shell takes care of history and automation, while the other programs can focus on solving a new problem.

Why have macros and history reimplemented badly by every application when one application could do it well?