Wiggins d Anconia writes: > > > > please let's do a split(/\s/, "Perl Programmer"). > > > > this return one array with two scalar: > > Perl > > Programmer > > > > that's why > > > > Back to semantics, define "Programmer". Your definition of programmer, > if it requires any knowledge of UML, is so strict that it will not work > in 99% of circles where the term is thrown around *today*. Admittedly I > have very little knowledge of UML, but my employer seems very happy with > my abilities as a "programmer", and from what little I have seen and > read around the subject UML is a colossal waste of time on any "real" > programming project.
UML does not help you program; it helps you design. UML is a diagramming tool to help you think about the relationships between verious things that could make up a system. It is a way to view the big picture. Typical UML shows the relationships and data flow between many computers and many programs and the data flowing between them all. That does indeed turn out to be pretty useless when you are trying to code an optimal loop to perform efficiently inside one of those programs. When people abuse UML to the point of trying to express line-by-line details of a single program in UML, they need to be slapped! I do not write UML, but I can read it, and use the diagrams to discuss how a system design might be improved. It has proved very helpful to me on the few projects where the chief architect has used it properly. I come from the "old school", having written my first program in 1967. I use any informal diagramming technique that helps me visualize and think about the problem at hand. This helps me a lot, but sometimes other people do not understand what I mean in these ad hoc diagrams. UML is an attempt to standardize the diagramming conventions to achieve protability among system architects. I remember having to throw out the idea of classical flow charts when I started writing context switching code for operating system internals in 1973. The classical flow chart could not capture the idea of parallelism. Of course, that was back in the "good old days", when I had 8K 16 bit words of real magnetic core memory and a 2.5 microsecond cycle time -- translates to 32 KB main memory and 0.4 MHz on a 16 bit machine,and everything was coded in assembler. The smallest machine I ever programmed was 1 KB or ROM and 64 bytes of RAM; that was for a robotic tool that worked inside of a sewer pipe in 1982. Today I work on little PC's that have half a terabyte of disk, several gigabytes of RAM, and run at several GHz. They are networked together and function as a single system. In the words of Sun, "The network *IS* the computer!" Hardware guys make progress much easier than software guys. As we encounter new problems, we find that we need new tools to think about them. UML is a pretty good "formal" tool right now, but don't ever think that is is the end-all. I still like my informal diagrams for brainstorming. The formalizers can convert them into UML for the system documentation. They need to, as I will probably be long gone (I am a consultant) before some maintenence programmer read the docs when trying to fix some nasty bug. He needs to be able to understand the diagrams too, so formalization is necessary for portability between people who never get to communicate with each other any other way. -- -------- "And there came a writing to him from Elijah" [2Ch 21:12] -------- R. J. Brown III [EMAIL PROTECTED] http://www.elilabs.com/~rj voice 847 543-4060 Elijah Laboratories Inc. 457 Signal Lane, Grayslake IL 60030 fax 847 543-4061 ----- M o d e l i n g t h e M e t h o d s o f t h e M i n d ------ -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
