Ask Slashdot: Why Do Programmers Make So Many Mistakes? (codinghorror.com) 391
A technical question occurred to Slashdot reader OneHundredAndTen when filling out forms online. "Are the programmers responsible for them stupid, incompetent, lazy, or all rolled into one?"
They provided two real-world examples that inspired the question:
- "I made up a company name that happened to contain a digit. When I submitted the information I got a big fat error diagnostic about this box, to the effect that numerals are not allowed in a company name. So you know, people â" no digits allowed in your company's name, or else!"
- "In a free text box limited to 1,000 characters (already stupid, arguably) the caption explicitly banned the following characters in the "free text" because they can interfere with the correct processing of input..."
~!@#$%^&*()|'
This prompted a response from UnknownSoldier (Slashdot reader #67,820), who shared the humorous "Murphy's Computer Law" aphorisms from 1984, calling them "sadly still appropriate" and referring to one in particular: "There's never time to do it right, but always time to do it over." In general Web programmers tend to be extremely lazy (undisciplined.) They don't value correctness because that would take "work". I'm not just singling out web programmers here, look at how many programmers fuck up the TRIVIAL example of FizzBuzz.
For example, here are two examples where incompetent programmers make tons of assumptions.
* Falsehoods programmers believe about names
* Falsehoods programmers believe about time
As they say the devil is in the details, or edge case, as it may be. Programming is littered with edge cases so bad programmers "stick their head in the sand and ignore the problem hoping it will go away."
Doing it right costs time, money, and skill. Management is partially to blame. Bad programmers are to blame. Schools are to blame. There are many factors why we end up with shit software like the use case you just described.
And now you know why old programmers become grumpy. Modern software is slow, bloated, with layers of abstraction piled upon abstraction, library upon library. You spend more time "decoding" code and reverse engineering what was done because no one ever took the time to comment it properly for the next guy.
Use these examples of "stupid shit" to be a better programmer.
Agree? Disagree? Share your own thoughts in the comments.
Why do programmers make so many mistakes?
They provided two real-world examples that inspired the question:
- "I made up a company name that happened to contain a digit. When I submitted the information I got a big fat error diagnostic about this box, to the effect that numerals are not allowed in a company name. So you know, people â" no digits allowed in your company's name, or else!"
- "In a free text box limited to 1,000 characters (already stupid, arguably) the caption explicitly banned the following characters in the "free text" because they can interfere with the correct processing of input..."
~!@#$%^&*()|'
This prompted a response from UnknownSoldier (Slashdot reader #67,820), who shared the humorous "Murphy's Computer Law" aphorisms from 1984, calling them "sadly still appropriate" and referring to one in particular: "There's never time to do it right, but always time to do it over." In general Web programmers tend to be extremely lazy (undisciplined.) They don't value correctness because that would take "work". I'm not just singling out web programmers here, look at how many programmers fuck up the TRIVIAL example of FizzBuzz.
For example, here are two examples where incompetent programmers make tons of assumptions.
* Falsehoods programmers believe about names
* Falsehoods programmers believe about time
As they say the devil is in the details, or edge case, as it may be. Programming is littered with edge cases so bad programmers "stick their head in the sand and ignore the problem hoping it will go away."
Doing it right costs time, money, and skill. Management is partially to blame. Bad programmers are to blame. Schools are to blame. There are many factors why we end up with shit software like the use case you just described.
And now you know why old programmers become grumpy. Modern software is slow, bloated, with layers of abstraction piled upon abstraction, library upon library. You spend more time "decoding" code and reverse engineering what was done because no one ever took the time to comment it properly for the next guy.
Use these examples of "stupid shit" to be a better programmer.
Agree? Disagree? Share your own thoughts in the comments.
Why do programmers make so many mistakes?
Two reasons (Score:5, Insightful)
1) Programmers don't care. You'd be surprised how many people say things like, "Bugs don't matter" or "we'll fix it in production." Managers who push deadlines over quality aren't helping here.
2) A lot of programmers do care. For them, it's inexperience. If they are keeping track of their bugs, and fixing them, you'll find that with experience, the number of bugs they produce goes down quite a bit.
Re:Two reasons (Score:5, Interesting)
Input validation is expensive and real mistakes are seriously, leading to venerabilities that most users find more serious that excessive limits in names. As shown in XKCD #327.Samsung does not allow special characters in names. I think it is stupid, but they may a good reason.
The balance for online resources is customer acquisition versus security and reliability. It is easy to set off, for example, /. anti ascii art protection. Any site that protects against malevolent input is going to be annoying. There is a nominal cost to storing and vetting input, so maybe 1000 characters is the balance between cost and user experience.
From a business point of view, if there are no negative consequences handling edge cases may not be viable. It is not required that every business serve every customer. If someone wants a number in their name I am not legally required to adjust my model to accommodate them. I am free to do so, but only if I wish.
Re: (Score:3, Insightful)
Input validation is expensive
It really isn't, it's a solved problem.
Re:Two reasons (Score:4, Insightful)
Yes but those who understand that and know that are more expensive than those who don't.
It's nearly always about cost. The way that manifests is different in each case, but it's the cost.
Re: (Score:2)
Yes but those who understand that and know that are more expensive than those who don't.
That is true.
Re: (Score:2)
Re: (Score:2)
Log4j is a solved problem, too. The solution is: don't use it. Remove it. There is going to be a long list of vulns in Log4j for many months, if not years. It's not secure.
Re: (Score:3)
Log4j is a solved problem, too. The solution is: don't use it. Remove it. There is going to be a long list of vulns in Log4j for many months, if not years. It's not secure.
I thought the list was very short: If you log anything that likes like a URL in a certain format, the bloody logger will go to the website of the URL, download Java code, and execute it.
Now if I can tell a programmer "shoot yourself in the foot" and he or she just does it, is that a vulnerability? Log4j works exactly as intended.
Re: (Score:2)
Input validation is expensive
It really isn't, it's a solved problem.
Really?
Just try to develop something as seemingly-straightforward as reasonable input-sanitization Rules that can successfully Pass any Legal email address; but will Reject all Illegal email addresses. It can be done; but it is far from trivial!
Re: (Score:2)
It is trivial; you pay money to someone who has spent the time, effort, and energy to do it right, and you write if(address.isValid(...)) { ... } and let someone who knows what they're doing do their job.
Re: (Score:3)
It is trivial; you pay money to someone who has spent the time, effort, and energy to do it right, and you write if(address.isValid(...)) { ... } and let someone who knows what they're doing do their job.
Which is exactly why someone used log4j and ended up vulnerable whilst other people used Windows and ended up vulnerable. Choosing an outside library is a good place to start but once you have done that and before your software gets anywhere serious you will want to have test cases for that library and audit both the code that's in it and the people that wrote the code. Do you have access to the source? If not, start again. Has the code been written to sensible standards? If not, start again. Do we know w
Re: (Score:3)
Now let us image the library that provides .isValid() does its validation by reaching out the remote mail server and doing a RCPT TO: or VRFY and checking the response. Yes there are libs that do that. If you dumbly use .isValid() without understanding that - bravo your application has a DOS vulnerability and is potentially abuseable for amplification attacks, unless you took some steps to ensure validation is rate limited in some way. We both know you did not, you decided the problem was trivial, typed 'n
Re: (Score:3)
Anybody who thinks they can do better than an '@' symbol with at least one character on either side doesn't know as much about email addresses as they think they do.
Re: (Score:3)
from email_validator import validate_email
valid = validate_email(email)
And how do you know that will return an actually Valid Result?
If you aren't smart and conscientious enough to write the Rules, you sure as hell aren't smart or conscientious enough to Validate those Rules. You just want someone to scapegoat when something goes wrong.
See, Lazy. And Stupid.
Re: (Score:3)
emailaddressgoeshere@z is perfectly valid if there is a host called "z" under your default search domain.
You can also technically send email to an ip address rather than a domain name, in which case you could have emailaddressgoeshere@1.1.1.1 or emailaddressgoeshere@2001:db8::1 both of which would fail your checks.
Re: Two reasons (Score:3)
DNS may be temporarily unreachable, so you cannot do that. And most certainly, SMTP is 100% allowed to tempfail, so you cannot insist on a valid y/n on that front for hours or days even.
Re: (Score:3)
For example
If you are using the data in a SQL statement, you need to encode all special characters that your DB are looking for (this is hopefully done by your ORM)
If you are using data on a command line somewhere, then you need to encode all special characters for that context
if you are using data to towards LDAP or putting it in a XML file or render it on an HTML page or running a query towards a docum
Re: (Score:3)
Bingo I have literally thrown security testing reports back in the face of practitioners who ought to know better when they recommended things like input validation to as a response to a SQLi vulnerability.
There are exactly three ways to handle inputs from unknown/untrusted sources
1) Validate - This ONLY possible when the domain of valid inputs is highly restricted and fully known. You might be able to do this with something like a domestic postal code or if asking for a measure as some integer number of un
Re: (Score:3)
Input validation is not a "solved problem" and never can be because the range of inputs is never-ending and the rules for validating them are very often project-specific and poorly thought through. Input validation is not just a programming problem; it's a requirements specification, programming and testing problem.
One of the articles linked in TFS furnishes a great example. Patrick McKenzie pours scorn on people who try to represent names in a database with first_name and last_name columns, but note that
Re: (Score:3)
Very good points. To add an anecdote, I'm currently working on a project which automatically transfers and processes information about business licenses back and forth from one state government department database to another state government department database. This replaces a system which was largely manual.
The exact issue of what is a valid business name was a huge thorn in my side for at least a month. The first department had their own notion -- can contain numbers or letters, but must have at least
Re: (Score:3)
And there's the heart of it: Not Invented Here Syndrome. They even give it fancy names like SOUP [fda.gov] (Software Of Unknown Providence) and enforce it with regulations!
This is as opposed to "how has this been solved before?" That should be the first question a programmer/engineer/architect/fancy_title_here should pose when given a problem to solve. Instead, they think of how they will solve it instead. And the knock-on effects of such leads to what we have today.
This isn't to say we should blindly always go
Re: (Score:3)
Are you sure? Re-check that Falsehoods programmers believe about names [kalzumeus.com] and then tell me, what is an input validator that will allow all names that occur "out in the wild" as per link, while preventing things that will outright break any system and simultaneously fulfill the management's requirement "the name field is mandatory".
Every single solution to this problem that exists currently is at least partially broken - either too restrictive, not allowing someone to enter their actual name, or too permissive,
Re: (Score:3)
This is the fake error message problem. In this case, commonly encountered, the text of the message is fixed and was written at some time different from the setting of the current value of the test. More generally, error messages are just text strings that have no necessary relationship to any actual tests, or other behavior of the code. Ideally there is a close correspondence, but error messages suffer severely from code drift as systems change.
Try Writing a Scientific Paper or Textbook (Score:5, Insightful)
The same happens with human languages when you have to be exactly correct. Try writing a science paper - or worse textbook - when you have to write down ideas and facts perfectly correctly and you run into the same problem. It is insanely easy to misstate something, state it in a misleading way or miss a word that can completely change a meaning etc Even if you are trying to be careful it is ridiculously easy for mistakes to creep in...and that's with human language, so why should programming be any different?
Re: (Score:3)
Exactly this. Programmers likely make less mistakes than most other professions.
The problem is that programming languages are extremely brittle.
If you forget to put on your blinker when changing lanes, it rarely results in a crash.
If you forget a semicolon, it almost always results in a crash.
Most other professions whether you are a carpenter, plumber or even doctor have
a much higher tolerance for small mistakes than programming.
Re: (Score:2)
Re: (Score:2)
ok, you need to re-think your life.
Re: (Score:2)
An alternative two reasons:
1) Quality software takes time and money.
2) People want software in little time and for little money.
Re: (Score:2)
Divide and Conquer approaches aren't always sufficient having issues emerge beforehand when things are highly interactive. Sometimes it takes extensive and structured field testing and thorough documentation to track things down. Excruciating work for many.
I had to learn the value of documentation the hard way due to
Re: (Score:2)
Things can get extremely complex quickly, where everything turns into differential equation systems.
There the primary problem is to make sure you have clear requirements (need to be 100% sure what equation you are implementing), and interfaces between components need to be very well defined (probably using a functional style will be easiest here).
Re: (Score:2)
Re: (Score:2)
Well, you're wrong. I'll bet you're used to that, though.
Re: (Score:2)
You check, identify the mistake, correct it if possible, and move on. Very normal for people that actually work in the field of science.
Though when people suggest that there's a fairly straight and simple approach one just has to take to notoriously difficult issues, without asking for further elaboration of the specifics, I'm inclined to think that they're case of the Dunning-Kruger effect at work.
As a matter of fact, writing solid software can be qui
Re: (Score:2)
Seems like you're having a bad day.
Re: (Score:2)
If I remember correctly you were also the person who suggested that hypercomplex numbers are actually quite simple. Which either means you're one of the smartest people on the entire planet, or you might be overestimating the extend of your abilities at least a bit.
Besides of that, I mean I do agree with your original post.
It's inexperience in many cases and management doesn't help either, while some people jus
Third reason dominates (Score:2)
(3) The darned computer keeps doing exactly what I told it to do, not what I meant!
These days I believe that's the overwhelming cause of problems, but in the old days there were far more bugs at higher levels that could take some of the blame. Yeah, modern OSes, interpreters, and compilers still have plenty of bugs, but they are much harder to stumble over now. Let's have a cheer for code bloat?
However, upon reflection I think there's at least one more reason worth listing:
(4) Code modules that don't play n
Discriminate the Irish (Score:2)
The ban on certain characters would discriminate the Irish among others.
Just hope that Ronnie O'Sullivan don't encounter this, he has enough money to pay a good lawyer.
But the character restriction also tells me about the Bobby Tables [xkcd.com] problem.
Re: (Score:2)
Also whenever he retires, maybe he can be the replacement "smug because he really is better than you" host over at Top Gear.
This is a topic I've given a lot of thought to (Score:4, Interesting)
Honestly, I think the philosophy of software engineering has gone wrong. Not that I don't appreciate automagic (I specialize in crafting it), but in our grand quest to be "better" we keep gluing features on through libraries and not through understanding. Between that, and a generation of people who learnt to code through copy and paste; and what did you expect would happen?
If I could change anything, it would be disable Control+V. Not that great minds don't copy, but there is a sublime value in even typing out something verbatim... it makes you think just a little more. If I got a second wish, it would be that we should fully re-embrace abstraction, the Unix way. Do one thing, really well, and embrace a common interface. It's not technically unfeasible, we've been doing the cloud right since System-V; just somehow we lost our way.
Meh, I think I'll go meditate some more.
Re:This is a topic I've given a lot of thought to (Score:5, Interesting)
begin RANT...
Divisions being run by managers who can't program, therefore don't appreciate the difficulties. Developers who don't understand test design, product owners who have yet to realize they are the gatekeepers of quality. Salesperson in an engineering management position (e.g. all the AT&T DTV's CTO weren't CTO's) making decisions from a saleperson perspective. Management letting marketing people set deadlines. Developers who become jaded because they're always working on defects and not new code. Coaches that are useless at understanding the cause of poor development practices...the list goes on. End result...Large numbers of developers post '98 don't have the tools, nor the desire to learn those tools, to produce a quality body of work.
To undestand my POV...Go back to the beginning of the SE as a career path (around late 1960's). Programming was expensive, HARD, and expensive! Did I mention expense? The people that were doing it were incredibly smart in that regards, and if you met any of them today you would be taken aback by how smart methinks. It's been going downhill ever since from my POV. I felt like a knucklehead compared to some of the older guys I had the privilege to work with.
Languages evolved to make it easier and more cost friendly.
FORTRAN/COBOL on punch cards?
APL using symbols and requiring special keyboards.
C with its buffer overflow issues that few understood well. Pointers anyone?
Few (if any) debuggers. And definitely no GUI's. All debugging was command line.
Late '70's saw the emergence of the personal computer. Those of us that had access to whatever model began to see it as a viable career path. Schools had computer SCIENCE courses that actual taught it as a SCIENCE. My curriculum included language parsers, compilers, database design (not tables, that actual DB). We were taught everything from ASM, C, PASCAL, FORTRAN, APL etc... Even machine language was part of one course. They still didn't teach test design however (not sure why that went under the radar).
By the late '80's there was an influx of software engineers that loved the craft aspect of it and wanted to understand the cause of defects getting through. The gang of four released their Design Patterns book in the early '90's which, by then, introduced C++ and other object oriented languages to the younger crowd. The CMM and other bodies conveying how a well established company could ensure some semblance of quality for their products. Source control, the beginning of build pipelines that included the running of unit tests to ensure no breakages (later evolved to CI), design reviews, code reviews, test design/code reviews etc... became the norm in well established teams. QA was their to measure the quality as it pertained to the customer POV. They were not the enemy but a collaborating division.
I know I certainly began to feel like software development was finally enjoying the rigor and precision that other engineering disciplines had.
And then the explosion of the .COM around '98. And the influx of cheap programmers from other parts of the world who hadn't evolved with the same knowledge, and the use of non-software engineers as their managers all trying to launch an online presence ASAP.
o do so they threw out design/code/test reviews, unit testing (hell wells fargo's online banking system was develop w/o unit tests because their development manager was convinced by the developers that QA did the testing). This saw the explosion of the "QA engineer" who did manual testing. And then along came the SilkTest, winrunner's etc... that promised managers that their manual testers could write tests (they couldn't) that would increase the cost savings (it didn't). This then lead to managers blaming QA for releasing a shit product. Those non-engineers as managers didn't understand the difference between preventive tests and tests used to measure the quality.
Hell in 2004 Google had to invent the term So
Re: (Score:2)
It's sad, but I started in the 80's and now I'm considered "Old Guard"; I can tell you as someone that hacked BPL and FORTRAN on RSTS/E, the niceties of "C" weren't really even on the horizon for a good part of the decade; much less the 60's.
I got my first modem so I could use someone else's C compiler, in 1989... that was my gateway drug to Unix.. and it's been downhill from there;
otherwise, yeah, this right there, 100%. If you don't understand the actual full stack, from the metal up; you're not engineer
Re: (Score:2)
Stack-based buffer overflows could be mitigated by a CPU design that tags each machine word stored in memory with an auxiliary tag for exactly how the data that is stored at that address came to be there (and perhaps even where it came from) , Reading or modifying these tags would require utilizing a special mode in the CPU which might utilize instructions only ordinarily be found in kernel level code.
Ordinarily reading or modifying these tags would be done directly by the hardware, transparent to regul
Bad management (Score:5, Insightful)
Why Do Programmers Make So Many Mistakes?
Bad management.
Here is the secret to management: You get what you reward. Not the right thing. Not even the right thing your staff knows is the right thing to do. You get what you reward.
Most managers reward for perceived "progress". Look, how fast so-and-so completes tasks on the current sprint. That person person is a rock star, every one should be like that person. And the manager never notices that among the future tasks related to bugs, his rock star produces more bugs per completed task than anyone else. As the rock star continues to be rewarded, others adopt his methods. Short cutting testing. Allowing bugs to exist so long as they don't manifest in a demo of a completed task's functionality, even new bugs introduced by the new code or newly reworked code. And if you can rework the demo to avoid the new bug, that's great, mission accomplished. Engieneers who just fix it are effectively penalized as lower performers.
Definitions (Score:2)
For some context from a programmer's viewpoint, here is something we deal with all the time.
Say some operation at a company starts on June 2. Is that 12AM? Or start of business? Maybe it doesn't matter. So 12AM. Except it's company-wide, and the company has sites in five different time zones. So is that June 2 12AM at the same time for every site? That doesn't work either. The thing has to start at 12AM on June 2 for each site. So it's not really one operation, it's a separate operation for each site, becau
Re: (Score:3)
Re: Definitions (Score:2)
Agree
Time is money (Score:2)
that's a dumb question (Score:2)
Humans make mistakes every day. That is a fact. The difference between a programmer and some other profession is the code is deployed and exists. That means there's proof of the mistake. Look at all the social media posts on the internet, what percent has typos and mistakes?
Until humans stop being human, there will be bugs. I've been programming for over 23 years and contributing to open source for 20 years. A lot of people tell me "you're stupid for throwing money away." or "why are you letting companies e
Re: that's a dumb question (Score:3)
Same stuff, different day (Score:2)
slashdot posts... (Score:2)
Forced lying (Score:2)
An easy example is address fields that have a mandatory 'State' field. News flash: Not all counties have states. I would often use 'Bliss' as my state when the address didn't matter anyway. Pointed it out to one website owner who then checked. He was amuse at the answer he found in his database. He fixed his website to make that field option in future.
Worst when it is a government system. Getting my driver's license in China the system would not a
Software sucks because... (Score:4, Interesting)
"Programmers solve problems they don't have."
This aphorism, coined by my wife, a project manager at the time, neatly encapsulates a great deal about usability, user experience and software design.
The programmer's task is to complete the programming for the form, but it's a form she's destined never to fill out in a real-world context.
If the programmer is simply complying with requirements, (a notably narrow and inadequate channel for communicating design intents), the P.O. who OK'ed the requirements bears some responsibility.
If the programmer never has to feel the pain of trying to enter "3com" or "Botany 500" in the "no digits in a company name" form, she'll never realize how much it sucks.
In fact, if the form meets the requirements in this state, she may not be able to get the form fixed, even if she knows it should be.
You get what you pay for. (Score:2)
That's easy, actually (Score:2)
Because they don't do (obligatory in many *professional* fields) 100% coverage lines and MC/DC unit tests.
There's too many bad programmers? (Score:2)
Why do so many people suck at their chosen career?
Because they "fell into it", as they had nothing better at the time?
Because they figured it would make them money and that was the only motivation?
There's lots of reasons, but I'd wager most of them are to do with lack of passion.
The art of coding is so much harder than many understand. The way I see it, it's a little bit like chess.
You have those who can "see" multiple moves ahead, either just naturals or those who have strived hard to reach that level.
Then
Re: There's too many bad programmers? (Score:2)
I think getting that logical problem solving mindset is an ability you can learn. You can learn from an early age as you said, but it's not inherent. People can learn when they're older too.
But you have to learn by doing it. If you're programming by copy pasting then that's what you're learning. Many of those crappy programmers could become good ones with application. They won't of course, but they could.
They're nerds and picking on nerds is customary (Score:2)
Honest answer: Lots of code is written by people who should never ever be allowed near a keyboard. But they write code because managers are cheap bastards who can't tell good code from bad code and will hire the cheapest copy and paste artist they can find. The only qualification you need to call yourself a programmer is that you program. Well, technically, but practically not even that.
A: I'm human (Score:2)
It's a feature that sometimes generates ideas.
there's this thing called "Requirements" (Score:2)
If you don't adequately specify the problem, you can't blame people for taking shortcuts within the inadequate or unspecified problem.
Also, it is kind of hard to design and write good tests without a specification.
Re: (Score:2)
If you don't adequately specify the problem, you can't blame people for taking shortcuts within the inadequate or unspecified problem.
The counter-argument would be that one of the more important skills for a programmer to have is the ability to recognize when requirements are incomplete or ambiguous, and respond by communicating further with the customer as necessary until the requirements have been fleshed out properly.
And of course the counter-counter argument is that sometimes the company/organization's structure doesn't allow for that sort of thing, in which case everybody is going to suffer in the end. :(
Reality is technology is badly designed... (Score:3)
... as someone who's programmed for decades. The reality is the von neuman model machine means compilers and programming languages are designed to conform to the hardware. The hardware model and software model itself is the issue.
Think about the common "mistake" in c or c++ of "buffer overlows" that lead to remote code execution, the whole reason this can exist is because CPU's literally move from function to function by pointer. The CPU has no "Awareness" like a human does if a value is being faked, that's why you can't eliminate cheating in PC games because at some point "the show must go on" and the CPU is going to tick down the stack to the next value.
The entire computing infrastructure was not designed with anything like the internet in mind, so the whole notion of "software security" is bullshit.
The reality is we are "cave men" at designing computers when it comes to technology. The reason isn't programs are bad, the reason is that the human brain was not designed to deal with the cognitive load that von neuman style chips.
Every good programmer knows that programming languages are only a means to solve a problem, eventually anyone who is serious about programming and getting good at is will take math or advanced university/computer science courses after they are done university to further their learning, and also courses outside of computer science, aka anything related to problem solving more generally. All a programmer can do is convert our thinking in our heads into mathematical statements that fit a von neuman style machine.
The revolution will come when programmers get back into hardware design since they can see just "playing at the edges" inventing new languages is not going to solve fundamental issues of how we want computers to actually behave.
Remember how current CPU's operate is just one kind of invention for a specific task by one small group of people. I've often thought that the future of computing is increased specialization for apps and hardware (aka imagine a computer JUST designed for text editing and code manipulation) aka you're bending the hardware and software towards how you'd like to use it.
Modern systems we are bending our thoughts and trying to convert them into some intermediate language which is the converted into assembly. I've always thought there's a many more models of how a digital circuit and how it is programmed can behave then we've even begun to explore.
AKA we must remember things like ASCII or UTF-8 and all that is just ONE small group of peoples idea of how characters should be encoded for an electronic device.
The design space is huge and beyond one human lifetime, I've thought if I ever had to do it over again I'd go into research. There's plenty of stuff that hasn't even been thought of or invented yet. One of the reasons "programming is hard" is because it is cognitively demanding, it forces you to make your thoughts rigorous and most people don't have the fortitude or cognitive capacity to be good programmers. It's cognitively demanding job if you take the profession and problem solving seriously.
Re: (Score:2)
And what, pray tell, do you have in mind to replace it? Harvard? Bovine Spongiform Whitespace? I hate to break it to you; but one of the fundamental rules of universal computing is that there is no computing machine that can validate all computable inputs.
What you think you want to do can't, won't, and cannot work; and it's a dangerous fiction to imagine that someday they will. At the end of the day, the only solution is hard work and accepting that non-trivial things will contain unanticipated states; an
Re: (Score:2)
"And what, pray tell, do you have in mind to replace it? Harvard? Bovine Spongiform Whitespace? I hate to break it to you; but one of the fundamental rules of universal computing is that there is no computing machine that can validate all computable inputs."
Sigh which has nothing to do with how CPU's were designed in such a way to allow array overflows, aka there were no special values to mark memory as the end or a beginning of an array. Think about parsing for fuck sakes, the computer has no idea of th
Re: (Score:2)
Somehow, you're imagining this great Harvard machine, with an immutable program register, and the smarts to have logic encoded for every possible data structure that could be stored on it's potentially infinite bitplane? Sounds great, but just one problem; if its turing complete, it will still have the same fundamental problem as a von Neuman state machine; full stop.
You can keep abstracting all day long, but at the end of the day, it all comes down to brainfuck; or something close to it; and the halting p
Re: (Score:3)
If it's not general purpose, then really, it's indistinguishable from a sufficiently large eeprom (i.e: a truth table). It's no longer computing, it's compressing a predetermined output.
Re: (Score:2)
Most programmers these days don't worry about any of the problems you've mentioned. Almost all of us use languages that don't allow buffer overflows, for example.
Re: (Score:2)
Most programmers these days don't worry about any of the problems you've mentioned. Almost all of us use languages that don't allow buffer overflows, for example.
I know I picked low hanging fruit, I used buffer overflows as an example of the CPU not having "any awareness" of where something begins or ends.
For instance when we write a value like an address or variable to memory, the data can be interpreted differently depending on what function is being currently executed and what function will use that value for. You may think this is a "no duh" and it is but the whole issue is you can't query important facts about data or functions about hardware under current vo
Re: (Score:2)
I don't know, I still feel like you're solving problems that most programmers in modern languages don't have.
Re: (Score:2)
I don't know, I still feel like you're solving problems that most programmers in modern languages don't have.
They are just an example, aka the idea is we've barely begun to understand what the problems are. I think of it like programmers don't know what they don't know about programming. To quote cheney
"As we know, there are known knowns. There are things we know we know. We also know there are known unknowns. That is to say, we know there are some things we do not know. But there are also unknown unknowns — the ones we don't know we don't know," Rumsfeld said in 2002.
I'm saying programming and hardware de
Simple answer...because dumb fucks enable them (Score:2)
Humans make mistakes (Score:2)
This is by no means exclusive to the software industry. Nearby where I live, many years ago they built a Steak ‘N Shake with the back side of the restaurant facing the road. You’d think at some point during the planning or hell, even during the initial stages of construction, someone would’ve noticed all the other buildings in the plaza faced towards the road.
Corporations are full of ass-kissing yes men who will happily build a building facing the wrong way. It’s no wonder the sof
Inaccurate assumptions (Score:2)
It's just that the inaccurate assumptions of programmers can become enforced (and built on top of) whereas most pe
You are FIRED! (Score:2)
Re:You are FIRED! (Score:4, Insightful)
I made a good chunk of my career on understanding the minutia of calendars ( 1999 treated me very well ); the blessing today is unless you're dense, or intentionally obtuse there's a well tested library in your language.
This is true of all trivial problems; What happens is people write and paste shitty code because they don't bother to ever understand it, and because they're not even bothering with understanding; they never stop to think if there's a better way.
Truth be told, I think we as a collective should spend much less of our time writing code with the mindset of solving a problem, rather thinking of programming as a job where you're mostly gluing together working things and managing exceptional conditions... with novel code being the exception, rather than the rule.
Automation (Score:2)
I have a conversation like this with my business folks at least once a year. Here's how I explain it to them:
It's called "Writing software" or "coding," but at it's core, what it's really about is automating a business process. When you look at it as automating a business process, your work as a developer is dependant on the business process being well designed and equally well described by the SMEs. After all, you can't automate something that doesn't exist yet, right?
Roughly speaking, our bugs fall into t
Everybody makes many mistakes (Score:2)
Everybody who makes anything, makes mistakes.
Every house has flaws. Every road, every device, everything humans make has flaws.
We programmers just happen to be close to code, so we have better visibility into programming mistakes.
Peanut Butter and Jelly Sandwich (Score:3)
Remember back in 4th grade when you did that thing where someone is given explicit instructions - remove cap from jar (how? which way do we spin? do I pick the jar up first? do I turn the lid? what's the lid?)?
Remember how if you missed a *SINGLE* step you'd be spreading the jelly on your hand as opposed to the slice of bread?
People don't think in terms of such low-level, nonsensical crap. It's handled by your brain so that you don't have to think that way. Language is a whole bunch of shared context -- and if you don't have that context, most people's conversations are very, very confusing. (Hell, look at legalese.)
The reason so many mistakes are made is because we have to do things fundamentally un-human -- and no one at all is good at being un-human. We work on models of the world, but these models don't exist in software development. (Some like to suggest they make cutesy models, and they suck -- and they're still not models of our 20-40-year life experience of the thing we're dealing with right this moment.) So, we spread the peanut butter on our hands sometimes.
Why isn't a number allowed in a company name? Because wtf NAME has a NUMBER in it? That's nonsense! Requirements are what is developed for, and "name" was never defined to be something other than a person's name. When you say "name," any normal human things, "bob, Joe, Neo, Morpheus" -- and not "Sam Adam's 123 Kaleidoscope". That's just nonsense.
So you're doing things that are outside the model being developed, outside the specifications being designed for (why wasn't it designed properly? Because a name is a name, not ABC-127_f3), and no one but you has run into that issue so far. Probably. At least for something new.
Re: (Score:2)
Because a name is a name, not ABC-127_f3), and no one but you has run into that issue so far.
Well me and this kid [washingtonpost.com].
Thanks Elon!
Everyone makes mistakes all the time (Score:5, Insightful)
... in everything they do.
In most everyday activities, however, minor mistakes don't greatly effect the outcome(*). In programming, however, they often do, which makes the mistakes more noticeable.
(*) case in point -- I should have written affect rather than effect, but despite my error, you understood what I meant to convey. For computer code, OTOH, a minor error like that could have significant repercussions.
Re: (Score:3)
Surprising to see my third reason so far down in the discussion...
But I should have added a fifth reason:
(5) Insufficient testing, every way you slice it. Not in the schedule and not funded, not demanded of the programmers, not performed by people who even understand the program specs, and so forth and so on.
Re: (Score:3)
And that insufficient testing probably had its roots in insufficient specification of what was required.
Time crunch. (Score:2)
The kernel compiles so fast, there's no longer time to get coffee. This leads to a chronic caffeine shortage and ensuing bad code.
Better question: Why does any software work? (Score:2)
It's amazing, given the many layers of complexity in a computer and in software, that any software every works at all! No programmer even understands all the layers of APIs and SDKs and OS functionality and hardware instructions that must all work correctly for software to work as intended. Despite this impossible contraption they operate, programmers manage to make many useful apps. I'm impressed.
Wrongly hired (Score:2)
Yes, the typical coder is incompetent, under-educated for their job, insufficiently experienced, and often arrogant (which prevents learning) in addition. Some may be lazy, but I think that is a secondary issue.
But the actual fault is with management that hires people not fit for the job, because they are "cheaper". Nobody would dream of hiring an electrician to do an EEs job (and that electrician would still be better qualified than the average coder). As this has been going on for a long, long time and no
Different story for admins/nonprogrammers who code (Score:2)
I think this is the opposite of what a sysadmins and other IT people, who aren't programmers by trade, but happen to code/script when they need to, end up doing. If I think a task will be repeated in the future, I spend more time creating scripts and programs to automate tasks I have to do than it would take to do the task manually, because then if that task ever comes up again I
I blame Slashdot (Score:5, Funny)
Get back to work. Now!
Do they? Compared to who? (Score:2)
Maybe programmers make less mistakes than the rest of the population.
Beyond all that.... (Score:3)
It's not the developers... (Score:2)
Software development is a stool made from 3 legs:
1. Cost
2. Time
3. Quality
You can only control 2 of the 3. Most businesses want to control cost and time, so they end up sacrificing quality.
This is significantly worse when dealing with consultants (I know because I am one). In consulting, you maximize profit by doing the least amount of work with the fewest resources in the shortest time possible. No developer wants to deliver bad code, but no client wants to pay what quality code actually costs.
No one wants to pay (Score:2)
Why did Evergreen get stuck in Suez? (Score:2)
In my opinion it isn't programmers that suck. It's users that are too stupid to put themselves in their shoes. Take the Evergreen, I mean, how hard can it be to not steer your ship into the sides of a tiny canal right? I'm sure many people must have sighed and said, "gee, if I had captained that ship that would never have happened, the captain must be incompetent and lazy".
Same goes for programming, it is far more complicated with far more requirements than you would ever care to want to know about -- and
Re: (Score:2)
Take the Evergreen, I mean, how hard can it be to not steer your ship into the sides of a tiny canal right?
I don't know, but it doesn't happen very often.
US dates (Score:2)
Ignorance (Score:2)
For example, where I live, there are a few instances of house adresses beginning with zero (like 0123). Because they are south of the standardized zero point. How many people know this? So this is why too many IT systems won’t let people enter their adresses properly
Also, stupidly, Slashdot does not allow characters higher than ASCII-127.
Priorities (Score:2)
Craft Skill (Score:2)
To some extent this is down to management expectation. Annual objectives (for instance) favour broadening one's skill-set (i.e. learn something new) rather than deepening one's skill-set (by getting better at what one a;ready knows). The reason is that the former is more
Every mistake is visible but no consequences (Score:2)
Simple: (Almost) every mistake a programmer makes is visible somewhere, but there's actually very little consequence to it. Put another way, bugs happen all the time, people notice but it doesn't matter.
Off by one, program crashes...user restarts it. Miss a "delete" somewhere, program runs out of memory (eventually), user restarts it. Some tiny bug corrupts user data, company fixes it, issues apology, life goes on. With a few (notable) exceptions, when a programmer makes a mistake, life goes on. Very f
Design mistakes, not programming mistakes (Score:2)
While the topic itself is somewhat interesting, the examples are about design decisions, not programming ones. Sure, the second example is a result of the some limitation on the programming side, but it's still a design decision. If both examples show user messages that something is disallowed, and didn't just cause a problem, then the programmer did his or her job well, as they were asked.
So the real question is, why do programmers get blamed for design decisions? In most cases the programmers aren't the o
Ask stupid questions, get stupid answers (Score:2)
Let he who thinks he can do better, do better.