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!
I've occasionally relied on enumerations being particular values, as a shortcut. Makes me feel icky, tho.
... despite that I keep telling them not to, but never good enough to save their business plan or their company from disregarding my wisdom.
- Agile/scrum, anything related to it, inspired by it, or even remotely like it, and the mindset of managers who advocate it.
- "continuous integration"
- "devops"
- server-side javascript
- giving every single person in the IT department the root server access
- using microsoft "solutions"
> VB6
Yet, there are plenty of nice things about it, for example:
Debugger: you can skip the execution point forward/backwards. You can edit code _live_ whilst debugging, or execute custom code in the same context as what's being debugged, and you can debug that as well. Can your favorite language's debugger do this?
= operator that makes sense: how many beginners fall over the = vs == confusion? In VB6, you'll never accidentally assign a variable in an if condition.
With statement actually works well, unlike implementations I've seen in other languages.
As a language predominantly aimed at beginners, it works reasonably well. It somewhat verbose and won't be as expressive as some experienced programmers may like (for example, you can't assign in an If condition), but I think it achieves its aim reasonably well.
I came here to actually say OOP.
Its an absolutely terrible idea that tries to make software work the way we think it should, not the way we think.
It never ends well, and every time it goes to hell, people say "Oh, but if it had been done right in the first place..."
Though somehow people actually make it work, and right now superior functional patterns aren't taught, so if you implement them everyone thinks you're crazy. So for now, OOP is a terrible idea that "works", that many know is wrong, but that we still use for historical reason to make working software, for now.
Sure, C gotos are the cleanest solution in a few specific cases and sometimes I get frustrated in higher level languages that lack it.
However I still demonise gotos when teaching coding because it should be use carefully and sparingly. New programmers often see it as a versatile stick that can solve all their problems, and while it can make the code "work" we moved on from spaghetti code for a reason.
My personal rule is that a goto should only ever go down the code and never into new blocks.
(except for implementing a try/catch system using longjump, every rule has an exception...)
Bad programming ideas: separating "business logic" from the rest of your program. Not sure what the difference is between 'business logic' and the rest of your programs that run your business but a lot of people seem to want to separate them out.
Any database implements a turing complete language, it's generally a really bad idea to do anything there. Although to save time, I've often implemented SQL triggers and the like to do clean up that I didn't want to figure out in the program.
Custom electronics and digital signage for your business: www.evcircuits.com
switch(true) {
case $a < 5:
do something;
break;
...
}
A bit messy, but a lot cleaner than a stack of if/then/else for a set of of conditions.
Objective-C and its weird syntax reached success within the iOS world
Slashdot, fix the reply notifications... You won't get away with it...
Some of us are old enough to have gone through a generation of "overload everything" which was a disaster.
Only much later did people learned to use overloading sparsely and with good effects.
This is similar to OOP which is also overused. Heck in Java you can't even have a variable or a function living on its own. Everything must be an object (except native types, sometimes).
I stopped doing that one day when I looked at the disassembly of my function and realized the compiler was optimizing my code to have multiple returns.
"First they came for the slanderers and i said nothing."
And tbh it's not that efficient anyway, but the programmer who wrote it doesn't know because he didn't time it........
Yes it is, and yes we do. Our programs run against massive data sets (anywhere from a couple hundred MB to tens of TB) on a single machine. Our inner loops run billions of iterations per pass, and response time is absolutely critical. A single extra instruction in an inner loop can cost many seconds of real response time. Cloud solutions are not an option, and neither are large server farms. This thing has to run on somebodies desk.
Short of assembler, there are not many ways to improve on what we are doing, and even there GCC and MSVC++ both produce some damn fast and highly efficient code when fed the right diet of templated inline functions. In the few cases where the final assembled version has made me do a WTF, it turned out to be instruction re-ordering to take advantage of (or work around) quirks of the x86 machines in common use today. I have been very hard pressed to beat the compiler for most functions compiled from good TMP. Some of the things we do with it simply cant be done anywhere else but assembler. Even C has its limitations.
As an exercise, try to figure out how to get a C program to compile down to a dynamic set of functions, all in-lined into a single function. In TMP, I can do it. The templating spreads out the function into as many versions as it takes to cover all the possible variations, each of which is a fully in-lined version containing only the desired "calls". I have been programming in C a long time, and the best I have ever seen was someone try to implement the same thing by actually implementing all the different variations of the in-lined function by hand, and then creating a jump table to pick the right one. It was thousands of LOC and prone to typos, as opposed to the TMP version which was 50 LOC, and either worked or didn't, no place for small corner case errors to hide.
I wish I had a good sig, but all the good ones are copyrighted
People crap on that language and, when I use it I usually violate MVC hard enough that it needs therapy. Yet, damn, I can pound out high quality products in that format like I am a programming firehose. I am talking products that make money and need little to no maintenance for years to come.
I can do python flask stuff that is technically cleaner, I could even do something super hardcore like a C++ we back end but for the easy homerun, PHP it be.
Obviously I am talking about the web.
Another dirty secret is that I do most of my stuff from scratch. Nearly every framework or great IDE extra out there I ignore. The whole storyboards thing in iOS, nope, Java on Android, nope, or just about any proprietary system that tells me how I should do something is a big fat nope. I find with most huge frameworks that I can knock of an almost fully functional prototype in no time at all, but then I start fighting with the framework and can never finish, 90% done and that is it.
By working with the fundamentals and good libraries, I start slow, and finish slow, but finish I do.
Seriously, the first time I saw Duff's Device I really thought it was a mistake. It's a do/while intermingled with a case statement. Look it up and be amazed.
Most bad programming ideas are bad programming ideas because they don't scale. They work fine in a small code base with sufficient documentation. They probably work fine sparingly in a large code base with good documentation. The problem is that if we teach bad programming ideas are routinely OK if we are careful, then we rely on them and when scope grows and we inevitably hit a moment in the project that doesn't allow for solid adherence to good software engineering practices then it blows up in our face spectacularly.