Visiting Python and Smalltalk

Something that I continually pester people about, after working on a message passing system in my very first big Java project, the switch statement is not OO, "The switch statement has all sorts of problems with cohesion and coupling. The irony today is that almost all OO languages today, other than Python and Smalltalk (in which it can easily be implemented), still have switch statements."

Also, OO - the Solution to the Problem of Switch Statements which links to Replacing Conditional with Polymorphism.

Beware the Chrysanthemum Men

Can Corporations Stop Doing Evil? "Aggressive and competitive tendencies assisted our ancestors to survive. That's why they are there. Effective channeling, not avoidance, seems necessary. We can do that with diversion ("Yay! The Steelers won! Woo hoo!") or direction (such as the very existence of the Special Forces and the CIA), but we had better not ignore it."

This posting reminded me of a few things that I had intended to blog but hadn't.

Are we designed for violence? "Anyone doubting that treating other people as more than instruments is founded in the brain would do well to look into developments in the study of self–other mapping. This has provided stronger and stronger evidence that these relationships are hardwired into us, strikingly with the discovery of mirror neurons that fire in the same way for events that occur to you or to those you observe (Gallese and Goldman 1998). Many argue that empathy is an outcome of these representations (see e.g. Frith and Frith 1999). And recent research demonstrates appreciating someone else's pain activates many of the same areas as experiencing it (Jackson, Meltzoff, & Decety 2004): good evidence for a VIM [Violence Inhibition Mechanism] -like mechanism, and certainly a rebuttal to those who think our withdrawal from violence is unnatural...We are not innately disposed to violence, or even indifferent to violence, we are neurologically bound away from violence. This understanding gives us a solid basis for treatment, and an honest beginning from which to address the continuing problem of violence in society."

Mirror neurons seems to be a theory that is reinforcing the idea of memes but also changing it slightly.

A NY Times article has more details (PDF) including the effect this might have on children: "Mirror neurons work best in real life, when people are face to face. Virtual reality and videos are shadowy substitutes...a study in the January 2006 issue of Media Psychology found that when children watched violent television programs, mirror neurons, as well as several brain regions involved in aggression were activated, increasing the probability that the children would behave violently."

This idea also has influenced other areas of research including: language, freedom of speech and autism.

Also, related is The Milgram experiment (as mentioned in "Enron: The Smartest Guys in the Room") and an interview last year with Peter Cundall showing that the capacity to do evil is everywhere:
"ANDREW DENTON: How do you break a human being down to a point of amorality?

PETER CUNDALL: By giving them power. By giving them absolute power over people. I suppose I see, today, the biggest problem in society is what we call the "control freaks". These are the malignant narcissists, right. The people who are - and we've met them. Look, you can go to a tiny organisation, a school parents and friends, a trades union, ABC, we know who the control freaks - it's true, we know them, we know who they are and they want - that's right.

ANDREW DENTON: We've just been cut off.

PETER CUNDALL: But they're people without a gone conscience and without any pity, and there is not many of them. But when you and I are fast asleep at night, they're lying awake, scheming, and they're hard to compete with, and I'm not joking. You know - anybody that's worked in an office or anything, there is always someone that wants to take control, right. The supreme example, of course, is people like Stalin and Hitler. Hitler, don't forget, almost his last days, when he was in the bunker, he was saying at one time that, "The SS have betrayed me," because they retreated, and he had all his commanders executed. And almost his last words was, "The German people have betrayed me," you know. I mean - and this is an example of a supreme form of pathological narcissism and you do get it. You get it in politics. They're the people who can't admit that they have made a mistake.

ANDREW DENTON: Do you get it in gardening?

PETER CUNDALL: Absolutely. You get it in gardens and in gardening, right. You get somebody - mainly with blokes. Blokes and women are totally different gardeners. Blokes are single-minded, right. So you get these dahlia men, right - really, it's true - and they compete with each other, or the cactus men and they compete, right, and the chrysanthemum men."

Build One to Throw Away

BenchMark-0.9.5 "Here are some Benchmark results between Wine and Windows XP, Your mileage will vary depending on your Linux config, Wine version and Hardware...Wine has the current lead on 67 tests"

