RSS
Obviously I’m doing more development right now than I would have expected. But in the long term I want to move beyond hacking to survive for the present, and write some code that’s sustainable. So I think I want to read a design patterns book. The last one I read was 15 years ago and I don’t really have much retention of it. I’m particularly interested in stuff geared toward Python (the language I’m starting to get comfortable in right now).
Readers with recommendations are invited to weigh in. I know I have a fair number of software engineers in the readership, so I’m asking for your thoughts and suggestions. Perhaps the classic from the GoF is still the way to go? Remember, I’m not a software engineering who works on scientific data, I’m a scientists who sometimes needs to do a little engineering and data analysis.
Note: Sean, if you take this as an opportunity to leave a long-winded comment about sexual selection and blond women, again, I’m going to have to finally ban you!
English
Arabic
Chinese (Simplified)
Dutch
French
German
Hebrew
Hindi
Italian
Japanese
Korean
Persian
Polish
Portuguese
Russian
Spanish
Swedish
Turkish
Vietnamese
The patterns in the GoF book are to some extent a workaround for limitations of the type systems of the popular languages of that era. Perhaps for that reason, the idea of software design patterns itself is less prominent than it used to be.
For instance, Java and C++ of the time did not support anonymous inline function literals, or lambdas. Almost all languages support this now, and this simplifies certain tasks sufficiently that you no longer need a pattern like Visitor. Many years ago Peter Norvig of Google had a presentation showing how many GoF patterns were superfluous in lisp.
That’s not to say that there are not still design patterns in use everywhere but I think they’re simpler, or taken for granted, and not often written about as such.
Also, one uses quite different patterns for building a GUI app, versus a high traffic server app backed by a database, versus ad-hoc data analysis at a prompt. Can you say a bit more about what sort of code you’re writing?
One good book on on design patterns is Domain-Driven Design by Evans. It is unusually thoughtful and clear.
I agree with Alexis (though to satisfy your curiosity you could probably get that book cheap, used).
But since you’re writing Python, how about:
Python in Practice: Create Better Programs Using Concurrency, Libraries, and Patterns by
Mark Summerfield
or:
Effective Python: 59 Specific Ways to Write Better Python by Brett Slatkin
I own both but haven’t but dipped into them – my memory is that Effective is good practices – discipline, which maybe you’re after, and ‘.. in Practice’ is more, cool things to do with the language. But actually they’re both kind of advanced, show you powerful features, and help you write better code.
If you can, look over them both before buying, but my guess is that if you get just one, the ‘Effective’ one is what you’re looking for.
I wouldn’t worry so much about object-oriented design patterns, especially if you are not collaborating with a large team or writing huge projects.
What I recommend reading is, for maintainability:
http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html
Get and use the pep8 code style checker as a way train yourself to write properly formatted code.
Create or find a variable naming standard you like and stick to it.
Use long descriptive variable names rather than cryptic ones. You should know what a variable contains from the name.
Get and use a revision control system like Subversion or Git. This will let you see and revert code changes.
Learn and use the Python unittest framework to build testing into your code.
Finally (and this is not the least important) Google for Python anti-patterns. Those are the things that people commonly do that seem like a good idea but you probably shouldn’t do. It’s a way to learn the lessons others have learned through trial and error without making the mistakes yourself.
What I’d suggest instead of design patterns is learning how to eliminate duplication using refactoring. Some form of test driven development would help. That has a refactoring step built into the code and test loop. Experience with getting really serious about eliminating duplication is that a lot of the basic design patterns simply emerge, quite naturally, as you chase down and destroy duplication.
It’s hard to give advice without knowing your current level. I agree with others that basic best practices, such as “use named constants instead of literals”, should come before patterns. If you are past that, patterns are still useful, but again agree with Alexis that early books like GoF would have to be “translated” into the modern idiom for Python and other modern languages. This is not always trivial. Python-specific books listed by gronk would give you a much smoother entry into higher-level design.
you will probably find it very useful to adopt functional programming techniques, even if you don’t adopt an actual functional programming language as your go-to analytical tool.
As others have written, ignore the (dull) GoF and design pattern books in general. By and large prefer keeping your code short, clear and easy to modify to keeping it general and abstract. Applied computing is still in the pseudo-engineering phase, so I don’t think you will find a tome that sets down sound principles you can (mostly) unquestioningly follow.
Instead I’ll offer two somewhat arbitrary recommendations:
1. Look at hypothesis for testing your python code (http://hypothesis.works/)
2. Read some lucid python code, written by a master. Peter Norvig is great.
You could start by having a look at some of his jupyter (formerly known as ipython) notebooks (http://norvig.com/ipython/README.html) and other python essays (e.g. http://norvig.com/spell-correct.html).
If you don’t mind learning Common Lisp (the book contains a fast paced intro) and looking at outdated classical AI code, have a look at Paradigms of AI Programming. It’s probably still the best programming book I’ve ever seen. Not only is the code elegant and concise, he doesn’t present the finished thing immediately but goes through several steps of debugging and refining it.
Norvig has also written about design patterns, BTW:
http://norvig.com/design-patterns/
RK:
Are you taking up Python because of a limitation or lack of functionality in Perl? (I have some vague memory of you mentioning Perl as one of your tools.)
Also, have you noticed superior or inferior performance with Python relative to Perl? Perl was my preferred analytical and parsing tool when I wanted good performance, but did not want to write C.
Good luck with your new tool. Can’t ever have enough.
I could never drink the various schools of programming ideology koolaid.
Designing good code is hard. People shy away from this. I design, implement, and then redesign and redesign again. Throwing away thousands of line of code is difficult.
Casey Muratori’s essay, Working on The Witness, Part 11, about semantic compression is good.
Configuring your editor with a linter like pyflakes helps a lot.
+1 for the recommendation about programming in a functional style. The “Boundaries” talk by Gary Bernhardt is quite good. The approach of concentrating business logic in data-in data-out functions separate from IO code makes an enormous range of programming problems tractable. Writing in ML-family languages (Haskell, Elm, OCaml) has really beat this into my head and made me a better programmer.
https://twitter.com/garybernhardt/status/616327747435036672
Lol love it! I too used to worry about patterns and shit but in reality good style, best practices, separation of concerns, and avoiding side-effects (functional programming) gets you 99% there.
I was a programmer and I fell for the patterns hype. GoF was one of the first programming books that I bought. Alexis is completely right about what patterns are: ways to work around missing features in a language.
Before fighting your tool you should learn to work with it. Each programming language reflects the mindset of its creator. It suggests a certain way to program. The best way to understand that mindset is to read the book by its creator. For C++ that means reading the The C++ Programming Language by Bjarne Stroustrup. For C you have K&R. For Python…? After getting to really know your language then you can start trying to work around it.
So I guess in the olden days you would then pull out a pattern book to find a pattern to adapt to whatever problem you were facing. However it just makes more sense to look for help on stackoverflow.com.
I agree with Sion.
I’ve worked with professional software developers and also with scientists who need to write software but don’t know best practices.
What the scientists are usually missing is not fancy-pants patterns. It’s basic hygiene:
– choosing descriptive names
– comments
– removing unneeded dependencies between parts of the code base
– using version control
– writing functions in a functional style (no side effects) whenever possible
– being aware of tools besides the one that everyone in your department uses
This last point is a tricky one. There’s a very strong argument for using what everyone around you is using, which is that you can ask them for help. To be honest, this should probably be the deciding factor.
But annoyingly this probably reads to a worse choice of technology as judged by actual merits. For instance, I worked with many physicists who used C completely by default.
But I’ve often wondered if an ML-derived language like ocaml would be a more comfortable conceptual fit for someone coming from the mathematical sciences. F# supposedly has an excellent REPL. And Mathematica has very good graphing primitives, which is invaluable for ad-hoc interactive data analysis.
But the safe choice of going with what your colleagues use is probably the best one.
I do think that languages from the ML side (originally a language meant do program "proof tactics" in the LCF theorem prover) have all the benefits going for them: Strongly and statically typed, functional, undergirded more by Philosophy and less Ad-Hoc-ery.
Personally I also like LISPlike languages, but the lack of typing always makes me edgy.
Razib. You may need to write a new article about male/female strength. Now it is claimed young millennial men have 20% less grip strength than their father’s generation. And it’s even claimed women aged 30-34 have as much grip strength as the men. https://www.washingtonpost.com/news/wonk/wp/2016/08/15/todays-men-are-nowhere-near-as-strong-as-their-dads-were-researchers-say/
I've worked with professional software developers and also with scientists who need to write software but don't know best practices.
What the scientists are usually missing is not fancy-pants patterns. It's basic hygiene:
- choosing descriptive names
- comments
- removing unneeded dependencies between parts of the code base
- using version control
- writing functions in a functional style (no side effects) whenever possible
- being aware of tools besides the one that everyone in your department uses
This last point is a tricky one. There's a very strong argument for using what everyone around you is using, which is that you can ask them for help. To be honest, this should probably be the deciding factor.
But annoyingly this probably reads to a worse choice of technology as judged by actual merits. For instance, I worked with many physicists who used C completely by default.
But I've often wondered if an ML-derived language like ocaml would be a more comfortable conceptual fit for someone coming from the mathematical sciences. F# supposedly has an excellent REPL. And Mathematica has very good graphing primitives, which is invaluable for ad-hoc interactive data analysis.
But the safe choice of going with what your colleagues use is probably the best one.Replies: @El Dato
But I’ve often wondered if an ML-derived language like ocaml would be a more comfortable conceptual fit for someone coming from the mathematical sciences. F# supposedly has an excellent REPL. And Mathematica has very good graphing primitives, which is invaluable for ad-hoc interactive data analysis.
I do think that languages from the ML side (originally a language meant do program “proof tactics” in the LCF theorem prover) have all the benefits going for them: Strongly and statically typed, functional, undergirded more by Philosophy and less Ad-Hoc-ery.
Personally I also like LISPlike languages, but the lack of typing always makes me edgy.
I can’t say too much about patterns books, but I thought I would just say that I remember a big change in my methods when first starting programming with Python.
I was trying to use lists for all kinds of things, like comparing lots of genomic data. As soon as I realized I could instead find ways to use sets for all the big operations, and then re-sort the data at the very end, the programs went from running for many hours to running in a few seconds.
Big surprise, my comment didn’t get approved.
You are a goddamn phony.
Unblock @Chateauemissary and @MrDickHollywood immediately and stop being a pussy in general.
[you’re a dumb animal -razib]
For instance, Java and C++ of the time did not support anonymous inline function literals, or lambdas. Almost all languages support this now, and this simplifies certain tasks sufficiently that you no longer need a pattern like Visitor. Many years ago Peter Norvig of Google had a presentation showing how many GoF patterns were superfluous in lisp.
That's not to say that there are not still design patterns in use everywhere but I think they're simpler, or taken for granted, and not often written about as such.
Also, one uses quite different patterns for building a GUI app, versus a high traffic server app backed by a database, versus ad-hoc data analysis at a prompt. Can you say a bit more about what sort of code you're writing?
One good book on on design patterns is Domain-Driven Design by Evans. It is unusually thoughtful and clear.Replies: @Douglas Knight
FWIW, Java came out after the book, so it can’t be responding to the even greater limitations of Java, only those of C++.
Not a design pattern book per se. But the best book I’ve ever read on software design is Robert Martin’s Clean Code. The examples are mostly in Java, but it’s by no means Java specific. If anything the philosophy is even more in line with the Zen of Python.