September 24, 2013 at 8:39 pm
Comments posted to this topic are about the item It Happens
September 25, 2013 at 1:51 am
It's a harsh fact of life and a quick look down the list of fixes in the older versions of SQL Server reveal some quite nasty bugs.
There is inherrent complexity in having fine grained multi-concurrent data systems. NoSQL is a very broad church so generalisations about NoSQL are risky. What I would say is that the NoSQL solutions are young and there will be bugs that we've forgotten we used to have in RDBMS's.
The companies behind the NoSQL products are energetic, enthusiastic and keen to improve their products. That is something to be welcomed.
September 25, 2013 at 2:39 am
I always like Maurice Wilkes' quote about this:
"I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs."
That was back in the late 40s, I believe, so this has been going on for a while! It doesn't help that SQL, as a language, isn't really well designed for debugging--it's one of the few languages I've used where I find it faster to just rewrite a line of code that isn't working rather than try to figure out why it isn't.
September 25, 2013 at 3:34 am
SQL has strong roots in relational algebra, this makes it harder to implement but easier to verify. If you use concepts like 'eventual consistency' it is much harder to find out wether everything still acts according too the rules in every possible case. Transactions and isolation levels are also based on a clear set of rules, with the same effect: hard to do it right, but not too hard to check if it's done right.
NoSQL generally means non-relational. Google returns to SQL for access to large data, for several reasons. I don't think SQL and the relational model are the only option when it comes to databases. However, when a model is based on some theoretical foundation, it is easier to prove that certain constraints will always be satisfiied. Does anyone has already encountered a candidate that rivals the relational model in this aspect?
September 25, 2013 at 3:35 am
paul.knibbs (9/25/2013)
...It doesn't help that SQL, as a language, isn't really well designed for debugging--it's one of the few languages I've used where I find it faster to just rewrite a line of code that isn't working rather than try to figure out why it isn't.
Debugging support has been designed into languages in mainstream use for some time now, however, there are plenty of examples of languages where this has had to be shoe horned in. Given that the majority of current popular languages have been designed in an era where Internet development was coming to the fore it is not surprising that these languages have embraced networked development from the off. The trouble is that I have yet to see a mainstream language with a clean implementation for mutlithreaded programming.
How does this relate to the editorial? Without high level abstracts to support such abilities code will be more prone to errors. Memory management is a fine example of this (especially as it highlights something where most languages can take control of but not all languages should).
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
September 25, 2013 at 4:52 am
"embrace the idea that code can be wrong" -- Nathan Marz
Surely this is the wrong approach, as it just gives people an excuse to be lazy.
Code should NEVER be wrong.
It is not difficult to write code that works correctly.
You just need to follow two simple rules:
1) Be crystal clear about the valid set of inputs, and throw an appropriate exception if the input is not in the valid set.
2) If you are not sure whether the logic is correct, break your code into smaller functions/procedures until it is 100% clear that it will work correctly in all cases.
Bugs only arise when people do not follow these simple rules.
Simon
September 25, 2013 at 5:55 am
Steve, did you make all those typos in your "It Happens" paragraphs just to make the point that we could still somehow figure out what you were saying? You're so clever! 🙂
September 25, 2013 at 6:26 am
It is not difficult to write code that works correctly.
:rolleyes:
You can write good code, but chances are you don't write perfect code, all the time. Just because it works, doesn't mean it's correct or right for all situations. Try writing a huge complex business application that runs on three different RDBMS, the desktop and the web, with features to satisfy hundreds of different companies with thousands of users with data collected from millions of people.
(There's a corollary to this about data: "All data is bad, some data is worse.")
September 25, 2013 at 6:33 am
paul.knibbs (9/25/2013)
I always like Maurice Wilkes' quote about this:"I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs."
That was back in the late 40s, I believe, so this has been going on for a while! It doesn't help that SQL, as a language, isn't really well designed for debugging--it's one of the few languages I've used where I find it faster to just rewrite a line of code that isn't working rather than try to figure out why it isn't.
That's a lot less depressing than realizing that a large part of your life from now on will be spent in debugging and correcting mistakes in other people's programs. 🙂
I have worked on quite a range of projects. Some systems are clearly written by people who care about the quality of their code, and other systems are clearly written by people who are only interested in adding a new technology to their CV before moving on to the next step on their intended career path and don't really care about the trouble they are causing for the people who will have to sort out the mess when they are gone.
Simon
September 25, 2013 at 6:40 am
"I hope that's not too gloomy a view of software."
I wrote my first program on punch cards in the late 1970's. Today I do .NET development, SQL development, and SQL Administration. In my experience, I don't think the view that our programs will have bugs or may not work entirely as intended is too gloomy. I don't think that's an excuse to be lazy either. I just think it shows the maturity that's required to realize we're not perfect.
It's delusional to arrogantly deploy a solution and then walk away thinking it's perfect and will never need to be touched again. :crazy:
As soon as we have perfect humans we can then start expecting perfect programs. It may be a long wait... :hehe:
Until then, I think the best approach is test-driven-development with continuous integration. Continually adding and improving test cases is not lazy. It's a lot of work and there are many places that skip test cases thinking they don't need them. That's lazy.
Test-driven-development with continuous integration acknowledges our imperfections while still trying our best to deliver the highest quality possible.
September 25, 2013 at 6:41 am
chrisn-585491 (9/25/2013)
It is not difficult to write code that works correctly.
:rolleyes:
You can write good code, but chances are you don't write perfect code, all the time. Just because it works, doesn't mean it's correct or right for all situations. Try writing a huge complex business application that runs on three different RDBMS, the desktop and the web, with features to satisfy hundreds of different companies with thousands of users with data collected from millions of people.
(There's a corollary to this about data: "All data is bad, some data is worse.")
I agree, we are all human and we all make mistakes from time to time.
However, I still believe that any system, no matter how large or complex, can always be broken down into simple components that can easily be coded correctly.
Problems only arise when people try to tackle too much in one go.
Simon
September 25, 2013 at 6:44 am
I've mentioned this example before, but it's completely appropos:
My boss used to work for a call center. Every so often the entire system would crash for no apparent reason. After some detective work, they isolated it to one specific employee.
The root cause of the problem was the guy was clicking on a button in the GUI just to see how fast he could make the colors change back and forth.
The moral: You can NEVER be 100% certain how your software will be used now and forevermore.
And these days software doesn't run in isolation. You can test your software until you're blue in the face, get it working perfectly, then the company (ahem) that writes the OS changes something that causes your code to break.
____________
Just my $0.02 from over here in the cheap seats of the peanut gallery - please adjust for inflation and/or your local currency.
September 25, 2013 at 6:56 am
simon.crick (9/25/2013)
However, I still believe that any system, no matter how large or complex, can always be broken down into simple components that can easily be coded correctly.
Then your point of failure becomes the communication between all these simple little components. It only takes a mistake in documentation for one part of your program to call another with incorrect parameters, and suddenly the whole thing comes crashing down in your lap. In addition, it's always possible for code to produce unexpected results even when it's entirely syntactically correct--compilers and interpreters are written by programmers who make mistakes, just like your own code is!
September 25, 2013 at 7:13 am
paul.knibbs (9/25/2013)
simon.crick (9/25/2013)
However, I still believe that any system, no matter how large or complex, can always be broken down into simple components that can easily be coded correctly.
Then your point of failure becomes the communication between all these simple little components. It only takes a mistake in documentation for one part of your program to call another with incorrect parameters, and suddenly the whole thing comes crashing down in your lap. In addition, it's always possible for code to produce unexpected results even when it's entirely syntactically correct--compilers and interpreters are written by programmers who make mistakes, just like your own code is!
Yes, you still need a good set of integration tests to ensure there were no misunderstandings at the interface level, but there is no excuse for bugs within individual components.
I'm not saying that we can ever achieve perfection (clearly that is not possible when humans are involved), but I do believe that we should be aiming for perfection.
To start out with the goal of writing anything less than perfect code, is a sure way to create a system riddled with bugs.
Simon
September 25, 2013 at 7:17 am
simon.crick (9/25/2013)
To start out with the goal of writing anything less than perfect code, is a sure way to create a system riddled with bugs.
This still seems to be suggesting that people who write buggy code are deliberately setting out to do so, which is not the case. I would hope *any* programmer would want to write bug-free, easily maintainable code (with the caveat of the usual "Fast. Cheap. Bug-free. Pick any two" problem), but wanting something really, really hard isn't guaranteed to make it happen!
Viewing 15 posts - 1 through 15 (of 60 total)
You must be logged in to reply to this topic. Login to reply