Via, "Is Wine really faster than Windows?".

The Best Code is Shared Code

Code Reviews: Just Do It (but really just a quote from Steve McConnell) "...software testing alone has limited effectiveness -- the average defect detection rate is only 25 percent for unit testing, 35 percent for function testing, and 45 percent for integration testing. In contrast, the average effectiveness of design and code inspections are 55 and 60 percent."

This is found in "Chapter 21: Collaborative Construction" of the 2nd edition of "Code Complete". Furthermore, he goes on to say that "The cost of full-up pair programming is probably higher than the cost of solo development - on the order of 10-25 percent higher - but the reduction in development time appears to be on the order of 45 percent..." The defect detection rate, stated in the book, is listed as 40-60%.

It also includes some tips for successful pair programming: coding standards, active, frequently rotated pairs, a good pairing environment, etc. Of course, he seems to think that pair programming involves one keyboard, one mouse and one monitor - which doesn't seem like a very good environment at all.

The hard data section contains lots of references to the benefits of early detection of defects, which are also mentioned in a paper, "Planning to Get the Most Out of Inspection". Similarly, "Testing is one of the Least Effective Defect Removal Techniques".

From a recent XP meeting.

On the Other Hand

A collection of posts that seem contrary to my current point of view but which I find myself agreeing with none the less:

