vgel

It's less calibrated but still useful, yea

Reading the transcript of Stalin, Molotov, etc's conversation with Eisenstein was really interesting. Even if you disagree with their analysis and what they're doing, it's clear they know the period very well--it's hard to imagine modern politicians speaking on history like that.

Thank you for making it free! I've used it on my blog (https://vgel.me) forever, since back before I ever would've paid for analytics, and it's been rock-solid the whole time. Some of the most "set it and forget it" software I use. I definitely owe you a donation so I'm glad I saw this!

Oh, we already sequenced it awhile back. As for physical media, that's not exactly what happened... https://www.ncbi.nlm.nih.gov/nuccore/NC_001611.1?report=fast...

Oh, interesting--I remember messing around with flags on the stack but was having issues with the WASM analyzer (it doesn't like possible inconsistencies with the number of parameters left on the stack between blocks). I think your solution might get around that, though!

Looks like Schism (https://github.com/schism-lang/schism) got part of the way there, but it unfortunately seems to be dead.

I think because it's ambiguous with unary plus (a = +b), since C isn't supposed to have significant whitespace in most circumstances.

Oh, that's neat (funny that they skipped out on similar things to me, like GOTO and structs :-)

I didn't see a link to the source in the article, but this seems to be it: https://sourceforge.net/p/tiny-pascal/code/HEAD/tree/NorthSt...

Maybe not the language choice, but the codegen of this compiler is terrible because of the single-pass shortcuts (for example, it unconditionally loads the result of all assignment operations back to the stack just in case you want to write `a = b = 1`, even though 99% of the time that load is immediately thrown away.)

Well, I set the 500 line budget up front, and that was really as much as I could fit with reasonable formatting. I'll be excited to see your 500 line C compiler supporting all those features once it's done ;-)

I actually almost made it a C-- (https://www.cs.tufts.edu/~nr/c--/download/ppdp.pdf) compiler, but IIRC the `goto`s made me go with the regular C subset instead.

I think the code is fairly readable! It's formatted with Black (and therefore limited to reasonable line lengths) and well-commented.

IMO, being under X lines of code is part of the readability—10,000 lines of code is hard to approach no matter how readable it otherwise is.

Ooh, this is cool! Using WASM let me avoid writing a register allocator (though I probably would have just used the stack if I had targeted x86/ARM since I wasn't going for speed).

I'm not sure, haven't looked at the codebases of old compilers in a long time. Definitely a lot of the language is pretty amenable to it, especially if you have unstructured jumps for e.g. the for advancement statement. I had a distinct feeling while writing the compiler every time I added a new feature that "wow, the semantics work exactly how I'd like them to for ease of implementation."

Compare that to, say, Rust, which would be pretty painful to single-pass compile with all the non-local behavior around traits.

Oh, C4 is neat—technically it has me beat since it also implements the VM to run the code—though their formatting definitely takes advantage of long lines :-)

A lot of the reasons for decline cited in the article feel fluffy. "The best washer/dryer depends on who you are"? The Wirecutter always gave alternatives and "upgrade picks". "People prefer influencers"? Are there washer/dryer and toaster influencers now?

What killed the Wirecutter for me was the standing desk referral code scandal, full stop. Their whole thing was "one stop for the best thing", and if there's any hint of bias there, it kills that. I believe that was after the NYT acquisition--I think it's very fair to lay the blame at their feet.

We had superhuman diagnosis systems 50 years ago!

> Mycin was never actually used in practice. This wasn't because of any weakness in its performance - in tests it outperformed members of the Stanford medical school. It was as much because of ethical and legal issues related to the use of computers in medicine - if it gives the wrong diagnosis, who do you sue?

https://cinuresearch.tripod.com/ai/www-cee-hw-ac-uk/_alison/...

> Swing dancing

Swing It Seattle? Me and my wife go to the wednesday dances :-)

Yeah, exactly, but to enjoy the small game at that point, I think you need to have an appreciation for small games. I guess it's possible to enjoy a small game as only the core of an imagined larger game, but... it's not how I think about game development, at least.

Some people, yeah. But a lot of people only enjoy the game because of complex systems that were added later: redstone, slimeblock machines, building complex farms, gear progression via material and enchantment upgrades, exploring an infinite world, etc. You can go on Youtube and see people who only play those parts of the game. I think it's fair to say that they wouldn't have enjoyed, say, Indev, before those features were added. And Indev, before the infinite world, was already the culmination of 6 months of work on the game! That's pushing the definition of "small game" already, and a lot of people would still treat it as "a cool toy, but not a full game" (I played it back then and remember people talking about it as such).

I think a lot of it is what types of games or genres you're interested in. Certain games / genres of games work better as small games than others.

Like I've worked on a lot of small games (https://vgel.itch.io), some better, some worse, but I've never tried, e.g., an FPSRPG or a Dwarf Fortress-esque simRTS. The process of "stripping down" those genres to be feasible as a small game fundamentally transforms them into something else. When you rip the complex skill tree out of an FPSRPG to simplify it, it becomes a different kind of game! And some people just don't like that—they only want the complex game. They didn't like early Minecraft, they only like Minecraft now, after 10+ years of development gave tons of interlocking features and mechanics. And that's... what it is. It makes me a little sad, but I don't think those people will be very happy as solo indie devs (unless they have the superhuman willpower to push through years of development on a single game without enjoying the early stages or the tight feedback loop of improvement you get by releasing smaller games).

I've tried to sell this vision to people before, maybe not as eloquently as OP, showed them Itch.io and some of my favorite games on there, and... they just didn't care. It didn't interest them at all. Other people got the appeal immediately. It just seems to come down to personal taste.

I still use an iPhone 6s—typing on it right now in fact—and the web has definitely moved on past these old devices. When I got it, it worked perfectly. Now lots of websites will run out of memory and crash the tab after a bit (e.g. new Reddit, Twitter, most news sites), and just chug in general because the rendering can't keep up. I've gotten familiar with how Safari prioritizes painting because on slow sites I can watch the sections pop in.

I've replaced the battery and the health is fine, people just don't test their stuff with old devices (I've done frontend before, I get why not).

I think that kobold is cute!

Oh yeah, absolutely. Just not something I'd use for, e.g., mortgages where denying someone unfairly could lead to a lawsuit.

But note that just because a model says it's using chain-of-thought or tools to come to a certain conclusion, doesn't necessarily mean that it is: https://vgel.me/posts/tools-not-needed/

Oh, this is really cool. Thanks!

Microsoft bought Mojang in 2014 and forced people to merge their Minecraft accounts into Microsoft accounts in 2021.

Microsoft bought Github in 2018. We'll see what happens in 2025...

Interesting--I didn't know why the first ingredient is listed as broth--but the doom and gloom attitude was a bit much. E.g.:

```quote

As Moss pointed out, even the FDA-mandated nutrition facts box that has appeared on most packaged food since the ’90s “was conceived by none other than the food industry itself as a way of placating us.” Back in the ’70s, he explained, consumer advocate Ralph Nader was talking “really loudly and publicly about the evil-sounding” chemicals that the food industry was feeding to unknowing consumers. “As a way of countering that attack, [they figured] why don’t we disclose lots of stuff on the labels of packages and if we do so, people will feel comforted by the idea that the government is keeping track and it must be okay,” Moss said. “What I thought was our friend was in fact a conceit of the industry to lull us into complacency.”

```

Alternative read: activist makes a stink about a bad industry practice and industry self-regulates an effective response that helps the situation significantly. Is it perfect? Of course not, but my understanding is that the US has some of the strongest food labeling regulations in the world (similar to the EU's, much better than e.g. China) and they're being continuously tweaked to be better. As a consumer I can look at a food label and see basically everything that's in it that I care about, e.g. HFCS, and that means customer preferences drive company behavior. What this article sees as crass language about "good labeling" from the chicken concentrate manufacturers, I see as evidence that food labels work to change corporate behavior. If there were no food labeling laws who's to say that store-bought chicken stock would have any chicken in it at all?

Maybe I just have more of a stomach for industrial food production? I mean I make homemade stock and it's delicious and in a different league than anything from the store, but sometimes a meal needs some chicken water and you have nothing in the freezer, you know? It's not so bad. If we want to talk about store-bought crimes against the culinary arts let's talk about store-bought bread.

If you're going to be working on CSS anyways, I noticed that the tables on the pronoun page could use a little bit of padding—the text is touching the table borders (https://vgel.me/imgshare/xe-pronouns-no-padding.png)

The problem is a lack of trust, same as a contractor. If you go to a new mechanic and he says you need a $1,000 repair—do you? Or is he trying to sell you replacement blinker fluid?

A lot of managers feel the same way when engineers talk about tech debt, refactoring, etc. Maybe they've never read code, or aren't familiar with the specific codebase. Projects seem to be getting completed—what's the problem? Maybe velocity is going down, but are the engineers right about why? Or are they just being anal about something that's simply less than ideal?

A good contractor walks you through why the repair is needed, what your options are (cheap temporary fix, long-term repair, total replacement), the consequences of those choices, and how much each will cost.

Unfortunately in software we don't really know how to answer any of those questions. A lot of refactorings and rewrites just shuffle irreducible complexity around ("it makes so much more sense now!" says the developer who just spent a week studying the code and rearranging it to their personal preferences). Not to mention that we suck at giving estimates.