addoo

Now imagine that the play cannot be altered (game build), it can only be performed on a specifically shaped stage (hardware requirements), actors can only be replaced by lookalikes (‘remaster’ tweaks), it can only be performed with a full theatre (online requirements), and the playwright retains the only copy of the play (source code).

Then you start to approach the problem that is gaming.

one of them exists now

My first thought was ‘this already existed, I could have bought virtually the same product already.’ …Which the article acknowledges even. Odd title.

I really wish that e-ink could be unshackled. I really love e-ink, I ordered Dasung’s latest portable monitor because I read on my computer a lot (which I’d love to you for work, but for a myriad of reasons I can’t… at least I can use it personally). My smart[ish] watch has an e-ink display. I’d love to see more products and more competition in the space, but sadly that doesn’t seem like it’ll happen.

The article already touches on this, but in the modern day the games that exist on physical media are pretty much useless without their zero-day patches. Putting physical media aside, companies rarely make older builds available, so even when media contains a game and servers are up there is already plenty of ‘lost media’ if you consider old and interesting (potentially hilariously broken) old builds of virtually every game.

I’ve realized this at some point, but video games are ephemeral and should really be enjoyed in the now. Even if you can perfectly preserve a game, and the means to play it, tastes change so quickly in gaming that a game that’s fun today might not be enjoyable even a year later.

We use ruff for everything that isn’t a custom rule.

The only thing I found it ‘missing’ was an indentation check (it’s in preview, I don’t turn on preview rules), but I realized it doesn’t matter because we also have a formatter running on everything.

I guess it’s all relative. One of my code bases still has pylint running with only a couple custom lint rules, that one is slow as hell.

As for version bumping, maybe it’s just a me thing, but I hard fix a version and only update occasionally. Sure each update brings new warnings, but most of them are valid and if you only do it a couple times a year… not that big a deal.

For context, my experience is colored by the kind of work I do: building codebases from scratch that tackle ‘niche’ (read: not readily available as FOSS or described online) problems, usually in small teams or solo.

For a completely inexperienced dev, they may delegate to having AI draft the entire project for them. If a part doesn’t work, they just keep repeating the prompt until it does. They’re not tweaking and twiddling, so the mindset is ‘if it works then I’m done’.

For an experienced dev, usually they will define a structure and have a clear understanding of what the inputs and outputs of each component are. They’ll also write what are known to be critical code sections themselves. AI is usually used here as they might take advantage of an intern—to do the busy work—and because they have adequate experience it’s fairly trivial to review the code and manually fix problems before adding it to the codebase.

For people in the middle ground, they end up with hybrid of these qualities, and it generally doesn’t turn out well. They might define a structure, but not well enough to know exactly what components to create from an LLM, nor knowledge of which sections need to be done by hand, nor be adept at finding deficiencies in the code they’re given. Because they have the ability to debug, they spend time debugging failures instead of just promoting again, and because they let bad code slip into the codebase failures happen just as often as if done by hand, but with the disadvantage of not having authored the code in the first place.

Humans

Please describe in more specific terms. Are we talking non-technical, intern, junior, or senior experienced humans?

Literally just yesterday I was diverted to help someone who is a senior developer, but a novice in Python itself, figure out why code that AI helped them write was completely busted. They were extra perplexed because most of the code was identical to a block of logic we use today (and works), but in this new context didn’t work at all. Turns out whatever the AI did, it didn’t have a concept of method overloads, so the types being passed around were suddenly wrong.

AI works well for people who know nothing (it can do things for them that work well enough), or people who know ‘everything’ (it can get them 95% of the way, they can use their experience to find and fill the remaining 5%). It’s absolutely terrible for people with middling experience.

This is political, so are the tariffs. It’s the same cat and mouse game with local/state regulations on restaurant staff compensation and ‘service fees.’

No love for Amazon in general, they’ve been gaming the system for a long time, but it’s not hard to see why they would do this. Prices will go up, this an easy way to deflect the blame (and to be fair… it’s an accurate deflection).

A CLI argument specification and a parser that implements it. Mostly because I’m annoyed with Python’s argparse, so I’m adding blackjack and removing hookers. Also because I’m annoyed with the arguments used for programs at work and how the same author might use args a different way for each tool (To pull up a usage string, you might need to use `help`, `-h`, `--help`, `-help`, `+help`, or `+<prog>.help`… not all scripts display a usage string when no args are given).

It’s not much, but it’s all I can cram into the free time I have, there’s a possibility I might actually finish it for once, and it’s something I could actually use once it’s done.

While there's certainly an argument for keeping a geographic map, the new map is loads clearer at a glance on connections and peak/exceptional route changes. I don't see a good way to do both and have your cake and eat it too.

I’m pretty sure part of the intent is that it should be easy to write (type) in this format. Separator characters are not that. Depending on the editor, they’re not especially readable either.

Unimportant detail: The prices in the image in the article are 48% lower than the prices at my local California In-n-Out.

I appreciate this article a lot more because it contains an iota of benchmarking with an explanation about why this might be more performant. Especially since my first thought was 'wouldn't this require more instructions to be executed?'

The original post seems really weird to me. I would have dismissed it as someone's hobby project, but... that doesn't seem like what it's trying to be.

This doesn’t really surprise me at all. It’s an unrelated field, but part of the reason I got completely disillusioned with research to the point I switched out of a program with a thesis was because I started noticing reproducibility problems in published work. My field is CS/CE, generally papers reference publicly available datasets and can be easily replicated… except I kept finding papers with results I couldn’t recreate. It’s possible I made mistakes (what does a college student know, after all), but usually there were other systemic problems on top of reproducibility. A secondary trait I would often notice is a complete exclusion of [easily intuited] counter-facts because they cut into the paper’s claim.

To my mind there is a nasty pressure that exists for some professions/careers, where publishing becomes essential. Because it’s essential, standards are relaxed and barriers lowered, leading to the lower quality work being published. Publishing isn’t done in response to genuine discovery or innovation, it’s done because boxes need to be checked. Publishers won’t change because they benefit from this system, authors won’t change because they’re bound to the system.

One thing I've learned writing documentation (and struggling) is that, when you find yourself writing at length, splitting text into sections, and peppering a copious amount of examples, you need to stop and do 2 things:

- Audit for conciseness

- Add a tl;dr summary at the top

And I do wish this had a real example it was playing with, and it consistently used that same example all the way through as it built the layers of what the problem being solved with decorators is. It's a lot easier to teach a concept when you can contextualize it in a way that's shows it's usefulness.

I'm not sure if this metric really matters, but this is wordier than the PEP that describes decorators.

The only things I’d have probably change about this list is the inclusion of some of the collections.abc containers for type annotations, TypedDict and how it can make working with strictly structured dictionaries not terrible (but if it looks like an class and quacks like a class, make it a class if you can), and Counter (only because I forget it exists every single time I should have used it).

Several comments disliking the walrus operator, like many of the features on this list I also hated it… until I found a good use for it. I almost exclusively write strictly typed Python these days (annotations… another feature I originally hated). The walrus operator makes code so much cleaner when you’re dealing with Optionals (or, a Union with None). This comes up a lot with regex patterns:

  if (match := pattern.search(line)) is not None:
    print(match.group())

Not a Python feature specifically, but I’d also love to see code that uses regex patterns to embrace named capturing groups more often. .group(“prefix”) is a lot more readable than .group(1).