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?
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.
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).
I remember Apple representatives promising to a room full of CERN researchers that the JavaBridge wasn't going away and how Java was a first class language for Mac OS X development.
You are misunderstanding - this isn't about which is better. Almost all new application code will be written in Swif, but swift doesn't bridge between C and the Swift/obj-c runtime, so Objective-C will continue to be required for writing the glue layer.
Additionally, this is just version 1.0. So nothing rules out that if Apple sees the language being widely adopted, other improvements in the FFI area aren't made.
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.
Rather back when Mac OS X 10.0 was being released and Apple was unsure if developers would be willing to write Objective-C code.
They created their own JVM, with Objective-C runtime support (JavaBridge) and let the developers choose.
At the same time, Apple representatives did sessions at UNIX heavy user groups, like CERN, where they sold Mac OS X as a better BSD, and Java as first class language was part of the feature list.
As they saw developers were comfortable adopting Objective-C in their toolchains, the JavaBridge was dropped.
BSD is implemented in C, so it's not left around, it's the foundation of the system. The syscalls at the base level (read(), write(), socket(), fork(), etc,) are implemented in C and so are the tools that are used by virtually every programming language at some level. C is the standard upon which several abstractions are made, not just another programming language.
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.