WorldMaker

We are in a golden age of indie cinema right now. Low budget stuff is doing better than it has in most of the history of the media. Both Backrooms and Obsession made strong returns on very low budgets. The kinds of movies like Reservoir Dogs and Pulp Fiction are doing rather well. Normal and Furious were both good as two recent examples. I could give a long list of really cool stuff I've seen just this year. Have you seen Buddy yet? So weird and rather great.

What Hollywood "lost" in recent decades wasn't indie/small budget/experimental/weird cinema, but "the middle budget", the romcoms and "family movies" and expensive ensemble comedy movies and oscar-bait dramas with lots of bankable stars doing silly or dramatic things on less than a blockbuster budget but more than an indie. But the indie world is filling in a lot of those gaps, and the direct to streaming "original" world is filling in more of those, and signs are some of those budgets are coming back (Heart of the Beast is an example of that sort of lost mid-budget film that just released to theaters).

You may not like superhero budgets, but they are not what killed "weirder indie shit". If anything they seem to be supporting it. Superheroes killed the mid-budget because they could play many of the mid-budget genres such as "family movie", comedy, and romance, and sometimes even "serious" drama.

(ETA: The Big Lebowski is a fun example because that was an indie budget film and the closest the Coens came to the mid-budget was The Hudsucker Proxy which needed it for all the period piece work. Budget size doesn't necessarily equal quality, though I remain a fan of The Hudsucker Proxy it did poorly in the box office and is often considered one of the worst films from the Coens. Ethan Coen directed Honey Don't and Drive-Away Dolls in recent years which were both excellent. The Coens haven't disappeared, though they've shifted gears a bit.)

