Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Thinking in Patterns: Download the First Version 82

Posted by jamie from the thought-provocation dept.
RichMeraz writes "Bruce Eckel has posted his first incarnation of Thinking in Patterns with Python on his website. What a wonderful Christmas present." Make sure to check the list of mirrors before downloading. As Eckel says, "This should whet your appetite to read Design Patterns " (or reread it)... classic book, I figure it can't hurt to refresh my memory once a year, and holidays seem like a good time to think in the abstract...
This discussion has been archived. No new comments can be posted.

Thinking in Patterns: Download the First Version More

Thinking in Patterns: Download the First Version

Comments Filter:

  • Use the third link in the story [mindview.net] if you just want to get the book. I didn't even see how to get there from the "first incarnation" link the story poster provided.

  • file formats (Score:1, Interesting)

    by Alien54 ( 180860 )
    One minor nit:

    It would be nice if this was in HTML or some similar format instead of Word.

  • Newsgroup (Score:5, Interesting)

    by javaaddikt ( 385701 ) on Wednesday December 26, 2001 @03:58PM (#2752796)
    If you've been reading c.l.python for the past month or so, you've been getting a bit of a preview to his work. He's been putting up little pieces of code which are pretty cool and getting advice from the roundtable.
  • I'll probably get slammed for this, but design patterns are not abstract in any good sense of the word. They are boilerplates that allow infinite monkeys (or bad programmers) to piece applications.

    It's like the difference between Legos and carpentry. Sure, it's a little harder to cut wood to the right length and you nails or screws to put it together, but would you want to live in a house made of legos?

    Learn what an algorithm is. Better, learn lots of algorithms. Don't just grab a bunch of patterns out of a bin and slap them together.

    • Re:Design Patterns are abstract? (Score:5, Funny)

      by AtaruMoroboshi ( 522293 ) <AnthonyNO@SPAMoverwhelmed.org> on Wednesday December 26, 2001 @04:09PM (#2752833) Homepage
      > It's like the difference between Legos and
      > carpentry. Sure, it's a little harder to cut
      > wood to the right length and you nails or
      > screws to put it together, but would you want
      > to live in a house made of legos?

      From this audience, I doubt you are going to get the answer you are looking for.

      .
      • OOP patterns are tedious physical representations of what would ordinarily be Boolean and/or relational formulas in procedural/relational paradigms.

        Relationships as formulas are easier to change and less disruptive of code structure (upon change) than physical class patterns. OOP patterns remind me of indexing files/tables by hand rather than telling the machine to do it. Or, sewing by hand rather than pushing a pattern button(s) on a sewing machine.

        P/r is more abstract and less primative in this sense.

        http://geocities.com/tablizer/prpats.htm

    • Re:Design Patterns are abstract? (Score:5, Informative)

      by mikewas ( 119762 ) <(wascher) (at) (gmail.com)> on Wednesday December 26, 2001 @04:25PM (#2752893) Homepage
      Patterns are a method of communication. A common language which allows you to say in just a few words what problem you are solving and how you will solve it. Yes, you still need a good algorithm, but that is an implementation detail and not what patterns are all about. They won't make a bad programmer a good one. It will let several programmers work together more effectively, and possibly make it easier to know what the bad programmer intended when you're stuck with fixing his code.

      My favorite example of a pattern, from the original "Design Patterns", is the porch. A porch is a transition between the inside spaces of a house & the outside. It should allow you to greet a person at the door, converse with him there, and decide whether or not you wish to allow him into the inner sanctum of your home. It should be at least 6 feet wide, to allow room for a few chairs, a table for a drink or book, and still allow somebody else to pass. It should be close to the street, but not so close that you are forced to be a part of the public street scene. It should have a low wall or divider so that you can be seated and hear what is happening on the street and be a part of it but still maintain your privacy to read a book or converse with friends. The wall should be low enough so that you can stand or move your chair by the wall, and from there see what is happenning, become a part of the public life on the street, greet a passer-by.

      Alexander spends several pages describing how a porch is to be used, what problems it solves, how it interacts with other patterns ... when an architect sees a client he can spend hours or days determining what sort of house they need to satisfy their needs, but when he returns to his office to converse with his coworkers he need only say "they need a porch" and everybody can get to work on the implementation.

    • Re:Design Patterns are abstract? (Score:5, Informative)

      by Junks Jerzey ( 54586 ) on Wednesday December 26, 2001 @04:29PM (#2752907)
      I'll probably get slammed for this, but design patterns are not abstract in any good sense of the word. They are boilerplates that allow infinite monkeys (or bad programmers) to piece applications.

      I tend to agree, though not for the same reasons. It a lot of ways, object-oriented programming has gone over the top, in that what would have been simple designs are turned into OO monsters that no one can understand. Patterns are a response to this. They provide a way of classifying and approaching problems in a structured OO way that keeps the programmer focused on the pattern and not on over-engineering a custom solution (spaghetti programming + OOP = ravioli programming). The obvious flaw here is that perhaps such a heavy reliance on OO-ness for *everything* isn't a good idea. After all, it's only certain groups of programmers that find themselves being sucked into the pattern dogma. Other programmers without strict OO hangups don't understand the reliance on patterns.

    • Learn algorithms *and* patterns (Score:4, Insightful)

      by PHAEDRU5 ( 213667 ) <instascreed.gmail@com> on Wednesday December 26, 2001 @04:37PM (#2752921) Homepage
      Most of what we do does not map to Dijkstra's Algorithm, or the Simplex Algorithm, or the Monte Carlo Method.

      Most of what we do is solve practical automation problems for people. You know, the kinds of problems that are never going to get the attention of hundreds of Ph.D. students, all intent on outdoing each other in terms of elegance and brilliance.

      Most automation problems get worked on by a series of programmers. There's the original developer, and after that person moves on to greener pa$ture$, maintenance staff. In a situation like that, if you can't say in the documentation that the original problem mapped to a certain well-known algorithm, the next best thing is to say that you implemented the algorithm using a set of patterns.

      If you do so, then you'll clearly communicate what was done, making it more likely that proper maintenance decisions are made (including, perhaps, the decision to replace the poorly thrown together patterns of the original implementation).

    • Re:Design Patterns are abstract? (Score:4, Interesting)

      by Greyfox ( 87712 ) on Wednesday December 26, 2001 @04:48PM (#2752947) Homepage Journal
      Design patterns alone are not a magic bullet any more than object oriented programming is, or flowcharting or any of the other advances in this industry that were hyped as the magic bullet.

      Nonetheless, programmers often have to solve very similar problems with very similar structures. Design patterns allow us to categorize those problems and structures in a very efficient way. Can they be abused? Absolutely. That doesn't mean you should dismiss the entire dicipline out of hand. I've also found that bad programmers are much less likely to be aware of patterns, as they don't tend to keep up with their profession as well as the good programmers do.

    • It's like the difference between Legos and carpentry. Sure, it's a little harder to cut wood to the right length and you nails or screws to put it together, but would you want to live in a house made of legos?

      Would you want to build a house by starting with a handful of acorns?

      Unless you write software by scribbling hex codes onto a legal pad, then entering them into the front panel of your box a byte at a time, you are probably taking advantage of quite a lot of pre-fab, pre-tested software artifacts that make your job easier. Like editors, compilers, operating systems, libraries, etc. Design patterns, like compilers, are another step toward automating the nitty-gritty details of a software development project. Nothing more. Like other tools, there are times when they're a great help and times when they're innappropriate.

      Why would you draw a line in the sand at any particular level of abstraction and say "Beyond this line lies the path to crummy code?" Crummy code was in plentiful supply when assembly was the language of choice, and it will continue to be in plentiful supply when Java sounds as modern as COBOL sounds now. The tools don't create or destroy crummy code - people do. And until we get the people out of the process (hold(mybreath)!=1), software quality will continue to run the gamut.
    • I'll probably get slammed for this, but design patterns are not abstract in any good sense of the word. They are boilerplates that allow infinite monkeys (or bad programmers) to piece applications. It's like the difference between Legos and carpentry. Sure, it's a little harder to cut wood to the right length and you nails or screws to put it together, but would you want to live in a house made of legos? I don't know how well you understand design patterns, but I've never heard anyone contend that design patterns were meant to be the meat of a program. They are simply tools to help you solve the parts of your problems that aren't new to the rest of the world. Why reinvent the wheel? I think in your analogy, design patterns would better be described as nails. You can build a house without them, but why waste the time?

    • Re:Design Patterns are abstract? (Score:4, Insightful)

      by WINSTANLEY ( 229048 ) on Wednesday December 26, 2001 @06:55PM (#2753310)
      It might be a more useful way to evaluate "patterns" by asking what it (they) allow good programmers to do.

      My background is that I had been using C++ for several years and even had a graduate level OO class (text was Booch) before I read the Design Patterns book. Though a fairly intelligent guy, perhaps I do solve problems a little slowly, but in any case DP was like pulling the scales off my eyes.
      DP provided thorough discussion and examples of how OO language features co1uld be put to good use. It answered the question, What is oo good for?

      Nowadays, I recommend to anyone learning C++ to read DP so that actually can understand the usefulness of OO languages.

      Many many programmers don't get exposed or trained in the way OO. STL code is one way they can get exposed to the possiblities of oo design (though the STL is probably a bit overwhelming and limited). The most popular oo framework, MFC, is written as though the implementers didn't (don't) understand oo and many of the people teaching C++ courses don't understand it either.

      Patterns seems to me the most effective way of teaching the possibilities for real-world problem solving with oo. IMHO, of course.
      • Many many programmers don't get exposed or trained in the way OO. STL code is one way they can get exposed to the possiblities of oo design (though the STL is probably a bit overwhelming and limited).

        STL has very little to do with OO design, there is little to nothing in the way of class heirarchy, and the polymorphism is largely static. STL is for the most part about generic and functional programming. I don't agree that it's "limited", but it certainly is "a bit overwhelming" (to put it mildly)

    • Re:Design Patterns are abstract? (Score:1, Funny)

      by Anonymous Coward
      Have you ever *seen* structures built out of the number of legos you would require to build a structurally solid house?


      We have some here at Legoland in the Mall of America. You'd need a sledgehammer to go through the models of the earth and the moon floating in the air. And judging by some of the quality buildings we have around here I bet some people *would* have preferred their builders would have used legos.

    • >It's like the difference between Legos and carpentry. Sure, it's a little harder to cut wood to the right length and you nails or screws to put it together, but would you want to live in a house made of legos?

      I'm passing out from the happiness induced by mere consideration of this idea...

      Oh, and you are wrong about Design Patterns. It's a great book that helps break old procedural patterns of design, and helps to define a set of OO concepts from which actual implimentations can be made. If you have people trying to impliment those patterns like monkeys, I don't think they understand... it's a book, it's a list of ideas.

      They also show how to write an OO parser, and say, don't do this. It's a book about thinking. About asking, how can this system use cooperating objects.

      AND: learn algorithms?!?!?! Talk about boilerplate solutions!

    • Better yet (Score:3, Informative)

      by CaptainSuperBoy ( 17170 )
      Learn what an algorithm is. Better, learn lots of algorithms. Don't just grab a bunch of patterns out of a bin and slap them together.

      Better yet - learn what makes a good algorithm, AND learn proper design patterns and best practices. Yes, you can think on your own while at the same time observing and learning from people who have had the same problems before you did. The authors of the book "Design Patterns" correctly observed that the same problems are being solved over and over again, and it would be helpful to come up with a list of elegant solutions.

      I do admit I've seen some poor programmers falling back on design patterns, and what you get is a bloated product thats functionality has been twisted so that patterns could be used. But the problem there is with people trying to force their problem to fit within a pattern.

      Plenty of people have had a programming problem similar to the one you are encountering now, and yes, some of them came up with a better solution than you did. A good programmer should be able to come up with his/her own algorithms, but recognize situations where other people have already done it better. Suppose a programmer dies today, and I have to come in and support his code. Personally I'd rather look at code that followed some established best practices, than code that was written by someone who felt he had to reinvent the wheel.

      Agreed, though, design patterns are certainly not abstract. They are merely directions on how to apply a decent solution to a problem.
    • It's like the difference between Legos and carpentry. Sure, it's a little harder to cut wood to the right length and you nails or screws to put it together, but would you want to live in a house made of legos?

      Learn what an algorithm is. Better, learn lots of algorithms. Don't just grab a bunch of patterns out of a bin and slap them together.

      But the truth is...
      There is a market and legitimate use for clipart.

      The same is true for code snippets (provided they are universally global calls or local OOP code unlikely to be duplicated by accident).

      The trick with clipart is having a user wise enough for them not to overuse it or accidentally imply the exact opposite of what the clipart is meaning to convey.

      The trick with code snippets is to make them universal like an #include library call or ungoofable internal code calls.

      The basic goal of both is to speed up making a workable product without requiring a genius or artist for the person trying to output useful and error-free results. I view a book like this in the same manner as "Numerical Recipes in C" or books of circuit diagrams. There will have to be a brain in the person hoping to use these, but they don't have to waste time reinventing the wheel (though there is nothing wrong with that).

  • Don't forget to buy a copy too (Score:5, Insightful)

    by 2Bits ( 167227 ) on Wednesday December 26, 2001 @04:23PM (#2752880)
    Bruce Eckel has put his very well written books for download. That's very nice of him. For those of you who can afford, don't forget to buy a copy too, just to show your support/appreciation. I've bought a copy of "Thinking in Java", even though I've never opened the hard copy book. I end up giving it to my brother-in-law.
  • Via Google:

    http://groups.google.com/groups?as_umsgid=mailman. 1009338389.32160.python-list@python.org [google.com]

    Just under the wire, I've manage to post the first early alpha version (0.1) of "Thinking in Python."

    Please note:

    1) This is not an introductory book. I couldn't bring myself to write yet another introductory language tutorial, and there are already plenty of good ones out there. This is "Design Patterns in Python," so I can use any language features or advanced techniques that I want, without apology (hooray!).

    2) This is an early translation of "Thinking in Patterns," so parts of it have not yet been translated. I've tried to mark those chapters, but please be patient.

    The source code is in the download package. When you unzip everything (remember to use the -a flag with unzip if you're on Unix), the code will be put into subdirectories for each chapter.

    In addition, this book debuts my new 'BackTalk' comment collection system that I built in Zope.

  • Clarification (Score:4, Informative)

    by alacqua ( 535697 ) on Wednesday December 26, 2001 @04:32PM (#2752912) Homepage
    While I agree that "Thinking in Patterns with Python" might be a better name, the text is actually titled "Thinking in Python" with the subtitle "Design Patterns and Problem-Solving Techniques".

    From the preface, it appears to be a port of "Thinking in Patterns with Java" to Python, with the hope of completing the Python version and then porting it back to Java. He (Bruce Eckel) makes clear that this is not a Python tutorial.

    You can get the complete explanation from the horse's mouth, but I figure it'll be slashdotted soon.
  • its 'thinking in python'. the 'thinking in patterns' book is a different link.

  • Aspect oriented programming (Score:3, Interesting)

    by Anonymous Coward on Wednesday December 26, 2001 @05:28PM (#2753081)

    I've been using the "patterns" as described in books such as the gang-of-4 one for some years, but I'm not actually happy with the whole thing. Beyond all the hype on patterns, it doesn't seem to deliver the level of reusability and abstraction it is supposed to handle (you may say it's my fault as a software designer, but I'm sure the paradigm lacks something - it's definitely not incrementally productive for large scale projects).

    It seems that the Aspect Oriented Programming paradigm is getting more attention because people is beginning to suffer with the bloat these patterns cause when used per se. There are some good AOP implementations for Java (AspectJ and Hyper/J), and one for Python (Transwarp, which is quite well engineered, although I couldn't make it work..). I strongly suggest that you take a serious look at AOP if you are a serious software designer.

    • I've been using the "patterns" as described in books such as the gang-of-4 one for some years, but I'm not actually happy with the whole thing. Beyond all the hype on patterns, it doesn't seem to deliver the level of reusability and abstraction it is supposed to handle

      The problem is that patterns are not really a new thing, they are a way of expressing tried and true software design concepts. Patterns are not going to radically change the world (because they're not a new thing), but having someone bother to write down advanced programming techniques does make it easier for programmers to learn about software design.

  • Patterns and Usefulness (Score:3, Interesting)

    by spiritualmechanic ( 546268 ) on Wednesday December 26, 2001 @06:09PM (#2753192)
    It seems to me that patterns, while occasionally useful, are especially useful in a specific domain. Lately a lot of the Java server-side design is accruing patterns that maximize Java and J2EE. While the standard patterns are always there, Singleton, Command, MVC, etc., it helps Java developers know where to expect to put a piece of code. Obviously this is most useful for web-based projects (I'm not so sure about a giant project that some people have mentioned above), but the J2EE Patterns do a pretty good job of ensuring that there's not a ton of code that's duplicated, and that cut/pasting is minimized. Even the Core PHP book has a section on patterns, so I think they're useful for any language. Also, while I appreciate patterns, I try not to design too much on the front end (beyond functional requirements) because it's really only after implementing a solution that you figure out where you can refactor your code. The nice thing about patterns is that you can take them or leave them, and use them as you find them useful. Obviously, patterns are especially useful when most/all of your developers are familiar with the basics and can recognize them. That way you can use abstraction together, and when you document "This is a singleton" people will know what you mean, as well as how it's implemented in a particular language. Theoretically patterns should reduce the amount of surprise in a development project. Although if it's incorrectly implemented, and someone documents "this is pattern x" then that's when the real debugging starts. ;-)

  • Bruse Eckel's books are some of the best resources for delving into the world of programming witout having a CS background. "Thinking In Java" was my first introductionto Java and his writing made it very approachable.

    Then I discovered his website [mindview.net]. What a treasure trove. Updated book releases and drafts of future publications. I've even downloaded a few of his recorded seminars. Great stuff and all of it free. I gues he figures he'll havea better product when it hitsa the street and maybe a few more customers if their appetites have been whetted by the drafts.

    I may not be the best programmer, but reading Bruce Eckel's writing helped me kake up my mind to change my profession to programming. Nother is better than a teacher that loves what he's teaching

    • Agreed. his Thinking in C++ book really helped me to grok C++ when I was trying to learn it in school. much better than the textbooks we were using.
  • Here is the problem with design patterns. Once upon a time, people would read the AT&T UNIX and BSD Kernels in order to get ideas for how to write programs well. In order to be a good programmer, you would invariably find a better programmer and then read all his stuff. It was in this way that you found cool programming concoctions, such as this :

    #define _CONCAT(X,Y) X/**/Y

    I'll list three more examples to make the point clear. On the Xerox STAR workstation, the BITBLT instruction was used to perform database range queries - e.g. give me all the servers in the network that support file serving.

    As a second example, the MESA signal facility was used during the expansion of mailing distribution lists to detect circular expansions (e.g., raise a "Have_I_Seen_This_One_Before?" signal, go up the stack looking for matches on the signal arg, if there is no match, fall through the signal handler and continue the recursive expansion).

    A fourth example is the way that the "C" switch statement is the ideal construct for parsing command-line arguments in a UNIX shell command.

    Now in the object-oriented world, people do not want to be bothered with the problem of reading others code, or thinking for themselves, so they go for these trendy "design patterns" books where other people do the heavy lifting or simply make up garbage to see if it will sell. This lets the average or below-average programmer off the hook and relieves them of the burden of forming their own opinions and developing their own tastes in programming.

    This is evil in it purest form. It is the an example of the same laziness that has us receiving 95% opinion and 5% in every news story reported today. This laziness have moved outside the news room and is invading software engineering.

    We're all dumber as a result of this trend !!!

    • I think you're missing the point of OO.

      It frees the programmer from having to worry about creating their own 'style' or learn how to do tricky CONCAT's, database queries, etc. If I'm not worrying about bits and trivial programming tasks that have been solved many times over (usually better than I could solve them), then I can more easily approach complex problems. I'm not thinking less, I'm thinking differently.

      The time I save by never having to think about x.concat(y) is spent learning even more design patterns and OO API's. In short, I become a better, more versed programmer because I do not have to stare at other ppl's code.

    • Now in the object-oriented world, people do not want to be bothered with the problem of reading others code, or thinking for themselves, so they go for these trendy "design patterns" books where other people do the heavy lifting or simply make up garbage to see if it will sell.

      This is not true at all. The whole point of studying design patterns is to study someone else's tried-and-true solution to a software design problem. It is not a substitute for forming ones own opinions. It's a tool for forming informed opinions as opposed to spouting ill-founded nonsense like your average slashdotter.

      • The fact is that, unfortunately, in many cases, design patterns are percieved as a substitute for forming ones own opinions.
        I mean, it's not the goal, but many programmers just use them saying it's God on Earth, without trying to have their own opinion. Why ? Many (bad) reasons, the main being : because that way "the next programmer who will read the code will understand straight: you just have to say 'this code follow the Observer pattern', and he will understand everything straightforward". NOOOOO !!! Code is understandable because it is written clearly (good indentation, and stuff), with good specs, docs and everything (javadoc is far more useful for the programmer than design patterns if u want my opinion).
        So, theoretically, u're right. Practically, unfortunately, u're far from always right (((((((((((
    • I think a lot of people on here are missing the point of design patterns. Patterns are not a replacement for *algorithms*, they are tools, or better yet, a common language, to describe how objects relate to each other and their basic purposes.

      The porch example above, you will notice, says nothing of how to construct the porch, merely how it relates to the house and the people. It is not meant as a replacement for a skilled carpenter who knows how to create a porch that can withstand the weight needed or how to pour the foundation so that it lasts 30 or 50 years.

      So the fact that a contractor or architect can use the language "they need a porch" has very little bearing on the quality of the implementation of that porch. Of course, when building systems, if you can say "he needs a porch (or a factory, etc), you don't need to spend days or weeks figuring out what a porch does, and you can actually focus on how you will implement this porch.

      The fact that you are using an example in C doesn't help your argument. Nothing stops an OO programmer from reading others' code to see implementations of algorithms OR patterns. I don't know where the comment "...in the object-oriented world, people do not want to be bothered with the problem of reading others code, or thinking for themselves.." is coming from but that has certainly not been my experience with programmers in the OO world.
    • I think the problem here is that you're missing the DESIGN part of "Design Patterns".

      You shouldn't be reading code to figure out design. You shouldn't be writing code yet either. That's what the DESIGN phase is all about: you have to figure out the way you're going to solve a problem at an abstract level.

      Design Patterns, like almost every design tool, says nothing about implementation. They don't even say anything about what algorithms will be used in the implementation, that's a lower level of abstraction you also have to deal with.

      If I remember correctly, "Design Patterns"'s authors spent a great deal of time trying to make that clear.

      When you're finally implementing the design you may and probably should go and read all the code you want to learn little implementation tricks as you're implementing your algorithms. That's an EVEN LOWER level of abstraction.

      Maybe it would be nice to have a vocabulary for the sintax patterns you use in a particular language, such as the ones you mention. "Hacking patterns"?

      But if you're confusing that with software design, then you are sorely mistaken.

  • The book is not good for patterns. (Score:1, Interesting)

    by Anonymous Coward
    Unfortunately, I have to say that while Bruce Eckel has done a great job with the book, his presentation about patterns leaves few things to be desired. The main problem is that he has completely forgot what made the Design Patterns books so great. Every pattern in GoF has been described in the same format. The pattern format is always the same and includes the following sections:
    • Name
    • Intent
    • Motivation
    • Applicability
    • Participants
    • Collaborations
    • Consequences
    • Implementation
    • Sample Code
    • Known Uses
    • Related Patterns
    Unfortunately, in Bruce Eckel's work, all this structure is completely missing. This minor flaw makes it not a pattern book. The book is decreased from a pattern book to just a normal textbook!

Slashdot Top Deals

To the systems programmer, users and applications serve only to provide a test load.

Close