It's called Testing...

XML does for data what Java does... what!? Where's this guy *been* the last decade? Camp J2EE?

 

I taught Bobby Woolf Smalltalk...but I do not agree with the idea that dynamic method dispatch/duck typing can fairly be called "weak typing."  Nor do I agree that static typing is at all superior to The Smalltalk Way--quite the reverse, actually.  

I'd love to see Smalltalk return to full mid 90 popularity and beyond. But one thing that I don't miss, and one thing I was glad to see bled out of the Smalltalk realm, was the high priced consultant. The type that basically moves from hot technology to hot technology, specializing in telling customers what they want to hear. A short stone throw from politicians frankly.

Sure, a guy should be given the chance to change his mind and reverse himself. But I don't think Bobby's in that category. His is not the story of someone who contributed at the edge of the Smalltalk community looking for the next big thing. His booklist for example tells a different story.

I've lived both the free-love Smalltalk lifestyle, as well as the boot-camp C and Java lifestyles.  I can deal with both fine.  Prefer loosely typed programming languages; strictly typed languages typically do no type interferencing, and thus require you to constantly repeat yourself, which makes programs unreadable.  Just look at what Java generics did to an already unreadable language.

On the other hand, having some structure around coarser grained artifacts is a good thing.  You mention RSS as an example.  There's a schema defined for that (kind of; Atom did a better job, obviously).  Structure.  Strongly typed.  Even Smalltalk has some structure; I can navigate through my classes and methods in various ways.  

Coarse grained: need some structure.  Fine grained: loosey goosey.

James wrote "Since you can run Smalltalk code at any time, not testing it takes effort ..."
Please don't write such drivel - it'll just be used to tear apart whatever point you may be trying to make.

James wrote "... even if you don't have unit tests, ad-hoc testing gets done all the time (I do it with my blog server and with BottomFeeder all the time)"
Which is to say you still don't use unit tests and still have no idea about test coverage - so much for explaining the concept of testing to Bobby Wolf.

James wrote "You can have all the declared interfaces you want, but they don't always help ..."
Why wouldn't "declared interfaces" help us to know if the "disparate pieces that were implemented by different people reading the same spec differently" actually fit together?

Comment by James Robertson

My doing ad-hoc testing has nothing to do with whether I have unit tests, actually. But thanks for playing, Isaac.

 > > So you didn't really know if your code worked until you ran it

Something about this statement just makes me laugh.  Can one *ever* **really** know if code works without running it?  Is that at all a realistic thing to expect?  I think the sane among us concluded long ago that it isn't.

I'm beginning to think that the insistence on big-declarations-up-front languages on the part of some folks is mostly motivated by their just being too lazy to test and the desire to get the machine (or perhaps, smarter programmers than they, who write compilers) to do all the work for them while they sit back and collect the checks.

James wrote "My doing ad-hoc testing has nothing to do with whether I have unit tests, actually. ..."
Oh what a tease you are! Tell us James - do /you/ write unit tests.

And the question you ducked ... Why wouldn't "declared interfaces" help us to know if the "disparate pieces that were implemented by different people reading the same spec differently" actually fit together?

chuck wrote Something about this statement just makes me laugh.
Maybe what makes you laugh is the understanding that he should have said - So you didn't really know if your code didn't work until you ran it.

chuck wrote ...too lazy to test and the desire to get the machine ... to do all the work ...
LOL! And some folk are just too lazy to hand translate their programs to bytecode! They just go on and on about being tool makers and increased productivity and automatic test generation and proof tools and ...

Compiling, to bytecode or otherwise, is obviously an automatable task -- they consist of a process of translating a program from one representation to another.

What I was trying to get at is that the anti-dynamic alarmists seem to think that if we can just give the compiler enough information, we can get it to tell us whether or not our program is correct with no, or very little, additional thinking or work required on our part.

On the other side of the typing debate, we don't believe such an idea to be realistic. Verifying that a program actually does what you set out for it to do is entirely another matter from compilation; a machine has much more limited capabilities for making such determinations . Until you run your code (for various values of "run" -- even proof tools more or less amount to something very much like just running the program) and devise and execute a well-thought out test of the results -- either through writing and executing a unit test, or just "ad-hoc" eyeballing the output (and preferably though some combination of both), you really don't know whether it works.

... er, and somehow I think I was trying to tie-in that idea with the above comment about "High Priced Consultant."  It's all mixed around in my head now but it made sense at the time  :D  It all kind of reminds me of the equally unrealistic old idea that computers will eventually program themselves and we'll have factored the human programmer out of the equation entirely.