I prefer the punny term "Soup opera". (It's full of supes.) It doesn't need to be gendered, women love many of the superhero movies and TV shows, too. There's also plenty of women that are fans of wrestling, as well.

Also, I say it with affection. I love my soup operas. Our culture has come to have negative connotations to the term "soap opera" and also to the term "wrestling", because of the association with lowest common denominator storytelling, but it is harder than it looks and mass appeal isn't something to scoff at.

I have and continued to say that "I googled it on the Bings". Some people have used it as the generic verb.

Microsoft has invested in C# for a much longer time, and uses it themselves in production. Why would you doubt Microsoft has at least some vested interest in exploring more cross-over of C# for systems programming that today Rust gets used for, but C# is growing capable of doing?

Yeah, 1 is always better than 0, just that reminder that real "product focus" happens when you have multiple customers, not just doing one-offs for one or two customers.

I know people that have used it that way in a while. Myself included: I certainly say that. I haven't intentionally used Google the search engine in years, but I use it at the generic term for an internet search.

Losing a trademark to a generic word can make marketing a lot harder, though. A company often needs a new brand then, because everyone else can use their old brand in the marketplace.

It would be fascinating for Alphabet to lose Google the brand to being a generic word. (To be fair, it is something that maybe should have happened already.) Kagi or DDG or someone could use a domain like google.new or google.tech to easily retrain old habits of some users. What is Alphabet going to do in that case? If Google is no longer a trademark but a generic word, do they focus on having the "Alphabet Brand Google" or "The Original Google, by Alphabet"? Either way, that's harder to market and maybe easier to build a fresh brand than fight the generic terminology.

Yeah, the Smalltalk and Self family take this "everything is an object" approach, sometimes to extremes.

Another relatively well known language in this space for its use as an alternative to especially Lua in embedding situations is Io: https://iolanguage.org/

> And you need at least one real customer project to dogfood the platform initially. Because most platforms start out way too generic with pure architecture astronauts [0] at the helm.

The Rule of Three in Refactoring applies to this scale, too. If you are building a "platform" for one customer project, that's a one-off and quite possibly YAGNI. If you are building a "platform" for two customer projects, that's likely coincidence and still possibly doesn't show company-wide need. If you can build for at least three customer projects, that is a pattern, that provides real guidance on exactly how generic things need to be and better ideas how to abstract it.

I've had similar fights over the years, on both sides of the discussion.

"If our internal design system is barely half as well documented than Bootstrap then teams will still use Bootstrap. We should take a page from Bootstrap's documentation and include as much detail as we can, on everything."

"As a platform team, your product is this API my app calls. My beta environment should be pointing to your Production, never your beta environment. If that means you need to support better multi-tenant from the same 'app', then you need better multi-tenant. Your outage impacts my testing, which impacts my velocity, which impacts my deadlines. Your backwards incompatible updates need to be planned and scheduled and rolled out like a Production update, every time."

Product mentality is still very useful in platform development. If you can't sell your platform on its documentation and its stability and you must sell your platform on mandate and top-down control, you probably aren't doing as much to help your engineering culture as you think you are.

I've had justwatch.com tell me things are on Mubi with ads, so I've watched films on it, but can't remember which ones and not enough to subscribe.

GoldenEye was re-released for Xbox One and is available to purchase right now: https://www.xbox.com/en-us/games/store/goldeneye-007/9n6639h...

I've been wondering this some myself, how many services I could drop and just return to a physical media budget.

One of the factors contributing to it not necessarily being cheaper to buy box sets: Target, Best Buy, and other big US chains have given up on physical media for movies. Last I heard Wal-Mart is on the fence about long term support for it. (At the moment the only chain I know that seems still in it for the long haul seems to be Barnes & Noble, but they could have one bad quarter and change their minds quickly. My local store the DVD and Blu-Ray section is somewhat obviously what used to the Music section and still has a bit left of that old focus.)

Even the manufacturing side seems to be disappearing. Sony has flirted with dropping physical media sales of movies. Warner Brothers and Paramount seem likelier to drop physical media sales if they are allowed to merge.

Netflix lets very few originals make it to physical media. Most of the exceptions I'm aware of are Sony projects. Sony Animation being one of Netflix's last exclusive deals from a studio that isn't themselves. A lot of Prime Originals don't make it to physical media. It seems a mixed bag for HBO Originals and Hulu/Disney+ Originals, presumably based on some internal formulas of popularity. A lot of Apple TV Originals seem to get delayed physical output, but that's largely been because Apple TV doesn't have its own studio, but that changed relatively recently with the purchase of Red Hour (Ben Stiller's studio, of Severance and The Dink fame).

It certainly feels like physical media is dying right now. Maybe more reason to switch to investing in it over streaming services, not that an individual's budget decisions in this vein will affect the company's bottom lines enough that they will notice.

Something that stood out in skimming the document was how close to parity the two languages seem to have in general, especially with things like Span<T> filling in a lot of the things that might have been "gaps" earlier in C# history. Knowing Microsoft's historic biases and wars, a part of me is wondering if this document is something of a trojan horse for the opposite conversation, trying to sell more Rust users that C# can be a "system's language" today when a Rust mindset is brought to it.

Especially the "unfair" comparison of the document sticking as much to the BCL as possible and trying to avoid NuGet packages, but needing cargo packages for a lot of the side-by-sides, seems to favor C# for some types of programming.

It's great that C/C++ developers are finally starting to see the light and moving to Rust. Maybe Rust is finally the bridge from C/C++ to C# that Microsoft has historically been missing and has been the source of some internal wars at Microsoft.

Keeping a UTC offset is two extra bytes and with a UTC offset you can do all of your time comparisons and time math as if everything was in UTC, but you have extra debugging information in the UTC offset. It's still sometimes useful to store a time zone as offsets to timezones certainly are not 1:1 (esp. with DST math), but some places like logs and past dates UTC offset is sufficient and you don't even need to store timezone.

Postgres doesn't a native type that supports UTC offsets, but some other databases do and it is extremely useful. At this point in my career, I would never choose UTC storage over UTC Offset storage.

SQL Server has `datetimeoffset` which stores the UTC offset (and so roundtrips it), which is definitely an improvement. (You still may need/want a string timezone column even with UTC offsets, but you don't need a denormalized _utc column because datetimeoffset math just works as if the times were all UTC.) It seems like something that Postgres could use. Especially because the overhead for storing UTC offsets isn't that much. (10 bytes versus 8.)

I've seen too many ways storing everything as UTC goes wrong/gets confusing. Round-tripping at least UTC offset (which unfortunately Postgres `timestamptz` in this case does not do and is effectively the same as storing as UTC) gives you more debugging tools for events in the past and more opportunities to do the right thing for future events in worst cases (strange, unexpected DST shifts). The best option is if you can also round trip exact time zones such as IANA strings like "America/Los_Angeles". Even fewer databases support that natively right now (as a single optimized column).

When UTC offsets roundtrip you can do all your date math as if everything was in UTC, but still not lose information from the user about what time they thought an event occurred at or might next occur at.

A lot of the design reads like almost but not quite ActivityPub.

I've known people advocating for proportional fonts for source code for a long time (many of them also in the literate programming camp). It would be funny if LLM slop was the final aesthetic push over the last few hurdles there to making it more common.

The other difference was that Bootstrap met WCAG standards and had a very strong baseline of accessibility. These LLM slop outputs meet no such standards and seem to laugh in the face of accessibility.

The vast majority of LLM slop seems to be Tailwind to me, so sort of the opposite of a library, just a bunch of common patterns in Tailwind so common as to be everywhere but not common enough anyone bothered to put them into a reusable library.

Exactly. The benefit to the Bootstrap boom was it elevated a lot of cookie cutter designs like a raft on a series of sensible defaults that were are close to sensible/good taste as some very talented designers could make industrial cookie cutter standards. Bootstrap enshrined smart, intelligent defaults like good color contrast and a baseline of accessibility for developers just copy and pasting and modifying what Bootstrap gave them. For a brief moment the "I just need to get this done" web had a good accessible baseline.

LLMs aren't starting from sensible defaults and don't have to meet WCAG scores unless you tell them to (and even then might hallucinate checks they didn't actually make).

All caps text is a roadblock for reading speed/comprehension. Accessibility experts were finally convincing major company design standards to stop doing it when LLMs made it a default again [0] for headers and incidental text.

Not to mention that all caps text is also generally associated with shouting and just feels rude to some readers.

[0] Or more accurately trained on all the bad examples before experts started catching them and has stuck to the mistake.

It's partly a "Don't think of a Pink Elephant" problem. I've worked on several projects where I had to keep telling prompt writers to stop writing negative examples because the more you include the more its "attention" to them is all it has. Like telling a toddler not to do something and being surprised that is now all they can think about and they want to keep doing it. These prompt writers kept getting surprised that I'd delete all their negative examples and harshly worded "Don't do X" and "Never Y" and "NO: Z" sections they spend so much time on and got better results with smaller more focused positive example only prompts.

I've seen a couple companies already change their design standards to "best in class Tailwind designs from Claude, use this prompt file/Agent file/skill file combo for all UX work".

Looking at automated emails I get from Microsoft and GitHub it certainly feels like they are one weird layoff from doing it company-wide.

The worst part is these glassification Tailwind heavy slop almost universally fail WCAG guidelines (and personally, seem hard to read to me because of taking the whispy sans serif thing to its foregone conclusion by almost exclusively using what to me are unreadably thin weights of the already too thin Inter font). The slop is going so quickly backwards for companies that invested in accessibility and these companies need to be taken to task for forgetting design isn't just aesthetics but readability and accessibility.

"Confidence scores" have always implied an anthopocentric meaning that doesn't exist. An algorithm doesn't have "confidence" in the way that a person has confidence, but as soon you put something with that name in front of a business person they assume the number is always a meaningful "letter grade curve" or "universal percentage". I still believe so much that the old quote to "there's lies, damned lies, and then statistics" remains a key to understanding so much why ML is leading to dumb outcomes versus hype. People don't understand statistics, so machines that produce nothing but statistics especially confuse people. (I feel this applies to LLMs as well.)

LVT is about assessing improvements, conservation can be understood as an improvement and valued as such. For the same reasons that urban parks should have a different tax assessment than low value surface parking lots.

I don't know how hard it is to imagine the easily elided phrase "garage or parking lot or street parking or whatever parking situation" after apartment, but unless you also park in your apartment on the 6th floor it seems silly to ask this question to me.

> Using a functional language for data transforms sounds like a sane idea, haven't played around with it yet but it's definitely on my list now.

It's been one of the plays that the F# community has also been trying to make (somewhat with a modicum of help from Microsoft's marketing arm, but not enough help from what I've seen) pitching F# as a language close enough to Python to feel familiar and useful to data science but with the performance help of rich ML types and the modern .NET performance ecosystem.

(To my experience: getting "fast" compared to Python seems easy for most functional languages. Getting data science out of Python seems hard for a lot of sociology reasons more than technical ones.)

Interesting, most functional languages are quite terse and heavily whitespace, so you would expect raw token counts like that to be lower simply because source documents are on average shorter. Even having to make up for disadvantage things like C++ style operators like &&= all having single tokens from heavy use across a variety of languages but fancy functional operators like <=> being much more rare and in worst cases of undertrained models needing multiple tokens to express.

But yes, terser source documents and low raw token counts could mean lower prediction rates and more prediction attempts needed to get intended results (again, especially if the model was undertrained in that particular language).