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 won't even call it a "bad programming idea". I've seen more problems from over normalizing a database than from under normalizing.
Maybe the bad idea is trying for fourth normal.
using assembly language to code a web page because the boss wanted it to be fast
Goto. I use that (in C) for error handling all the time, and frankly, it is about the cleanest way to do it I have seen.
In theory, practice and theory are the same. In practice, they're not.
Every new software, platform, framework, library, protocol, language, compiler... is rife with shortcuts (by design or accidentally) which are, relatively speaking, considered 'bad programming ideas' from generations of folks who did not prioritize them previously. So every modern program basically sucks for the same reason.
While it's great for reporting, It will never be a good fit for real applications. When I say real, I mean the ones that you use to actually get work done and not browse kitten videos. Modern use of HTML/JavaScript is the worst example of shoving a square peg into a round hole that I've ever seen... and yet, with enough effort, we make it work.
I'll take that and raise you VB6... or VB in general, old and new.
Frequently run into it, where I have a data set that is small, but difficult as hell code in such a manner as to go through efficiently. So, I can spend many hours trying to get the efficient code right, or just use the much simpler more brute force approach which will still get the task done just a quickly to the user's perception.
C++ Template Metaprogramming FTW.
For when it absolutely positively has to squeeze every last instruction cycle, and screw the next guy...
I wish I had a good sig, but all the good ones are copyrighted
There aren't any bad programming ideas that work.
Coding in Javascript, PHP and VB6.
The world's burning. Moped Jesus spotted on I50. Details at 11.
There's a lot of cases where you end up doing something that is considered not "best practice" and is frowned upon, but it gets the job done, is not likely to cause headaches for future developers, and is the most efficient way to solve a problem. It's not programming, but using !important to force a style when you absolutely have to or to override a bad implementation of bootstrap is a surefire way to solve an issue.
and Matlab ....ffffffFFFFFFFFUUUUUUUU..........!
enough said.
Seems terrible because you become less productive, but with the overhead of communication with a larger team, it's still much more efficient than hiring more people.
Or really file systems in general, but most of the modern ones has directories. File systems try to seem like a general purpose database abstraction, but using a filesystem to access data is really fraught with peril.
“Common sense is not so common.” — Voltaire
I've occasionally relied on enumerations being particular values, as a shortcut. Makes me feel icky, tho.
Or rather forget about what's business logic and what's not - if it can be done in the database, do it there.
bite my glorious golden ass.
Few programs are more hellacious to write and maintain than code that has been overly-factored into classes, that inherit from other class, that implement some abstract that was inherited from other abstract, that isn't even called directly because it is actually a event handler or intent for yet another inheritance mess. OOP makes sense if used sparingly, if not, it makes GOTO spaghetti look sane.
... 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"
For a while the mantra was that you only return from a subroutine in one place, at the bottom.
I think that's been pretty much abandoned. Return when you're done; don't go through contortions to get out of nested loops or IF statements just so you can get to the return at the bottom.
Javascript, the worst possible programming idea that seems to unfortunately work.
Some people used Tcl because for a while, it was the only way to use Tk, and Tk was handy. But people who used Tcl for the sake of Tcl shouldn't be watched over, for their own good.
Am I part of the core demographic for Swedish Fish?
No, really - I'm not making this one up. MUMPS manages to find every possible bad coding idea and make it as easy as possible. Interpreted code, typeless data, naked array references, zero FS compatibility with anything . . .
I once discovered that an interpretting parser was faster than a compiled version of it. Probably because the compiled version became so large that it was larger than the CPU caches, causing lots of reads from memory, while the interpretter did not. It is often the case that interpretting is fast enough and that there is no need for compiling (to machine code or virtual machine).
Magic numbers save tons of time. You get to working code quickly to verify your algorithm. They nev
>Segmentation Fault
I always see people implementing some sort of bubble sort (often badly) in higher level languages like Java, PHP and Python. I don't understand why, there is a perfectly good sort method in most if not all languages yet every idiot programmer seems to want to reinvent it.
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.
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.
I've been dwelling the past months in my team's will to go full-fledged MVC (actually MVP) while developing for the Android SDK (for those out of topic: making apps). I see peers and myself struggling with old, large activities, running laps around to make them pass "technical debt" code reviews intending to "make them more future proof".
It would be nice and all if I could grasp the benefits, but the problem is three-fold:
a) the team is fooling themselves and the company into spending too much resources in something they can't assure adds value;
b) Android already has a very solid MVP-like pattern going on, and MVP-ing it up further is a clear case of overengineering
c) most important of all: there is no actual standard to guide the team, so it's a free for all and I see all the initial benefits down the drain just because everybody tastes a different flavour of the view/presenter combo
And I see and underlying problem which might even be more crucial: the app will likely be dropped before reaping the long-term benefits, turning the entire endeavor TOTALLY WORTHLESS. So what I'm trying to say is: you got a solid framework with great patterns put in place already, developed by a company that is on the tech top 10, and you decide to be all trendy around it? You're pretty much grinding for a promotion you definitely don't deserve, because you're making that framework worse for everybody that you manage.
Objective-C and its weird syntax reached success within the iOS world
Slashdot, fix the reply notifications... You won't get away with it...
Did you make your macros Hygenic?
I have found many of those tests to actually be useless. Such as testing that the implementation is doing what the developer thinks the implementation should be doing, rather than testing that the behavior is correct. And then never documenting what those tests were really supposed to be testing (maybe testing that OS version must by 1.2.3 because they all break in 1.2.4).
Or the useless tests that don't really exercise anything important. Such as add 100 items to a list and then pull them all off and make sure they come out in the correct order. I modify it to insert then in a reverse order and it breaks. Didn't matter if they increased the test size to be one million as it would always succeed but I could make it break with a size of 2... The original test was ok, except that there were no other tests to go with it that would have caught any bugs.
It was a bit loopy.
Was going to be sarcastic and answer "Ruby on Rails", but I'll go with "process per request" instead. That is, the Apache model, or for Rails the model where you keep a pool of instances that only handle one request at a time.
Terrible in terms of scalability, but generally works for small workloads. Plus it largely sidesteps developers having to understand how to write thread-safe code.
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.
I wrote a hobby-program once that needed to sort a list. A really big list - too big to fit in memory. After much thought I came up with a really neat search algorithm, a sort of modified radix sort that used only linear access and so would run with good performance from reading from a file. I doubted I could have invented a new approach to sorting, but I couldn't find anything quite the same as it.
A couple of years later I came across that algorithm - in a book that dates from the mainframe era, describing how to sort data on tape. It was just obscure because few people have to sort multi-gigabyte lists.
That's elitist bullshit. Sure, programmers vary in qualifications from horrifyingly bad to mindblowingly excellent, but don't use words like "application programmer" for our less gifted brethren and "system programmer" for the better ones; that just makes you look like an elitist prick.
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.
An example of domain modelling would be a human resources app that models employees, managers, offices, etc. as objects. This mostly flopped
This is not an example for OO. Because the design is wrong.
Hence your conclusions are wrong.
The correct domain model is Person, Role, HierarchicPosition where every Person has a set of Roles and HierachicPositions define your company layout/hierarchy and has a set of Persons filling those positions.
But OOP works fairly well for making API's to network and system services
That does not really sound plausible.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Also works when a 23 year-old "expert" from one of the big consulting firms reports to the CIO that the servers are underutillised.
My reply was "certainly, what level of utilisation would you like?" but the grin on my face gave it away. It was then followed by a laymans explanation of utilisation vs. response times. And a decision that the consultancy wasn't in the company's best interests.
You left money on the table with that.
I don't know the context...how many other people were working alongside this guy, or how representative he was of the team (if there was one) that was there. But if he worked for the consultancy I work for, we'd have wanted to know about this. You should have raised this (along with what must have been several other curious ideas from the guy) to the account manager/account executive/throat to choke (the technical term) for your company. I'm pretty sure that the guy's going to get pushed out an airlock sooner or later, but you could have helped hasten the process.
Remember: it's stupid people - not stupid companies - that come up with stupid ideas. Smart companies want to know who the stupid people are so they can remediate the problem, while stupid companies are nothing more than companies where the stupid people outnumber the smart ones and have taken over. Either way, if you assume the company isn't stupid and act accordingly, you'll get better results. Even if that means finding out that your assumption is incorrect...at least then you know, rather than assume, that the company is stupid.
For your security, this post has been encrypted with ROT-13, twice.
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.
Views allow you to operate on the database as if it were denormalized, without losing the consistency guarantees and other benefits of a properly normalized database.
It's the same concept as STORING datetimes as a number internally, a consistent, monotically increasing number, while DISPLAYING them as strings like "November 6, 2016 1:30 AM". Storing "November 6, 2016 1:30 AM" is crap for any kind of calculation, especially because that string represents two different times an hour apart - there's no way to know whether that comes before or after "November 6, 2016 1:20 AM".
Similarly, views are virtual tables which provide whatever you'd like the user to see, without breaking the underlying data structure.
Indeed, if code is nested 8 levels deep, four or more of those levels should probably be separate functions. The first function might be: .= build_sql(line)
while (line = readline) {
if (notcomment) {
sql
}
}
return sql
The levels of indentation related to building the sql are off in another function, called build_sql().
Human working memory can hold about 8 items at a time, in this case 8 lines of code. Which means you can look at an 8-line function and understand it all at once; you know what those 8 lines are doing. When looking at a 300 line function, you have to scroll up and down parsing parts of it at a time. That greatly increases bugs. Functions no more than 8 lines can normally be seen to be correct - you can fully understand it, without need to scroll up and try to remember how foo affected bar 250 lines ago.
Back in the early 90s I worked at the big cellphone company. We worked on Unix workstations, and I learned a lot of what to do and what not to do. We used an in-house built bug system built to use sccs. I managed the build shell scripts. The only way to get code into the build was to enter a CR (Change Request) and link the source files to it. Then the build would examine all the CRs for a weekly build, check out that code, ftp it to the target platform (tandem), build it. If all went well, 8 hours later you would have a successful build, which I would then write to 9 track tapes, and THEN install it on the target system testing platform.
So the bug system I mentioned used flat readable text files to store all the info. There was a gui front-end but it was kind of slow.
Out of necessity to quickly look things up, I wrote a shell script that would allow you to search and view CRs on the command line. Bad built on top of bad, but it worked pretty well. Other people on my team started using it too.
It worked so well in fact that somewhere around 2006 I was living across the country, having been at a few other companies since then. An old colleague still at my first company got in touch with me, and someone was asking about me and the tool I created. They saw my email in the header of the script, and wanted to get in touch with me to see if I would let them edit it. They were still using it! What I created for myself others found so useful that it was still chugging along doing its job on the command line. I don't know if it made me proud or sad, but it was humorous to me. I haven't heard anything from them since then, but it would be very interesting if they were still using that same process and those shell scripts I created so long ago.
My beliefs do not require that you agree with them.
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.
Amen! Productivity (work-related) application programming (CRUD) using HTML/DOM/JS is a f8cking nightmare.
Part of the problem is that each browser brand/version combo can potentially render things differently such that you have to test on say 30+ combo's of browsers and devices to cover all bases, AND future versions may STILL break it after all those 30+ tests. My hair is turning Bernie Sanders shades over that crazy shit (and falling out like his). It makes the DLL-hell of the 90's feel better in comparison. Now we have render-hell.
Possible solutions include bringing back WYSIWYG and/or vector coordinates, OR doing the "auto-flow" rendering on the server and making the browser be a dumb coordinate-based vector plotter. That way you are dealing with only one renderer instead of 30+.
Another idea is to put X Window engines on browsers, but I'm skeptical of the input box response. Input boxes should (optionally) buffer on the client.
Other ideas welcomed.
Sure, you if you put a lot of bloated margins around everything you can make stuff "shift proof" in the web stack; but it looks ugly, wastes space, and is often not what the customers want.
Table-ized A.I.