Slashdot Mirror
'Here Be Dragons': The Seven Most Vexing Problems In Programming (infoworld.com)
InfoWorld has identified "seven of the gnarliest corners of the programming world," which Slashdot reader snydeq describes as "worthy of large markers reading, 'Here be dragons.'" Some examples:
- Multithreading. "It sounded like a good idea," according to the article, but it just leads to a myriad of thread-managing tools, and "When they don't work, it's pure chaos. The data doesn't make sense. The columns don't add up. Money disappears from accounts with a poof. It's all bits in memory. And good luck trying to pin down any of it..."
- NP-complete problems. "Everyone runs with fear from these problems because they're the perfect example of one of the biggest bogeymen in Silicon Valley: algorithms that won't scale."
The other dangerous corners include closures, security, encryption, and identity management, as well as that moment "when the machine runs out of RAM." What else needs to be on a definitive list of the most dangerous "gotchas" in professional programming?
Script kiddies spent their whole fucking lives in Javascript are terrified of threads...just like they are of Trump. All good software is multithreaded. All useful software is multithreaded. Threads have been around for fucking decades. Just because ppl got all chicken shit and decided to go all "single threaded non-blocking V8 engine jackoff" means squat. If you can't do threads you suck as a programmer and should either work really hard to figure it out or find something else to do.
As far as I know, there are four hard problems in programming:
1. caching
2. naming (i.e. how do I name that variable/method/class)
3. off-by-one errors
Or, as old Fortran programmers would put it, insisting that the first item in a list have an index of 0.
Not only that; closures are not a problem but actually the ultimate solution to the actual problem of name scoping. Lots of approaches were tried before closures remained as the only sane idea.
Ezekiel 23:20
Agreed that race conditions can be very tricky to spot. But there is one case I've run into a couple of times...
If you're trying to debug something and you start putting in some print statements or breakpoints, and suddenly the bug goes away... It's probably a race condition, which was inadvertently "fixed" by you slowing down the execution with your breakpoints, etc. I like to think of it as the CS equivalent of the Observer Effect.
Only crack the nuts that crack. You don't put the ones that don't crack in the sack.
NP-Completeness becomes a programming problem when the people who do the programming cannot spot a NP-problem and then spend countless hours to beat it.
To be honest, it's often the programmers who hear "optimally solve it" when the requirements actually are "sufficiently solve it". For example I just suggested for a knapsack problem at work we use a simple overflow algorithm instead. It doesn't matter that we're not perfectly sizing the chunks as long as they're below the max size, it's like a 10-20% deficiency on a 50-fold improvement. Sure with infinite time and resources we might have done it perfectly, but really it's just a workaround for limitations in another imperfect system. And particularly when it comes to any human scheduling, were it often turns out that there are some unsaid requirements which means they'll look at a time table and say this won't really work anyway.
Live today, because you never know what tomorrow brings
(For people not much into set theory: The cardinality is the answer to "how many elements are in a given set?", and the ordinality answers "how many predecessors does the number have?")