Re: [Chicken-users] Re: Integrating unit tests into source code
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, 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). 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. 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 did, because I had only experience with imperative programming. Just because it's a new paradigm you're not familiar with doesn't mean it's bad. 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! 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. (what exceptions does it raise? What should happen if I supply some particularly strange combination of arguments?) The code is what is going to happen in the machine once the thing is running. Tests may miss significant situations people just didn't think of at the time. Same goes for contracts, by the way. If you do not want to read code, you shouldn't be in the programming business. 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. 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? 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. I suppose we just have to agree to disagree on this issue. Maybe a user poll about what approach to take is in order? Regards, Peter -- http://sjamaan.ath.cx -- The process of preparing programs for a digital computer is especially attractive, not only because it can be
Re: [Chicken-users] Re: Integrating unit tests into source code
On 12/15/06, Peter Bex [EMAIL PROTECTED] wrote: I suppose we just have to agree to disagree on this issue. Maybe a user poll about what approach to take is in order? Why can't everybody just use the approach he/she prefers? When asking about the docsexpr thingy on this list, I was just trying to figure out what users generally think of it. I will add some sort of generalized approach to add annotations based on a quoted list/docstring to chicken, what people make from that is their own choice. I agree that too much tests in the body of a procedure might distract, though. I also find contracts interesting, but didn't understand the particular way PLT handles it, yet. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: Integrating unit tests into source code
Hi! Also, I think the legal issues would be complicated. No, it is not complicated at all. The only way it can be complicated, is if you're not writing your own new BSD code, but stealing the LGPL code. It can be a problem for those who want the liberties which the BSD licence provides, but the LGPL doesn't. Not the same issue. Here, the issue is proprietary code polluting BSD code. Whereas the FSF is *never* going to sue anyone for modifying LGPL code. That's what they *want* people to do, it's what they *believe* in. They're only gonna sue if you copy LGPL code and don't license it LGPL. Note that the FSF is not the only LGPL copyright holder on this planet. Other LGPL copyright holders do not necessarily share the goals and believes of the FSF. However, it is still very unlikely that anyone will be sued for using LPGLed code while reimplementing its functionality. Well, you could be a MacOS guy I suppose, which from a UI standpoint is a helluva lot better than being a Unix guy. Yeah, you are right, the ``Worse is better'' paper is also applicable in the UI world. Ah well. Technology sucks, and then you die. It is indeed easier to blame technology than to blame yourself. Groetjes, Peter. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: Integrating unit tests into source code
On Fri, Dec 15, 2006 at 02:58:17AM -0800, Brandon J. Van Every wrote: Peter Busser wrote: A few years ago most ``UNIX'' based mailing lists I was subscribed to were reply-to-mailing-list kind of lists. The problem with you Windows guys is that you configure your mail server, clients, or whatever to send ``I am out of office'' messages for every message they receive and no matter where it comes from. So during the holiday season, mailing lists would receive the same kind of ``I am out of office'' kind of e-mails from the same people over and over and over again. I am not now, nor have I ever been, an auto-responder. I think you're confusing Windows programmers for Windows *users*. The latter, admittedly, are almost morons. They can't quite be though, because MS software is so bad it keeps people on their toes. Well, there is no need to take it personal Brandon. It was just a joke. And I can't believe that you take it so seriously. ;-) Groetjes, Peter. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: Integrating unit tests into source code
Peter Busser wrote: Well, you put the LGPLed code in a separate source file. And you reimplement it in yet another source file, while gradually deleting the LGPLed functionality. There is one catch though. The BSD licence allows people to make proprietary changes to the code and does not mandate any code sharing with others. When you mix BSD and LGPLed code, at least the LGPLed code must be shared with others AND the binary must be distributed in such a way that the LGPLed code can be changed, compiled, and relinked into a functional binary. Right. Which is why I said if we snarf PLT's contract.ss, it would have to be in an egg. Can't have a LGPL requirement in Chicken proper. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: Integrating unit tests into source code
Brandon J. Van Every wrote: [...] 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. [...] Hello, all the contract based programming systems I know don't come up with a specific language for describing the contracts. I usually see contract based programming systems as syntactic sugar allowing you to specify arbitrary code which will be run upon entry to and exit from a function. Of course it makes most sense to put parameter and return value checking assertions into those blocks, not something with strange side effects or the like, because all the contract blocks are usually automatically removed in the release build. In contrary to unit tests, I find contracts very useful not only to debug library code, but also code using a library. But contracts don't replace tests. Like Felix said earlier in this thread, I would as well vote for a general code annotation system that could be used to implement both contracts and unit tests in CHICKEN. cu, Thomas ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: Integrating unit tests into source code
Peter Busser wrote: Hi! Also, I think the legal issues would be complicated. No, it is not complicated at all. The only way it can be complicated, is if you're not writing your own new BSD code, but stealing the LGPL code. It can be a problem for those who want the liberties which the BSD licence provides, but the LGPL doesn't. Chicken has a natural separation. Chicken proper is BSD licensed (except for the CMake build stuff, which I put under MIT because I actually want people to say I did it. Anyways, even less restrictive than BSD.) The eggs are licensed with whatever the author chooses. That's how it's going to be with any third party library for any language. Now admittedly, if contract programming is rather core to how someone wishes to program, and we snarf from PLT, then that LGPL egg is going to be in their way. LGPL is kind of a nuisance when it doesn't feel like a library, but rather a core language capability. But in practice, if it's really really an issue to someone, they could write a BSD contract egg, using the LGPL egg as a point of departure. If they really really don't want to do that work, then they'll go find another Scheme. But they won't go find PLT, because the entireity of PLT is LGPL, not just the contract.ss library. Are there any Schemes that offer contract programming under BSD license? If not, then perhaps the person choose a different language. Not the same issue. Here, the issue is proprietary code polluting BSD code. Whereas the FSF is *never* going to sue anyone for modifying LGPL code. That's what they *want* people to do, it's what they *believe* in. They're only gonna sue if you copy LGPL code and don't license it LGPL. Note that the FSF is not the only LGPL copyright holder on this planet. They're the only one with teeth. Ah well. Technology sucks, and then you die. It is indeed easier to blame technology than to blame yourself. Careful, you'll get me started on the sociocultural inscription of technology... Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: Integrating unit tests into source code
Thomas Christian Chust wrote: Brandon J. Van Every wrote: [...] 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. [...] Hello, all the contract based programming systems I know don't come up with a specific language for describing the contracts. I usually see contract based programming systems as syntactic sugar allowing you to specify arbitrary code which will be run upon entry to and exit from a function. How is that better than just writing tests then? Of course it makes most sense to put parameter and return value checking assertions into those blocks, not something with strange side effects or the like, because all the contract blocks are usually automatically removed in the release build. Standard way to add and remove tests, is that the benefit? In contrary to unit tests, I find contracts very useful not only to debug library code, but also code using a library. But contracts don't replace tests. I feel a need for Wikipedia coming on. Like Felix said earlier in this thread, I would as well vote for a general code annotation system that could be used to implement both contracts and unit tests in CHICKEN. Sounds good to me. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: Re: [Chicken-users] Re: Integrating unit tests into source code
It was my impression that you were going to do something along the lines of extend-procedure and procedure-data--the main difference being the parser would create the docstring or docsexpr slot automatically. One could reuse the extra procedure data slot right now for this purpose, e.g. (define square (extend-procedure (lambda (x) (* x x)) '(doc (p Squares argument (code x) . #;7 (square 5) 25 #;9 (procedure-data square) (doc (p Squares argument (code x) .)) and you can obviously macro this, so I figured it was a simple matter of adding a doc slot, accessor and modifying the parser for define in some basically R5RS-compatible way. Then you do whatever you want with the data. I think what Felix was asking was for a general syntax for doc-sexprs that was compatible with R5RS and that doesn't confuse people or put them off. After all, the obvious syntax for docstrings is readable, and will just be ignored by R5RS. I like the idea, anyway. Build a good, unobtrusive version and people will find a use for it. On 12/15/06, felix winkelmann [EMAIL PROTECTED] wrote: On 12/15/06, Peter Bex [EMAIL PROTECTED] wrote: I suppose we just have to agree to disagree on this issue. Maybe a user poll about what approach to take is in order? Why can't everybody just use the approach he/she prefers? When asking about the docsexpr thingy on this list, I was just trying to figure out what users generally think of it. I will add some sort of generalized approach to add annotations based on a quoted list/docstring to chicken, what people make from that is their own choice. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: Integrating unit tests into source code
Brandon J. Van Every scripsit: I've never cared about contract programming, because I'm too saddled with performance concerns to worry about that. If it doesn't have to work, I can make it as fast as you want. Oops. The problem, in my point of view, is that you Unix guys are always setting up mailing lists to be Reply To Sender. Nothing to do with Unix; the convention much predates the use of Unix to run the world's mailing lists. So I have to manually type the name of the list every time I reply. Use the Reply All button. (The owner will get two copies, like you are getting of this message; big deal.) Windows guys set up their mailing lists to be Reply To List. Until the first time that a *highly* confidential reply to the author, possibly libeling another list participant, goes back to the list. Windozers go for what makes sense to the common man; Reply means send it back to where it came from. Reply means reply to one (the author); Reply All means reply to all (the list). What could be clearer? 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! It isn't all those servers, it's all those brains. Why should 500 or 5000 mailing-list participants have to read (even enough to delete) your personal, private, of-no-concern-to-anybody-else response? -- Is a chair finely made tragic or comic? Is the John Cowan portrait of Mona Lisa good if I desire to see [EMAIL PROTECTED] it? Is the bust of Sir Philip Crampton lyrical, http://ccil.org/~cowan epical or dramatic? If a man hacking in fury at a block of wood make there an image of a cow, is that image a work of art? If not, why not? --Stephen Dedalus ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: Integrating unit tests into source code
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 [EMAIL PROTECTED] Subject: Re: [Chicken-users] Integrating unit tests into source code To: chicken chicken-users@nongnu.org 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
Re: [Chicken-users] Re: Integrating unit tests into source code
Peter Bex wrote: 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. Of course it's allowed. Delete code from the LGPL library. Add *your own* equivalent functionality somewhere else in your app, either above the LGPL library, or beside it. You just can't use their code, you have to write your own from scratch. But you could do this gradually over a long period of time, using the LGPL library as scaffolding that gets gradually whittled down. Also, I think the legal issues would be complicated. No, it is not complicated at all. The only way it can be complicated, is if you're not writing your own new BSD code, but stealing the LGPL code. Clearly, the LGPL exists so that it can be used in conjunction with proprietary licensed code. No court is going to say, Well you have to implement that functionality in the LGPL library, because they were there first and it looked like a good infrastructure to do it with. You can throw out 99% of a LGPL library if you want to, and just keep one function. You're still going to have to provide a .dll for that 1 function, and its source code. There is no restriction in a LGPL that you must somehow keep the integrity and functionality of the work. Some other licenses do have such restrictions. That's why I said, LGPL is an acceptable scaffolding license as compared to other licenses. 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. Not the same issue. Here, the issue is proprietary code polluting BSD code. Whereas the FSF is *never* going to sue anyone for modifying LGPL code. That's what they *want* people to do, it's what they *believe* in. They're only gonna sue if you copy LGPL code and don't license it LGPL. Also, in practice, you really think Chicken is a legal target? Hardly. Even Linux was gazonkers popular for many years before it was worth someone's time to try to sue over license pollution. By that time, I assure you, any crappy LGPL contract starter code will have long since been whittled away beyond recognition. 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. How do you know you've specified it right? I'd say, you don't, until it has failed a few times. Which gets back to the question of changing designs. 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 :) I was ribbing Felix as the listowner, and YES he is a Unix guy, not a Windows guy. And as far as I'm concerned, if your Chicken build isn't MinGW, Cygwin, or MSVC, you're a Unix guy. Well, you could be a MacOS guy I suppose, which from a UI standpoint is a helluva lot better than being a Unix guy. 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. I wonder if Thunderbird can be so clever. Well, looks like it will be soon, but not now. http://open.nit.ca/wiki/index.php?page=ReplyToListThunderbirdExtension Starting a flamewar about Unix vs. Windows is not appropriate here. So don't. I didn't. That is, I couldn't possibly expect anyone to take this stuff so seriously. 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. Ah well. Technology sucks, and then you die. 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
Re: [Chicken-users] Re: Integrating unit tests into source code
John Cowan wrote: Brandon J. Van Every scripsit: I've never cared about contract programming, because I'm too saddled with performance concerns to worry about that. If it doesn't have to work, I can make it as fast as you want. At DEC we always ran OpenGL Conformance suites, and other tests. Back in the day, we had the highest Conformance in the industry. I do believe in testing. I just haven't had a reason to do it via the meme of contract programming. Oops. The problem, in my point of view, is that you Unix guys are always setting up mailing lists to be Reply To Sender. Nothing to do with Unix; the convention much predates the use of Unix to run the world's mailing lists. That's scary. So I have to manually type the name of the list every time I reply. Use the Reply All button. (The owner will get two copies, like you are getting of this message; big deal.) No no no it's against my religion. :-) Actually I think gmail is clever enough to mask the duplicates. Which unfortunately means I never see my own posts. I like seeing my own posts; they're usually well-written. Windows guys set up their mailing lists to be Reply To List. Until the first time that a *highly* confidential reply to the author, possibly libeling another list participant, goes back to the list. My B.A. is in Sociocultural Anthropology. Also I'm 36 years old. I've learned not to go to certain emotional places, generally speaking. There are humanistic answers to such problems. Windozers go for what makes sense to the common man; Reply means send it back to where it came from. Reply means reply to one (the author); Reply All means reply to all (the list). What could be clearer? No, Reply All means reply to both the author and the list, as you said above. Windozers think Reply means, reply to the 1 entity that just sent you something. In their minds, that 1 entity is the list. I don't interact with individual authors. I interact with everybody on this 1 list. But here of course we're just reiterating that people have different mental models. 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! It isn't all those servers, it's all those brains. Why should 500 or 5000 mailing-list participants have to read (even enough to delete) your personal, private, of-no-concern-to-anybody-else response? Oh no! The Mummy rises, and chases me around the room! Back, foul creature of the dead! Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
