[Top][All Lists]
[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
pgpBo8dxZfpTB.pgp
Description: PGP signature
- [Chicken-users] Integrating unit tests into source code, felix winkelmann, 2006/12/14
- Re: [Chicken-users] Re: Integrating unit tests into source code, Peter Busser, 2006/12/15
- Re: [Chicken-users] Re: Integrating unit tests into source code, Brandon J. Van Every, 2006/12/15
- Re: [Chicken-users] Re: Integrating unit tests into source code, Peter Busser, 2006/12/15
- Re: [Chicken-users] Re: Integrating unit tests into source code, Brandon J. Van Every, 2006/12/15
- Re: [Chicken-users] Re: Integrating unit tests into source code, Peter Busser, 2006/12/15
Re: [Chicken-users] Integrating unit tests into source code, Michele Simionato, 2006/12/14
Re: [Chicken-users] Integrating unit tests into source code, Peter Busser, 2006/12/14