In 1991 Ungar and Smith wrote about the experimental programming language SELF, and in it described duck typing, calling it behaviorism. I found an early example of Duck Typing in “SELF: The Power of Simplicity” by David Ungar and Randall B. Smith. It’s from 1991. Is this the earliest example of duck typing? Behaviorism. In many object languages, objects are passive; an object is what it is. In SELF, an object is what it does. Since variable access is the same as message passing, ordinary passive objects can be regarded merely as methods that always return themselves. For example, consider the number 17. In Smalltalk, the number 17 represents a particular (immutable) state. In SELF, the number 17 is just an object that returns itself and behaves a certain way with respect to arithmetic. The only way to know an object is by its actions. ...

The great benefit of knowing the command-line is being able to write scripts to analyze scripts, all in ~1 minute. Add to your .bash_profile. # get list of objects and functions in a python file alias python_structure="perl -ne'print if /\\b(?>!:)(class|def)\\s/'"

How I write CSS. I follow the rule of only having one parent. It’s just enough hierarchical information to tell me where an element should be used. But it doesn’t create a large and fragile hierarchy. (And all hierarchies become fragile once the code is in maintenance mode.) It’s easy to create a base style for an element, while still being able to modify it slightly for specific places. It does the above two while minimizing the number of classes needed on a particular element. For simple websites, an element should only need one, damn class. My goal in One Parent CSS is not just to create good CSS, but to avoid a few patterns I hate. ...

I hand-crafted the CSS for the site. It’s still a work in progress. I learned that while semantic tags are good for HTML, they’re not that great for CSS. The great HTML5 semantic tags like section, article, header, and footer may be great for crawlers, and nice when you’re reading the HTML, but when I tried to rely on them exclusively for CSS it just resulted in confusing markup. The “article > footer” question When you’re reading CSS, what do you think article > footer {...} means? ...

After a lifetime of programming and compsci education, I’ve had some issues learning with Python. It screws me up in small ways. It’s a wonderful language, but dear god I wish these things were different. Missing the ++ operator. Missing foo.push. I’ve spent my whole life being trained to use push() on lists, and now it’s just not there. This breaks a deeply-ingrained typing habit. Seemingly random things are not object-oriented. Like len(foo) instead of foo.len(). Or type(foo) instead of something like foo._type(). I don’t know why tuples are needed. Not having to worry (too deeply) about immutable strings is one of the glories of modern programming languages. So why does Python need to use immutable arrays? I’d guess the answer is “optimization”, but that doesn’t seem to gel with the fact that we aren’t managing immutable strings. Ridiculously minor issues: I have to modify two things to change import foo to from foo import bar. I wish I could just append text onto the end, like import foo specifically bar. Vi has made me lazy like that.

When I first read the gang of four’s Design Patterns I dismissed most of it as a coverup for the unfortunate parts of C++’s object design. That was definitely unfair, since the strongest benefits of Design Patterns come from managing huge code bases, a fact that I missed with all the small examples. But even still, I would love a book on design patterns that is built for modern interpreted languages, with duck-typing and no type checking.

font-feature-settings is a great CSS feature to play with, but it should probably be turned off in code blocks. With Markdown and highlight.js, that means adding this little piece of CSS to your stylesheet. pre, code { font-feature-settings: normal; }

The greatest problem in learning object oriented design is in the toy problems. The object oriented solution never looks better than the regular solution. I recently read Head First Design Patterns and redid every pattern in that book in Python. You can see my results at https://github.com/jmcguire/learning/tree/master/design_patterns. Look at the original files and the new files. The new files are always longer, and never easier to grok. The real problem is that the benefits of Object Oriented Design don’t show themselves until you are past toy problems and dealing with real-world applications, but those applications won’t fit in a book or in a paper. ...

Learn the right way to write a program the wrong way In my last post I reviewed a paper by David Parnas. In it he talks about the right way and the wrong way to decompose a program. I’d like to show off how I like to do things, which is the wrong way. It’s a good skill to have, but one that a lot of beginners on Stack Overflow don’t know. ...

This paper is considered seminal in Object Oriented Design, but Parnas never mentions objects, and his example program is described in procedural programming terms. The lessons in this paper are applicable to all programming methodologies. It’s just about smart design decisions. Good programming design grew a major root in 1972 with “On the Criteria To Be Used in Decomposing Systems into Modules” by David Parnas. How do you build a big program? You have to break it down into smaller programs, obviously, but that leaves the also-obvious question how do you choose those smaller programs? David Parnas looks at a silly little program called The KWIC Index Production System to demonstrate two different answers to this question. ...