On Sat, Feb 21, 2009 at 9:52 AM, Jared Rypka-Hauer <[email protected]> wrote: > Behind every successful programmer is a huge library of books he > hasn't looked at in years.
Hey, stop looking in my office! (I have bookcases full of great computing books that I'm embarrassed to admin I have mostly not read at all, let alone in years... these days, they're there for when I get stuck and need a fresh perspective) I started do OOP in 1992 using C++. All of my early code sucked. Over time it sucked less. I started doing Java in 1997. I've worked in a variety of OO languages over the years and each new language has taught me new ways to approach problems which is why I highly recommend learning additional languages - that are very different from your day-to-day language(s). Learn Smalltalk, learn Prolog, learn Haskell. You'll probably never use them in your day job but you'll learn great new techniques. Of those, only Smalltalk is OO - Prolog is declarative, Haskell is functional - but all three will change the way you think about problems. After 17 years of OOP, I'm still improving my design skills and try to "learn something new every day". It's a journey, not just a destination. On UML, I agree with Alan: use UML to sketch out ideas but don't try to use it to specify your code. Activity diagrams are by far the most important type to learn and use, more so than Class diagrams. Collaboration diagrams (aka Communication diagrams) are also very important if you're intent on going down the UML route. I've used UML on and off for a long, long time. In fact I started with OOSE (Ivar Jacobson) and the Booch method (Grady Booch) before they joined forces with James Rumbaugh (originator of OMT) to collaborate on what became UML. OOSE was very focused on Use Cases which helped me focus on high-level specifications rather than digging into class-level stuff too quickly. I've worked on projects that use UML very formally and they were hard work - for the same reason that trying to use Z to specify a system is hard work: when it comes down to details, code is much easier to write than a specification of that code. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
