yoyonamite

As someone that recently went through an introductory Japanese course in Japan, I don't find this much different than how it's taught. Or maybe I'm missing something?

It seems like the article is trying to make the case that in romaji, you can split the letters and isolate the vowel (e.g. the asterix in the article's conjugation).

But we were simply taught to change from the う- row to the い- row (u- row to i- row). I switched to Japanese to illustrate that you can make that statement even without romaji. In that case, it seems like basically the same thing?

As an anecdotal point, my class was mostly non-english speakers and I didn't find the above to be a sticking point for my classmates. The real sticking points were messing up the ichidan verb exceptions (ichidan verbs that look like godan) and conjugating the correct form for the different grammar points. Te and ta form were also a bit tricky. But the article doesn't seem to offer anything new to help there.

I don't use VSCode, but I've heard that the default model isn't that great. I'd make sure you're using something like Opus 4.5/4.6. I'm not familiar enough with VSCode to know if it's somehow worse than Claude Code, even with the same models, but can test Claude Code to rule that out. It could also be you've stumbled upon a problem that the AI isn't that good at. For example, I was diagnosing a C++ build issue, and I could tell the AI was off track.

Most of the people that get wowed use an AI on a somewhat difficult task that they're unfamiliar with. For me, that was basically a duplicate of Apple's Live Captions that could also translate. Other examples I've seen are repairing a video file, or building a viewer for a proprietary medical imaging format. For my captions example, I don't think I would have put in the time to work on it without AI, and I was able to get a working prototype within minutes and then it took maybe a couple more hours to get it running smoother.

Why is it silly? Is it reasonable to hold the opinion that DOGE should not have been given access to these systems (note: this doesn't mean that the opposite view isn't also reasonable)? If it's a reasonable position to hold, then getting access to these systems can be reasonably construed as an attack, can it not?

I don't really think this argument merits a comparison to "technology is the mark of the beast" or that the only people that can be opposed to DOGE suffers from "personality derangement" or "glorifies bureaucratic power"

I think it might actually be worse. I don't think the judiciary can enforce any of their court orders.

It's because people ended up with models that were thousands of lines and difficult to reason about. Out of curiosity, did you end up running into this issue and how did you deal with it?

If you don't mind me asking: Do you see a solution, technical or otherwise, to this problem?

My guess is there are limits to knowledge transfer that's difficult, if not impossible, to overcome.

Good code to me usually comes down to things like state management, code organization, ... Having code that reads like prose isn't a high priority to me, but I'm familiar with that style and I can see why people like it. I just wish they'd realize they're expressing an opinion on style instead of a fact.

I think every subreddit should have created a community on a reddit alternative, like lemmy, kbin, etc. and actively promoted it as a "temporary" replacement. This way, Reddit waiting out the blackout risks losing marketshare to the alternative.

Right now, that risk is very low because the alternatives didn't seem to have picked up enough critical mass, especially outside a few big topics like technology or news. Without an alternative picking up steam and stealing eyeballs, Reddit doesn't have an incentive to come to the table and can easily wait this out.

I'm not affiliated with Gimp and don't know why they didn't support fat binaries in the end; but I did look into compiling Gimp as a Universal Binary on my own at one point. My experience matches those of another comment, which is that not all dependencies supported compiling to fat binaries (i.e. you couldn't just add a bunch of flags and get a fat binary at the end). The only solution I thought of was to compile for both platforms and then lipo all the built files. The main problem is I couldn't figure out a strategy to do this without making the build scripts into a gigantic mess.

Getting a Silicon build of Gimp wasn't actually that difficult. I know at least one other person besides myself that had gotten a build working from source and published how to do it in some form. The problem is that the CI system Gimp used for the Mac build did not have ARM runners, yet. This meant that to produce the production build required cross-compiling from an Intel Mac. While I'm sure it's possible to accomplish this, it was quite tedious and I gave up. As an example, one problem was that the Gimp build process builds tools that need to be run on the system doing the build and just splitting out those parts from the parts that need to be compiled for the target system was tedious.

> Honestly, if someone showed up with a gap in their resume and claimed that they were doing start-up, open source, etc. for an interview, I'd dig deep into that hard.

This is just as, if not more toxic than the advice that you're opposed to. I've had similar experiences with interviewers for non-technical questions, and it comes off as aggressive, antagonistic and traumatizing; especially in your example where they left it off their resume as a gap. The interviewee's perspective might have been to say that they've been spending some of their spare time keeping their skills sharp and now you're hammering them to see if a project left off their resume qualifies for some "high bar," while all they see is a negative and dismissive attitude.

Personally, I would much rather be programming my own projects or doing leetcode than play video games, but I wouldn't judge someone negatively if they told me they played games on their own time.

The majority are simply going to follow popular opinion regardless of the merits, and developer efficiency is often not that important. I also think the efficiency gains are bigger for smaller and inexperienced teams.

Also, people are getting used to app-like experiences and designers are designing for it. Building an app-like experience is more natural as a Single Page Application, which basically means taking on the modern frontend stack. There are places that push against this, but to do so requires buy-in to the engineering side over product and design. Even then, the engineering side has to be knowledgeable enough to not follow popular opinion and come to the determination that Laravel/Rails/Django is actually the right tool, which isn't always the case.

True liberation is non-attachment. By attaching yourself to doing something that you love, you may be setting yourself up for disappointment.

Is this really what I love? Is my solution actually helping anyone? Will I have to make compromises to better monetize my solution? I've been working on this project for a year and don't feel like I've made a meaningful innovation.

Some people go down this path and everything works out well but not everyone.