Re^2: Programming is more than writing code, but it's *not* a science (design ~ code)

[tye]

I'd just like to add that this high degree of similarity between a sufficiently detailed design and a sufficiently factored implementation was not nearly so much the case those few decades ago when I started programming.

Languages and programming techniques have been moving toward allowing you to write a program by writing more design-like code while design techniques have been encompassing more of the details that are required when you write the code. There has also been more development of thorough methodologies that encompass both design and coding and these produce even more similarity in design and code when used.

When I've done design that really pushes my abilities, I've longed for a tool that would let me build the framework by typing up some quick class definitions, change panes to see a graphical representation of the resulting relationships, make some changes in that GUI pane, switch back to the first pane and see the classes reflecting the results of my mousing, and continue back and forth like that. I've used some tools that try to come close to that, but none of them did it well enough to be a big pay-off. I always ended up avoiding much of the "help", using them in a "less integrated" manner, and being a bit sad that they were still too awkward or ridgid or whatever such that they became more of a hinderance than a help when I tried to make full use of them.

Note that I agree with your final statement. Even if I had the perfect tool above, I'd only be using that for the design part of the coding. There'd be a line beyond which I'd then be coding and I'd stop using the design tool. Looking back, I'm a bit surprised to realize that C++ appears to me to have done a pretty good (but not perfect) job at effectively separating the design from the code where *.h is nearly all "design" and needn't contain hardly any "code" while *.cpp contains very little "design" (mostly just restatements of chunks of the design that is in the related *.h, and somewhat annoyingly verbose restatements at that).

I do wish C++ allowed the "private:" bits to not be specified in the *.h, however. I also found that enforcing some rules about the order in which you write the different parts of your C++ class definition made it much easier to see the "design" when looking at the *.h. And this all makes me realize that I've not noticed this design/implementation break nearly so much in other languages. And I'll end my musing there (bringing the topic somewhat back to Perl and even to Perl 6, if one is paying proper attention). :)