Friday, January 02, 2009

Everything has a price

People with lots of money invested money with Madoff, because since they had a lot of money then clearly they needed >10% yearly returns no matter what. Therefore, people that buy a painkiller at a higher price enjoy better results than when buying the same thing at a discount.

Of course the painkiller was a placebo to begin with.

Makes perfect sense to me.

9 comments:

Peter William Lount said...

That means that "nothing" has a price too?

What about the use of nil? Does it have a price? What price/cost does it have when you use nil? When you don't use nil? When you use nil when it's not needed? When you ignore nil when it should be used?

Andres said...

I'd say that yes, (ab)using nil has a price too. For example, I'd say that when code has a lot of isNil/notNil, or things like something == nil, it could be the case that a better design would allow objects to exist in a well defined state most of the time. This makes answering runtime questions such as isNil unnecessary.

Andres.

Peter William Lount said...

Sometimes however NOT using "isNil ifTrue: [...]" or "ifNil: [...]" makes the code and object design much more complex. "ifNil:" and it's variants are a polymorphic design after all.

Simplistic systems tend to make the assumption that there always will be a "thing" when that might not be the case in actual usage. For example, it's often assumed that there will be an "end date" or "expiry date" on a particular object in real life business applications, however that isn't always the case. It's when the existence of an object, the "end date" in the example, is "ignored" that it becomes a problem with programs literally crashing with walkbacks error logs.

Simple yes, simplistic no. Pay the price of existence checks if it must be paid, for all too frequently failure to pay leads to failure in live systems.

Peter William Lount said...

By the way Andreas I picked up a copy of your excellent book, "Hashing in Smalltalk: Theory and Practice". Although I've not yet had time to do more than skim parts of it I'm excited about reading it thoroughly.

How is it working out with the way you published it?

Very nice cover too. ;-)

Andres said...

I meant to go after the unnecessary *runtime* nil checks that happen because of abusing nil into doing all sorts of things.

For example, sometimes nil checks are used when a more elaborate design would create different code paths that would make it useless to perform the nil check.

Every so often I hear arguments in favor of this alleged code compression, and they go along the lines of "it's better because there are less classes".

Well, sure, but the code that would have been in those classes is now sprinkled all over the place. If that's not bad enough, these checks have the potential to make code run slower because design time distinctions are being drawn at runtime.

So, this does not mean that it is possible to eliminate every single nil (or other) check. For example, it would be nice to implement Integer>>isPrime in terms of ^true or ^false, depending on which integer is the receiver, but alas no such luck. Hopefully this makes my point a bit more clear.

Andres.

Peter William Lount said...

In one very large business application that I helped clear up many bugs the cause of which was a systematic avoidance of the existence of objects.

So one can also say that there can be an abuse the other way in avoiding existence checks with "ifNil:" and it's variants.

Overall design is a balance.

One of the problems with the "hasX" and "doesXExist" type of truth methods that were prelevant in many business applications is an utterly massive explosion of extremely tiny methods all over the place. Talk about code spreading. When almost all of the methods become just a few lines where does all that code go? It goes all over the place and there is a huge explosion in the number of methods and often for no apparent good reason. It's quite a challenge understanding objects when they literally have thousands and thousands of tiny one line methods. Of course one doesn't want long methods either... so it's a balance.

Often design decisions that looked good at the start of a project don't turn out so well at the end but by then it's too late to turn the ship off it's course.

Andres said...

I think we may be saying the same thing, mod the tone of gray. It's really difficult to discuss these topics without talking about a concrete example!

Also, this kind of stuff is what the Fundamentals book is about.

Andres.

Peter William Lount said...

Yes, shades of gray.

Which "Funamentals" book?

Andres said...

The one I am writing :).

Andres.