On 12/03/2010, at 9:46 AM, Andrey Fedorov wrote: > Chris Gahan wrote: > Or your goal could be "this program should have a response time of less than > 0.5 seconds". > > Again, much better to be expressed as code. Remember, after all, that code is > simply unambiguous text which a computer can interpret. This seems like a > good rule to put along-side your unit tests, for example. > > I see one of the goals of STEPS as explicitly *removing* the need to write > down your intentions twice (once in readable and again in interpretable form). >
SO rather than "the code is the goal" what you mean is "write your goals in code". This is great, but code should be easy enough to understand that anyone can read it... like, say, an even "easier" and better version of Cucumber. Do that kind of binding, and I see there being no difference between writing down the goals in these two ways. http://cukes.info/ What disappoints me about Cucumber is that, along with most things I see these days, it doesn't really address "scale". Some descriptions need to be very BIG PICTURE, and others need to be more about intimate detail. It'd be good to have some kind of system which respected this. One of my fundamental issues with Smalltalk, Self, Cocoa, in fact almost every coding system I've ever used is that they don't promote self-discovery in terms of context. For instance, in Smalltalk it's very easy to traverse a tree of learning based around inspecting objects, but there's rarely any indication of "where one is" when one is trolling through detailed code browsers and namespace trees. Or at least, the "where one is" sucks. It's great for showing the class system (hence class browser) but what'd be really interesting is an Object browser in the same way that Self works... except that neither of these two promote learning about the system and coding in and of themselves. The two things that strike me here seem to be that information hiding is useful at some scales (ie big picture) and at other scales it's bad (ie intimate detail)... there need to be more than these two scales that we can look at, too. At its biggest picture, the goals of a system should be evident (ie we need a scale browser to promote learning in a system) The goal of the computer part of a system is usually to do the bidding of its owners. As you go into more detail from this "biggest picture", there come about a number of "programs"... So probably the first goal of this system needs to be to discover what the goals of its users/owners are... Now here, the interesting thing for me is that programs are less about performing specific tasks and goals, and more about doing certain activities. For example, a word processor isn't solely about writing a letter, but it can be used as this... so at a "next detailed level", the goals of the user need to be written down (this includes the goals of a programmer when they are using the system to do programming)... so these goals need a system to organise themselves... so the first "program" that is required is part of a system to organise the goals of the user (and therefore the system)... if one of the most important goals of the user is to write a letter by a certain time, then the system needs to provide an environment that facilitates this as easily as possible - involving both discovery of tools (ie availing the user of how to use the system in the same way that computer games do...) and also in terms of allowing the system to be expanded when it becomes apparent that the system doesn't have facility to do what the user wants to do when writing this letter (for example, perhaps the user wants to be able to make their words go up and down in a curve in a particular part of the letter... part of this issue is that they don't know what's possible as a user and a part of the issue is that if we put the ability to program ANYTHING easily within their reach, they'll IMAGINE what's possible and do things that a systems programmer hasn't envisaged. This is truly awesome. As Self and Smalltalk have tried to point out to us, make programming SO EASY that it is the SAME THING as using the computer. At any scale, it should be easy to be able to see the goals the people who own the system themselves have along with the context of those goals, and also the programs that correspond to these goals that are running at any point... for example, one of the goals might be to stay connected to one's friends and family, and also to remain open to new communications from new people... email performs a part of this goal... and it would actually be that checking email would be connected up as a sub-goal of this goal... The thing about tasks I perform day to day using my computer system is that I often use a suite of THE SAME PROGRAMS to drive towards different projects goals... for example, I'll use a programmer's editor to work on three different projects, all of which are driven by different goals. In two of those projects, I may need to compile programs, and in the other, I may need to interpret programs. In the third, I may also need to heavily refer to documentation on how to use javascript or HTML or some other technology... my point is that these projects vary in subtle and sometimes not-so-subtle ways and in their requirements on the computer. The goals dictate these requirements. When I'm writing a letter to my mother, I know I won't need a spellchecker or the ability to run code, or even change the colour of the text. I may need to include some media... maybe photos or something like that. This is a context I'd call "informal letter"... now this requirement probably won't change much, and I can use it for sending a letter to any of my family... If I was writing a formal letter, I'd probably need a spellchecker and grammar checker... because of the requirements stipulated by my goals... In sending communications to my friends, perhaps one of the primary goals is that the messages get there as quickly as possible out of all of the communication methods we have at our disposal... and so it goes on and on... Our current computers don't really address this at all. They suck. Julian
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