• Instead of autoboxing in Java being confusing, inconsistent and clunky it's useful and concise.
• Instead of Java being dead because of its strong typing people are increasingly picking more strongly typed languages and Perl is being replaced by Ruby.
• Instead of test driving making creating procedural/data driven code and to avoid any test artifacts, test driving leads to more OO code and methods for testing should be left in (although I would've thrown an IllegalArgumentException not a NPE).
• Instead of everyone becoming a librarian, librarians and semantic web developers are excluding many means of shared understanding.

Gnarly Client Code

Firebug "FireBug is a new tool for Firefox that aids with debugging Javascript, DHTML, and Ajax. It is like a combination of the Javascript Console, DOM Inspector, and a command line Javascript interpreter."

Includes the ever important "printfire" to send debug messages to the console.

Related to, December Java Users Group talk on AJAX.

A Post from the Future

Folktologies -- Beyond the Folksonomy vs. Ontology Distinction "One point that Clay makes, which I think is very interesting, is his view that perhaps the world is moving from a graph-theory information model (ontologies) to a set-theory model (folksonomies) -- but in fact, under the surface this argument falls apart. OWL is nothing other than a language for enabling extremely sophisticated set-theoretic operations on information. In fact, if you actually look at the OWL language itself, it is primarily comprised of set-theoretic statements."

"Ontologies are, in my opinion, simply the next evolution of database schemas. Surely, Clay would not argue that database schemas have no place in the world!"

"Imagine a folksonomy combined with an ontology -- a "folktology." In a folktology, users could instantly propose or modify ontological classes and properties in the same manner that they do with tags in tagging systems. The most popular ontological constructs (the most-instantiated classes, or slots on classes, for example) would "rise to the top" and self-amplify, while the less-instantiated ones would "fall to the bottom" over time. In this way an emergent, self-organizing, and self-pruning ontology could emerge within a community."

Via, Folktologies -- Beyond the Folksonomy vs. Ontology Distinction.

Mocking Correctly

A really great posting, "Best and Worst Practices for Mock Objects" lists a number of best practices for mocking.

• "Be careful about mocking or stubbing any interface that is outside your own codebase. If you don’t truly understand the semantics and proper usage of an interface you don’t have any business mocking that interface in a unit test. My best advice is to create your own interface to wrap the interaction with the external API classes."
• "My advice is to just test the data access code against the actual database with integration tests. For the most part I think testing persistence code without the database is a complete waste of time."
• "I’ve worked with some people before that felt that there should never be more than 1-2 mock objects involved in any single unit test. I wouldn’t make a hard and fast rule on the limit, but anything more than 2 or 3 should probably make you question the design...Minimizing the number of mock objects necessary for any given unit test is a very effective way of keeping the Cyclomatic Complexity of your classes below an acceptable level."
• "Ideally you only want to mock the dependencies of the class being tested, not the dependencies of the dependencies. From hurtful experience, deviating from this practice will create unit test code that is very tightly coupled to the internal implementation of a class’s dependencies."

A few more occurred to me:

• Use as many patterns and idioms in your unit tests that you do in regular code, like testing exceptions and fixtures. This can be a great way to reduce the drudgery of testing bean objects for instance (not that I in anyway condone the use of bean objects).
• Allow reuse of commonly used objects between tests.
• The length and complexity of a unit tests is an indication of the complexity of the underlying object - once a test reaches a certain length/complexity it's time to refactor the object being tested.
• Duplication in tests is just as bad as duplication in the code being tested.
• No code goes into production just for the sake of testing.
• Use reflection to gain access to internal object state. This is related to the previous point as a way to avoid artifacts of testing in production code. Other ideas include a good equals method, package level access and getter methods - but these leave code that may only exist for testing. And the last two are also a good way to break encapsulation.
• Something that is easy to test is not always good design. For instance, having a fixture or utility code that makes bean objects easy to test drive shouldn't dictate using bean objects for everything.

The previous post in the series, "Why and When to Use Mock Objects" lists what makes a good unit test including: being atomic, order independent and isolated, intention revealing, easy to setup (a unit test code smell is a lot of setup code) and runs fast.

There also looks like a really interesting site, Test Automation Patterns. It lists test code smells including: test code duplication is bad, obscure tests, and data sensitivity. Also, a list of fixture strategies: standard, fresh and shared.

IntelliJ vs Eclipse Deathmatch

For my own reference, I'll put comparisons of Eclipse vs IntelliJ. I didn't like Eclipse because I found setting up projects a pain so it was a bit of a non-starter.

Tom's guide: "Eclipse requires you to save all the time...Eclipse has serious usability issues in graphical diff...Like Word, Eclipse wants to own your files and wants you to make all your changes through it".

It's subject of a recent Slashdot article.

It'd be good to find a comparison of the refactorings that are missing/different in Eclipse. I'm also trying out NetBeans 5 to see what it's like.

Update: An old comparison of Eclipse and IntelliJ and a PDF comparing RefactorIt, Eclipse 3.0 and IntelliJ 4.5. A list of new refactoring in NetBeans. Eclipse 3.2 M4 reproduces many features of Swing and IntelliJ IDEA, one of the threads Is $500 really alot of money?.

Definition of Open Source

"Software that takes longer to install and configure than it would to write yourself."

This isn't what I truely think, but after several frustrating experience with LAMP software (especially PHP) it feels like it.

Query Anything

Access In-memory Objects Easily with JoSQL "Once in a while something comes along that is so simple, so straightforward, and so obvious that it's amazing that nobody did it long ago."

An example query,

SELECT *
    FROM   java.io.File
    WHERE  name $LIKE "%.html"
    AND    lastModified BETWEEN toDate('01-12-2004') 
                        AND toDate('31-12-2004')

I've blogged previously, Using RDF to improve Object-First Development. This is an example that is the same principal as Kowari's resolvers (or any idea of smushing metadata like Gnowsis) - allowing anything to be treated as RDF (or in JoSQL's case SQL).

DSLs, LOP and Ruby

Ruby on Rails vs. Java: An Expert Roundtable "...you can start doing that now in Java with language-oriented programming because there are some new tools coming out. Martin Fowler coined this term "language-oriented programming (LOP)." In fact, he's written a paper about it. The paper will be influential because new tools are coming out—tools that let you build a domain-specific language on top of the Java Machine. There's a product coming out (based on JetBrains's Meta Programming System) that I am showing here at No Fluff, Just Stuff.

Intentional Software (Charles Simonyi's company) is coming out with a tool soon. Microsoft is doing it with something called "software factories". People have written domain-specific languages in dynamic languages like Ruby, because a dynamic language is more suited for creating a DSL. But now we are starting to see tools that allow you to use a DSL in a strongly type language like Java."

"One of the things that delights me is seeing that testing is in Ruby on Rails from the first minute. Of course you want to build your application and test it, but with Ruby on Rails we all build our applications and test them the same way. So I know when I sit down on somebody else's Ruby on Rails project, it's not just that the language, the framework, the templates, and all those things are going to be the same. The discipline for writing the automated tests at different levels is going to look the same across projects, so I can jump in and immediately be productive. I feel like when I sit down to do a Java application today, or join some team that is working on one, I'll immediately have to figure out how their automotive testing is done—or worse yet I'll have to design the automated testing because they haven't done it yet."

Don't put all your Pasta in the One Basket

What Sort of Pasta Do You Want? "After reflecting on a system that was developed using techniques found more so in agilest development teams such as Test Driven Development (TDD) and dependency injection, they observed that the parts of the system were more loosely coupled and more easily interchangeable, good indicators that it would be a better system to maintain. The code is better described as ravioli code instead of that of its more common pasta brethren.

This analogy has really stuck with me since because of the number of parallels it draws. Take one such example – the reason that ravioli is typically more expensive than spaghetti, even though they are both made from the same fundamental ingredients, is that making good ravioli takes a lot more skill than it does spaghetti. This idea is,of course, not new, and can be taken to extremes (see Wikipedia’s entry) but I know which one is is my favourite."

So ravioli code is part of the pasta theory of programming which includes lasagne code.

A little bit of Spring, makes your code Sing! "We make extensive use of Spring at the day job, and feel it has been a key contributor to our extremely high code coverage, and the promotion of the ravioli code pattern; although some are of the opinion that ravioli code is an anti-pattern, I prefer smaller pieces loosely joined over the alternative."

It is an anti-pattern in the way that too many, loosely joined, tiny pieces of code hampers the understanding of the code. Too many classes with 10 lines in them calling another class, just catching an exception or looping around a method call, etc. In this way, it can reduce the ease at which code can be modified.

In "Where Smalltalk Went Wrong 2": "Again, ravioli code doesn't offer a path from here to there. "Here" in this case is the ignorant programmer first introduced to the code, "there" is the same programmer successfully making whatever change they need to make. In my experience with ravioli code there is a gestalt which is arrived at in a sudden realization, when the picture comes together. But before you reach that realization you find yourself in a murky set of code where it is difficult to predict effects or determine causality, and you seldom know how far away you are from the gestalt realization.".

To push the analogy, the ravoli becomes too small so that there is nothing left but empty shells of pasta. It's much more palatable, code-wise, than spaghetti (where the goodness is all over the plate and can't be stuffed in) or mud.

In the same way that there is duplication detection there should also be a metric available to judge whether a piece of code is not providing enough functionality or value. However, the way most code is written this isn't frequently a problem. A good example given of "about the right size" is where the algorithm is on paper and the code is in our head.

Dull Little Boxes

New Apple ad with about Intel Inside. From the unlikely URL of: http://www.apple.com/intel/ (which also includes a link to the keynote).

Northrop Grumman Killing Kowari?

Resignation from Kowari due to Northrop Grumman Letter "It is with sincere regret that I resigned as an administrator and developer of the Kowari Metastore."

"Northrop Grumman's position seems to be that they "purchased all rights associated with the Kowari software", a position not reconcilable with their continued release of the software under the Mozilla Public License, version 1.1."

So it would seem that Northrop, for whatever reason, dislikes Kowari's existence.

To get David and then Tucana (whose IP was eventually sold to Northrop) to start and continue with an open source version of TKS (the closed source version of the RDF database) was my little hobby horse (I fought fairly long and hard you could say). The idea was to get the Semantic Web bootstrapped and to create a value network around Semantic Web technology (I got this originally from "A critical look at object-orientation"). It is deeply disappointing for me to see it (the value network and Kowari) threatened in this way.

Like any OS project it is the ecosystem that is built around Kowari that makes it work. With so many contributions, just how much of the total code does Northrop actually own the copyright to? By accepting changes it isn't following the dual licencing model used by the owners of Berkley DB. To me Kowari was always using open source as a development and distribution model. Already, we have some contributors threatening to pull out their code (more at, "Disturbing News From Kowari").

Having administrators leave due to Northrop's actions is a good way to kill the project. Hopefully, Northrop's bullying will get a lot of interest - it's good to see, for instance, that this has been picked by aggregators like Topix's Aerospace and Defense.

The other posting David W linked to: Is Northrup Grumman Smushing Kowari?, "But I’d like to know what the status of Kowari is going to be, open source or not, because there are clients for whom Kowari might be the right choice, and we won’t bet on a dog that Northrup Grumman seems determined to publicly beat to death.

Relying on Kowari is now not prudent, given our obligation to do our best for our clients; but it’s also bad for Semantic Web uptake in the US federal government, and that’s something Northrup Grumman should think very carefully about."

Update: Paul and Andrae have also added their thoughts.

Update 2: David has published the letter from Northrop's lawyers. Danny posts, "...clearly if the current Kowari is MPL’d they can’t stop other developers working on the system."

Bookshelf of Bookmarks

• Slashdot is Going out of Style in 2006 "2006 will the year in which the once great Slashdot dies." More up-to-date and more stories over comments?
• Comparing LINQ and Its Contemporaries Comparison of Ruby on Rails, Hibernate and other languages/APIs and LINQ.
• Fire & Motion: The Trouble with Competing with Google How Google picks its fights in order to cause the most cost to its competitors.
• RDF For Rapid Development Of A Data Model How to use RDF to eventually get to a relational or other integration system (mentions Metis).
• RuleML "The aim is to build an expert system shell which implements native support for RuleML and incorporates the latest concepts in web-based and distributed processing." Via Sumatra Posted to Sourceforge.
• From the same site: Grand Challenge, Neural nets and rule engines How to distribute the RETE algorithm by processing locally and distributing indexes.
• A couple of links on the Ruby VM, Rite: Rite and YARV (Yet Another Ruby VM)
• Luke 6:41 "Our Leader hasn't caught Osama bin Laden, but he's doing a bang up job rounding up brown people."
• Modularity Rules "IBM’s investment changed the nature of the industry so completely that modularization is the name of the game."
• JAHAH Home AJAX is so 2005.

Bug or Feature

ImplicitInterfaceImplementation "What would it mean to implement an implicit interface? Essentially it would tell the type system that the ValuedCustomer class implements all the methods declared in the public interface of Customer but does not take any of its implementation, that is its public method bodies, and non public methods or data. In other words we have interface-inheritance but not implementation-inheritance."

InterfaceImplementationPair "Using interfaces when you aren't going to have multiple implementations is extra effort to keep everything in sync (although good IDEs help). Furthermore it hides the cases where you actually do provide multiple implementations."

Interfaces "Somewhat related to this is one of Robert Martin's Principles of Object-Oriented Design: "The Interface Segregation Principle", which says "Clients should not be forced to depend on methods that they do not use. Interfaces belong to client, not to hierarchies."

In a dynamic system like Smalltalk, Ruby, or Python, we don't need explicit interfaces, so "The Interface Segregation Principle" doesn't seem to apply. In static systems like Java and C++, one could declare interfaces specific to each client, but it seems that few people do.

The principle seems to more about dependency-breaking than anything else. I'd be interested in hearing from people who have actually done this extensively."

Implicit Interfaces "Of course Martin's suggestion would make it easier to use third party code without wrapping it up in a shim of your own. Personally I think it's a good thing to get in the habit of segregating third party code and putting it behind a thin, object based firewall of your own devising. The shim/wrapper code allows you to blend the alien API into your standard ways of doing things and gives you a chance to refine the abstraction that the third party API provides. Chances are their abstractions are in terms of the problem that they solve whereas yours should be in terms of the problem that you are solving and might only use a small part of the API... What's more, if you have slipped in an interface you can test without the third party code and you can, potentially, replace the third party code with other code if required..."

This last point is very much in line with my own experience and the point in A RATIONAL DESIGN PROCESS: HOW AND WHY TO FAKE IT "Often we are encouraged, for economic reasons, to use software that was developed for some other
project...The resulting software may not be the ideal software for either project, i.e., not the software that we would develop based on its requirements alone, but it is good enough and will save effort."

Mac XP

Sort of like the "Pooh and the Philosophers" only for XP and the Mac development team.

Project Metaphor: Creative Think "Find a central metaphor that's so good that everything aligns to it. Design meetings are no longer necessary, it designs itself. The metaphor should be crisp and fun."

Refactoring: -2000 Lines Of Code "He recently was working on optimizing Quickdraw's region calculation machinery, and had completely rewritten the region engine using a simpler, more general algorithm which, after some tweaking, made region operations almost six times faster. As a by-product, the rewrite also saved around 2,000 lines of code."

Simple Design: MacPaint Evolution "I was surprised a few days later when Bill told me that he decided to remove the character recognition feature from MacPaint. He was afraid that if he left it in, people would actually use it a lot, and MacPaint would be regarded as an inadequate word processor instead of a great drawing program. It was probably the right decision, although I didn't think so at the time. I was amazed that he was able to detach himself from all the effort that he put into creating the discarded feature; I know that I probably wouldn't have been able to do the same."

Constant Integration: Real Artists Ship "We starting doing release cycles that were only a few hours apart, re-releasing every time we fixed a significant problem."

Pair Programming: Real Artists Ship "At one point, around 2am on Sunday night, I stumbled across a bug in the clipboard code. I thought I knew what it might be, but I was so tired that I didn't want to deal with it. I tried to pretend that I didn't see the problem, but Steve Capps was watching my expression and knew there was something wrong. I also was too tired to sustain a pretense; he grilled me about the problem and then helped me craft a fix, since I was too tired to do it on my own."

Automated Testing: Monkey Lives "The Monkey was a small desk accessory that used the journaling hooks to feed random events to the current application, so the Macintosh seemed to be operated by an incredibly fast, somewhat angry monkey, banging away at the mouse and keyboard, generating clicks and drags at random positions with wild abandon. It had great potential as a testing tool, so Capps refined it to generate more semantically rich events, with a certain percentage of the events as menu commands, a certain percentage as window drags, etc."

Coding Standard: Hungarian "Bud decided that it would be too error prone to try to translate the Hungarian memory manager directly into assembly language. First, he made a pass through it to strip the type prefixes and restore the vowels to all the identifier names, so you could read the code without getting a headache, before adding lots of block comments to explain the purpose of various sub-components.

A few weeks later, when Bud came back to attend one of our first retreats, he brought with him a nicely coded, efficient assembly language version of the memory manager, complete with easy to read variable names, which immediately became a cornerstone of our rapidly evolving Macintosh operating system."

The importance of on-site customers: Round Rects Are Everywhere! "Steve suddenly got more intense. "Rectangles with rounded corners are everywhere! Just look around this room!". And sure enough, there were lots of them, like the whiteboard and some of the desks and tables. Then he pointed out the window. "And look outside, there's even more, practically everywhere you look!". He even persuaded Bill to take a quick walk around the block with him, pointing out every rectangle with rounded corners that he could find. ...Over the next few months, roundrects worked their way into various parts of the user interface, and soon became indispensable."

New Newsy News

I should've done this a little while ago, a link to The News before The News "Tech opinion from James Webster". Perhaps one of the few people to constantly surprise me with stuff that I hadn't read about before.

Includes links to my blog including: "All Yuor Google Base Are Belong To Us!" and "DabbleDb - Naked Objects for Web 2.0".

Rocketman

First jet powered Birdman flight "After checking the altimeter several times, it was apparent that there was no appreciable loss in altitude for this period of time. Visa next changed his angle of attack by redirected the thrust and changing his body position to attain vertical climb...The jump has proven empirically that level human flight is possible and sustainable using the combination of jet engines and a bird-man suit. The strength required to control level flight was relatively easy, and controlling the direction of flight feels surprisingly natural. The duration of flight is simply a factor of the consumption of fuel of the engine(s) powering the flight."

Video here.