Re: [racket-dev] RFC: Coding Guidelines
On Sep 2, Noel Welsh wrote: > On Thu, Sep 2, 2010 at 11:57 AM, Eli Barzilay wrote: > > Well -- you do, in a sense. When something is broken, someone > > needs to fix it. There's tons of stuff that is (or has) > > bitrotting away since there's no proper owner to take care of some > > code, or bugs in code with no clear owner need to wait for someone > > to volunteer to do the work -- and that's less likely to happen. > > Agreed. I think less stuff should be in the core, and this would go > some way to solving the problem. I think you want this as well. Yes, I want this -- but the ownership issue is still pending as long as the libraries in question are maintained in the plt repository as a group effort. > To elaborate, I think Racket should still come with all the > libraries it currently does but 1) they should have versions like > Planet does and 2) they should be distributable independently of > Racket core. This way a particular library update is independent of > updates to other libraries or the core. (Yes, that's the plan.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] RFC: Coding Guidelines
On Thu, Sep 2, 2010 at 11:57 AM, Eli Barzilay wrote: > Well -- you do, in a sense. When something is broken, someone needs > to fix it. There's tons of stuff that is (or has) bitrotting away > since there's no proper owner to take care of some code, or bugs in > code with no clear owner need to wait for someone to volunteer to do > the work -- and that's less likely to happen. Agreed. I think less stuff should be in the core, and this would go some way to solving the problem. I think you want this as well. To elaborate, I think Racket should still come with all the libraries it currently does but 1) they should have versions like Planet does and 2) they should be distributable independently of Racket core. This way a particular library update is independent of updates to other libraries or the core. N. > My worry re ownership is that making a mess there will lead to more of > these problems. To make a concrete example, there's some unstable > code now that is a big extension to a big library -- and if the > theoretical plan where the unstable manager merges that code in, we > get three people involved: (a) the original author of the library, (b) > the author of the extension, and (c) the unstable manager. Now what > happens to bugs in the resulting extended library? To me, this sounds > like a recipe for one of those silly volleyball moments where the > three players stand next to the ball with "I thought *you'd* pick it" > looks. > > Because of this, I much rather see such extension getting in by (b) > cooperating with (a) to get the extension in. With the result being > - (a) making sure he knows all the bits and becoming the owner of > the result; > - (b) becoming the owner of the resulting extended library; > - or deciding on a clear separation where the two parts are visible > (possibly involving work on either side), and the two maintain their > own bits. > > >> > * "\"Primum non nocere\"" -- after looking this up (bad for such a >> > document), I strongly disagree with it. IIUC, it reads as "if >> > it works, don't mess with it" >> >> Idiomatically that would be "if it ain't broke, don't fix it". I too >> strongly disagree with this. > > (Yeah, I saw that -- and the context that it's coming from is dealing > with a very different kind of machine, where the rules are very > different...) > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://barzilay.org/ Maze is Life! > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] RFC: Coding Guidelines
On Sep 2, Noel Welsh wrote: > On Sat, Aug 28, 2010 at 5:34 PM, Eli Barzilay wrote: > > I (finally) read this and the thread that went on at the time, and > > I don't see any point in all of this, besides a vage plea to > > encourage tests, and a slightly more concrete (but impractical) > > call for stress tests. > > I think laying down general philosophy is useful. It sets a tone. > However, I agree with most of your other points though I'm less > concerned about the ownership of code side, probably 'cause I don't > have to deal with everyday. Well -- you do, in a sense. When something is broken, someone needs to fix it. There's tons of stuff that is (or has) bitrotting away since there's no proper owner to take care of some code, or bugs in code with no clear owner need to wait for someone to volunteer to do the work -- and that's less likely to happen. My worry re ownership is that making a mess there will lead to more of these problems. To make a concrete example, there's some unstable code now that is a big extension to a big library -- and if the theoretical plan where the unstable manager merges that code in, we get three people involved: (a) the original author of the library, (b) the author of the extension, and (c) the unstable manager. Now what happens to bugs in the resulting extended library? To me, this sounds like a recipe for one of those silly volleyball moments where the three players stand next to the ball with "I thought *you'd* pick it" looks. Because of this, I much rather see such extension getting in by (b) cooperating with (a) to get the extension in. With the result being - (a) making sure he knows all the bits and becoming the owner of the result; - (b) becoming the owner of the resulting extended library; - or deciding on a clear separation where the two parts are visible (possibly involving work on either side), and the two maintain their own bits. > > * "\"Primum non nocere\"" -- after looking this up (bad for such a > > document), I strongly disagree with it. IIUC, it reads as "if > > it works, don't mess with it" > > Idiomatically that would be "if it ain't broke, don't fix it". I too > strongly disagree with this. (Yeah, I saw that -- and the context that it's coming from is dealing with a very different kind of machine, where the rules are very different...) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] RFC: Coding Guidelines
On Sat, Aug 28, 2010 at 5:34 PM, Eli Barzilay wrote: > I (finally) read this and the thread that went on at the time, and I > don't see any point in all of this, besides a vage plea to encourage > tests, and a slightly more concrete (but impractical) call for stress > tests. I think laying down general philosophy is useful. It sets a tone. However, I agree with most of your other points though I'm less concerned about the ownership of code side, probably 'cause I don't have to deal with everyday. > * "\"Primum non nocere\"" -- after looking this up (bad for such a > document), I strongly disagree with it. IIUC, it reads as "if it > works, don't mess with it" Idiomatically that would be "if it ain't broke, don't fix it". I too strongly disagree with this. > * Yet another huge ommision from such a document is style. This comes > in several flavors: Yes. This is one of the most important aspect IMO. Consistent style makes it easy for anyone to navigate the code base. We have evolved a house style at Untyped and it is useful. N. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] RFC: Coding Guidelines
On Aug 19, Jay McCarthy wrote: > I hope I've incorporated much of the feedback from this thread: > > http://faculty.cs.byu.edu/~jay/tmp/201008161509-guidelines.html I (finally) read this and the thread that went on at the time, and I don't see any point in all of this, besides a vage plea to encourage tests, and a slightly more concrete (but impractical) call for stress tests. * It talks about code in general -- no distinction between introducing new functionality, and fixing existing code. It looks like the emphasis is on the former, but that's not clear. These two cases are very different. * For the latter case of fixing someone else's code, much of this is irrelevant. If I see a bug in a library, and I tell the author about it but it is not fixed after a while -- if the fix is simple, I'll probably push it. (*I*'ll probably fix it right away.) But does that mean that the responsibility of keeping the code (and therefore maintaining a test suite) is now all mine? The text makes it look that way, but if these rules were enforced in some concrete way (for example -- you touch the slideshow code, and you get to be responsible for all its bugs) the net result would be no fixes. * So obviously some concrete ownership change is out of the question. Is there some implicit change, or something less radical like "you own your changes"? Probably -- but such things are hard to impossible to formalize in any way. I think that ultimately it's something that gets settled between the owner of the code and the person fixing it. As someone who was very often at the fixing side, I've just learned to deal with things on a case by case basis. In some cases the owner is happy for any fix, even if testing it is very difficult (or if the fix is obvious that there's no need for a test). In other cases the owner rejected any change and my fixes got dumped -- and I learned to completely avoid such pieces of code. It yet other cases the owner is relatively new, and I'll do more radical changes. The bottom line is that I don't see any formal way to formalize sane rules and keep moving at the same time. * "As long as your code fulfills its promises" seems like a weasel passage that can admit anything -- it's me who writes the code and me who does the promising, so I can always claim that I never promised [whatever you don't like about it, including bugs]. * There's an emphasis on stress testing -- but I don't see anything concrete there, and I don't see any way of making any concrete conclusions wrt such testing. To give a few examples: - We still have the `seqn' operators in, and they still imply a runtime cost of ~200. What should I do in light of the stress tests passage? - Add a test that will actually break, knowing that fixing it is not a matter of some local change to the code? - Remove the code, because a 200x is bad enough to be considered a bug? - Spend a month rewriting how sequences are represented to actually solve the problem? - Shut up about it, and learn to ignore it? - The unstable/queue code had a much smaller performance hit, but the code in question was simple enough to make that hit much more noticeable, so in that case even a small 5x factor is bad. - In Hari's code there is generally a similar performance hit, but in that case the added functionality (being pure) is worth it, and the code is less simple (certainly not something I'd want to write myself whenever I need purity). So a 5x factor is not a problem. * A minor note: the text refers to the tests/stress/stress library, but that code has no real documentation. (Looking at the code, there's some aspects that should really go into `time' -- like the ability to run the body multiple times, and average the results.) * "\"Primum non nocere\"" -- after looking this up (bad for such a document), I strongly disagree with it. IIUC, it reads as "if it works, don't mess with it" -- which is a recipe for an ever growing codebase with almost no changes to existing code. There are places where this does apply (eg, everything around drracket involve subtle state-based issues that random by-passers are unaware of), and places where it clearly should not apply. The question should really involve ownership: your own dialog with the owner of the code, or your willingness to become its owner. * Speaking about ownership -- IMO it is one of the important aspect of any "coding guidelines", yet there is nothing about it in the text. So IMO this is a huge omission. More specifically, much of my criticism of the unstable collection is related to ownership -- code being dumped as is and left as an orphan with noone to take care of problems. (Yes, there's a policy of clarifying the owner of each bit, but the bottom line is that except for a few things, there was no discussion on it and
Re: [racket-dev] RFC: Coding Guidelines
I am fine with these changes. On Aug 19, 2010, at 10:53 AM, Jay McCarthy wrote: > I hope I've incorporated much of the feedback from this thread: > > http://faculty.cs.byu.edu/~jay/tmp/201008161509-guidelines.html > > Jay > > On Thu, Aug 19, 2010 at 8:14 AM, Matthias Felleisen > wrote: >> >> Yes. I started using the phrase "I have bug reports, therefore I exist" at >> Rice. I think Jay should add this phrase right next to the other quote. >> >> >> >> >> On Aug 19, 2010, at 10:03 AM, Robby Findler wrote: >> >>> Guys: we need one more thing to go into the beginning of these >>> guidelines. Specifically, we should say (something like) "Bugs are >>> something to be proud of; not to be ashamed of." the rationale being >>> that there are always bugs, but if they are unknown bugs then it means >>> your software is not being used. >>> >>> It is the way we choose to fight our bugs that determines our >>> character, not their presence or absence. >>> >>> Robby >> >> _ >> For list-related administrative tasks: >> http://lists.racket-lang.org/listinfo/dev >> > > > > -- > Jay McCarthy > Assistant Professor / Brigham Young University > http://teammccarthy.org/jay > > "The glory of God is Intelligence" - D&C 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] RFC: Coding Guidelines
I hope I've incorporated much of the feedback from this thread: http://faculty.cs.byu.edu/~jay/tmp/201008161509-guidelines.html Jay On Thu, Aug 19, 2010 at 8:14 AM, Matthias Felleisen wrote: > > Yes. I started using the phrase "I have bug reports, therefore I exist" at > Rice. I think Jay should add this phrase right next to the other quote. > > > > > On Aug 19, 2010, at 10:03 AM, Robby Findler wrote: > >> Guys: we need one more thing to go into the beginning of these >> guidelines. Specifically, we should say (something like) "Bugs are >> something to be proud of; not to be ashamed of." the rationale being >> that there are always bugs, but if they are unknown bugs then it means >> your software is not being used. >> >> It is the way we choose to fight our bugs that determines our >> character, not their presence or absence. >> >> Robby > > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev > -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] RFC: Coding Guidelines
Nevertheless, Shriram, I think you're picking on one of parts of the system that follows these ideals the best. Better to pick on slideshow. :) Robby On Thu, Aug 19, 2010 at 9:22 AM, Shriram Krishnamurthi wrote: > You put it through Spidey. If you didn't have any code, what would > you have put through Spidey? Nothing. > > The code came first. It had long since been deployed before you did > this. > > Performance testing came when we set out to write a paper and wanted > to do measurements. They were initially designed only to measure > performance, not to actually *stress*. They morphed into stress tests > later. By that time, too, the system was long since deployed. > > Shriram > > On Thu, Aug 19, 2010 at 9:59 AM, Matthias Felleisen > wrote: >> >> I, with Paul's help, worked the entire Web server through MrSpidey and >> eliminated all but those checks that Herman-Meunier later showed how to >> eliminate with their ICFP paper. That's far more than testing in some sense >> even if it doesn't show that it serves. >> >> Paul set up automatic stress tests back then already. We reported them in >> our paper. >> >> I call this judgment inaccurate. >> >> >> >> >> >> On Aug 19, 2010, at 9:56 AM, Shriram Krishnamurthi wrote: >> >>> Neither would the PLT Web server. I'm pretty certain Jay's own edits >>> to it were not preceded by tests. >>> >>> Jay's changes to the PLAI language most certainly were not, because >>> the current PLAI that is bundled with DrRacket is broken. >>> >>> (Sorry, Jay, but it's your prose.) >>> >>> Shriram >>> >>> On Thu, Aug 19, 2010 at 9:50 AM, Casey Klein >>> wrote: On Thu, Aug 19, 2010 at 8:44 AM, Sam Tobin-Hochstadt wrote: > On Tue, Aug 17, 2010 at 3:57 PM, Jay McCarthy > wrote: >> Please comment. > > I think that this: > > "Your first task when changing old code is to build an adequate test > suite to ensure you do not introduce new mistakes as you attempt to > improve it. Thank you for improving the world for future generations!" > > is too demanding. There are enormous areas of our code that don't > have a test suite. How comprehensive a test suite do I need before > changing slideshow? Or scribble (which has a test suite for the > syntax, but not the language)? Robby and Matthew, would Slideshow exist today if you'd be expected to build it with this process? _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev >>> _ >>> For list-related administrative tasks: >>> http://lists.racket-lang.org/listinfo/dev >> >> > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] RFC: Coding Guidelines
You put it through Spidey. If you didn't have any code, what would you have put through Spidey? Nothing. The code came first. It had long since been deployed before you did this. Performance testing came when we set out to write a paper and wanted to do measurements. They were initially designed only to measure performance, not to actually *stress*. They morphed into stress tests later. By that time, too, the system was long since deployed. Shriram On Thu, Aug 19, 2010 at 9:59 AM, Matthias Felleisen wrote: > > I, with Paul's help, worked the entire Web server through MrSpidey and > eliminated all but those checks that Herman-Meunier later showed how to > eliminate with their ICFP paper. That's far more than testing in some sense > even if it doesn't show that it serves. > > Paul set up automatic stress tests back then already. We reported them in our > paper. > > I call this judgment inaccurate. > > > > > > On Aug 19, 2010, at 9:56 AM, Shriram Krishnamurthi wrote: > >> Neither would the PLT Web server. I'm pretty certain Jay's own edits >> to it were not preceded by tests. >> >> Jay's changes to the PLAI language most certainly were not, because >> the current PLAI that is bundled with DrRacket is broken. >> >> (Sorry, Jay, but it's your prose.) >> >> Shriram >> >> On Thu, Aug 19, 2010 at 9:50 AM, Casey Klein >> wrote: >>> On Thu, Aug 19, 2010 at 8:44 AM, Sam Tobin-Hochstadt >>> wrote: On Tue, Aug 17, 2010 at 3:57 PM, Jay McCarthy wrote: > Please comment. I think that this: "Your first task when changing old code is to build an adequate test suite to ensure you do not introduce new mistakes as you attempt to improve it. Thank you for improving the world for future generations!" is too demanding. There are enormous areas of our code that don't have a test suite. How comprehensive a test suite do I need before changing slideshow? Or scribble (which has a test suite for the syntax, but not the language)? >>> >>> Robby and Matthew, would Slideshow exist today if you'd be expected to >>> build it with this process? >>> _ >>> For list-related administrative tasks: >>> http://lists.racket-lang.org/listinfo/dev >>> >> _ >> For list-related administrative tasks: >> http://lists.racket-lang.org/listinfo/dev > > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] RFC: Coding Guidelines
Yes, we all did. I think it was Matthew who pushed to the point where we would think of saying such things by his release-early-respond-quickly philosophy of software building. (It would be nice to figure out a way to build on Dijkstra's quote to do this.) Robby On Thu, Aug 19, 2010 at 9:14 AM, Matthias Felleisen wrote: > > Yes. I started using the phrase "I have bug reports, therefore I exist" at > Rice. I think Jay should add this phrase right next to the other quote. > > > > > On Aug 19, 2010, at 10:03 AM, Robby Findler wrote: > >> Guys: we need one more thing to go into the beginning of these >> guidelines. Specifically, we should say (something like) "Bugs are >> something to be proud of; not to be ashamed of." the rationale being >> that there are always bugs, but if they are unknown bugs then it means >> your software is not being used. >> >> It is the way we choose to fight our bugs that determines our >> character, not their presence or absence. >> >> Robby > > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] RFC: Coding Guidelines
Yes. I started using the phrase "I have bug reports, therefore I exist" at Rice. I think Jay should add this phrase right next to the other quote. On Aug 19, 2010, at 10:03 AM, Robby Findler wrote: > Guys: we need one more thing to go into the beginning of these > guidelines. Specifically, we should say (something like) "Bugs are > something to be proud of; not to be ashamed of." the rationale being > that there are always bugs, but if they are unknown bugs then it means > your software is not being used. > > It is the way we choose to fight our bugs that determines our > character, not their presence or absence. > > Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] RFC: Coding Guidelines
On Thu, Aug 19, 2010 at 9:01 AM, Sam Tobin-Hochstadt wrote: > On Thu, Aug 19, 2010 at 9:48 AM, Robby Findler > wrote: >> On Thu, Aug 19, 2010 at 8:44 AM, Sam Tobin-Hochstadt >> wrote: >>> On Tue, Aug 17, 2010 at 3:57 PM, Jay McCarthy >>> wrote: Please comment. >>> >>> I think that this: >>> >>> "Your first task when changing old code is to build an adequate test >>> suite to ensure you do not introduce new mistakes as you attempt to >>> improve it. Thank you for improving the world for future generations!" >>> >>> is too demanding. There are enormous areas of our code that don't >>> have a test suite. How comprehensive a test suite do I need before >>> changing slideshow? Or scribble (which has a test suite for the >>> syntax, but not the language)? >> >> You should make a reasonable effort to put in a test case or two for >> the specific functionality that you're adding/modifying. If there is >> no test suite and you aren't sure how to build one, then ask, see what >> responses you get, and go from there. > > So, to make this concrete, I recently made some small changes to the > scriblib/autobib library. These included changing the regexp to allow > hyphens in last names, as well as allowing multiple citations at once > in a particular special case. I tested these changes by running a > not-then-published paper that I was working on, and seeing that it did > the right thing. Then I sent the patch to Matthew, and he said it > looked good. Then I committed it. > > There's two forms of automated test that I could have added. I could > have just added a file the used the functionality, and checked that it > didn't error when run. That would have been a minimal test, and > wouldn't even have exercised the bug fix (it was just parsing my name > wrong). Or I could have written a test framework for Scribble PDF > rendering. I'm not sure how that would have worked, and it would have > been a big programming investment. I don't think I had time then (or > now) to do that work. This example sounds to me like you could have written a call to a scriblib function and checked that there was no error (for the second). For the first, you probably would have had to expose some functionality to make the bib record give you back the sorted list of names (or something like that) that it would have used when rendering. In general, I'd say that a big piece of good test suite design is figuring out how to add observations to some library you want to test so that you can test it only and not test things that it depends on (pdf rendering in this case). Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] RFC: Coding Guidelines
Guys: we need one more thing to go into the beginning of these guidelines. Specifically, we should say (something like) "Bugs are something to be proud of; not to be ashamed of." the rationale being that there are always bugs, but if they are unknown bugs then it means your software is not being used. It is the way we choose to fight our bugs that determines our character, not their presence or absence. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] RFC: Coding Guidelines
On Thu, Aug 19, 2010 at 9:48 AM, Robby Findler wrote: > On Thu, Aug 19, 2010 at 8:44 AM, Sam Tobin-Hochstadt > wrote: >> On Tue, Aug 17, 2010 at 3:57 PM, Jay McCarthy wrote: >>> Please comment. >> >> I think that this: >> >> "Your first task when changing old code is to build an adequate test >> suite to ensure you do not introduce new mistakes as you attempt to >> improve it. Thank you for improving the world for future generations!" >> >> is too demanding. There are enormous areas of our code that don't >> have a test suite. How comprehensive a test suite do I need before >> changing slideshow? Or scribble (which has a test suite for the >> syntax, but not the language)? > > You should make a reasonable effort to put in a test case or two for > the specific functionality that you're adding/modifying. If there is > no test suite and you aren't sure how to build one, then ask, see what > responses you get, and go from there. So, to make this concrete, I recently made some small changes to the scriblib/autobib library. These included changing the regexp to allow hyphens in last names, as well as allowing multiple citations at once in a particular special case. I tested these changes by running a not-then-published paper that I was working on, and seeing that it did the right thing. Then I sent the patch to Matthew, and he said it looked good. Then I committed it. There's two forms of automated test that I could have added. I could have just added a file the used the functionality, and checked that it didn't error when run. That would have been a minimal test, and wouldn't even have exercised the bug fix (it was just parsing my name wrong). Or I could have written a test framework for Scribble PDF rendering. I'm not sure how that would have worked, and it would have been a big programming investment. I don't think I had time then (or now) to do that work. For Typed Racket, testing is a hard problem, but one that I've put a bunch of effort into making possible, because it needs testing. But there's no way I'd expect someone else to put that effort in. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] RFC: Coding Guidelines
I, with Paul's help, worked the entire Web server through MrSpidey and eliminated all but those checks that Herman-Meunier later showed how to eliminate with their ICFP paper. That's far more than testing in some sense even if it doesn't show that it serves. Paul set up automatic stress tests back then already. We reported them in our paper. I call this judgment inaccurate. On Aug 19, 2010, at 9:56 AM, Shriram Krishnamurthi wrote: > Neither would the PLT Web server. I'm pretty certain Jay's own edits > to it were not preceded by tests. > > Jay's changes to the PLAI language most certainly were not, because > the current PLAI that is bundled with DrRacket is broken. > > (Sorry, Jay, but it's your prose.) > > Shriram > > On Thu, Aug 19, 2010 at 9:50 AM, Casey Klein > wrote: >> On Thu, Aug 19, 2010 at 8:44 AM, Sam Tobin-Hochstadt >> wrote: >>> On Tue, Aug 17, 2010 at 3:57 PM, Jay McCarthy >>> wrote: Please comment. >>> >>> I think that this: >>> >>> "Your first task when changing old code is to build an adequate test >>> suite to ensure you do not introduce new mistakes as you attempt to >>> improve it. Thank you for improving the world for future generations!" >>> >>> is too demanding. There are enormous areas of our code that don't >>> have a test suite. How comprehensive a test suite do I need before >>> changing slideshow? Or scribble (which has a test suite for the >>> syntax, but not the language)? >> >> Robby and Matthew, would Slideshow exist today if you'd be expected to >> build it with this process? >> _ >> For list-related administrative tasks: >> http://lists.racket-lang.org/listinfo/dev >> > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] RFC: Coding Guidelines
On Thu, Aug 19, 2010 at 7:56 AM, Shriram Krishnamurthi wrote: > Neither would the PLT Web server. I'm pretty certain Jay's own edits > to it were not preceded by tests. That's not true. > > Jay's changes to the PLAI language most certainly were not, because > the current PLAI that is bundled with DrRacket is broken. The thing that you are referring to was not tested, but I wrote a test suite for almost everything else. IMHO The problem with PLAI was that the printing was not part of the "spec". > > (Sorry, Jay, but it's your prose.) > > Shriram > > On Thu, Aug 19, 2010 at 9:50 AM, Casey Klein > wrote: >> On Thu, Aug 19, 2010 at 8:44 AM, Sam Tobin-Hochstadt >> wrote: >>> On Tue, Aug 17, 2010 at 3:57 PM, Jay McCarthy >>> wrote: Please comment. >>> >>> I think that this: >>> >>> "Your first task when changing old code is to build an adequate test >>> suite to ensure you do not introduce new mistakes as you attempt to >>> improve it. Thank you for improving the world for future generations!" >>> >>> is too demanding. There are enormous areas of our code that don't >>> have a test suite. How comprehensive a test suite do I need before >>> changing slideshow? Or scribble (which has a test suite for the >>> syntax, but not the language)? >> >> Robby and Matthew, would Slideshow exist today if you'd be expected to >> build it with this process? >> _ >> For list-related administrative tasks: >> http://lists.racket-lang.org/listinfo/dev >> > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev > -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] RFC: Coding Guidelines
... whoops, sent too soon. I would say that there is some code where we know how to test it and laziness is the only thing that keeps it from being tested. There is other code, however, where it is something more than laziness that keeps it from being well-tested, ie testing it is a large programming project in its own right. DrRacket is in that category, but I spend some energy writing and maintaining test suites for it regardless (they are FAR from comprehensive). Slideshow is in that category too. Robby On Thu, Aug 19, 2010 at 8:55 AM, Robby Findler wrote: > But that's not true for Matthew, say, who has volumes of course slides > in slideshow that he uses each year. (I think he's the biggest > slideshow client, tho.) > > Slideshow is not an easy thing to test, I'd say. One could probably, > with sufficient work, build something that would reveal properties of > picts and then test for them with the combinators, but it would be > something on the level of complexity of the framework's test engine, > roughly speaking. > > Robby > > On Thu, Aug 19, 2010 at 8:53 AM, Matthias Felleisen > wrote: >> >> There's code and there's code. I don't think slideshow is at the level of >> Racket or Typed Racket or DrRacket. If it went away, I'd have no trouble >> changing the ten or twenty files in my world that use it. Sure, I'd lose a >> few days but if I lost Racket, I'd lose a year and more. >> >> -- Matthias >> >> >> >> >> >> On Aug 19, 2010, at 9:50 AM, Casey Klein wrote: >> >>> On Thu, Aug 19, 2010 at 8:44 AM, Sam Tobin-Hochstadt >>> wrote: On Tue, Aug 17, 2010 at 3:57 PM, Jay McCarthy wrote: > Please comment. I think that this: "Your first task when changing old code is to build an adequate test suite to ensure you do not introduce new mistakes as you attempt to improve it. Thank you for improving the world for future generations!" is too demanding. There are enormous areas of our code that don't have a test suite. How comprehensive a test suite do I need before changing slideshow? Or scribble (which has a test suite for the syntax, but not the language)? >>> >>> Robby and Matthew, would Slideshow exist today if you'd be expected to >>> build it with this process? >>> _ >>> For list-related administrative tasks: >>> http://lists.racket-lang.org/listinfo/dev >> >> > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] RFC: Coding Guidelines
Racket's core is one of the best tested parts of the system, I'd say. Robby On Thu, Aug 19, 2010 at 8:57 AM, Shriram Krishnamurthi wrote: > But most people wouldn't dream of touching the core Racket engine (for > much the same reason). Are these guidelines for kernel hackers? > > Shriram > > On Thu, Aug 19, 2010 at 9:53 AM, Matthias Felleisen > wrote: >> >> There's code and there's code. I don't think slideshow is at the level of >> Racket or Typed Racket or DrRacket. If it went away, I'd have no trouble >> changing the ten or twenty files in my world that use it. Sure, I'd lose a >> few days but if I lost Racket, I'd lose a year and more. >> >> -- Matthias >> >> >> >> >> >> On Aug 19, 2010, at 9:50 AM, Casey Klein wrote: >> >>> On Thu, Aug 19, 2010 at 8:44 AM, Sam Tobin-Hochstadt >>> wrote: On Tue, Aug 17, 2010 at 3:57 PM, Jay McCarthy wrote: > Please comment. I think that this: "Your first task when changing old code is to build an adequate test suite to ensure you do not introduce new mistakes as you attempt to improve it. Thank you for improving the world for future generations!" is too demanding. There are enormous areas of our code that don't have a test suite. How comprehensive a test suite do I need before changing slideshow? Or scribble (which has a test suite for the syntax, but not the language)? >>> >>> Robby and Matthew, would Slideshow exist today if you'd be expected to >>> build it with this process? >>> _ >>> For list-related administrative tasks: >>> http://lists.racket-lang.org/listinfo/dev >> >> _ >> For list-related administrative tasks: >> http://lists.racket-lang.org/listinfo/dev >> > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] RFC: Coding Guidelines
Shriram: tests do not guarantee the absence of bugs, just their recurrence. There are lots of PLAI tests, I believe. Robby On Thu, Aug 19, 2010 at 8:56 AM, Shriram Krishnamurthi wrote: > Neither would the PLT Web server. I'm pretty certain Jay's own edits > to it were not preceded by tests. > > Jay's changes to the PLAI language most certainly were not, because > the current PLAI that is bundled with DrRacket is broken. > > (Sorry, Jay, but it's your prose.) > > Shriram > > On Thu, Aug 19, 2010 at 9:50 AM, Casey Klein > wrote: >> On Thu, Aug 19, 2010 at 8:44 AM, Sam Tobin-Hochstadt >> wrote: >>> On Tue, Aug 17, 2010 at 3:57 PM, Jay McCarthy >>> wrote: Please comment. >>> >>> I think that this: >>> >>> "Your first task when changing old code is to build an adequate test >>> suite to ensure you do not introduce new mistakes as you attempt to >>> improve it. Thank you for improving the world for future generations!" >>> >>> is too demanding. There are enormous areas of our code that don't >>> have a test suite. How comprehensive a test suite do I need before >>> changing slideshow? Or scribble (which has a test suite for the >>> syntax, but not the language)? >> >> Robby and Matthew, would Slideshow exist today if you'd be expected to >> build it with this process? >> _ >> For list-related administrative tasks: >> http://lists.racket-lang.org/listinfo/dev >> > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] RFC: Coding Guidelines
But most people wouldn't dream of touching the core Racket engine (for much the same reason). Are these guidelines for kernel hackers? Shriram On Thu, Aug 19, 2010 at 9:53 AM, Matthias Felleisen wrote: > > There's code and there's code. I don't think slideshow is at the level of > Racket or Typed Racket or DrRacket. If it went away, I'd have no trouble > changing the ten or twenty files in my world that use it. Sure, I'd lose a > few days but if I lost Racket, I'd lose a year and more. > > -- Matthias > > > > > > On Aug 19, 2010, at 9:50 AM, Casey Klein wrote: > >> On Thu, Aug 19, 2010 at 8:44 AM, Sam Tobin-Hochstadt >> wrote: >>> On Tue, Aug 17, 2010 at 3:57 PM, Jay McCarthy >>> wrote: Please comment. >>> >>> I think that this: >>> >>> "Your first task when changing old code is to build an adequate test >>> suite to ensure you do not introduce new mistakes as you attempt to >>> improve it. Thank you for improving the world for future generations!" >>> >>> is too demanding. There are enormous areas of our code that don't >>> have a test suite. How comprehensive a test suite do I need before >>> changing slideshow? Or scribble (which has a test suite for the >>> syntax, but not the language)? >> >> Robby and Matthew, would Slideshow exist today if you'd be expected to >> build it with this process? >> _ >> For list-related administrative tasks: >> http://lists.racket-lang.org/listinfo/dev > > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] RFC: Coding Guidelines
Neither would the PLT Web server. I'm pretty certain Jay's own edits to it were not preceded by tests. Jay's changes to the PLAI language most certainly were not, because the current PLAI that is bundled with DrRacket is broken. (Sorry, Jay, but it's your prose.) Shriram On Thu, Aug 19, 2010 at 9:50 AM, Casey Klein wrote: > On Thu, Aug 19, 2010 at 8:44 AM, Sam Tobin-Hochstadt > wrote: >> On Tue, Aug 17, 2010 at 3:57 PM, Jay McCarthy wrote: >>> Please comment. >> >> I think that this: >> >> "Your first task when changing old code is to build an adequate test >> suite to ensure you do not introduce new mistakes as you attempt to >> improve it. Thank you for improving the world for future generations!" >> >> is too demanding. There are enormous areas of our code that don't >> have a test suite. How comprehensive a test suite do I need before >> changing slideshow? Or scribble (which has a test suite for the >> syntax, but not the language)? > > Robby and Matthew, would Slideshow exist today if you'd be expected to > build it with this process? > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] RFC: Coding Guidelines
But that's not true for Matthew, say, who has volumes of course slides in slideshow that he uses each year. (I think he's the biggest slideshow client, tho.) Slideshow is not an easy thing to test, I'd say. One could probably, with sufficient work, build something that would reveal properties of picts and then test for them with the combinators, but it would be something on the level of complexity of the framework's test engine, roughly speaking. Robby On Thu, Aug 19, 2010 at 8:53 AM, Matthias Felleisen wrote: > > There's code and there's code. I don't think slideshow is at the level of > Racket or Typed Racket or DrRacket. If it went away, I'd have no trouble > changing the ten or twenty files in my world that use it. Sure, I'd lose a > few days but if I lost Racket, I'd lose a year and more. > > -- Matthias > > > > > > On Aug 19, 2010, at 9:50 AM, Casey Klein wrote: > >> On Thu, Aug 19, 2010 at 8:44 AM, Sam Tobin-Hochstadt >> wrote: >>> On Tue, Aug 17, 2010 at 3:57 PM, Jay McCarthy >>> wrote: Please comment. >>> >>> I think that this: >>> >>> "Your first task when changing old code is to build an adequate test >>> suite to ensure you do not introduce new mistakes as you attempt to >>> improve it. Thank you for improving the world for future generations!" >>> >>> is too demanding. There are enormous areas of our code that don't >>> have a test suite. How comprehensive a test suite do I need before >>> changing slideshow? Or scribble (which has a test suite for the >>> syntax, but not the language)? >> >> Robby and Matthew, would Slideshow exist today if you'd be expected to >> build it with this process? >> _ >> For list-related administrative tasks: >> http://lists.racket-lang.org/listinfo/dev > > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] RFC: Coding Guidelines
There's code and there's code. I don't think slideshow is at the level of Racket or Typed Racket or DrRacket. If it went away, I'd have no trouble changing the ten or twenty files in my world that use it. Sure, I'd lose a few days but if I lost Racket, I'd lose a year and more. -- Matthias On Aug 19, 2010, at 9:50 AM, Casey Klein wrote: > On Thu, Aug 19, 2010 at 8:44 AM, Sam Tobin-Hochstadt > wrote: >> On Tue, Aug 17, 2010 at 3:57 PM, Jay McCarthy wrote: >>> Please comment. >> >> I think that this: >> >> "Your first task when changing old code is to build an adequate test >> suite to ensure you do not introduce new mistakes as you attempt to >> improve it. Thank you for improving the world for future generations!" >> >> is too demanding. There are enormous areas of our code that don't >> have a test suite. How comprehensive a test suite do I need before >> changing slideshow? Or scribble (which has a test suite for the >> syntax, but not the language)? > > Robby and Matthew, would Slideshow exist today if you'd be expected to > build it with this process? > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] RFC: Coding Guidelines
On Thu, Aug 19, 2010 at 8:44 AM, Sam Tobin-Hochstadt wrote: > On Tue, Aug 17, 2010 at 3:57 PM, Jay McCarthy wrote: >> Please comment. > > I think that this: > > "Your first task when changing old code is to build an adequate test > suite to ensure you do not introduce new mistakes as you attempt to > improve it. Thank you for improving the world for future generations!" > > is too demanding. There are enormous areas of our code that don't > have a test suite. How comprehensive a test suite do I need before > changing slideshow? Or scribble (which has a test suite for the > syntax, but not the language)? Robby and Matthew, would Slideshow exist today if you'd be expected to build it with this process? _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] RFC: Coding Guidelines
On Thu, Aug 19, 2010 at 8:44 AM, Sam Tobin-Hochstadt wrote: > On Tue, Aug 17, 2010 at 3:57 PM, Jay McCarthy wrote: >> Please comment. > > I think that this: > > "Your first task when changing old code is to build an adequate test > suite to ensure you do not introduce new mistakes as you attempt to > improve it. Thank you for improving the world for future generations!" > > is too demanding. There are enormous areas of our code that don't > have a test suite. How comprehensive a test suite do I need before > changing slideshow? Or scribble (which has a test suite for the > syntax, but not the language)? You should make a reasonable effort to put in a test case or two for the specific functionality that you're adding/modifying. If there is no test suite and you aren't sure how to build one, then ask, see what responses you get, and go from there. In the special case that you found a bug and are fixing in, there should be a way to observe that bug and you should be able to turn that into a test case. If you cannot, perhaps that points to something the language is missing. This case, I'd say, is particularly worth investigating, even in something that has completely no tests. And, of course, Matthias's earlier caveats apply here too. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] RFC: Coding Guidelines
On Tue, Aug 17, 2010 at 3:57 PM, Jay McCarthy wrote: > Please comment. I think that this: "Your first task when changing old code is to build an adequate test suite to ensure you do not introduce new mistakes as you attempt to improve it. Thank you for improving the world for future generations!" is too demanding. There are enormous areas of our code that don't have a test suite. How comprehensive a test suite do I need before changing slideshow? Or scribble (which has a test suite for the syntax, but not the language)? -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] RFC: Coding Guidelines
Supplement it with those words but do leave the prose alone. This is a goal, just like smooth releases are. In general, I think we have reached a size and complexity and a turn-over (new people joining us and committing code) where we should have something to point them to. We're not asking you to rip out your code from the base. We're asking you to point your students to this set of strong suggestions. -- Matthias On Aug 19, 2010, at 9:08 AM, John Clements wrote: > > On Aug 17, 2010, at 4:27 PM, Jay McCarthy wrote: > >> On Tue, Aug 17, 2010 at 2:24 PM, John Clements >> wrote: >>> >>> On Aug 17, 2010, at 3:57 PM, Jay McCarthy wrote: >>> We're attempting to write down coding guidelines for the project. Here is a first attempt: http://faculty.cs.byu.edu/~jay/tmp/201008161509-guidelines.html Please comment. >>> >>> You write >>> >>> "As long as your code fulfills its promises and meets each of these >>> criteria, you can push incrementally. >>> >>> For example, I may be working on adding an exhaustive queue library to >>> Racket. I imagine supporting 30 different functions across 5 different >>> queue implementations. I don't have to wait to push until all 150 function >>> implementations are documented, tested, and stressed. I can push whenever I >>> make progress on each of the required points." >>> >>> Either this is contradictory, or I'm misunderstanding it. The first >>> paragraph suggests that the code must meet each of the criteria; the second >>> suggests that as long as it's *closer* to meeting the required criteria, >>> it's fine. >> >> Maybe you can help me say it better. What I'm trying to get at is that >> 150 functions is perfect to me, but if I only promise 30 functions and >> meet the criteria for each of them, then I can commit even though it >> is not "perfect". Progress here is meeting the 4 points for each new >> function I push. > > Okay, so every individual piece that's committed should meet the criteria. I > think that's the most sensible reading of what you wrote, but it also > frightens me. I don't think that very much of our current code meets these > criteria, and I'm worried that trying to enforce them is going to pull us > into a sinkhole of no-new-functionality. I suppose that we should write down > what we want before we figure out how to get there, though. > > As far as this piece text is concerned, I think I would replace that last > sentence with essentially what you wrote in response: > >>> For example, I may be working on adding an exhaustive queue library to >>> Racket. I imagine supporting 30 different functions across 5 different >>> queue implementations, for a total of 150 functions. If I have just 30 of >>> these documented, tested, and stressed, then it's fine for me to push. > > > John > > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] RFC: Coding Guidelines
On Aug 17, 2010, at 4:27 PM, Jay McCarthy wrote: > On Tue, Aug 17, 2010 at 2:24 PM, John Clements > wrote: >> >> On Aug 17, 2010, at 3:57 PM, Jay McCarthy wrote: >> >>> We're attempting to write down coding guidelines for the project. >>> >>> Here is a first attempt: >>> >>> http://faculty.cs.byu.edu/~jay/tmp/201008161509-guidelines.html >>> >>> Please comment. >> >> You write >> >> "As long as your code fulfills its promises and meets each of these >> criteria, you can push incrementally. >> >> For example, I may be working on adding an exhaustive queue library to >> Racket. I imagine supporting 30 different functions across 5 different queue >> implementations. I don't have to wait to push until all 150 function >> implementations are documented, tested, and stressed. I can push whenever I >> make progress on each of the required points." >> >> Either this is contradictory, or I'm misunderstanding it. The first >> paragraph suggests that the code must meet each of the criteria; the second >> suggests that as long as it's *closer* to meeting the required criteria, >> it's fine. > > Maybe you can help me say it better. What I'm trying to get at is that > 150 functions is perfect to me, but if I only promise 30 functions and > meet the criteria for each of them, then I can commit even though it > is not "perfect". Progress here is meeting the 4 points for each new > function I push. Okay, so every individual piece that's committed should meet the criteria. I think that's the most sensible reading of what you wrote, but it also frightens me. I don't think that very much of our current code meets these criteria, and I'm worried that trying to enforce them is going to pull us into a sinkhole of no-new-functionality. I suppose that we should write down what we want before we figure out how to get there, though. As far as this piece text is concerned, I think I would replace that last sentence with essentially what you wrote in response: >> For example, I may be working on adding an exhaustive queue library to >> Racket. I imagine supporting 30 different functions across 5 different queue >> implementations, for a total of 150 functions. If I have just 30 of these >> documented, tested, and stressed, then it's fine for me to push. John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] RFC: Coding Guidelines
It IS a typo in the original. Matthias, please note. Frankly, John, I'm just not seeing what you're seeing. Maybe I read it too quickly, but at the speed at which I read it, it made perfect sense to me. Shriram On Tue, Aug 17, 2010 at 4:22 PM, Jay McCarthy wrote: > It may be a typo in the source material. > > http://www.ccs.neu.edu/home/matthias/HtDP2e/prologue.html#(part._not) > > On Tue, Aug 17, 2010 at 2:21 PM, John Clements > wrote: >> >> On Aug 17, 2010, at 3:57 PM, Jay McCarthy wrote: >> >>> We're attempting to write down coding guidelines for the project. >>> >>> Here is a first attempt: >>> >>> http://faculty.cs.byu.edu/~jay/tmp/201008161509-guidelines.html >> >> " and that you and your readers will so in the future" >> >> Will so? Should that have been "will also"? Or "do so"? >> >> John >> >> > > > > -- > Jay McCarthy > Assistant Professor / Brigham Young University > http://teammccarthy.org/jay > > "The glory of God is Intelligence" - D&C 93 > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] RFC: Coding Guidelines
On Tue, Aug 17, 2010 at 2:24 PM, John Clements wrote: > > On Aug 17, 2010, at 3:57 PM, Jay McCarthy wrote: > >> We're attempting to write down coding guidelines for the project. >> >> Here is a first attempt: >> >> http://faculty.cs.byu.edu/~jay/tmp/201008161509-guidelines.html >> >> Please comment. > > You write > > "As long as your code fulfills its promises and meets each of these criteria, > you can push incrementally. > > For example, I may be working on adding an exhaustive queue library to > Racket. I imagine supporting 30 different functions across 5 different queue > implementations. I don't have to wait to push until all 150 function > implementations are documented, tested, and stressed. I can push whenever I > make progress on each of the required points." > > Either this is contradictory, or I'm misunderstanding it. The first > paragraph suggests that the code must meet each of the criteria; the second > suggests that as long as it's *closer* to meeting the required criteria, it's > fine. Maybe you can help me say it better. What I'm trying to get at is that 150 functions is perfect to me, but if I only promise 30 functions and meet the criteria for each of them, then I can commit even though it is not "perfect". Progress here is meeting the 4 points for each new function I push. Jay -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] RFC: Coding Guidelines
On Aug 17, 2010, at 3:57 PM, Jay McCarthy wrote: > We're attempting to write down coding guidelines for the project. > > Here is a first attempt: > > http://faculty.cs.byu.edu/~jay/tmp/201008161509-guidelines.html > > Please comment. You write "As long as your code fulfills its promises and meets each of these criteria, you can push incrementally. For example, I may be working on adding an exhaustive queue library to Racket. I imagine supporting 30 different functions across 5 different queue implementations. I don't have to wait to push until all 150 function implementations are documented, tested, and stressed. I can push whenever I make progress on each of the required points." Either this is contradictory, or I'm misunderstanding it. The first paragraph suggests that the code must meet each of the criteria; the second suggests that as long as it's *closer* to meeting the required criteria, it's fine. John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] RFC: Coding Guidelines
It may be a typo in the source material. http://www.ccs.neu.edu/home/matthias/HtDP2e/prologue.html#(part._not) On Tue, Aug 17, 2010 at 2:21 PM, John Clements wrote: > > On Aug 17, 2010, at 3:57 PM, Jay McCarthy wrote: > >> We're attempting to write down coding guidelines for the project. >> >> Here is a first attempt: >> >> http://faculty.cs.byu.edu/~jay/tmp/201008161509-guidelines.html > > " and that you and your readers will so in the future" > > Will so? Should that have been "will also"? Or "do so"? > > John > > -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] RFC: Coding Guidelines
On Aug 17, 2010, at 3:57 PM, Jay McCarthy wrote: > We're attempting to write down coding guidelines for the project. > > Here is a first attempt: > > http://faculty.cs.byu.edu/~jay/tmp/201008161509-guidelines.html " and that you and your readers will so in the future" Will so? Should that have been "will also"? Or "do so"? John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] RFC: Coding Guidelines
We're attempting to write down coding guidelines for the project. Here is a first attempt: http://faculty.cs.byu.edu/~jay/tmp/201008161509-guidelines.html Please comment. Jay -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
