wheels

We're not frying batteries quicker, we're using our phones longer. The only reason I'd have to replace my 3.5 year old phone is that the battery is dying, but it probably doesn't make sense to spend half the price of my phone (phone was only $200-ish) on a replacement. I just don't have any qualms with my phone or have any particular reason to need a new one. I resent having to replace my phone because a part that could be easily user swapable at a reasonable price point isn't.

Your assumption that phones would only be used for 2 years is pretty weird on an article about using phones for 8 years.

I feel like the elephant in the room is that there's no phone battery that's going to stay useful in anywhere close to that time frame, and replacing phone batteries is usually a losing proposition. I've tried, several times. Fake, low-quality batteries are rampant (usually degrading within weeks), and genuine ones are prohibitively expensive -- usually a significant fraction of the cost of a new phone.

I've heard it explained a different way: Americans stopped eating mutton when plastic became widespread. Mutton was largely a side effect of wool production, and with the invention of nylon, far less wool was produced.

Counter-intuitive as it may seem, math does have the notion of larger infinities.

This an extremely weird passive-aggressive flex. The thread basically went, "I think people that notice font problems have something wrong with them." To which I respond, "No, designers and design-y people notice stuff like that." And then to go from there to this is pretty, bwah?

I just watched the first half of the talk, and it's pretty interesting. I don't think Adam Neely is actually saying they're the same; he's saying it's interesting to think about their similarity. And what you actually get out of the talk is that his point is that pitch is our perception of frequency over a certain limit, and that rhythm is our perception of frequency under that limit. They're both perceptions of frequency and the ratios of those frequencies are the defining property of both chords and polyrhythms.

Fixed width fonts have a special purpose. They're designed to fill that purpose, not to be optimal for other things.

There's an age-old debate of how much "good taste" is subjective, but in this particular case, it's someone hammering a nail in with a wrench. Some will be bothered, others not, but it's definitely the wrong tool for the job.

The example of not liking lights in certain places isn't a very good one. It's an attempt to elide all "things people don't like" into subjectivity, but there are actually things that are better and worse. You would agree that website design can be better or worse, right? And that some people would have a better eye for good or bad design? With me so far? I'm saying you're probably not one of the people out on the end of the spectrum that's best able to recognize good and bad in design, but I hope you recognize that good and bad design exist, and that people vary in their ability to recognize it.

I wouldn't be bothered about it in this case (I'm much more offended when the font size or margins are stupid), but to use your phrase "I don't want say this in a way that comes off as insulting, but I'll just say it and please don't take it as a put down..."

You probably just don't have a strong sense of aesthetics. Some people notice design-y stuff and some people don't. A lot of people do notice fonts, or misaligned margins, or whatever. And a lot of people don't. The latter category are probably never going to be good designers or artists or whatever. People are different.

We're talking past each other because we're arguing different things. If I understand you, you're saying that you can avoid technical debt by using tools that are intrinsically more performant, and that skilled developers are more productive with more advanced tooling.

That's all correct.

But the point I'm making is that if an MVP isn't accruing technical debt, it's over-engineered. Most of them will be thrown away, or rescoped, and so taking on technical debt is an advantageous strategy: you only have to pay the technical debt on the few survivors.

Shopify at its offset was a CRUD app (fun fact: it started as a snowboarding shop), and in 2006, Rails was a great choice for that.

Your notions are fine for an established company building a piece of infrastructure they're certain they'll need. But that's not what Shopify was, and it's not the spot most startups picking a framework are at.

Your thing about developer quality is kind of meh. Building the first versions of a shopping platform isn't rocket surgery. You don't need Anthony Bourdain to make a sandwich. Particularly if you're not sure anybody wants a sandwich.

It's a false dichotomy in theory. It's mostly not in practice. And that was far truer in 2006 when Shopify got started. Then there really weren't any modern web frameworks in performant languages.

Primarily it's not the language that makes people more or less productive, though it does have some influence. It's mostly the frameworks in those languages. And traditionally the most modern / full-featured web frameworks haven't been in systems languages. The major counterexample at the moment (while still obviously not a systems language) is that modern JS VMs are actually really fast, so while I don't love JS, it does hit that sweet spot at the moment of performance and mature frameworks.

