<scream> On Mon, Jul 13, 2009 at 2:54 PM, Nicholas Thompson < [email protected]> wrote:
> But Doug: I don't want MY answer; I want YOUR answer. > > Nick > > Nicholas S. Thompson > Emeritus Professor of Psychology and Ethology, > Clark University ([email protected]) > http://home.earthlink.net/~nickthompson/naturaldesigns/<http://home.earthlink.net/%7Enickthompson/naturaldesigns/> > > > > > > ----- Original Message ----- > *From:* Douglas Roberts <[email protected]> > *To: *[email protected];The Friday Morning Applied Complexity > Coffee Group <[email protected]> > *Sent:* 7/13/2009 9:50:00 AM > *Subject:* Re: [FRIAM] Philosophy, Mathematics, and Science > > Nick, > > I like you. I really do. But you sometimes make me just want to scream. > > If you want to know what pseudocode is, go to the web and find out! Here's > a starting point for you: > > http://en.wikipedia.org/wiki/Pseudocode > > Then, if you still *really* want to know what psuedocode is, *write some*. > And then pick a language and turn it into actual code. Then you will know > what psuedocode is. > > --Doug > > On Mon, Jul 13, 2009 at 9:28 AM, Nicholas Thompson < > [email protected]> wrote: > >> What is the relationship between pseudo-code and code. >> >> Are actual codes "realizations" of pseudocodes? >> >> Nick >> >> Nicholas S. Thompson >> Emeritus Professor of Psychology and Ethology, >> Clark University ([email protected]) >> http://home.earthlink.net/~nickthompson/naturaldesigns/<http://home.earthlink.net/%7Enickthompson/naturaldesigns/> >> >> >> >> >> >> ----- Original Message ----- >> *From:* Steve Smith <[email protected]> >> *To: *The Friday Morning Applied Complexity Coffee Group<[email protected]> >> *Sent:* 7/13/2009 9:16:11 AM >> *Subject:* Re: [FRIAM] Philosophy, Mathematics, and Science >> >> >> >> Can be built upon in theory, but in practice they are with high >> probability thrown away and rebuilt from scratch. >> >> Because they are complex linguistic objects which, like philosophers' >> arguments, are often harder to figure out than to do over from first >> principles. >> >> -- rec -- >> >> Well said Roger. I think we have all had the experience of choosing >> to: >> >> 1. rederive an equation >> 2. redesign an algorithm >> 3. rewrite a piece of code >> 4. rehash a philosophical argument >> >> when there was already a perfectly good (maybe) >> equation/algorithm/program/argument layed at our feet. >> >> For me, this is a mixture of: >> >> >> 1. Pride >> 2. Trust >> 3. Understanding >> >> >> This was a major challenge to code re-use at one time... about the only >> published Algorithms many of us trusted were those published in Knuth! And >> even then, we had to rewrite the actual code in whatever context we were >> operating in, and were generally proud to do it. But we couldn't help >> noodling on the algorithms, trying to think of a new, more elegant, more >> general, or more efficient way of solving the problem at hand. >> >> Often, by the time one has worked through an algorithm forward to >> backward, backward to forward, one might as well have designed it. The >> existing algorithm provides a few important things, however: >> >> 1. Existence proof. We *know* there is at least one algorithm that >> achieves the desired result. >> 2. Hints. Even if we don't understand an algorithm on first blush, we >> usually get a sense of it's arc. >> 3. Reference. When we think we've got ours right, we can go back and >> test it against the original. In fact, we probably now understand the >> original as well as our own and if we have any humility may throw *ours* >> away and use the one made available to us in the first place >> >> For proceduralists, C's concise method of creating complex objects (data >> structures and pointers to them) made it possible to build >> good/interesting/understandable libraries from tried and true algorithms. >> With the introduction of ObjC/C++/Java and a huge new influx of programmers >> (the Internet may not have *created* new programmers, but it connected them >> to the rest of us in a way that was unprecedented), the number of libraries >> went up dramatically. With the Open Source movement, these accreted and >> evolved into some pretty interesting, trusted and useful libraries. Today, >> only a hardcore group like this crowd here are likely to >> rederive/redesign/rewrite/rehash. >> >> It is a dying art, which I am nostalgic about. It is one of the >> entertainments I find on this list. I liken what happens here (sometimes) >> to the WPA era when the very few remaining craftsmen in many building arts >> were found and encouraged/supported to building some last monuments to an >> old era of craftsmanship that no longer exists. >> >> Maybe huge systems built of handcut C (assembly?) code, implementing >> custom algorithms are not as obviously beautiful or elegant as some of the >> grand WPA era National Park resorts (Mt Hood, Grand Canyon Lodge, Yosemite, >> ...) but there is a similarity in the values and the processes. >> >> I respect Nick and others here for wanting to apply the same principles to >> the *context* of our various constructions as well. I don't always (even >> try to) follow the arguments but I appreciate the desire to (re)hash the >> hash, even if I don't always want to participate in it. >> >> - Steve >> >> >> ============================================================ >> FRIAM Applied Complexity Group listserv >> Meets Fridays 9a-11:30 at cafe at St. John's College >> lectures, archives, unsubscribe, maps at http://www.friam.org >> > > -- Doug Roberts [email protected] [email protected] 505-455-7333 - Office 505-670-8195 - Cell
============================================================ FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
