Split Fiction has a couple of mechanisms that make it accessible for people who are not experienced gamers. There is a general "reduce damage done by enemies" setting that make dodging attacks unnecessary. If you get stuck on something, there is a "skip to next checkpoint" button. This is very helpfully for the one or two really oboxiously hard parts. This is an improvement in accessibility over the developer's previous game It Takes Two.
I'd highly recommend Split Fiction, both for its game play and story. It is also superior to It Takes Two in that there is no part where the games "to continue playing, press X to dismember your daughter's anthropomorphic stuffed animal to make her cry". That was a jarring and unpleasant shift in tone for an otherwise mostly light-hearted game.
I wonder if they don’t include all the application compatibility stuff in LTSC. It would be a good way to make the version work for its intended purpose (as part of a larger appliance or industrial tool with purpose built software), while making it much less useful for ordinary purposes.
I think for a very specific audience the article is useful: an English speaker who is in the first month of learning Japanese and is having trouble understanding the basics of Japanese verb conjugation.
If you are not in that target audience, the article is not that useful. If are starting to learn Japanese, you would not start by reading this article. And once you are past your first month of learning Japanese, you have internalized how this basic part of Japanese verb conjugation works and thus the article seems hyper focused a tiny part of learning Japanese. So it’s predictable that people would point out the limited scope of the article.
I think “Aeron Buchanan's Japanese Verb Chart” offers a more complete overview of Japanese verb conjugation in a more concise form. It expects you to know how to read hiragana, which is reasonable because it’s one of the first things you learn when studying Japanese.
> people who block everyone out by default, passively and indiscriminately, contributes to social rust rather than trust
I'll turn this around: when I see people wearing headphones on the train or the bus, I appreciate that they respect everyone around them. Silence is a commons, and the headphone people respect that not everyone wants to hear their TikToks, their phone calls, their hallucinations, or their small talk.
> conducting yourself as though everyone is de-facto untrustworthy is a problem that doesn't seem likely to be solved by passively blocking the world out
Actually it does. Dealing with touts and sales people by ignoring them is usually more effective at getting them to leave you alone. If you engage at all, they manipulate your sense of politeness to draw you into a longer conversation or get you to do what they want. This is also true of most types of grifters and assholes.
Every time I got drawn into a scam or harassment, I could have prevented it by simply not engaging in the first place.
> I don't know why I'd pay to live somewhere where I'd prefer not to interact with anyone. If the place actually does suck, then I should do everything in my power to find somewhere that sucks less.
I live in the SF Bay Area and frequently visit Boston and Japan. In this limited experience, I've had a great time meeting strangers in social situations like at bars. I have never had a positive result from giving a stranger the time of day in public places (outside of giving directions). Maybe these places suck and I should leave, idk, but don't judge me for taking a default deny stance after consistently having negative experiences.
And this is just my male perspective. My female friends have even stronger stances against engaging with random people in public.
You say “as long as it's not clearly harassment” as if that is uncommon. Outside of giving directions at train stations, the times when a stranger has started talking to me in public have been almost universally negative. Often times it starts as a friendly conversation before the harassment or begging for money or scamming starts. Other times the people just start out crazy or harassing.
I feel like your conception that “ignoring people either consciously or through technology is rude”
makes more sense in higher social trust situations. Like at a party or a bar, where bad actors are less dense and there is an expectation of socializing.
That's funny about your last line about Messenger. When I was at Facebook in 2020 and 2021 I thought the "Lightspeed" version of Messenger [1] was something of an engineering marvel. Specically the way it was centered around SQLite as the datastore, how the sever side could integrate with it, and how the UI was power by this reactive-style framework written in C. With lots of testing to keep binary size under control and things working reliably. And the DX was not bad for all these constraints. I think CG/SQL [2] is one of the few open source artifacts from this effort.
There were other reasonably nicely engineered things there, like some of the code-as-configuration things in PHP like the ORM and the structured logging. Where you just write and commit code and the databases and data warehouses just get set up automatically.
The choice to have a monolithic web stack at Facebook had some benefits. The latency from landing a diff to being in prod was a couple of hours, not matter what part of the site you touched. And given an arbitrary URL, there was a tool that used static analysis to tell you which file handled that request. Compared to Google where every damn thing is a micro-service with its own variable release schedule and different ways of doing request routing. Trying to figure out where a request goes is combination of dynamic tracing of the RPC trace behind it plus a bunch of grepping through the related code bases.
All that said, I was far away from doing real engineering at Facebook. I accidentally joined a growth team. Which meant our teams remit was churning out all kinds of experiments to see what we could to do to make our team's number go up. I did not find this type of work enjoyable and quit. So I have a narrow perspective.
Also to give these multinational corporations some benefit of the doubt, some of the way they operate is path-dependent. They have hundreds of millions of lines code. So they can get to a point where it makes sense to hire a bunch of compiler engineers to fork PHP and make the Hack language. Whereas a startup would almost certainly never create a new programming language to write their product. To take solutions of this context and apply them to the outside world might not make sense.
And a lot of the time pressing back will take you to some other article on the website instead of where you came from. Because the site used history.pushState in JavaScript to manipulate your history.
I suspect you are right that LLM-generated software will likely negatively impact people's lives. The flip side of this is there is going to be a lot of software generated that would have never been possible before. And for some use cases, some crappy software is better than no software. I think it's hard to predict whether on net this will be a good or bad thing.
To make this more concrete, the Chromium source code browser has a subset of the functionality of the internal Code Search tool. For example, you can left click on symbols to go to reference and right click to find all references:
Eh, at least for people consuming .NET apps compiled with NativeAOT, the experience is similar. Applications can be compiled as a single file with no dependancies. A hello world in .NET is half the size of one in Go:
I understand the stated reasons and disagree with their conclusions. It seems like a lot of extra work on the part of the Zig developers to have to reverse engineer undocumented interfaces. There is potentially extra work for the Windows developers if they want to change their private implementation details that Zig programs are now relying on. And in the case where the lower level APIs are missing features implemented higher level APIs, Zig has to either reimplment the functionality themselves or not have the same level of support for Windows features that normal Win32 apps have. A concrete example is looks like Zig programs can't open serial devices:
> I wonder how much of this problem was caused by lack of adequate documentation describing how an installer should behave, and how much was developers not reading that documentation and being content when it works on their machine.
There is a third option: the developers knew the rules and chose to ignore them for some reason. A modern example of this is the Zig language’s decision to reverse engineer and use undocumented APIs in Windows in preference of using documented APIs.
In addition to reason in the article, one thing I’ve noticed among some executives and product managers is their experience using LLM coding tools causes them to lose respect for human software engineers. I’ve seen managers lose all respect for engineering excellence and assume anything they want can be shat out by an LLM on a short deadline. Or assume because they were able to vibe code something trivial like a blog they don’t need to involve engineers in the design of anything, rather they should just be code monkeys that follow whatever design the product managers vibed up. It is really demoralizing to be talked to as if the speaker is promoting an LLM.
There is a middle ground between using XML and imperative code for representing tax forms. Robert Sesek’s ustaxlib [0] uses JavaScript to encode the forms in a way that is reasonably statically analyzable. See the visualizer [1]. My approach uses XML to represent the forms with an embedded DSL to represent most expressions tersely. See for example Form 8960 in ustaxlib [2] and my TaxStuff program [3]. The main thing that the XML format from the article has going for it is that it is easy to write a parser for. But it is a bit verbose for my taste.
I can be contacted at AustinWise through gmail.
http://www.awise.us/