Slashdot Mirror
Thinking in Patterns: Download the First Version
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...
RUN "WEEKDAY"
Sleep, work, eat, game, sleep, work, eat, game......
RUN "WEEKEND"
Sleep, TV, eat, game, sleep, TV, eat, game.......
Use the third link in the story 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.
It would be nice if this was in HTML or some similar format instead of Word.
"It is a greater offense to steal men's labor, than their clothes"
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.
Oh you mean, perform an " " conversion..
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.
http://groups.google.com/groups?as_umsgid=mailman
Stupid job ads, weird spam, occasional insight at
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.
Move on. There's nothing to see here.
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).
668: Neighbour of the Beast
its 'thinking in python'. the 'thinking in patterns' book is a different link.
My blog: http://jkratz.dyndns.org/~jason/blog/
Just use it.
Please mod this post only if you think others should/n't read this. I have enough ego^H^H^Hkarma. Thanks!
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.
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. 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
"God fights on the side with the best artillery." - Napoleon, Marshal of France - speaking truth to power
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 !!!
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.
Excuse me, you don't know what you are talking about. In the US, most lumber comes precut, or precut and preassembled. All of it that is assembled onsite is assembled according to design criteria, known as "blueprints". This allows infinite monkeys (or bad carpenters) to piece homes together. You can think of patterns in carpentry as "bay windows" or "hip roofs" or "gables". No two exactly the same, but every carpenter knows them by name. Without this "lego" like approach with dimensioned lumber, and the "patterns" to found a common vocabulary among carpenters, most people would be living in tents, except for the few people that could afford the labor costs to fashion the lumber. Of course, applying the rules here on /., anyone that can't build their own house doesn't deserve to live in one. Hope your laptop is waterproof.
Reviews on The Assayer would be another nice way to give positive feedback if you like the books, and like the free-information approach!
Find free books.
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
Table-ized A.I.
- 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!