Summary:
Ward Cunningham talks with Bill Venners about using the programming language, rather than the whiteboard, to design and communicate ideas.
The ability to add new comments in this discussion is temporarily disabled.
Most recent reply: February 15, 2004 1:16 PM by
todd
|
Thanks for the replies and patience.
The new installment goes a long way to answering my question.
I guess that the extra effort needed to implement Smalltalk purely as recursive objects comes under the heading of 'complexity that is empowering,' like the learning the new branch of mathematics in order to reach a 10 page proof.
|
|
|
>I separate the how from the what. Customers, performance >requirements, GUI requirements, size requirements are all >part of 'what'. 'how' is where XP techniques make the >implementation of all these things faster and more >effective.
Exactly what I was trying to say, but more clearly! Thank you.
|
|
|
I think of a language designer as a special case in which the same person can be both the client and the programmer. He would also have "two hats", and he would not wear them at the same time.
When the designer is wearing the client's hat, he's thinking globally, ahead of time. He has to have a clear vision of his "business problems", the language he wants to make. Then, he could create stories for implementation.
Whether or not to make everything an object becomes a "business" decision which should make sense within the overall vision of the new language. It is not a "programmer's" decision, and therefore it doesn't have to be "the simplest thing that works".
Then, wearing the programmer's hat he could tackle the stories, following XP's rules. He would naturally find out that some of his ideas (as a client) may not be as good as he thought initially. He would have to switch hats to modify his inital vision, but this would be more like a business requirement change, not necessarily a programmer's problem.
|
|
|
>To worry about tomorrow is to detract from your work today.
This is almost like a play with words and logic. *Thinking* about tomorrow (or the future) is not the same as *worrying* about tomorrow. One is clearly a negative view of it.
>Time you spend thinking about tomorrow is time you're not >spending thinking about what to do today.
Well, that's ok, because you saved time yesterday when you thought about today! :-) It's just like instruction pipelining!
It just sounds like a play with words for not having to plan for the future. People are lazy by their nature, but sometimes it's good to do some work now to avoid making work in the future, but as with all things, having a balanced view is better than being extreme in any direction. (There was a mentioning of Zen, think of Ying/Yang) Being extreme is easy, you don't need to balance...
>There's something about syntax that makes it very precise >for reading. I love photography. A photograph will tell a >story. But words tell a story even better. Words are more >versatile. You can paint a verbal picture that's much >richer than you can photograph.
Syntax is the grammar, structure, or order of the elements in a language statement. What do you mean by saying it makes it very precise for reading?
Ward, you draw very strange conclusions about words and pictures. How can you say that words are more versatile, for whom are words more versataile? Words and pictures will tell different storys for different people, words in particular mean very different things to different people depending on culture etc, but pictures on the other hand usually can communicate feelings across cultures. It's interesting that you use words to 'paint'! This probably means that you internally create pictures when you read words, and will experience this as telling the story better as you get to chose the pictures!
>Grandma Moses didn't paint that way.
Well, first of all we don't know what Grandma Moses paintings looked like! And if you draw the parallel to puzzles. Try assembling a puzzle without know what the final picture will look like!
I'm not against XP, I think there are many good things to learn from it. Still I get the feeling it is better applied without the 'extreme' part of it and what it really wants to convey is the 'get dirty and get the work done' idea.
|
|
|
Speed. I can think and scribble at a high level much faster than i can code. If i am wrong so what. In XP you are always wrong because the next user story changes whatever your did before, so being wrong isn't a problem.
Complexity. Let's discuss our clustering system by writing code. Don't think so.
Appropriate level of abstraction. Code is at one level abstraction. Instead of following simple rules why not use your judgement about what will work best for what you are trying to discuss. Sometimes that is code. Sometimes it is not. The code only is like being shown your DNA instead of an xray of your broken bone.
|
|