I was hacking scripts and web shit together in perl, python and php for many years before learning C, and just a couple months learning C/C++ made me understand so many more basic concepts than all previous years experiences combined.
Nah, our generation had to tinker with shit to get it working. Kids these days have it easy, which is good from a user perspective, but fails to train them how any of it actually works at a deeper level.
No one has to install a device driver anymore.
It’s a beginners book filled with a mix of bad and good advice, which takes considerable experience to separate the two. Those who can point out all the bad advice already don’t need the book, and newer developers will pick up absolutely atrocious coding advice. There’s simply better books that target beginners better, like The Pragmatic Programmer.
So when you are on-boarding junior devs that have bought into the clean code/SOLID dogma, you’re spending several months beating all their terrible coding habits out of them.
Programming is mostly research. Researching curses to cast on the guy who wrote the Incomprehensible mess you’re currently debugging.
Well yeah, 100% of programming errors are programmers fault.
Most can’t, but that’s why clandestine cyber-intelligence firms like NSO group exist.
Meanwhile PHP quietly runs 80% of the internet by being used for WordPress.
“There are only two kinds of languages: the ones people complain about and the ones nobody uses.”
Always remember, the silicon valley ethos of “break things” wasn’t about their applications, it was about breaking industry, society, laws and your ability to oversee or regulate them.
the tests are now larger than the thing itself
Is such a weird complaint. You should aim for your codebase to be as small, simple and readable as possible, while your tests should be a specification that guarantees behavior is consistent between refactors. When you add behavior, you add tests, when you remove a behavior, you delete tests.
The size of either is independent of eachother. Small code bases that provide lots of features should be simple to read, but with a lot of tests.
I’ve programmed C# for nearly 15 years, and have used goto twice . Once to simplify an early break from a nested loop, essentially a nested continue. The second was to refactor a giant switch statement in a parser, essentially removing convoluted while loops, and just did a goto the start.
It’s one of those things that almost should never be used, but the times it’s been needed, it removed a lot of silliness.
async/await was introduced in version 4.5, released 2012. More than a few releases at this point!
Powershell
/s
Like a fungus you learn to live with
Apparently every code base I’ve ever worked on was run through this.
The company I work for is smort
This is every company I’ve ever worked for. If other people didn’t vouche for their own tests, I’d assume automated testing was a myth.
I never saw that, that’s legitimately funny. I’d love to be in the room when that feature was designed, and the reaction of the developer it was handed too.
I don’t know if the game is the best example of busineses making top-down design decisions, since that game was an obvious scam from the start.
Razor
Razor is the templating engine that’s been there since the original MVC. Blazor Server is the one that needs a server and streams changes to the client using signalR. Blazor WASM is the one that uses Web Assembly. As of .Net 8, Blazor can now also ne used as a generic SSR backend. They all use Razor Components, which is a component model using the Razor engine.
Not to be confused with Razor Pages, which is also a generic SSR backend.
I took a compiler course focused on optimization and porting. So I worked with x86 and ARM. There’s very little reason in modern computing to write assembly by hand, but it’s still useful to be able to read and understand.