Re: [Chicken-users] Re: Integrating unit tests into source code

[Brandon J. Van Every]

Peter Bex wrote:

On Thu, Dec 14, 2006 at 03:41:44PM -0800, Brandon J. Van Every wrote:
  

I know and understand why to use tests.  I'm not opposed to tests,
but I am opposed to lumping the tests in with the main code.
I'd much rather just keep the code clean and put the tests in
another file.
  
   Well,  I  question  why we have files.  We have historical reasons for
   it; all of our text editors are built in terms of them.  But a program
   is really just one big database of stuff, and it might make more sense
   to  have  it  all  uniformly  accessed and searched, rather than being
   cobbled across a filesystem.
   Thus  I  am saying, "why should it appear together" vs. "why should it
   appear  apart,"  is  pretty arbitrary and historical.  If one regarded
   the program as a database, then either is just a view of the database.
    

When the time comes that all tools support this kind of "I choose what
I want to see" stuff, 

Well, even SciTE appears to support "folding," which seems to be the gratuitous expansion and collapse of code you don't want to look at.  So if your editor could "fold" the contract, then the clutter wouldn't be an issue.  So it seems that the time is now, for some tools that are somewhat evolved.

you won't need files and there's no problem with
lumping everything together because you select your own preferred view
for the particular task you're working on.  Unfortunately (?), that time
isn't here yet and we have to make do with imperfect plaintext-editors
(though paredit.el really helps).
  

One mustn't apologize for Emacs.  Those cardboard stands at the grocery stores with all the dimes and quarters in them?  They're for the Emacs users.

   Only  if those specifications are terse, legible, and universal enough
   to  describe  nearly any class of problem that needs specification.  I
   have  my doubts, but I haven't tried this paradigm.  I suspect my eyes
   will glaze over, and that deciphering contracts isn't much better than
   deciphering simple tests.
    

What I read between the lines is that you're opposed to this idea because
you don't have any experience with it.

You needn't read between the lines, just re-read what I've written elsewhere in this ever lengthening thread.  I don't oppose contract programming.  I'm generally in favor of any testing method, good comments, and things that resemble literate programming.  However, I think there are probably limits to what contract programming can do for people, so I'm not inclined to oversell it.  It would be one heckuva specification language that could handle any arbitrary problem domain, with clarity and aplomb.  I think there will be head scratching, same as always.  It isn't that different from writing small, clear, concise test cases.

  I bet once you've seen a few
programs that work like this, you will gradually learn how to read them
and that will mean a productivity increase.
When you first came into contact with a recursive Scheme program, didn't
you think it was very difficult to read?

I *still* think it's difficult to read.  I think *C* code is difficult to read.  Code is difficult to read.

I'm sure specifications in the form of contracts, if done properly, are
a lot more terse than tests.  Which is exactly why I'm so fiercly opposed
to inline tests.  As an example: A big project I'm working on at work has
a core library that has to be tested well.  The library is only 400 lines
of Ruby code (it builds on existing classes), but it has ~1400 tests.
That is an awfully big test:code ratio.  You really don't want to have
these tests inlined!
  

I don't value terseness.  I am opposed to gratuitous required verbosity, like VariableNamesThatMustBeReallyLong, but that's not the same thing as valuing terseness.  If you read CMakeLists.txt, you will see it is far from terse.  It certainly isn't bloated, everything in there actually does something, but it became a lot more verbose when I tutorialized the whole thing.  Whether something is 400 or 800 lines of code really isn't the issue.  The issue is how long does it take to write it, and how long does it take to read it.  If it's longer but clearer, that's better.  If it's longer and straightforward, rather than being terse and fancy, that's better.  The worst code I wrote in CMakeLists.txt is the stuff where I gratuitously macrotized the lists of files.  It's much easier to maintain a manual list of files, because people can actually find things and add/delete them, without needing to understand any oh-so-clever macros.

I think Perl sucks.  That's pretty much the epitome of terseness at the expense of intelligibility.

  Tests
don't say shit.  They're a very low-level and nonsemantic way of
groping around to ensure your corner cases are covered.

   Depends  on  the  test.   I think the comments are what help.  I don't
   care  what  kind of code someone writes, it's gonna make my eyes glaze
   over.
    

Again, this is personal.  In my opinion, code is the only thing that
really counts.  Comments are often neglected with the heat of a deadline
on your heels, or don't touch upon every aspect.

Well, I don't like the computer industry, or how most programmers behave in it.

 Tests may miss significant situations
people just didn't think of at the time.  Same goes for contracts, by
the way.  

Right, which is why I'm not inclined to oversell contracts.

If you do not want to read code, you shouldn't be in the
programming business.
  

Hey that's like saying if you don't want to read Microsoft APIs, you shouldn't be in the programming business.  Bull-oney!  There's all kinds of things in programming I don't *want* to do.  The question is *will* I do them?  Yeah, I'll read / funge other people's code *if* it does something for me, or *if* I'm getting paid.  Otherwise, it's a complete waste of my time.  Sitting around reading other people's code ain't one of the joys.

   Declarative   styles  are  not  panacea.   Some  problems  are  better
   specified  imperatively.   Sometimes  you  really want to know that "A
   happens, then B happens, then C happens" and it's easier to debug.
    

That's a matter of personal preference.  I am sure a lot of Schemers
will disagree with you here.
  

No, it's not preference.  What I stated above is fact.  You are going to run into situations where "A happens, then B happens, then C happens" is easier to debug.  Now, how often you write that sort of code, or have to deal with that sort of code, depends on what you're up to.

   The  latter.   Because  I'm  probably  implementing  a  bit  twiddling
   optimization algorithm, and I need to know exactly what's happening as
   the   code  converts  to  machine  instructions.   When  you  state  a
   preference  for declarative interfaces, you are implicitly stating you
   don't  want  to be bothered with the implementation details.  That you
   prefer  abstract  problems.   Now  that  may have its place in various
   problem domains, but not typically in mine.
    

If your domain is the odd one out, should Chicken really give second-class
treatment to all those other ones?

Should Scheme be a pure declarative language?  Nope.  Should OCaml?  Nope.  I don't believe in pure programming languages.  When you straitjacket people with The One True Paradigm, all you do is complicate things for someone else's real world problem.

  Of course, from your perspective it
should right now, but what if you need to write some entirely different
type of program?  Wouldn't you like to do it the best way possible, and
in Chicken?

  

   Bigger is fine.
    

I really dislike Java and C# where you often end up with huge amounts
of boilerplate code.  Bigger is *not* better, that's one of the reasons
we have macros.
  

Macros are a two-edged sword, requiring judicious use.  The common wisdom is, don't use 'em unless that's the only way to get the job done.

I suppose we just have to agree to disagree on this issue.  Maybe a user
poll about what approach to take is in order?
  

No, not really.  Having declarative contract programming available is fine.  Forcing people to use it is wrong.  Expecting everyone to think it's the greatest thing ever, is unrealistic.  Some people will do contracts and others will do tests.


Cheers,
Brandon Van Every