Slashdot Mirror
Ask Slashdot: What Are Some Bad Programming Ideas That Work? (infoworld.com)
snydeq writes: Cheaper, faster, better side effects -- sometimes a bad idea in programming is better than just good enough, writes InfoWorld's Peter Wayner: "Some ideas, schemes, or architectures may truly stink, but they may also be the best choice for your project. They may be cheaper or faster, or maybe it's too hard to do things the right way. In other words, sometimes bad is simply good enough. There are also occasions when a bad idea comes with a silver lining. It may not be the best approach, but it has such good side-effects that it's the way to go. If we're stuck going down a suboptimal path to programming hell, we might as well make the most of whatever gems may be buried there." What bad programming ideas have you found useful enough to make work in your projects? Don't be shy or ashamed, we all want to hear your responses!
Applications? HTML was never meant for "applications". It was meant for web *pages*. Websites.
I had to work under a lead who had "Design Pattern Prejudice". Every class had to be named based on the pattern it took after, and everything had to come from factory factories that worked off interfaces to abstract parents at every step, everything had to be immutable, and in any given review, he'd point to a section of code and ask what design pattern this followed. If you couldn't specify one, he'd fail the review, and if you could, he'd want you to rewrite it to use at least 2 or 3 more patterns.
Granted, he'd spend a whole week writing code, fail to complete any of his issues, and check in around 40 new classes & interfaces, but not one of them had any business logic in them at all, and then demand everyone refactor their code to use his new architecture.
We only got things done when we started ignoring him.
I think that you forgot Perl
The real "Libtards" are the Libertarians!
In 40 years I've used dozens of languages, the only one I learned to actively hate was Javascript/ECMAscript. A pathetic, piss poor excuse for a language.
I've heard PHP is just as bad but, as I've never written anything in PHP I'll give it the benefit of the doubt.
It could definitely be an anti-pattern if used incorrectly, but honestly, I've been programming in C++ for about twenty years, and do you know how many times I've seen co-workers abuse operator overloading? Precisely ZERO. Seriously... never seen it. Apparently, I work with people who weren't stupid to flagrantly abuse operator overloading for no good reason, even among those who didn't exactly produce the cleanest or more elegant code.
On the other hand, this is the type of code I typically work with:
Vector3 posDelta = position - lastPosition;
Or this:
Matrix m = m1 * m2;
Overloading operators is best done in an absolutely literal sense. For instance, if you're doing matrix multiplication or subtracting two positions to get a delta value, the intent and what's happening in the code is 100% clear to everyone.
I chuckle sometimes at how C programmers believe that there's some evil overloaded operator lurking behind every multiply or addition. Uh, yeah... you can also obfuscate the crap out of your C programs too (pretty sure I've heard about some sort of contest too *cough*), but you just don't do that.
Irony: Agile development has too much intertia to be abandoned now.
Depends on the utilization patterns.
Heavy I/O utilization will give you a bad time. As a counter-point, overprovisioning RAM relative to your working set will cut back on some of the I/O--a lot, if you're not on a write-heavy workload or a database. Correct RAM provisioning has to include the working set (application memory) and page cache (which is working set represented on disk, rather than persistently loaded into memory by the application).
PU utilization at 90% during peak is fine, if your applications can handle it. A PHP or C# application that can service 5,000 requests per second only takes, on average, 1/5000th of a second to fully-service a request; if it's designed to queue and thread in some sane way, then it shouldn't stall later requests because an earlier request is waiting for something. Its ability to handle 5,000 requests per second includes all that overhead: you can't automatically scale the HW requirements to service 100 RPS and claim now it does 5,000.
An nginx server at 90% utilization typically operates just fine, because nginx (as a reverse proxy, caching proxy, or static file web server) *does* serialize sanely. It provides one worker per CPU (configurable), and passes requests to workers under the least load. Each worker serializes requests--they service one request at a time--and will basically put a waiting request on hold and immediately start servicing a different request. If a worker is waiting with no request to service, it can take a new request--even if it has 37 requests all waiting for something (I/O, a back-end proxy, an application).
Writing an application to handle parallel requests with that kind of efficiency is *hard*. It's not impossible, and some applications handle it well; others do in fact increase latency significantly with utilization.
Latency will, of course, always increase when utilization exceeds unity. Using more than 100% of all CPUs means something has to wait.
Support my political activism on Patreon.
From Round Hole,
Please go look at some old houses and barns. Guess what, the construction is almost all "post and beam"...and guess what, they did it by hammering square pegs into round holes.
Why?
Because it is very hard to drill a square hole. And making round pegs is far more labor intensive than square ones, and wastes a ton of wood. Lasty, friction baby.....that's right. A round peg in a round hole will either slide in and out too easily and not be secure OR it will be so tight that the friction will make it nearly impossible to fit it in. So instead, they hammers a square peg into a round hole. Both the peg and the hole deformed slightly. Allowing for a tightly fitted peg to lock the post and beam together.