John Cotton Dana

I'm writing this on August 19, 2014. John Cotton Dana was born on August 19, 1856 in Woodstock, Vermont. I looked him up after I came across this snappy graphic on the Web:

I was surprised to learn the extent that he had influenced my life.

http://en.wikipedia.org/wiki/John_Cotton_Dana

Wikipedia says he died in New Jersey on July 21, 1929. I did find another web page that says he died in Manhattan, not New Jersey, so once again we see that Wikipedia is not a definitive source, even if it is darn informative.

So how did this long dead person influence me? Well, for starters, in 1909, he founded the Newark Museum. I grew up in Union, NJ, about 9 miles by car from Newark Museum. My Mom would take me there for an easy day trip when we had nothing specific to do. I particularly enjoyed the science and technology exhibit of simple machines. I haven't been there in many years now and surely there has been turn-over of the exhibits, if nothing else, to make up for mechanical wear and tear.

Besides founding that museum, John Cotton Dana also was a librarian. I think my favorite line from the Wikipedia article was this:

He would have found a library school curriculum intolerable, and doubtless a library school would have found him intolerable.

Before John Cotton Dana, libraries tended to have closed stacks. A librarian would go fetch the book that you wanted to look at. Dana pioneered the radical concept of open stacks. The main library of the Rutger's-Newark campus is named after him. I'll leave it to you to forage around the Internet or your favorite local library to learn more about this man. Hey! At least read through the Wikipedia article, please.

Not all of his point of view would be accepted today. For example, Wikipedia says that he organized the first ever children's library room, but he believed its proper role was to help provide material to teachers. He was opposed to "story-time" at the library.

