This doesn't seem overly useful.

It's a list taken out of a bunch of books with no regard for how something can be the best path in one language and a smell in another language.

Look at this page for example: https://luzkan.github.io/smells/imperative-loops

It suggests using functional loop methods (.map(), .reduce(), .filter()) instead of using imperative loops (for, for in, for each) but completely disregards the facts that imperative loops also have access to the break, continue, and return keywords to improve performance.

For example: If I have an unsorted list of 1000 cars which includes a whole bunch of information per car (e.g. color, year manufactured, etc...), and I want to know if there were any cars were manufactured before the year 1980, I can run an imperative loop through the list and early return true if I find one, and only returning false if I haven't found one by the end of the list.

If the third car was made in 1977, then I have only iterated through 3 cars to find my answer.

But if I were to try this with only functional loops, I would have to iterate through all 1000 cars before I had my answer.

A website with blind rules like this is going to lead to worse code.

I've got to say, seeing this:

https://github.com/zed-industries/zed/network

instead of something like this:

https://fork.dev/blog/posts/collapsible-graph/

or this:

https://miro.medium.com/v2/resize:fit:4800/format:webp/0*60NIVdYj2f5vETt2.png

feels pretty damn legacy to me.

At least once every few days while coding, usually to do one of the following:

1. Select multiple things in the same file at the same time without needing to click all over the place

   Normally I use multicursor keyboard shortcuts to select what I want and for the trickier scenarios there are also commands to go through selections one at a time so you can skip certain matches to end up with only what you want.

   But sometimes there are too many false matches that you don't want to select by hand and that's where regex comes in handy.

   For instance, finding:

   • parent but not apparent, transparent, parentheses, apparently, transparently
   • test but not latest, fastest, testing, greatest, shortest
   • trie but not entries, retries, countries, retrieve
   • http but not https

   ... which can be easily done by searching for a word that doesn't include a letter immediately before or immediately after: e.g. \Wtest\W.

2. Search for things across all files that come back with too many results that aren't relevant

   Basically using the same things above.

3. Finding something I already know makes a pattern. Like finding all years: \d{4}, finding all versions: \d+\.\d+\.\d+, finding random things that a linter may have missed such as two empty lines touching each other: \n\s*\n\s*\n, etc...

Better to ask a rubber duck than an LLM.

It has better results, is cheaper, and makes has a positive compounding effect on your own abilities.

Eh, it’s the same on the Android side of the fence. There are big and small features that Google has been comically slow to crib from iOS.

I’ve definitely said “fucking finally” to things like overflow scrolling animations,

Those things like overflow scrolling, keyboard peak, etc... were only held back because Apple would patent it prevent it from being put into Android and would file frivolous lawsuits against other phone manufacturers to try and get them not to use them, even when some android variants already had it built in before apple patented it in the first place. (I still facepalm at apple trying to sue others over a rounded rectangle shaped phone)

And those patents lawsuits only stopped because other phone companies called bullshit and started threatening apple with their own patents.

and the “wild” idea that users should get 5+ of major OS releases.

TL;DR on this point: not much of an issue anymore.

This isn't an android/iOS thing, it's a manufacturer thing. If a chip isn't supported by it's manufacturer, then no software on it can be supported. Different manufacturers had different support windows, but Qualcomm became notorious for making chips, then only supporting them for 2 years so they could sell a new "supported" one (and watch the money roll in). Once they saw other the larger players getting pissed off and poking around with the idea of making their own chips, Qualcomm quickly decided that they could support their chips for longer. Now they have to since both Google and Samsung have made public promises for 5-7 year support cycles. Of course, that hasn't stopped other phones from already reaching 7 years of official support before. (A notable example being Fairphone 2 who used a Qualcomm chip while they were still in their shitty behaviour phase and managed to support it for 7 years, 2 years Qualcomm support then 5 years of their own support despite Qualcomm.)

Also, when Google was pissed at Qualcomm they decided to start modularising their OS and pulling chunks out of it out of needing direct hardware support. This means that even if chip support were to stop, it would only affect the background / lowest-level-invisible-to-the-user parts of the OS, and all the user visible parts of the OS could be updated independently (starting with Project Treble, and going all out with Project Mainline). This basically means that entire chunks of the OS can be updated the same way an app can be, early 2010 Qualcomm companies be damned.

This also has the weird thing of android not really being a "version" per se, one phone might have different components of Android 10/11/12/13/14/etc... running at the same time. The components themselves have their own versions.

Windows 95, 98, 2000, XP and 7 are generally regarded as having great UIs.

Of course, we know what happened later:

https://mastodon.social/@danluu/111802159638869338

I like to say:

We have a half finished skyscraper, and you're asking me to Just add a new basement between the second and third floor. Do you see how that might be difficult? If we want to do it, we have to tear down the entire building floor by floor, then build up again from the second floor. Are you prepared to spend the money and push back the release date for that new feature?

You can take the contents of a C file, put it into a C++ file and there's an 80% chance it will work without modification, and 15% of the incompatibility will be just sticking a type on your pointer instead of using void pointers (untyped pointers), or in newer code switching the restrict keyword for one of C++'s newer pointers.

You can't do that between JS and Java.

1 hour of planning can save 10 hours of work.

1 hour of research can save 10 hours of planning.

Some small nits to fix:

1. C has it's own undefined behavior.

2. JS has confusing behavior, not undefined behavior. Its specs are well defined and backwards compatible to a fault, making some things unintuitive and harder to learn if you don't learn the history of the language.

3. Problems with both should be avoided by learning and using standard practices. (Don't pretend C is object oriented, always use === instead of == in js, etc...)

In complete agreement:

1. Result types are awesome, all future languages should be designed around them.

Where do you put your comments in JSON files?

Also, you can buy Tic Tacs from any newsagent or gas station.