Subject: Re: How Excel tests Excel? - msg#00092

Previous Message by Date: click to view message preview

Re: Problem running sample code - Unit Testing Chptr. 2

On Fri, 22 Jul 2005, Mark Ramm wrote: > In my experience this has not been the case. Setting up a large > "standard" over the top of a flexible environment is significantly > more difficult than setting up an environment with standardization > built in. [...] > That's not to say good teams can't write readable perl code together. > My contention is simply that another team, which is not quite so good, > not quite so jelled together, and not quite so ad dept at enforcing a > standard through social pressure, can can write just as readable of a > Ruby or Python program. Not only that, the second team will expend > less overall effort in the process. Are you saying that Ruby and/or Python are less flexible than Perl ? And that "flexible" and "standardization built in" are antithetical ? And that a more flexible language implies a language that takes more effort to code in in teams ? Or am I reading you wrong ? ,-o--------o--------o--------o-. ,---. irc.freenode.net #dataflow | | The Diagram is the Program tm| | ,-o-------------o--------------o-. `-o------------o-------------o-' | | Mathieu Bouchard (Montréal QC) | | téléphone:+1.514.383.3801`---' `-o-- http://artengine.ca/matju -' Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/pragprog/ <*> To unsubscribe from this group, send an email to: pragprog-unsubscribe-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/

Next Message by Date: click to view message preview

Re: Well I am done reading the original "Pragmatic Programmers"

Yes, there are many who craft write-only APL programs, ostensibly to show their cleverness, and I'm sure I went through that phase as well. A few occasions supporting clients at 2AM took me away from that. I wouldn't recommend buying into the "culture of J" either, since one does have the choice of building great software in J qithout that. I am curious as to the broader applicability of these other languages. Would you elaborate? ----------------------------------------------------------------------- |\/| Randy A MacDonald | you can't pay for it, |\\| randymacdo-bJEeYj9oJeDQT0dZR+AlfA@xxxxxxxxxxxxxxxx | even if you want to. BSc(Math) UNBF'83 Sapere Aude | APL: If you can say it, it's done.. Natural Born APL'er | demo website: http://69.193.255.224/ ------------------------------------------------------------{ gnat }- ----- Original Message ----- From: "Fergus Henderson" <fjh-mailbox-20-UpNH1qtbVFvQT0dZR+AlfA@xxxxxxxxxxxxxxxx> To: <pragprog-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx> Sent: Friday, July 22, 2005 8:58 PM Subject: Re: [pragprog] Well I am done reading the original "Pragmatic Programmers" > On 21-Jul-2005, Randy MacDonald > <randymacdo-bJEeYj9oJeDQT0dZR+AlfA@xxxxxxxxxxxxxxxx> wrote: > > I recommend J, a "dialect of APL" that has a reasonable licence for > > downloading (don't quote me, but my impression is that it is free for > > non-commercial use, although registration is suggested.): > > http://www.jsoftware.com/ > > I disrecommmend J. It is an essentially write-only proprietary language. > The culture of J programming involves practices which are antithetical to > most of what we have learned about software engineering in the last 50 years. > > > The power of J is such that the highest ranking people in the Project Euler > > competition(http://www.mathschallenge.net) cite APL/J/K as their languages > > of choice. > > The Project Euler competition description says that "with more difficult > problems", "it may take several hours to design a successful algorithm". > J is probably a handy tool for such problems, but it doesn't scale > to problems which will take much longer than a few hours to solve. > If you're interested in learning a language that is of broader > applicability, I would suggest a different language -- for example ML, > Ocaml, Haskell, or Mercury. > > -- > Fergus J. Henderson | "I have always known that the pursuit > Galois Connections, Inc. | of excellence is a lethal habit" > Phone: +1 503 626 6616 | -- the last words of T. S. Garp. > > > > Yahoo! Groups Links > > > > > > Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/pragprog/ <*> To unsubscribe from this group, send an email to: pragprog-unsubscribe-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/

Previous Message by Thread: click to view message preview

RE: How Excel tests Excel?

Steve Maguire mentions the excel scenario in âWriting Solid Codeâ. ÂI just noticed that someone borrowed my book, so I canât give you a page number, but Iâm positive itâs there.     From: pragprog-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx [mailto:pragprog-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx] On Behalf Of Chris Morris Sent: Friday, July 22, 2005 11:24 AM To: pragprog-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx Subject: [pragprog] How Excel tests Excel?   I've retained in my head a bit I think I heard from Dave once, that the way the Excel team tests Excel is to have essentially two engines: one is the production engine, highly optimized, etc, the second is a test engine that is easy to work with, but may be slow or somesuch. But it's been in my head so long now, I don't trust my memory. Is that true? Does anyone have any references to this or any other similar story, other testing scenarios where you essentially have to have a second implementation of the production code in order to test it (like testing an MD5 algorithm?) -- Chris http://clabs.org/blogki

Next Message by Thread: click to view message preview

Re: How Excel tests Excel?

On Fri, 22 Jul 2005, Chris Morris wrote: > I've retained in my head a bit I think I heard from Dave once, that the > way the Excel team tests Excel is to have essentially two engines: one > is the production engine, highly optimized, etc, the second is a test > engine that is easy to work with, but may be slow or somesuch. But it's > been in my head so long now, I don't trust my memory. Is that true? To me, it doesn't matter much whether it's true or not. What's certain is that it's a good idea to test things like that. It saves half of the job of writing tests: in the contract of the complex implementation you stipulate that the outcome of that implementation has to be equal to the outcome of the first implementation in all situations. Then when you write your unit-tests, you leverage the contract so that you only have to set up a situation and not have to write what the outcome would be. Well, that last part is something you can do in every situation in which you have a contract if the contract is deep enough; but in this particular case you not only save on writing tests, you also save on writing contracts, because the (other, simple) implementation acts as a specification. However I'm not sure what that would mean for something like Excel. I hope they also use contracts and unit-tests on the simple engine. > Does anyone have any references to this or any other similar > story, other testing scenarios where you essentially have to have a > second implementation of the production code in order to test it (like > testing an MD5 algorithm?) There are many tasks in which the only (known) way to verify that the task has been done properly is to do it again. E.g. "find the distance from point A to everywhere else". To verify that a distance has been computed correctly, there's no other way but to find out than to compute the distance again and verify equality. In general, problems of the type "find the best solution to do XYZ" are like that. MD5 also looks like a good example. ,-o--------o--------o--------o-. ,---. irc.freenode.net #dataflow | | The Diagram is the Program tm| | ,-o-------------o--------------o-. `-o------------o-------------o-' | | Mathieu Bouchard (Montréal QC) | | téléphone:+1.514.383.3801`---' `-o-- http://artengine.ca/matju -' Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/pragprog/ <*> To unsubscribe from this group, send an email to: pragprog-unsubscribe-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/