'Here Be Dragons': The Seven Most Vexing Problems In Programming (infoworld.com) 497
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?
Serious he missed the 2 biggest problems I've had (Score:5, Insightful)
Re: (Score:2, Insightful)
Cowboy programmers really hate that.
Re: Serious he missed the 2 biggest problems I've (Score:4, Funny)
Re: Serious he missed the 2 biggest problems I've h
Arbitrary truncation of data...
Re: (Score:3)
1&2&3&4&5&6&7&8&9& (Score:3)
The title of this message is originally "1&2&3&4&5&6&7&8&9&0&1&2&3&4&5&6&7&8&9&0&1&2&3&4&5&".
I can't type another character into the title box.
It all shows when I hit Preview, but I won't know if it makes it until I hit Submit.
Re: (Score:3)
Re:Serious he missed the 2 biggest problems I've h (Score:5, Insightful)
Re:Serious he missed the 2 biggest problems I've h (Score:5, Funny)
Haha, you should be more Agile! It's not Agile to find out what your customers need first. Just throw a bunch of shit at the wall, make it flatter, and dump it into production to let your customers do your testing and chip away at the things they complain about.
They'll definitely give you useful feedback and not switch to another software product instead. If there's one thing that's always been true about customers, it's that they're fiercely loyal to their software vendors.
Re:Serious he missed the 2 biggest problems I've h (Score:5, Insightful)
However, I've had a few projects that have been very well designed from the get-go, with a thorough design that stands up to chaning requirements. Agile is a perfectly fine approach to develop or extend that kind of software.
Re:Serious he missed the 2 biggest problems I've h (Score:5, Funny)
Put everything in one huge massive universal class of doom. Kiss refactoring goodbye!
Re:Serious he missed the 2 biggest problems I've h (Score:5, Insightful)
Well, that's because Agile is not supposed to solve technical issues like architecture or data models. It's supposed to help software development efforts track changes in organizational priorities and incorporate things they learn into their plans as they learn them.
If you rely too much on any methodology it's not going to work.
I have often thought the most important quality a software developer has to have is caring about the people who will be affected by their work. If you're only interested in technology you'll find an excuse to use the latest thing. If you're a prig about methodology you'll end up going through the motions. When you care about your users you'll always find a way to not let them down.
Re: (Score:3, Interesting)
Agile is meant to help you learn about the problem domain. If you already know everything about the problem, there's no need for Agile. If somebody else already knows everything about the problem and you can hire him/her, the do it - no need for Agile. If nobody knows everything about the problem because it's a new problem that no one else has worked on yet or a new approach to a known problem, then you definitely need Agile or something similar to help you produce something that works at the same time that
Re: Serious he missed the 2 biggest problems I've (Score:2, Insightful)
Reminds me of my last job.
Boss: this isn't what I wanted, did you read the spec?
Me: you gave me a ticket that had 3 sentences in it. That's not a spec.
Boss: that is too a spec. Go back and read it.
Me: this leaves a ton open to interpretation. This isn't a spec. You need to clarify this with a lot more detail.
Boss: come on, you knew what I meant.
And that's partially why I quit.
Re: Serious he missed the 2 biggest problems I've (Score:4, Insightful)
Reminds me of my last job.
Boss: this isn't what I wanted, did you read the spec?
Me: you gave me a ticket that had 3 sentences in it. That's not a spec.
Boss: that is too a spec. Go back and read it.
Me: this leaves a ton open to interpretation. This isn't a spec. You need to clarify this with a lot more detail.
Boss: come on, you knew what I meant.
And that's partially why I quit.
So you didn't ask your boss what he actually wanted before you started coding? You didn't ask for clarification for each ambiguity you discovered during coding? You just shat something out at random?
Re: (Score:3)
I've worked with lots of people like that boss. If you try and get more detail, you're chided for not working quickly enough, or for bothering them. My policy is always to give such people what they ask for. If they can't or won't learn, that's not my problem. Their spouse/parents/pet can change them. It's not my job.
Comment removed (Score:5, Interesting)
Re: Serious he missed the 2 biggest problems I've (Score:5, Insightful)
For a spec to be that good it's got to be written to the same precision as a computer program.
So just write the fucking code.
Re: (Score:3)
Write the code, but for the love, make it readable. Make it so readable to the point that you can show an implemented business rule to the guy who will be using it, and he should be able to make out what's going on even with no programming experience. (Not lower level database access, UI code, etc.)
Re:Serious he missed the 2 biggest problems I've h (Score:4, Insightful)
Re:Serious he missed the 2 biggest problems I've h (Score:5, Insightful)
1 who's my customer
2 What does he or she actually want.
What you mention are not programming problems.
I am a programmer and I deal with these two issues way more than any problems with multi-threading and NP-completeness. Multi-threading isn't that hard if you have some experience and a good library. NP-Completeness is more of a math problem than a programming problem. For programming, there is no optimal way to do NP-complete, so you just use a heuristic for a "good enough" solution.
Re:Serious he missed the 2 biggest problems I've h (Score:5, Insightful)
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.
Re:Serious he missed the 2 biggest problems I've h (Score:4, Informative)
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.
Re:Serious he missed the 2 biggest problems I've h (Score:4, Insightful)
I agree. These problems are something my architect brother spoke about. His way to deal with it was to listen to what the customer asked for and then come back with three options for them.
The first is give them EXACTLY what they asked for. If they wanted a staircase to nowhere and a conversation pit in the garage then that's what they'd get. The second option is to offer them what he thinks they really wanted. Some people just don't know what they want but with experience my brother could get an idea of what people liked and needed. The third option is he'd give them what he wanted to make. He'd take their input but then come up with something he'd find interesting or would like to see experimented with. He said few people would take his first option.
I've also seen this in healthcare. People complain about how hospitals and their staff do things among other complaints on how they are treated. I can trace many of these complaints to a single cause, they are not the customer. The insurance company is paying the bills and so they are the real customer, and many of those in healthcare know this. This then creates a problem because the patients will not complain to the insurance company because they don't realize that their "customer" is not the hospital, but the insurance company. This is why I fear government healthcare, it adds another layer in this chain with one of them being the people that brought us the DMV and the poor customer experience we've all come to know from it.
That's not exactly where I intended to go with this but it is where I happened to end up. As a "customer" of government healthcare through the VA I can tell you that is not where you want to be. I will say that VA care has improved but it only took people dying of negligence and suicides for a enough US Senators to notice and care enough to act.
node (Score:5, Insightful)
Oh christ if I get one more node.js developer claim that node is multi threaded...
Re: (Score:3)
How about people throwing 16-core AWS instances at Reddis? ;)
2 more I've seen (Score:5, Interesting)
2 Developers who decide to reinvent the wheel because "They know best". (Just dealing with code where somebody decided I don't want to use the built in stuff, I'm going to do my own date time stuff which constantly has issue. Makes you pull your hair out.)
Re:2 more I've seen (Score:5, Insightful)
1 Not being careful with floats. (Those can totally bite you including using floats when you should have used an int/uint type)
Some developers, when encountering a problem, say "I know, I'll use floating-point numbers!" Now, they have 1.9999999997 problems.
ARRRRGHH! (Score:5, Funny)
Re: (Score:2)
It's depressing how much code stores coordinates in floating point format.
Re: (Score:2)
My latitude and longitude have arbitrary precision.
Re:2 more I've seen (Score:5, Funny)
You should have modified the code to take those fractions of cents, and deposit them in your account.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Why do you think there were rounding errors — no faintest clue because it was well hidden!
Re:2 more I've seen (Score:4, Funny)
Freaking slashcode:
The problem is, people will write if (x * 3 < 1) ... then be mystified when it fails. My favorite is all the if (x < 0) ... bugs, failing to realize that negative zero is less than zero. Great fun.
Then there are the NaN-related bugs, which are the sort of math errors most people overlook - like dividing X and Y by N, which accidentally is 0, then later comparing them and discovering that they're equal.
Re: (Score:2)
Betcha no one read "Numerical Methods for Scientists and Engineers" Richard Hamming, 1962.
Re: (Score:2)
Re: (Score:2)
Every real Software Engineer and Computer Scientist.
Re:2 more I've seen (Score:4, Insightful)
Doesn't matter, this is stuff they should have learned in school. Even in high school if they decided to skip college. Even if they go to college I think they just don't bother learning. A computer to many developers is just a magical black box. If the math comes out wrong they switch from float to doubles. If they math is still wrong they complain about the computer (seriously I had professional physicists try to tell me that the VAX was broken because the numbers were coming out wrong). A lot of developers don't even understand integers to be honest, like 2's complement, overflow, fixed point, etc.
Wait physicists? (Score:2)
Re: (Score:3)
Scaled floating point, unless you're working with an IBM Z series (does Power8 have decimal float?).
Every modern processor has fast floating point; a double can store and express 53 significant bits, so express the floats in pennies. Or if not in USA, the smallest denomination in the money system you use. Server class machines probably do long doubles.
("Every" includes all Raspberry Pi models, the Odroids, Banana PIs, Orange Pis, etc.; essentially every X86 since 1991, Every Power since about 2003 and all A
Closures? (Score:2, Insightful)
C'mon. Threads -- I concur wholeheartedly. But closures? Granted, you have to wrap your head around them, but then they are a docile workhorse.
As for threads... don't unless you have to. You add the benefits of concurrence and common address space and multiply their curses.
Re:Closures? (Score:4, Informative)
Re: (Score:3)
I think the problem is the paradigm shift from object oriented to functional. I learned to program in Scheme many, many years ago (early 80s), although I never used it professionally. When javascript came along, people looked at the bizarre object system and thought "This is dumbed down Java." I looked at it and thought, "This is kind of like Scheme."
Re:Closures? (Score:4, Interesting)
C'mon. Threads -- I concur wholeheartedly
I've never understood why programmers have problems with threads. Almost everything is one of two models:
* Solve the problem as a series of queues with worker thread pools. Really hard to mess that up.
* Entire request-to-response workflow in a thread for each request. You have to be a bit careful about locking around shared objects, but usually the answer is avoiding shared objects.
If you can't get multiple threads on one machine right, how are you going to work on distributed systems?
Re: (Score:2)
Buffers (Score:3)
Buffers seems to cause a lot problems, particular when they overflow. As a non-programmer (well, a very long time ago programmer) I've never grasped why preventing overflows seems to be so difficult.
Re:Buffers (Score:5, Interesting)
Saw this in C:
some_func(char *data) {
char *buffer;
buffer = malloc(200);
memcpy(buffer, data, 2000);
send_buffer(buffer);
free(buffer);
}
Occasionally it would cause a crash.
Re: (Score:2)
Yeah send_buffer() was almost certainly asynchronous.
Re:Buffers (Score:4, Interesting)
Microsoft wrote a bunch of code, that in hindsight was a really really bad idea. I'm not really sure that the problems were all Microsoft's fault - they probably didn't invent them. They are Microsoft's fault in that they embedded the concepts into the operating system and then widely popularized them.
The big gotchas all have to do with limitations of C, and the twists used to optimize Microsoft's programming for the 8086 architecture. I'm thinking of:
char string[MAX_PATH];
What can possibly go wrong? Especially before MAX_PATH was invented.
malloc() new() and friends
For any non-trivial program, it's almost impossible to get correct. They only really work for something like a C compiler which will allocate a variable amount of memory, do a task, and then end. If you miss a few free() calls along the way - they will be cleaned up when the compiler terminates.
GlobalAlloc(), LocalAlloc() and friends
Just in case you couldn't make it work with malloc, try the operating system version of the call. Using OS calls really opened the window to some famous bugs - OpenSSH comes to mind.
Multi-threading in C
For any non-trivial problem - it doesn't work. Firstly, for any non-simple piece of code, it is tough to do correctly. Secondly, for a trivial piece of code, like a save operation, you need to somehow make the memory being stored immutable for the duration of the save. For most save operations, this defeats the purpose, as the first thing the user wants to do after save is to change the document. Thirdly, if you really need multi-threading, there is a good chance some of your users need parallel-processing across machines. Multi-threaded code and parallel-processing code are not the same things at all.
Embedding code in data.
Firstly, the x86 architecture encouraged this, by not having proper page protections. Secondly, it completely opens the system up to malicious code. ActiveX, JPEG libraries, font libraries, everywhere Microsoft had an API that embedded code in data, it was all exploited.
Re: (Score:2)
char string[MAX_PATH];
What can possibly go wrong? Especially before MAX_PATH was invented.
Start your path with \\?\ and see how MAX_PATH/PATH_MAX works.
That's why Hurd guys had the right idea to remove these whatsoever, causing lots of buggy software to fail to build instead of having crashes, often exploitable, at runtime.
Re: (Score:3)
Buffer overflows are often the result of not checking the data that is going into the buffer carefully enough, or at all. The spec says the string is max 80 characters, so someone sends 80 characters and some exploit code which runs over the end of the buffer.
Four hard problems in programming: (Score:5, Funny)
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
Re:Four hard problems in programming: (Score:4, Informative)
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.
Re:Four hard problems in programming: (Score:4, Informative)
(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?")
Re:Four hard problems in programming: (Score:5, Interesting)
The best but if advice I've ever had for variable naming is to put the units in the name. If you are handling values in millimetres, use a _mm suffix. For area use _mm2. For graphics use _px for pixels etc.
I've seen so many programmers get hopelessly confused because they can't remember what units they have when doing maths or trying to render data on screen. On some systems pointers can use byte or word addressing too.
Re: (Score:2)
Ah, true hungarian notation. The other use case being suffixes such as _raw vs _validated.
Re: (Score:2)
Pigs are flying, Hell is frozen solid, and I agree with AmiMoJo. Putting units in your names is the best advice. (But I can still argue with you - you "_" using heretic! Eeeeeeevil!)
Re:Four hard problems in programming: (Score:4, Insightful)
Or, even better, put them in the type. This is one thing that makes std::chrono hard to use incorrectly.
Re: (Score:3)
The best but if advice I've ever had for variable naming is to put the units in the name. If you are handling values in millimetres, use a _mm suffix. For area use _mm2. For graphics use _px for pixels etc.
That works and has generally been my go-to method.
An interesting alternative is where the units are part of the type, and I've been getting to the C++ std::chrono library which makes heavy use of it. It's actually rather nice. It models durations and time points as separate concepts, but not only that, it
Re:Four hard problems in programming: (Score:5, Insightful)
How about?:
4. Race conditions
Often very hard to spot using static analysis and not guaranteed to show up during testing.
The bane of embedded and command-control systems.
Re:Four hard problems in programming: (Score:4, Informative)
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.
Multithreading is a solved problem (Score:5, Insightful)
And it's not that hard. Some people make it hard because they're incompetent. The golden rule of multithreading is: your multithreading set-up has to be very simple. Don't optimize (and for the love of god, unless you really understand cache coherence, don't use atomics), aim for clarity, use mutex locks for shared data, and if you have to use several, make sure you acquire them in the same order. 99.9% of the problems disappear if you follow this simple advice.
Re: (Score:3)
Re: (Score:2)
Re:Multithreading is a solved problem (Score:4, Insightful)
You'd be surprised what people try though (Score:2)
Re: (Score:2)
It's manageable, but wise programmers tend to avoid threads when there is another option.
atomics have nothing to do with cache coherence (Score:2)
I think you mean "memory consistency".
Re: (Score:2)
You can do shared memory in go, locks and all. But yes, it encourages the use of signals.
Naming (Score:3)
Seriously, i spend more time thinking on this than anything else lately.
Everyone runs with fear from NP problems (Score:5, Funny)
> 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."
Customer: Why is this problem not scaling?
Programmer: It is NP-hard we are basically just brute forcing it.
Customer: If you can't solve this "NP-hard" problem, then I'll just find someone who will.
Programmer: Sure, let me know when that happens.
Re: (Score:3)
Customer: GTFO&DIAF
Programmer: Well, shit.
These are all horseshit (Score:2)
Multithreading's issues in particular are a matter of education, not technology. The rest are related to programming only vaguely; in particular, NP-completeness is mostly a CS thing and very rarely encountered in software engineering.
Re: (Score:2)
I think in large programs multithreading can be very hard. Not to make it work, and not even to fix once you've got a good handle on the problem at hand, but you never know how much problems are still lurking there are being newly introduced while the code is evolving and each problem is hard to locate. At the same time CPUs are increasing their number of cores forcing you to make use of multithreading.
I agree I don't see the problem with NP completeness. Normally you're happy with a good but not perfect so
Re: (Score:2)
See now, that's what you get for your lack of education.
Prevention of multithread-related bugs is exactly as dead simple as prevention of bugs related memory addressing, or array indexing. The answer is: only do things that have a defined meaning in terms of the concept space of the bug category at hand. So for array indexing, ensure that your index variable is always known to be in a valid range; for memory access, design the program in such a way that for each pointer it's known what they're supposed to p
Re: (Score:2)
NP-hard problems are easy to run into everyday problems. Its just a matter of identifying them; most people seem unable to.
Re: (Score:2)
Such as for example?
Re: (Score:2)
Variants of the exact/set cover problem, or travelling salesman. There's also a good bunch of NP-hard problems when you start working with graphs and trees.
NP is the new P (Score:2)
Modern SAT solvers [toronto.edu] are able to solve SAT problems [wikipedia.org] with millions of variables in seconds. Yes, there are hard problems with some hundred variables that are too hard to solve. But as it turned out, most useful problems are easy to solve. So if you have an NP-complete problem, you should just try to put it into minisat [minisat.se]. If it can't be solved easily, there's still time left to despair.
dates (Score:5, Insightful)
Re: (Score:3)
Dates, including time zones and daylight savings time. Constant source of bugs.
The only safe way to deal with dates/times is to use a 64-bit int for milliseconds (UTC - always UTC). No time zone nonsense, not DST issues, safe to subtract to get a duration, easy to add a duration to, always the right answer.
Performance Optimisation (Score:2)
Writing performant code without obscuring the algorithm or introducing CPU / OS dependencies that will break when you port it.
Writing code that understands cache coherency and is structured for memory locality.
Reporting (Score:2)
Ignorance abounds (Score:5, Insightful)
Closures are not a ``problem''. Ignorant or incompetent implementations of closures is the problem. ...
Just as ignorant or incompetent implementations of garbage collection and memory management is a problem.
And ignorant or incompetent use of arrays/vectors/buffers and pointer arithmetic and access permissions and
So here is an alternative list:
1. Low-skilled programmers (``script kiddies'') who write profound amounts of buggy code.
2. Low-skilled language ``designers'' who re-introduce the known bugs of the past and introduce new innovative bugs as well.
3. Low-skilled managers who reward high output over high quality, thus ensuring an on-time, under-budget hairball and bugs nest.
4. Low-skilled educators who teach ``coding'' rather than computer science, thus ensuring another generation of the above.
5. Low-skilled professional organizations who reward and encourage incompetent industry leaders to unduly influence the field.
6. Low-skilled investors who reward incompetent technology from dominant, monopolistic companies.
7. Low-skilled consumers who flock to buy flash-in-the-pan shiny stupid gimmicks but won't invest in sound technical innovation unless it's flashy.
This is why C students should never be allowed to graduate w/ a degree. They only go on to further muck up the world. Color me bitter. ;-)
P.S. That `C' above refers to grade level / professional competence, not the language (which should really be named D or D minus minus). *smirk*
"closures"? Are you F'ing kidding me? (Score:5, Insightful)
One of the biggest, most vexing problems in computer science is newbies who equate basic programming to the hardest problems of the field.
OK, I realize this is arcane. Let me give an equivalent situation in, let's say, agriculture.
Farmer: "OK, young intern, today we'll learn how to water plants!"
Intern: "Waaaaah! This is as hard as the manipulation of space-time with thought alone!"
Farmer: "...Grab a goddamned watering can, moron."
dumb stuff (Score:5, Interesting)
Ooh, dragons.
1. Multithreading. In some languages (e.g. Java) multithreading is no worse than any kind of parallel processing. Can you be a buffoon and fail? Yes you can. But you can do that in a single-threaded program too.
In other languages (e.g. C) the chance of errors impacting some completely random data structure are so high that it's frankly important to stay away from anything that would confuse the control flow, such as multithreading.
2. Closures. Okay, you're talking about Javascript here. javascript is a hideous language which should not be used to the maximum extent practical. Why complain about closers when all of javascript is bad mojo?
3. Too big data. Also known as lazy-ass programmers who don't want to be bothered to deal with the possibility that their program may be called upon to process a large data set. Solutions for processing large data sets explicitly on the disk (not with virtual memory) are well understood. You just have to choose to use them.
4. NP-complete. There's no particular dragon there... the elephant in the room is those programmers too ignorant or clueless to bother computing the big-oh running time of their algorithms, so they write software that appears to "lock up" as soon as anyone gives it a useful data set to process.
5. Security. Correct security implements defense in depth. Break one level so what? Even patched slowly, it's patched before enough layers can be broken to grant access.
Programmers make two classes of stupid mistake:
a. They assume they don't need defense in depth because they've written secure software.
b. They carelessly implement functionality that cuts through all layers of security. Like single-sign on.
6. Encryption. The odds of a long-surviving conspiracy to hide mathematical breakthroughs which bypass encryption are essentially zero. You can relax on that score. You can also expect one-time-pad encryption to remain unbreakable regardless of mathematical improvements. Because no analysis of extremely long strings of random bits is meaningful.
You have to be pretty bone-headed to mess up security in this day and age. Yes, many many programmers are bone-headed. But that's not encryption's fault.
7. Identity management. The only thing which makes this hard is its constant misuse. No authentication is perfect, so correct programming makes authenticated actions reversible instead. The more critical the action, the more critical it be reversible.
8. Measuring hardness. Now we're in to mumbo-jumbo territory. A simple big-oh evaluation will tell you whether your algorithm is usable. Trying to figure out whether it will be easier or harder to solve one problem or another, neither of which have a known useful algorithm? Silliness! Problems like that are solved when someone finally has the key insight. Inspiration is not a product of work, it's a product of the creative mind.
9. The authors can't measure. They claimed 7 but listed 8 things.
Code on code violence (Score:4, Interesting)
They missed the most vexing problem of all. Hiring a skilled and talented old timer programmer to come solve the problems that fresh faced recruit coders created. Then offering the same rate as they paid the fresh faced recruits, not being able to grasp that the ability to solve, often under tightest of all deadlines, messes left by inexperienced programmers. In some cases less! I have personally had the extreme joy to explain to a physicist that the code he wrote, while it would solve his problem, was written in a manner that the solution was of order O n squared. While the problem could be solved in an manner that mathematically provided the same solution but was order O n. The physicist then said he wanted to test both solutions. His was actually faster on a data set of 100 items. (Lots of fixed constant cost was involved, my solution had more precalculation setup, so for small sets of data, my overhead was more) He proclaimed himself the winner deriding my science. I asked (already knowing) what the normal sample size was they analyzed? What, 100,000 samples? Sure let's use one of those... 20 minutes later mine was finished, I cleverly asked to run first since I lost the prior test. He ran his. It took a while. The next morning his finished. The results were the same. Save the physicist was a mixture of miffed and conciliatory. Very brilliant physicist. Not so great at mathematics. I've even encountered programs implemented in a manner to be non-deterministic when a deterministic solution existed. Vexing is working with some programmer that thinks they know everything. Which really annoys the ones that do.
Re:arrogance is tops (Score:5, Interesting)
Re: (Score:2)
the software industry's propensity to follow a Logan's Run-like purging of more experienced developers.
Wow... if there ever was an apt analogy, this is it. Actually, it is a little bit worse than that. In most places I worked, programming is not just seen as a young man's game, but as a job that you do before you get a real job like manager or team lead or architect or business analyst. A bit like getting started working in the mail room. After a year or 3 of coding you are an "experienced programmer", after 5 you are a "senior developer", and after 8 years... you are a loser. Small wonder so many of o
Re:arrogance is tops (Score:4, Interesting)
A related problem is that there is no way for the hiring manager to tell the difference between a very good programmer and a good programmer. All of the first year CS resumes say the candidates are skilled in C, Java, and a few more buzzwords. Every software project has a life-cycle, and the better programmers move between projects. This means all the experienced resumes show people with many projects. This makes it hard to tell the difference between a competent person that makes meaningful contributions then moves on, and a less competent person that is a good talker and drifts.
It's a real problem for the hiring manager. It essentially means that you can't pay more for better programmers. Economists even have terms for this. Product differentiation. [wikipedia.org] If you can't show you are an A+ programmer as opposed to an A programmer or a C programmer, then it becomes difficult to make the case that the A+ programmer is worth four C programmers. It even becomes difficult to tell who the A+ programmers are. This tends to drive out experienced programmers into other careers.
This problem really affects software engineers. I can tell the difference between a skilled electrician and an unskilled electrician in minutes. Great architects win awards. Develop a great piece of real-time engineering on a safety-critical system - no one is ever going to see your work. Sure, you might save lots of lives with your code. But the hiring manager for your next job can't tell the difference.
Re: (Score:2)
with some proper study of functional and parallel programming
Yeah but for every person who does that there are 10000 wannabees who just want a bigger paycheck.
Re: (Score:2)
Closures have been a part of programming since LISP
Since Scheme, I believe. Lisp "at large" tended to be dynamically scoped before Scheme, with predictable (deleterious) results. The improvement was so substantial that this was one of the novel things adopted in the Common Lisp standard, beyond the "lowest common denominator" unification of extant dialects.
Re: (Score:3)
Wow. The script kiddies where I work are doing all their backend programming in coffescript, running in js interpreters. Every branch and loop they write creates a new callback (which they call threads) so there is no way to predict which order they run in. Half the applications are tricks to put order of execution back into a meaningful sequence and avoid race conditions.
Re: (Score:2)
Re: (Score:2)
data and operations are duals
In my experience, data and operations tend to fight duels - often to the death! Sometimes on horseback with 10 foot lances, sometimes not. Its all good fun - if you are hiding behind the servers and peeping though the gap where the backup drive should have been!
Thus spake the master programmer.
Definitely nah (Score:5, Insightful)
Yes, this. the threading comment struck me more as indicative of an amateur in the area than any real flag of a problem area.
if you understand threading, you can work just fine within it, do appropriate things, don't do inappropriate things. You also have to understand the problem you're trying to solve, but again, that comes down to your skills - not any inherent "Dragon-ness" of threading.
I thread the heck out of my software. Works great. Cross-platform, too. Relatively easy stuff - image processing - and really hard stuff, real time signal processing where all manner of stuff is happening concurrently that depends in one way or another on the other stuff that's happening concurrently. I'm not talking about some thread off doing network management, either.
For me, it's strictly a matter of not going in there casually and carelessly. The appropriate planning and thinking - IOW, design first, then write software - pays off every time.
Of course, if you treat threading casually (as with many other things), it immediately becomes a footgun. Well, that's why Darwin gave us multiple feet, sonny. :)
But the whole point is we're supposed to be good at this. You have to pay your dues to get there. Programming Javascript on a web site isn't going to build the required skillsets.
Yeah. Was:Definitely nah (Score:4, Interesting)
If you understand pointers and malloc(), you can work just fine within them too. But that hasn't stopped people from disparaging them relentlessly and trying to come up with new "safe" languages that don't have pointers and memory allocation.
Added irony: With pointer and memory allocation bugs, the problems are at least reproducible. Can't say that about threading bugs.
still cannot figure out why the Java developers thought they needed to do away with pointers and (application-controlled) memory allocation, but then turned around and encouraged the use of threads. It's kind of like saying to children: "Don't play with those scissors, you might cut yourself. Use the power saw instead!"
Re: (Score:3)
Added irony: With pointer and memory allocation bugs, the problems are at least reproducible. Can't say that about threading bugs.
Sounds like you never had to debug a use-after-free bug.
Re: (Score:2)
...compounded with "I know it'll work, I'll just build and ship, THAT doesn't need to be tested!"