Also, I've never worked in Rust, but am mostly a systems programmer, and while I understand that Rust is supposed to be easier than C or C++, I'm skeptical that it's as easy to work with as higher level languages, or that you could throw most web developers into Rust without some serious additional learning.

Am I really going to have to get out the premature optimization quote?

Most businesses fail. Those that don't fail, usually don't have interesting scaling issues. (You can go a really long way on a boring monolith stack.)

So in most cases, whatever gets things out into the world and able to see if the business can be validated makes sense, and then you optimize later. A nonscalable stack that you can iterate on 50% faster is more likely to produce a viable company than a more scalable stack that's slower to work with.

If you're a hired employee, it's easy to forget that the place you're working for is already a big exception just by the virtue of it grew large enough to hire you.

I didn't say it always does. I said it's about 50/50 on whether the cruft is from actual complexity vs. bitrot.

We know that it's not (primarily) rocky though because the radius is 2.6 that of earth, but the mass is only 8 times. So it's about about 46% as dense as earth.

Gravity is only about 1.25 g, according to Wikipedia. Density matters. The earth and Saturn have about the same surface gravity.

May I venture that you're probably early in your career?

There's almost always things that can be redesigned to be better and smaller if one has a better understanding of total scope from the beginning, but there's equally as much discovery that the reason things seemed unnecessarily complicated was a lack of understanding of the complexity, and that the new rewrite eventually reintroduces much of it as it's used in production.

A lot of that is about developing intuition and like in most fields, there's not an easy way to develop intuition without a lot of experience.

What helped me a lot was starting to work through "On Cooking", which is geared towards culinary students, and at least has a more useful progression of skills (e.g. starts with equipment, knife skills, etc.) and techniques, and then starts building up from there. e.g. you learn to make sauces before starting on full dishes, etc. But doing something like that is a pretty large commitment (and all of the recipes have to be scaled down to non-restaurant sizes).

At one point in my early 30s I considered writing a cook book based on trying to teach my housemate to cook, starting with the assumptions that the person in question hadn't ever cooked and didn't own any reasonable cooking stuff, and trying to establish a baseline of recipes that could all be cooked from the same 20-ish ingredients that one could reasonably always have around.

There are definitely recipe-based and intuition-based approaches to cooking, and while I think teaching intuition is difficult, learning a particular vocabulary of skills in a certain order can help.

You're not taking the amps into account. Voltage without the amps on the circuit breaker is pretty useless. Quickly Googling indicates that a standard residential circuit breaker in Japan is 30A (3000 watt max), meaning you'd get more power than you would in the US with 120v / 15A (1800 watt max), and much less than where I live in Germany with 230v / 16A (3680 watt max).

A lot of people simply don't have a dominant hand. They're typically grouped with the people for the hand they write with, but that's a pretty incomplete picture. I suspect your friend who "switched" never had a dominant hand in the first place.

I'm one of those folks. I write left handed, but other stuff tends to be mostly, but not completely, right handed. This is mainly since there's a small advantage to right handedness (baseball gloves fit, mouses are there, guitars are right handed by default, etc.). There's a lot of randomness: I eat right handed, except when using chopsticks (left-handed), including long cooking chopsticks, but tongs (which have a similar purpose) are with the right hand.

Assumed unrelated, but responding to a different part of your post: I can also read and write in mirror image with little loss of speed. I've never thought of that being particularly special. I just started randomly taking notes in mirror image in high school out of boredom (and right-to-left is slightly more comfortable for lefties).

We manage non-unique names in a lot of domains. It'd be a shit-show if given names had to be unique. It'd be acceptable to have an ID in the background that helped regain specificity. (Kind of like social security numbers in the US, though those also notably are not unique.)

Some random anecdata:

I have a chronic sleep disorder, "Non-24 Sleep / Wake Disorder", which means my sleep floats pretty freely and doesn't naturally sync up with the sun. For the most part, I've structured my life for that to be ok, but sometimes it's not. I basically use melanin to bludgeon myself into a more normal sleep pattern when I have to. I usually start with 2 mg, 30-60 minutes before I want to sleep, but often when that doesn't work, take another 3 mg, which usually gets the job done. Often I don't even notice 1-2 mg, but 5 mg does register reasonably strongly.

