Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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 n

    --
    J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
    • 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
      • 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.

        --
        J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers