6 ms·
A Different Look at Software Design
- mlLK 17y agoHis 3 step iteration for the 'Essence of Design' reminded me of WikiWikiWeb's 3 step iteration for HowToLearn [http://c2.com/cgi/wiki?HowToLearn http://c2.com/cgi/wiki?HowToLearn] They're strikingly similar except the language for learning is far more abstract and generalized.
- anonymousDan 17y agoDoes anyone have any idea what the difference between a 'model' and a 'representation' is with regards to this article? They seem to emphasize the importance of using the former instead of the latter, but I have no clear model(!) of the distinction between the two..
- 10ren 17y agoHis full term is "representations of design", and he uses it previously in the following ways: Languages aren’t design; they’re representations for writing down the design once we get it. Quit thinking of external representations as what design is all about, and focus on mental process. By representations of design, he means something more concrete and less fluid than mental models. Even mathematical notation is less fluid than mental models, because they presuppose the terms of reference, which is a solidification of a model, which makes it harder to even visualize the problem in other terms. BTW: lisp is more fluid than java, but less fluid than mental models.
- omouse 17y agoRepresentations are different ways of looking at the model. Let's say you have a book. The ideas are the model and they can be adapted into various representations such as the book, a magazine excerpt, a movie, a musical, etc. I think he means that the people who have trouble with design are those who focus on solving the problem that the representation demonstrates rather than solving the underlying problem (which is in the form of the model). So the solutions are specific and brittle rather than general and adaptable. Or something like that...
- 10ren 17y agoHe's saying design is trial-and-error, but it helps to have an approximately right model to start from. It seems to me that mathematics could lead us directly to the right model without mistakes... or is the truth that the same trial-and-error still occurs, but just in more abstract and general terms? Does that seem right to the mathematicians here? ... the nature of design, as they discovered, is so intensely cognitive, happening inside the mind at mind speed, the researchers could conceive of no useful tools to help in that process! This is exactly my experience. The closest is diagrams with pen-and-paper, but it doesn't help that much. The more difficult part is not solving the problem, but showing that you've solved it i.e. a proof, for all possible cases. Finding a proof of a solution is as much work (if not more) than finding the solution in the first place. It is by logic we prove, it is by intuition that we invent - Henri Poincaré The article is talking about consciously formulated conjectures, not about instantaneous insight, discussed here: p.62 of Intuition in science and mathematics: http://books.google.com/books?id=qqGWlEwWj5UC&pg=PA62&lpg=PA62&dq=anticipatory+intuitions&source=bl&hl=en&sa=X&oi=book_result&ct=result&resnum=5#PPA62,M1 http://books.google.com/books?id=qqGWlEwWj5UC&pg=PA62...
- mgreenbe 17y agoBuilding a mathematical model is also a process of trial and error. Which definitions are necessary? What are the invariants of the structures you build, and how must those structures interact? Particularly when modeling CS structures, mathematics feels like programming (to me). This makes particular sense when you reason about CS structures using constructive logic -- then it is programming.
- 10ren 17y agoI think programs that are proofs (as in COQ) is a cool idea. It seems economical, in that you get two things (a program and a proof) for the price of one. However, my experience is that adding extra constraints to a problem makes it harder and more complex to solve, whereas separating out different aspects (divide&conquer) makes it easier. Jack of all trades/serving two masters etc. That is, you'll write better code if that's all you're doing; and you'll write a better proof if that's your sole purpose. "To hit a bird on the wing your whole mind must be on that bird..." etc. Ironically, the power I personally find in a mathematical approach is that you can freely separate out constraints in any way you like, regardless of usability or performance, in order to show some quality clearly. Combining the proof with code pushes in the opposite direction - and for me, when it's at the max complexity, this pushes it over the threshold. I still think it's cool though, perhaps mostly because it provides an automatic test of theorems.