chuck wrote ... anti-dynamic alarmists ... the compiler ... we can get it to tell us whether or not our program is correct ...
"anti-dynamic alarmists" seem to think that the compiler can tell us whether or not our program is consistent.

chuck wrote Verifying that a program actually does what you set out for it to do ...
Do you mean validate rather than verify?

chuck wrote Until you run your code ... for various values of "run" ...
I don't think there's any confusion about what you meant by "run your code" and suggesting it included static analysis is insincere.

chuck wrote Until you run your code ... execute a well-thought out test ... or just "ad-hoc" eyeballing the output ... you really don't know whether it works.
Is "whether it works" the same as "whether or not our program is correct"?

iirc that Dijkstra guy said "Program testing can be quite effective for showing the presence of bugs, but is hopelessly inadequate for showing their absence" but I suppose he's just an "anti-dynamic alarmist".

Comment by James Robertson

Hmm:

Is "whether it works" the same as "whether or not our program is correct"? iirc that Dijkstra guy said "Program testing can be quite effective for showing the presence of bugs, but is hopelessly inadequate for showing their absence" but I suppose he's just an "anti-dynamic alarmist".

I'd say yes, that's what he is. Testing is the best tool we have at present.

James wrote Testing is the best tool we have at present.

Do /you/ write unit tests?

("Testing is the best tool..." for what? Are you just agreeing with the first part of Dijkstra's comment "Program testing can be quite effective for showing the presence of bugs..."?)

> whether or not our program is consistent.

> Do you mean validate rather than verify?

> Is "whether it works" the same as "whether or not our program is correct"?

Obviously I'm speaking in generalities here. This is, after all, a blog-comment discussion. If you'd prefer a well-researched PhD thesis with scientifically precise and consistent semantics, you'd be better off looking somewhere other than blogs :D Splitting hairs about the definitions of words that are closely related or similar in common usage is one of the oldest tricks in the trollbook.

Basically though, I see static typing, garbage collection, proof methods, and even testing are all tools to try to make sure, as much as we can, that our program does something we meant it to do, and doesn't do something we don't want it to. And I think that actually running the code in a controlled environment, i.e. testing, is the best tool we have. The others are useful to the extent that they enable the programmer to get the program right and soon, and are non-useful or harmful to the extent that they get in the programmer's way; they're trade-offs like everything else in programming, and I don't believe that any of the tools on that list other than testing will ever replace testing. If anything will, I think it is yet to be discovered.

> I don't think there's any confusion about what you meant by "run your code" and suggesting it included static analysis is insincere.

You'd be mostly right there; the other values of "run" only occurred to me some time after writing the original comment, while thinking the subject over. Static analysis, proof methods, to me seem like other kinds of running your code -- albeit through some other process, rather than through an interpreter/machine similar to the one that it is intended to run on in production, and after first translating it into some alternate representation that can be analyzed with such a process, and then testing the result of that process. So much of this is extra intermediary steps that have to be done by either humans or by other programs that themselves had to be written and tested by humans, and thus present more opportunities for error to be introduced into the process, ironically since the intent is to reduce or eliminate error. As opposed to just running the code on a computer like that on which it will be run in production, and testing that, which is much more directly relevant to the program actually doing its real job.

I'm not sure if what Dijkstra was saying there proves or disproves anything you're saying directly, but it's a good appeal to actual authority. Oh, and also, I write unit tests.

chuck wrote Splitting hairs about the definitions of words that are closely related or similar in common usage is one of the oldest tricks in the trollbook.
And playing bait and switch with generalities was hackneyed before the sophists.

The distinctions which you call splitting hairs are directly on point

• you ridicule "anti-dynamic alarmists" for supposedly thinking the compiler will tell us "whether or not our program is correct" which you don't believe to be realistic - and now you complain when I agree that your strawman isn't realistic and provide a statement that is!
• as you probably know, say "Verifying that a program ..." and we're talking about checking against its specification, say validating and we're talking about asking someone if its what they wanted - for one of those using a computer really wouldn't be that helpful.
• as you write unit tests, you probably know that the difference between not finding a bug and the program not having a bug is kind-of important.

chuck wrote Dijkstra ... a good appeal to actual authority
No, just giving credit where credit is due.

chuck wrote I think that ... testing, is the best tool we have.
Maybe you're just wrong - Static Driver Verifier

chuck wrote As opposed to just running the code on a computer like that on which it will be run in production, and testing that, ...
iirc for "testing that" you're assuming someone will eyeball the output (perhaps just a little error prone?) or you're assuming someone will write "well-thought out" unit tests (I don't think I need to ask James again).

Is there a Smalltalk implementation of QuickCheck?