weegee101

I feel nerd sniped by this too. Factory games go back to the 90s. There are probably earlier ones too, but Free Enterpri$e (https://www.mobygames.com/game/2408/free-enterprise/) is the earliest I know. In terms of factory mechanics, there are many similarities with modern factory games. Unfortunately, it feels like a game from 1996 and I'm pretty sure it's impossible to turn a profit in it.

Sure, but then Clean Code goes and directly pushes for polymorphism in an area (branching) where indirection and polymorphism is known to be costly for both complexity and performance.

An aspect of this that I wish Muratori had touched on when he wrote this in 2023 is how each of these tenants he has issues with in Clean Code are just trading complexity. All four of the structural rules that Muratori demonstrated issues with generally don't reduce complexity. At best, each trades one type of complexity for another.

There are some great ideas in Clean Code, but outside of DRY, the structural recommendations tend to be more harmful than good.

The issue with this in practice is that there are always cases where panics are absolutely the correct course of action. When program state is bad enough that you can't safely continue, you need to panic (and core dump in dev). Otherwise you are likely just creating an integrity minefield for you to debug later.

Not saying there aren't applications where using these lints couldn't be alright (web servers maybe), but at least in my experiences (mostly doing CLI, graphics, and embedded stuff) trying to keep the program alive leads to more problems than less.

You're right, it is easy to over engineer sites these days. It boils down to tooling for SPAs vs traditional static sites. The tooling for making static sites, even the most modern tooling such as Hugo or Jekyll, simply pales in comparison to libraries such as React, Vue, or others. The author is absolutely right that developers are attracted to shiny new objects, and the interest of the greater community is focused on SPA libraries when we should be equally (or arguably, more) focused on static site generation libraries as well.

Haha, that "sample security test" is hilarious. Basically just a link to SSL Labs saying they meet industry standard. That's great, glad they can meet low hanging fruit. How about proving that they can do better?

Yes, and I think people should head to Swift if it fits their needs. That is very different from Objective-C losing support however. Objective-C is not going away.

This is not even remotely similar to that situation. Obj-C is far more important & integrated than I think you realize.

That is extremely unlikely. Enough so that I would bet money on it.

Swift is targeted at the largest user base of the Obj-C language, the iOS developers. Obj-C will be around for a long time both for legacy purposes and because Swift doesn't interop with K&R C (unless that code has an Obj-C wrapper, like CoreFoundation), and C++ code. Since both Swift and Obj-C support using Cocoa libraries, any API added to Cocoa will be usable by both, but Cocoa is only one of many libraries in the Macintosh ecosystem.

Swift will become a replacement for the development the vast majority of people do, but that doesn't mean that Obj-C is going away. Apple has done nothing to indicate so; they've really been stressing the point that Swift is intended as a new tool to work along side your old one (Obj-C).

No, it doesn't. It is a great way to do 99% of the tasks most developers do. There is, and always will be, a place for Obj-C on the Macintosh platforms. Apple recognizes that most developers don't need the verbosity and tight-knit compatibility with C that Obj-C provides, and that is where Swift comes in.