chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Bex
Subject: Re: [Chicken-users] Re: Integrating unit tests into source code
Date: Thu, 14 Dec 2006 17:12:40 +0100
User-agent: Mutt/1.4.2.2i

On Thu, Dec 14, 2006 at 05:59:23AM -0800, Brandon J. Van Every wrote:
> 
> I don't really understand this part.
> 
>    The   point  is,  you  can  use  LGPL  code  as  "starter  code,"  and
>    incrementally  transform  it,  until  you  have  only  BSD  code.  The
>    incrementality  is  important.   Some  licenses  will prevent you from
>    doing that.

I didn't know that was allowed.  Also, I think the legal issues would be
complicated.  Think USL vs. BSDi and the recent SCO vs. IBM.  Where does
the code come from, and who is to know for sure?
I wouldn't want to go anywhere near that.

>    It takes me 6 design iterations to get anything right, and that's only
>    for  perfunctory  low-level  features.   For  contract programming I'd
>    rather  look at someone else's mature programming model.  The paradigm
>    is pretty fundamental to the way you're gonna write your software.
>    That  may  be  an argument in favor of simpler testing mechanisms.  If
>    the  Scheme  programmer  doesn't  have  to  think  of  anything new to
>    implement a testing mechanism, that's a short-term benefit.

>    I've  never  cared about contract programming, because I'm too saddled
>    with performance concerns to worry about that.

You can always disable contract checking.  It's just like compiling with
or without debugging symbols.  You can have the overhead if you'd like the
debugging support, but you can also leave it out when and where speed
matters.  Ideally you could selectively enable/disable contract checking
per module.

>    Also,  when you write code that can return errors, there's the ongoing
>    question  of  "Gee,  what  are  we  going to do about the errors?"  If
>    you're  a  20  person  organization, well you're gonna have lotsa code
>    monkeys  writing  lotsa code to deal with the errors.  But if you're 1
>    guy  just  trying  to  get something working, you're wasting your time
>    mentally  masturbating  on  how  you  might deal with the errors, in a
>    design  that  isn't  mature  yet,  and is gonna change another 5 times
>    before you're happy with it.

An breach of contract means either your design has failed or the caller or
callee contains a bug in the code.  You don't "deal with errors", you
let it crash and burn, then you inspect the pieces to see what went
wrong.  It's not just an exception that signals "something went wrong,
I can't perform this operation" to the caller, it's an actual fault in
the code.

>    I'm  saying,  testing  and  errors are appropriate when your design is
>    more  stable.   That's  rather downstream, and also a rather expensive
>    support burden.
>    Compare  build  engineering.  Chicken had to exist a long time, and go
>    through  a  bunch  of so-so builds, before it was worth having someone
>    like  me  come  along  to "make it all proper" with 1 build.  Not that
>    we're  there  yet,  but  in  6..12  months  it'll be there.  The heavy
>    lifting  is  done.   And  it was *expensive* to do that heavy lifting.
>    Chicken was stable enough to take it though.
> 
>   
> 
> Are there any BSD licensed Schemes worth poaching?
> 
> I hope someone else can answer this.
>   
> 
>    You could Google around about it.  :-)  Admittedly, it's more involved
>    than  looking  up  the  PLT  Scheme  license.  I thought I saw a chart
>    comparing all the Scheme implementations once upon a time, but I can't
>    find  it  now.   Here's  the  Wikipedia  entry  on Design By Contract:
>    [1]http://en.wikipedia.org/wiki/Design_by_contract#PLT_Scheme        .
>    That's the only Scheme listed there.  I don't know how many flavors of
>    DBC  are  out  there.   I  suspect  several.   So  there's the broader
>    question of "what kind of DBC?"
> 
> Please don't post to another list when replying to a thread.  It makes
> it very hard to follow discussions.
> 
>    Oops.   The  problem,  in  my point of view, is that you Unix guys are
>    always setting up mailing lists to be "Reply To Sender."

"you Unix guys"?  Could you please use a milder tone?  We're all Chicken
users here :)

Actually, I have set up mutt to reply to the list.  It also sets the
proper headers so other threaded clients can see the mail is a reply
to the original mail.

The mail you replied to had these headers set:

From: Peter Bex <address@hidden>                                           
Subject: Re: [Chicken-users] Integrating unit tests into source code            
To: chicken <address@hidden>                                          
Date: Thu, 14 Dec 2006 11:05:15 +0100                                           

Starting a flamewar about Unix vs. Windows is not appropriate here.
I use what I like, you use what you like.  I'm cool with that, as long
as both sides speak the respective standards correctly and it doesn't
hinder communication.
But please don't complain about other people's software or
culture without doing your homework.

>    So I have to manually  type  the  name of the list every time I reply.
>    Sometimes I make  a mistake.  Windows guys set up their mailing lists
>    to be "Reply To  List."

If I understand your reasoning correctly, you just overwrote 'chicken-users'
with 'chicken-hackers'.  The 'To' and 'From' headers both had
'chicken-users' in them.

>    This  is  all  religion  about how mail
>    clients should be implemented.    Unixers  go  for  the  traditions
>    peculiar  to  their  historical  mail  clients.   Windozers  go for
>    what makes sense to the common  man;  "Reply"  means "send it back to
>    where it came from."  We subscribe to a list, things come from the
>    list, we send things back to the list.

A nice enough idea in theory, but this won't always work.  Lots of lists
just leave the original sender in the From header, so a naive non
list-aware mailclient's 'reply' function would ignore the list entirely.
Yes, there are also older Unix based MUAs which work like that, but I
beg everyone to please not use those!
If lists set the 'Reply-to' header, there would be no problem (unless
people are using MUAs that don't honor _that_ header), but lots of
list servers don't do that either.

There's more to proper handling of mail & mailinglists than you'd
initially think!

>    I  will  wager,  furthermore,  that  a default of Reply-To-Author is a
>    relic  of  a  time  when  net  curmudgeons  didn't  want  you "wasting
>    everyone's  time"  with your idle chit-chat.  Force you to think about
>    replying  to  the  entire  group,  the entire world community, all the
>    resources wasted on all those servers, oh my!

We were having a nice discussion about testing and contracts in Chicken.
Please don't spoil that by allowing it to degenerate into a Windows/Unix
flame fest.

>    actually  belongs.   I  suppose  "do  you  like  testing  or  contract
>    programmer  interfaces?"  is  a Users question.  How to do it, such as
>    where you will snarf code from, is a Hackers question.

A valid remark.  I suppose if one wants to move it to another list
it's best to inform others about it on both lists.  ie, saying 'moving
this message to chicken-hackers' in your reply and sending it initially
to both lists.  People on chicken-hackers only will be able to swap in
the proper context from the chicken-users archive and people on
chicken-users will know why their thread disappeared.

PS I hope I haven't offended.  I just would like this list to remain
friendly.

Regards,
Peter
-- 
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music."
                                                        -- Donald Knuth

Attachment: pgpBo8dxZfpTB.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]