That's the idea! "Allow" the user to install any apps they choose. (I put "allow" in quotes, to emphasize how bizarre it is that a few platform vendors get to decide what all of humanity is "allowed" to do with their computing.)
GP here. I agree in spirit but there’s a technical difference between ”approved to distribute” and ”approved in an App Store”. Specifically, you can distribute software for Windows and Mac outside of their stores, but you still need to have a code cert which means you’re under their mercy. This is the model Google wanted to transition Android to recently: keeping the APK path (no App Store) but gatekeep developers through signature enforcement etc.
This is sort of the defining mechanic of these games in my memory. The first thing that pops into my head when I think of Last Ninja is aligning and realigning myself, and squatting, awkwardly and repeatedly (just like a real ninja, lol), until that satisfying new item icon appears. Perhaps surprisingly, these are very fond memories.
This mechanic is augmented by not even always knowing which graphics in the environment can be picked up, or by invisible items that are inside boxes or otherwise out of sight (I think LN2 had something in a bathroom? You have to position yourself in the doorway and do a squat of faith).
The other core memory is the spots that require a similarly awkward precision while jumping. These are worse, because each failure loses you one of your limited lives. The combat is also finicky. I remember if you come into a fight misaligned, your opponent might quickly drain your energy while you fail to get a hit in.
At the time, it seemed appropriate to me that it required such a difficult precision to be a ninja. I was also a kid, who approached every game non-critically, assuming each game was exactly as it was meant to be. Thus I absolutely loved it, lol.
One problem with the /italics/ form is that it's not convenient when writing about filesystem paths (though I do like its visual indication of slanting).
Or italics can be //double slash// to avoid ambiguities with file paths. That still leaves the windows style //some/file/path as ambiguous
But I’ll never accept single * as natural for italics.
Perhaps more proof of work is necessary, but it makes me sad.
I still remember creating my HN account. It stands out in my memory, because it was the smoothest, simplest, easiest, and quickest account creation of my life.
I had lurked here for around a decade before finally creating an account. Any urge to participate was thwarted by my resistance toward creating accounts (I just hate account creation for some reason). But HN's account creation process was a breath of fresh air. "You mean it can be this easy? Why isn't it this easy everywhere? If I had known how simple it was, I would have created an HN account years earlier, lol."
It was especially stunning to me, because I think the discourse on HN is generally of a higher quality than most other sites (which I wouldn't naturally associate with such an easy account creation process).
It's my only fond memory of account creation (along with maybe when I created an account on America-Online back in the 90s, since that was my first ever account and it was all so novel). Just a few quick seconds, and then I'm already commenting on HN. It was beautiful. I remain delighted.
Somehow I've been browsing HN since ~2019 without ever wanting to reply so much that I was willing to make an account (and start receiving emails, etc) but your comment made me curious how easy it could be, and wow. Now I have an account.
I kind of assumed it was hard to make an account (maybe even an invite-only situation) based purely off of how unique most handles were, and how well curated/moderated everything was. So I guess you could say, the quality of the usernames and the quality of the posts :)
I prefer the perspective that a computer program is akin to a mathematical constant. This was true in the old days. A program I wrote in C64 BASIC, way back in 1980s, should still work precisely the same today (even on one of the freshly-manufactured Commodore 64 Ultimates).
You've honed right in on what's changed since the old days: Platform vendors (such as Apple) now continuously inject instability into everything.
You might argue that developments such as "changing processor architectures" justify such breaks from stability (though I myself have qualms with one of the richest companies in the world having a general policy of "cutting support and moving on"). But I would point out that Apple (and other vendors) create instability far beyond such potentially-justifiable examples.
To me, it appears as if Apple actively works to foster this modern "software is never finished" culture. This is seen perhaps most clearly by they way they remove apps from their iOS store if they haven't been updated recently (even as little as 2 years!): https://daringfireball.net/linked/2022/04/27/apple-older-gam...
Shouldn't we be demanding stability from our platforms? Isn't the concept of "finished software" a beautiful one? Imagine if you could write a useful program once, leave it alone for 40 years, and then come back to it, and find that it's still just as useful. Isn't this one of the most valuable potential benefits of software as a premise? Are the things we're trading this for worth it?
I keep looking for more useful DOS applications. Have had a git repo for 15+ years that has my config and virtual C:. Once something is installed it will just keep working and I sync that repo to all my machines so it have the exact same things running with the exact same versions. Binaries from 40 years ago still run fine. Just wish more modern applications supported it.
I also have QEMU installations of some Windows versions and old Debian versions (I like Debian 3.0, since the entire library of packages fits neatly on a single DVD ISO... that was the last release that small). Those are also useful for having stable platforms to run offline applications on without having to be bothered by upgrades.
> Not a lot of companies allow disabling their garbage, but FF does.
>
> Can't we be happy with this nice switch?
I want my tools to keep working the way they have been working. I don't want to be paranoid that "garbage" (as you put it), or any other controversial changes, are going to be slipped into my tools while I'm not looking.
There is something to be said about that. Firefox does keep inserting it's 'helpful features' like Pocket on users, which is very annoying.
My point is just that everyone is so critical of Firefox, when the alternative is disproportionately, orders of magnitude worse for the user.
I'd rather bash on minor Firefox grievances when it's the #1 browser, not when it's losing/lost the browser war and it's our last chance at browser engine diversity.
> The typical Go story is to use a bunch of auto generation, so a small change quickly blows up as all of the auto generate code is checked into git. Like easily a 20x blowup.
Why do you think the typical Go story is to use a bunch of auto generation? This does not match my experience with the language at all. Most Go projects I've worked on, or looked at, have used little or no code generation.
I'm sure there are projects out there with a "bunch" of it, but I don't think they are "typical".
Same here. I've worked on one project that used code generation to implement a DSL, but that would have been the same in any implementation language, it was basically transpiring. And protobufs, of course, but again, that's true in all languages.
The only thing I can think of that Go uses a lot of generation for that other languages have other solutions for is mocks. But in many languages the solution is "write the mocks by hand", so that's hardly fair.
Me neither. My go code doesn't have any auto-generation. IMO it should be used sparingly, in cases where you need a practically different language for expressivity and correctness, such as a parser-generator.
Anything and everything related to Kubernetes in Go uses code generation. It is overwhelmingly "typical" to the point of extreme eye-rolling when you need to issue "make generate" three dozen times a day for any medium sized PR that deals with k8s types.
But sometimes it is useful to return both a value and a non-nil error. There might be partial results that you can still do things with despite hitting an error. Or the result value might be information that is useful with or without an error (like how Go's ubiquitous io.Writer interface returns the number of bytes written along with any error encountered).
I appreciate that Go tends to avoid making limiting assumptions about what I might want to do with it (such as assuming I don't want to return a value whenever I return a non-nil error). I like that Go has simple, flexible primitives that I can assemble how I want.
Then just return a value representing what you want, instead of breaking a convention and hacking something and hoping that at use site someone else has read the comment.
Also, just let the use site pass in (out variable, pointer, mutable object, whatever your language has) something to store partial results.
But in most cases you probably want something disjoint like Rust's `Result<T,E>`. In case of "it might be success with partial failure", you could go with unnamed tuples `(Option<T>,E)` or another approach.
While I understand that having identical UI elements across apps aids in discoverability, I just love it so much when an app has its own bespoke interface that was clearly made with love.
Like you, it might be my love of games that has given me this preference. Would StarCraft II have a better UX if its menus used the standard Windows widgets where applicable? I think certainly not. And I think the same can be true for many non-game apps.
My perception is that there's always been some dissonance between loving tech intrinsically for itself vs. the Silicon Valley venture capitalist business model. Conflating tech with its dominant business model enables the paradox where a person deeply in love with tech can also be anti-tech.