If you have kids, remember John Cotton Dana today by taking them to your local children's library, where I wager, you will find open stacks for easy browsing of the book collection. Even if you don't have kids, today would be a good day to make sure you know where your library card is. (You do have a library card for your local public library, don't you?) Make sure your card is up to date. If not, renew it, and use it.

Speaking of children's libraries, here in Westbury, NY, the founding of the local children's library pre-dates the establishment of the local public library for adults. The 2 only joined together since 1965. History of Westbury Children's Library

Revised 08/19/2014 to correct a wretched typo: Dana was born in 1856, not 1956!

Revised 09/22/2020 to put the missing graphic back into the page.

Getting more familiar with Python Classes and Objects.

If you've been following this blog, you're aware that I feel unprepared to make good use of the Object Oriented Programming facilities of the Python programming language. Python is kind enough to allow programming in non-OOP styles, but Python's OOP features keep glaring at me, reminding me of what I don't comfortably know.

I posted a question on Quora.com asking for real world examples of multiple inheritance being used in Python programs. I was disappointed about how few answers came back. That dearth of response left me with the suspicion that I'm not the only person around who isn't completely comfortable with multiple inheritance. http://www.quora.com/What-is-a-real-world-example-of-the-use-of-multiple-inheritance-in-Python. Looking around at other multiple inheritance questions on Quora (http://www.quora.com/Why-is-there-multiple-inheritance-in-C++-but-not-in-Java), I see some reason to suspect that super serious application of OOP is just going to need more time to sink into the heads of the majority of developers. So, I'll continue to watch and learn, but will try to remember to adhere to the KISS principle to the greatest extent possible.

Additional Lessons

1. This 40 minute video from Ray Hettinger (The Art of Subclassing) explains how Python classes differ from classes in other languages. Ray tries to reshape people's thinking here, so if you aren't already deeply steeped in OOP lore, you may feel he's dwelling on the obvious. He may give you some ideas of appropriate uses of inheritance in Python objects.

   
   

2. Ray mentions this 2nd talk in his video. This 2nd talk was the next talk after his at Pycon 2012. "Stop Writing Classes", Jack Diederich, 28 minutes. Basically, that video asserts that my own example so far of writing a class for a Python program is not very good. The clue: My example class had only __init__ and one other method. I could have written it as a simple function and used the partial function from the library functools module to handle the initialization.

Further Reading

I have 3 previous blog articles on OOP in Python.

In Creeping up on OOP in Python - Part 1 I described a use of an object-oriented library module, pyparsing, to solve a Project Euler problem.

In Creeping up on OOP in Python - Part 2 I reworked my solution to add a simple class of my own. I was happy that introducing that class made the code cleaner to read. But if you watched the "Stop Writing Classes" video given up above in this blog article, you'll probably notice that my class is an example of exactly what they say you shouldn't do.What can I say? I'm still learning this stuff.

The 3rd in my Creeping up on OOP in Python" series was a bit different from the first 2. It explored an academic question about multiple inheritance. It is exactly the kind of A, B, C example that Ray mentions avoiding in his talk. Creeping up on OOP in Python - Part 3. I haven't forgotten my promise of a Part 4 as soon as I have a practical example of multiple inheritance to substitute for A, B, C and D in that academic question. But so far, there is no Part 4.

Ray mentions "the gang of 4". If you aren't familiar with them, here's a reference for you to pursue: http://en.wikipedia.org/wiki/Design_Patterns. And he mentions "Uncle Bob". I also mentioned Uncle Bob, with some links here: SOLID software design.

Know more about this OOP stuff then I do? Well, don't keep the info to yourself. Please post a comment with a link or example to help me learn more. Have you found a particularly relevant MOOC that you'd suggest?

TED Talk for Mature Audiences - Dismal Science, Disappointing Careers

For many years now, Economics has been known as the "dismal science". So, who better than a (Canadian) economist to deliver a 15 minute TED talk on "Why You Will Fail to Have a Great Career". TED talks, in general, are upbeat talks and this one, despite it having a somewhat cynical tone to it, really does have an upbeat message in there. I do worry in pointing out the talk that it requires a certain amount of maturity to hear the real message. The message an immature audience just might receive from this talk could be extremely negative. You've been warned! So, if you think you have the maturity to find the constructive up-lifting message in his talk, give a listen to Larry Smith of U. of Waterloo on why you will fail to have a great career.

The talk mentions the 2005 Stanford Commencement Address by the late Steve Jobs. If you haven't given that one a listen, I urge you to spend the 22 minutes that it'll take to play that one for yourself too.

you don't have to agree with the speakers in these video talks. If you have an opinion on what you've heard here, you're invited to leave a comment down below. I'm looking forward to hearing from you. And, of course, if you know someone who might benefit from giving a listen to either or both of these videos, please pass along the link to this blog article.

Python and Parallel Processing

(Image taken from http://www.ibm.com/support/knowledgecenter/SSEPGG_9.5.0/com.ibm.db2.luw.admin.partition.doc/doc/c0004569.html without explicit permission, but with acknowledgement of the source of the work).

I've written about Parallel Processing here before. e.g. See "What's the fuss about Parallel Processing?". I've been worried by my reading that seems to predict that imperative languages such as Python will never be able to safely cope with massively multi-processor architectures in the future. The "Downfall of Imperative Programming Languages" basically says that functional programming languages (such as Haskell and Erlang) are going to be the way of the future. I've been trying to get my head wrapped around Haskell, but so far without much success. So I was happy to hear a clear call from the Python camp that "I'm not dead yet!".

The article that gives me new hope is "Parallelism in One Line" the gist of which is that "Sure you can use the threading library to manage pools of threads (or of processes), but that takes a lot of lines of code and is very error prone, but there's another way to do it." The other way to do it is to use a parallel version of the map function. I, for one, didn't know that there's more than one version of "map" available in the Python library.

If you do a Google search for:

Python map

you will readily find documentation for Python's standard (iterative) map routine. e.g. "Python 2.7.8 builtin functions documentation - map".

If you readily want to find documentation of the parallel version of map that the Parallelism in One Line article talks about, you need to modify your Google search to:

Python map multithreaded

which will take you to a subset of the first search. I was amused to find among the search results a 2010 ActiveState Recipe for building your own "concurrent map" function, which drew a comment from one reader asking why not just use "multiprocessing Pool.map". The recipe's author admitted not knowing about that one.

From that 2nd search I found "Multiprocessing - process based threading documentation". It does worry me that the documentation seems to have more complexity and gotchas than the Parallelism in One line article owed up to. Arguably I shouldn't be blogging about this at all until I've actually given it a try myself (but I still don't have a multi-core processor here at home).

It's a trick?

If you've been reading this carefully, you might rightfully object that it's all a bit of a trick. The map function is an element lifted from the world of functional programming and then provided in Python. The parallel version is only safe in Python if the function that you are mapping is "pure". If the function code has side-effects, then you will have race conditions and potentially suffer horribly at the hands of multi-cores. The language isn't going to inherently protect you so you have to be careful out there.

If you want to read more about the challenges of Python vs. multi-core architectures, see "Python's Hardest Problem, Revisited", by Jeff Knupp. The piece parts to roll your own multi-processes or multi-threaded Python program remain available, but be sure you have plenty of iodine and bandages on hand if you cavalierly venture into the world of multi-cores in a language that makes no promises of (much) concurrent processing safety. Design your code carefully and watch out!