Lambda the Ultimate

Hi guys,

I would like to share with you a silly experience that happened over the weekend that got me thinking about object orientation/classification and how it affects, (and was affected by) the different ways in how individuals classify and manage bits of information or real objects in the world around themselves.

I recently bought a painting for my girl-friend's lounge, but I didn't get a chance to put it up for her over the weekend, so she got her father to come around to do it for her. He brough along his toolbox (he sells professional tools (Snap-on, KingTony, etc) for a living, so he's a DIY type through and through). Something came up however just as he was about to put the painting up, so he just neatened everything up and left the tools there for me to use.

The art gallery I bought the painting from, kindly and conveniently included a number of frobbitzim, such as hooks, masonry nails, wood screws for the frame, string, etc, all in a little plastic bag.

So last night I get a chance to put the painting up, and lo and behold, the plastic bag with all the goodies is nowhere to be found.

Aggravated, and cursing and muttering, I strip-search the apartment, including her father's toolbox, and the baggie is still nowhere to be found. So Iresort to looking in the trash. There it is, the plastic bag. But empty. And the goodies are not in the trash along with it.

So I go take a close look at the toolbox. My g/f's father decided that, as part of the neatening up, the frobnitses needed sorting as well. His toolbox includes one of those organiser things on the side, so he put the the screws along with their little friends in the screw compartment, the masonry nails along with the existing nails in the nails compartment, and the hooks in the 'misc' compartment, and so on. The string defied classification so it ended up in the bottom of the toolbox. The baggie itself ended up in the trash because it didn't have a purpose anymore.

So here I am aaarghing away, scratching through all the compartments to find MY frobbnitzes, all the while muttering under my breath: why?....why?....why oh why oh why?

All of this was perfectly acceptable to my girlfriend as well, who obviously thinks exactly like her father. To them, it's perfectly logical to classify and group things according to type, instead of according to function. To my way of thinking, the plastic bag was a perfect object that encapsulated all of its members, and the whole's purpose was OBJECT_TYPE_FOR_ERECTING_PAINTING, so leave it be, darnit!

To me it doesn't matter that a screw is of type TScrew, what was important to me was that I had a number of different types that belonged together as a functional whole, grouped according to one singular purpose. The object-oriented programmer in me was screaming inwardly at what I thought to be a very illogical thing to do, but obviously the difference is in human perspective and way of information classification.

I wonder now if OOP is not hard for some programmers to grasp simply because intuitivly they classify information according to type instead of function, and because they think in terms of data pools that are manipulated using functions or operators.

After doing C++ for years, with some Java/C# here and there, I've gotten around to doing some web development and have started playing around with Javascript. With the recent Ajax and "web 2.0" hype, Javascript seems to be getting more attention.

I've been curious about Prototype based Object-oriented languages for a little while now, but have never used one extensively as modern, widely-used implementations (except for Javascript) seem to be rather scarce. Slate seems to be still in development though. Here is a LtU discussion that concentrated on memory concerns and here is a paper on Self.

What are others thoughts on OOPLs. Is the added flexibility that proponents argue needed to be looked at more? What are the pitfalls and advantages? Do languages like Ruby "fake" it well enough? I'd be particularly interested in the psychological criticism given in this (google cache)paper, as well as this paper.

(via Keith)

Io is small, pure object oriented, prototype-based programming language. The ideas in Io are mostly inspired by Smalltalk (all values are objects), Self, NewtonScript and Act1 (prototype-based differential inheritance, actors and futures for concurrency), LISP (code is a runtime inspectable/modifiable tree) and Lua (small, embeddable).

The paper and slides are available here.

Microsoft's PDC videos are online, including some that are of interest to us.

Paul Vick directs us to three presentations: (1) the future of VB; (2) Dynamic languages on the CLR; (3) LINQ.

Note: You need to use IE to view these presentations.

See here for some examples/demos from Microsoft.

The papers presented at the International Workshop on Software Factories (held at OOPSLA 2005) are avialable online as well.

The Role of Type Equality in Meta-Programming (Emir Pasalic)

Meta-programming, writing programs that write other programs, involves two kinds of languages. The meta-language is the language in which meta-programs, which construct or manipulate other programs, are written. The object-language is the language of programs being manipulated.
We study a class of meta-language features that are used to write meta-programs that are statically guaranteed to maintain semantic invariants of object-language programs, such as typing and scoping. We use type equality in the type system of the meta-language to check and enforce these invariants. Our main contribution is the illustration of the utility of type equality in typed functional meta-programming. In particular, we encode and capture judgments about many important language features using type equality.
Finally, we show how type equality is incorporated as a feature of the type system of a practical functional
meta-programming language.

An interesting investigation by Emir Pasalic into meta programming and its relation to both dependent typing and multi-stage programming, among which an exposé of the development of Omega (see also: Tim Sheard ).

From this Wired article:

In 1976, computer pioneer Edsger W. Dijstra made an observation that would prove uncanny: "Program testing can be quite effective for showing the presence of bugs," he wrote in an essay, "but is hopelessly inadequate for showing their absence."

Thirty tears later, Dijsta's words have the ring of prophecy. Companies like Microsoft and Oracle, along with open-source projects like Mozilla and Linux, have all instituted rigorous and extensive testing programs, but bugs just keep slipping through. Last month, Microsoft's monthly drop of bug patches included fixes for 14 security holes that escaped prerelease testing, four of them rated "critical."

There's a bit to chew on here, including the by-now-de rigeur misidentification of Java, Python, and Perl as "type-safe languages." But I think the article is valuable in spite of that for its frank admission that even intense testing regimes aren't doing well at addressing serious quality issues. Daniel Jackson, leader of the Alloy project at MIT, is quoted.