4 ms·

He'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 t

by 10ren 17y ago

He'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&#3...

mgreenbe 17y ago
Building 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 ago
  I 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.
godDLL 17y ago
I think you may be doing it backwards then. Trial-and-Error, or mental modelling were working out fine for me when I was just starting to learn how it all worked. But now it's down to critical and logical thinking processes. I don't build models until I know which actors in the system they represent. And I only do that because OOP is built to deal with this kind of system-building. I try not to fulfill the requirements but to require fulfillment; build, define the problem in the terms of a solution. That works for me. Sometimes you need to break down the problem into smaller problems to do that.
- 10ren 17y ago
  I'm really not following that - can you clarify please? I'm not sure which concepts your words refer to e.g. what is it in "how it all worked"? which models do you mean in "I don't build models until" (in the article, models are mental models, and it uses the term representations for their representation in code or notation.
  - godDLL 17y ago
    > …how it all worked… Refers to building systems in general. How do you build a solution to a problem? This is a skill, and it is learned and taught. > …don't build models… Refers to mental modelling, correct. I don't do that until I have broken the problem down into mentally tangible pieces, and then – only to accommodate for the particular tool that I'll be using – i.e a programming language/famework/hardware of this kind or another.
    - 10ren 17y ago
      Those terms were just examples. Anyway, thanks for having a go at clarifying.

by 10ren 17y ago

mgreenbe 17y ago

Building 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 ago
I 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.

godDLL 17y ago

I think you may be doing it backwards then. Trial-and-Error, or mental modelling were working out fine for me when I was just starting to learn how it all worked. But now it's down to critical and logical thinking processes. I don't build models until I know which actors in the system they represent. And I only do that because OOP is built to deal with this kind of system-building. I try not to fulfill the requirements but to require fulfillment; build, define the problem in the terms of a solution. That works for me. Sometimes you need to break down the problem into smaller problems to do that.

10ren 17y ago
I'm really not following that - can you clarify please? I'm not sure which concepts your words refer to e.g. what is it in "how it all worked"? which models do you mean in "I don't build models until" (in the article, models are mental models, and it uses the term representations for their representation in code or notation.
- godDLL 17y ago
  > …how it all worked… Refers to building systems in general. How do you build a solution to a problem? This is a skill, and it is learned and taught. > …don't build models… Refers to mental modelling, correct. I don't do that until I have broken the problem down into mentally tangible pieces, and then – only to accommodate for the particular tool that I'll be using – i.e a programming language/famework/hardware of this kind or another.
  - 10ren 17y ago
    Those terms were just examples. Anyway, thanks for having a go at clarifying.