Perl is great at code generation, I says.
I've determined that I'm going to try and be methodical about drawing diagrams better. Start simple, know what you're trying to say, don't be afraid to wad up the paper and start again.
I've also determined that I'm going to try and cook more often. (I cook far more than my wife.) Having pizza should be an admission of defeat! Yesterday I made a spinach paneer except with tofu instead of the cheese normally used. Very good, and this time I didn't make it bitingly spicy. Tonight was burritos with garbanzo beans whipped up in the food processor with the usual spices and thrown in with some sauteed onions, ginger and red peppers. Add to that some pressed yogurt (forgot to get sour cream) in a tortilla with usual trimmings and you've got yum!
Bugged the DBD::InterBase list about not being able to open two statements on a single handle. This throws a monkey wrench into previously mentioned plans unless I implement that plan to filter security in SPOPS using a join rather than serially...
Every software engineering course/text I've had preaches the "picture is worth 1000 words" principle. I believe it, but I've never had a course or a book teach me anything useful about diagramming. We've got wonderful standards like UML and such, but I can't use them because the examples always teach me how to use UML to define an elevator or a zoo instead of how to define a program. I've learned three to five diagramming standards that I cannot use at work because while I can read the diagrams, I have no clue how to use the diagramming conventions to represent even the simplest one-off tool programs I write.
Re:The problem with diagrams
james on 2002-04-30T08:26:59
I've learned three to five diagramming standards that I cannot use at work because while I can read the diagrams, I have no clue how to use the diagramming conventions to represent even the simplest one-off tool programs I write.
This is one of the problems with current diagramming techniques IMO. They actually work somewhat in reverse. More complicated programs are more easily represented than less complicated ones. Whereas a one-off tool would probably not have more than a class or two (and more-often none at all) and has a low degree of headspace-to-knowledge requirements (ie, the amount of headspace you need to know what the program does and how it is designed) larger pieces of software have far more classes and interactions, and therefore a higher degree headspace-to-knowledge is needed. In the former case there is far less benefit to any design or documentation[0].
Software design using UML is just as hard as software design without it - you need to be able to identify core classes early on. One of the most important things that UML has given software people is a (more) formalized vocabulary when talking about software.
[0] I'm not saying there is no benefit, just far, far less
Re:The problem with diagrams
jdavidb on 2002-04-30T14:06:04
To rephrase, I've learned three to five diagramming standards that I cannot use at work because I have no clue how to use the diagramming conventions to represent even the simplest one-off tool programs I write, let alone a large program. The problem is I don't know how to use these diagramming conventions to represent a program. I know how to use them to represent a giraffe or an elevator or an automobile. In the book you see an example like this, in class the professor goes over the same example, then they turn you lose with a programming assignment to try it out on and grade you down for not producing a proper (or even useful) diagrammed design.
Then you get out in industry and found out how much you really need this kind of skill and so you buy yourself a book -- where they teach you how to represent an elevator with UML. I'm tempted sometimes to think that some of the bright minds in the UML world are just full of it and have never written a line of code in their lives. This isn't limited to UML; we used a structured programming diagramming convention in my first software engineering class, and I had the same problem.
Re:The problem with diagrams
lachoy on 2002-04-30T12:25:41
I agree entirely about not being taught diagramming. It's something that is just assumed you can pick up by osmosis. Maybe it's just that most people can pick up up with the Carnegie Hall principle ("practice, practice, practice!"). I have a bad tendency to read books I should be using as a workbook -- for instance UML Distilled is said to be an excellent introduction. I've found UML to be verbose, but there are probably shortcuts, and I don't think there's a requirement (enforced by the UML Cops) that you use all of it...
Back to learning: maybe you need that "aha!" moment to get this sort of thing to stick. I remember working with relational databases for the first time and flailing around for a bit until I understood what a join was. Then everything made sense.
Re:The problem with diagrams
james on 2002-04-30T16:43:17
I agree entirely about not being taught diagramming
Me too, for that matter.
I've found UML to be verbose, but there are probably shortcuts, and I don't think there's a requirement (enforced by the UML Cops) that you use all of it...
I never use all of it. Just enough to do just-enough-design. For me its being able to dump the structures you have to build up in your head into offline storage quickly, without having to write code to do it. And of course its nice when someone says "how does that work?" to be able to give them a reletively straight forward design.