In many countries adults just continue to wear backpacks. One of the things I keep in my backpack is a big IKEA bag, meaning I'm pretty set for shopping on foot (or bike, which is more common for me). Medium sized purchases go in the backpack, larger things go in the IKEA bag.

Crew Republic, one of the biggest German craft beer producers, makes a session IPA.

George Carlin's take on the words:

https://www.youtube.com/watch?v=hSp8IyaKCs0

I think it's more of an admission that internet discussions aren't analogous to in-person discussions, and have a way of dehumanizing the person you're discussing with. Combined with modern-day tribalism, it means that most online "discussions" on a particular set of topics are more about virtue signaling and displaying tribal membership than they are about convincing others. As such, it's not unreasonable shorthand for a forum to avoid such topics en masse, as when allowed, they tend to drown out everything else.

I don't watch enough movies in a theater to measure walk outs there (though I would have walked out of the latest Avatar had I not been there with my son; so boring and long...), but I do stop maybe 1/5 novels without finishing and maybe 1/20 movies without finishing them. There's more interesting stuff I could be doing with my time, and if they are completely not my taste, I'd rather be ding those things.

My usual thing is to say that early on, there's only the technical person and the money person. There is no ideas person. If you aren't one of the first two (i.e. access to savings, investment, sales channels, etc.), then you don't have a role. Too many wantrepreneurs just want to basque in the glory of their own ideas while someone else builds them.

To make this more numerical:

Windows is about 66% of our customers, macOS about 33%, Linux about 1%. On Windows we currently only test on x64 for Windows 10 and Widows 11. On macOS we test 4 configurations. Each Windows configuration we test is 33% of our users. Each macOS configuration about 8%. Linux is starting at 1%, and previously we tested only one configuration, which was already 8x more costly than macOS. But there were a lot of complaints from people using other distros / versions, which resulted in anger, bad reviews, claims that we don't understand Linux...

To get reasonable coverage of the Linux desktop landscape, we'd need to test probably 20+ different configurations, meaning each of them would cover about 0.05% of our customers. The QA tests take multiple hours to run through. That makes supporting a Linux user a staggering 160x more expensive than supporting a macOS user, and 660x more expensive than supporting a Windows user.

Again, you need either a giant user base, or a disproportionate number on Linux (which is the opposite of true in pro-audio) to even hit break-even on Linux users.

Literally most of the packages on the page you link there explicitly say that they're maintained by other people. The author seems to maintain an RPM and a DEB setup, which is already more than most. And my point is absolutely not that some people don't go nuts there, but that's not where or how most Linux users get their software. It's mostly coming from stuff packaged by the distributions.

And I am sure that's how most open source packages on Linux are built. Again, I spent a lot of time in that world. (Former KDE core developer, former employee at SAP Linux Lab, friends working at all major distros, have a bunch of my stuff in every distro, talks at lots of Linux conferences, etc.)

Building really isn't the problem. It's testing and supporting. Building is relatively easy. But you can't just ship commercial packages without testing them. Pulling out a Debian 11 VM because someone's having problems with your software there under Wayland, but not X11, but it seems to work in Sid... Again for the 0.01% of your customers using that configuration, ... it's hard. And it rarely makes economic sense unless you've got a disproportionate number of users on Linux, or a ginormus user base. You can't assume because something works on Arch Linux that it also works on Mate. Or that something on Ubuntu works on Debian. Or Redhat on SUSE. And then your users may have any of 3-4 versions of those installed. By the time you get to a specific configuration you're dealing with often debugging things for a single-digit number of users.

Doesn't work for things that are, or use plugins, which is typical in pro-audio. (Our software is primarily used as a plugin.)

Most of the time those packages, or the build files for them, are contributed by the distributions themselves, or avid users of those distros. (Reference: I have multiple software projects I've created that are a part of every Linux distribution. I've never packaged any of them myself.) Even big enterprise companies usually work directly with the distros under NDA, and the distros produce the packages.

That works for FOSS, but not for smaller closed-source consumer apps. And it's not just building, it's also testing and debugging. It's just not tractable for a small company to test on dozens of different distros / versions for such a small percentage of users.