Testing for valid data
When I'm learning a new language I like to translate old programs into the new language as a test of my understanding. However, many of the old programs are from old programming texts, many written in the time of punch-cards for batch processing, and many containing significant amounts of code that only tests for valid data. Should we still be writing programs in this fashion, or acknowledge the fact that better tools for pre-screening data are now available and code only for the problem at hand? Michael
michael rice
When I'm learning a new language I like to translate old programs into the new language as a test of my understanding. However, many of the old programs are from old programming texts, many written in the time of punch-cards for batch processing, and many containing significant amounts of code that only tests for valid data. Should we still be writing programs in this fashion, or acknowledge the fact that better tools for pre-screening data are now available and code only for the problem at hand?
Hm - I remember test suites in a dynamically typed program with test case upon test case checking that functions expecting integers would throw an exception when given a string, and so on. Doesn't seem that long ago either.. I think the whole -- well, no, but half, maybe -- point of Haskell is that the static type system proves data validity throughout the program. And half the trick of writing correct programs is to design your data types to constrain the possible values to valid ones. -k -- If I haven't seen further, it is by standing in the footprints of giants
Hi Ketil,
Good point, but I think it side-steps the question. Haskell coughs on a data value. Do we grep our data, finding and fixing the offender, or build extensive data tests into our application code?
Michael
--- On Sat, 3/27/10, Ketil Malde
When I'm learning a new language I like to translate old programs into the new language as a test of my understanding. However, many of the old programs are from old programming texts, many written in the time of punch-cards for batch processing, and many containing significant amounts of code that only tests for valid data. Should we still be writing programs in this fashion, or acknowledge the fact that better tools for pre-screening data are now available and code only for the problem at hand?
Hm - I remember test suites in a dynamically typed program with test case upon test case checking that functions expecting integers would throw an exception when given a string, and so on. Doesn't seem that long ago either.. I think the whole -- well, no, but half, maybe -- point of Haskell is that the static type system proves data validity throughout the program. And half the trick of writing correct programs is to design your data types to constrain the possible values to valid ones. -k -- If I haven't seen further, it is by standing in the footprints of giants _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On Sat, Mar 27, 2010 at 2:42 PM, michael rice
Hi Ketil,
Good point, but I think it side-steps the question. Haskell coughs on a data value. Do we grep our data, finding and fixing the offender, or build extensive data tests into our application code?
I'm not convinced I understand your question, but I think I get part of it. I think approaches where you munge the input to make it fit your expectations are almost always wrong. They tend to lead to subtle problems and overcomplication. Consider HTML in the early days compared to more recent developments in that area. Back in the late 90s and early 2000s browsers were being made that just magically accepted invalid HTML and silently interpreted it in whatever ways the authors felt like. Things aren't perfect now, but I think it's been getting better by having the implementations be pickier about malformed input. As for building extensive data tests, I'm not sure what you mean here. I would have to see examples. Often if you have a solid parser that throws detailed errors on invalid input then you're good to go right? And of course, you don't want to let garbage into your program. That's going to lead to headaches. Jason
participants (3)
-
Jason Dagit -
Ketil Malde -
michael rice