Friday, December 31, 2010

The non-discriminating audience

Check out this patent from Apple: let's reward reviewers of products when their prediction of product success matches actual product success. This approach has a number of problems.

First, it's a well known fact that you can get any junk sold by the millions with a proper marketing campaign, e.g.: Britney Spears (with all due respect). Thus, we conclude people will do effectively as they are told.

Second, as per the item above, if many reviewers give glowing reviews of product X then it's more likely product X will succeed, so the reviewers stand to benefit. It does not matter whether product X is good as long as it sells, e.g.: Lady Gaga (with all due respect).

Third, it's yet another obvious sign that shows today's audience is non-discriminating. Rather, it's like this plant that grows towards light. Marketing is trying to shine the light the plant will grow towards the most. Again, it does not matter what plant it is, or what light it is. All that matters is that money keeps flowing.

Therefore, this patent is about maximizing the flow of money and, thus, Apple's profits because they have a toll booth position controlling access to the things being bought. It does not have anything to do with content quality.

Why can this happen to begin with? Because the audience is non-discriminating. In other words, the audience is a poor judge of quality. Or, in perhaps more direct terms, what Apple and many others do is to target an uneducated audience. Because if the audience was more educated, then we wouldn't have to think music was good because somebody else likes it. We would not even hear about Britney Spears, or Lady Gaga, or...

... well? It's not just about music, is it? How about our crappy politicians, political parties, laws, justice, health care, salaries, jobs, environment, energy efficiency, journalism, etc? How will this uneducated audience deal with today's very complex problems using their US-standard high school education? It's just not possible, and so we get what we deserve: an exploitation marketplace like that set up for teenagers.

But folks at Apple and similar places are not to blame (at least not entirely). Rather, the non-discriminating audience is to blame. Because if that same audience would stop accepting crappy stuff, then the producers of said crappy stuff would go out of business. But, oh, alas... how do you fix the non-discriminating audience when it is so convenient to so many that it remains non-discriminating...

Tuesday, December 28, 2010

Assessments 1.49

I just published a fix so that the Assessments RB extension works when Store is not loaded. Enjoy!

Monday, December 27, 2010

Smalltalk is typed

In the last post, I mentioned that I had found some fascinating material for chapter 6 (in Fundamentals' volume 2). Here's a bit that has profound consequences: Smalltalk is typed. Well, of course, receivers have to be of the same type, right? Yes, of course. And that means one of the most fundamental types of objects in the image will cause endless performance issues because each one of them is an instance of a different class. But which objects are singletons and instances of a singleton class?


So that means that whenever you send messages like #respondsTo:, or #withAllSubclasses, or #superclass, or #isKindOf:, you will effectively cause message sends that cannot possibly be cached (particularly when you do them in a loop). Consequently, performance stinks. I know, because I did the experiment of replacing VisualWorks' sorted collection method dictionaries with actually hashed method dictionaries. The performance of the enumeration part of this expression

Object withAllSubclasses reverse do: [:each | each yourself]

went up by 60-70%! But there are many other such cases hidden all over the place. For example, put all those classes in a Set and then look them up to see if they are there. It happens --- slowly, but it does. Now do the same with an identity set. Bam!!! It's two times faster!!! But why?

The message #= is implemented in Object as #==. However, when the message #= is sent with a multitude of receiver classes, each send requires a lookup (and an expensive lookup at that, because you have to go all the way up to Object). If you use an identity set, then you send #== directly --- which in most Smalltalks is not even a message send. Thus, there are no lookups when comparing objects, and no wonder the code runs way faster.

Huh... Smalltalk is typed, and there are consequences to that...

Among other things, chapter 6 explores actual production problems in which this kind of stuff makes a huge difference. Hopefully I can finish it off soon so I can move on to chapter 7, On Threading.

Sunday, December 26, 2010

Book writing update...

I just finished the next to last section of chapter 6. It turned out to be yet another example of fascinating material. The draft is now 150 pages. I hope to have the last section finished soon, and after that it's chapter 7 which, for some reason, I had previously decided to write on threading. Semaphores, shared queues, critical sections, that's a lot of fun!

Saturday, December 18, 2010

How long is that name field?

Oh, everybody knows first and last names fit in 20 characters, right? Well, ok, maybe 32. Or maybe 50, to account for some edge cases like this. Right? No, wrong. How about 590 characters for a last name, plus 25 middle names and a suffix of Senior? What happens to this guy's identity when he comes into the office to be registered in some computer system?

And everybody knows that, in the US, everyone has a social security number, right? Well, at least those on some payroll database. Sure, unless you're one of those that has many, or one of those whose social security number has changed over time. Does that mean that the HR department cannot keep track of your identity because someone in the IT department assumed that "one person" is identical to "one social security number"?

If the software cannot handle the identifiers used to determine your identity, does that mean you don't exist? For example, what happens if you are Chinese, but the characters used in your name are not supported for input in computer systems?

These are fascinating problems, because they illustrate how absolutely limited (and limiting) our software can be when we allow reality to be defined by computer programs. You might want to read Data and Reality, by William Kent. Some excerpts are available here.

Now, what happens when we allow software to alter our behavior so it fits into certain patterns? Don't we become a mindless gear in someone else's machinery? For what purpose? And who benefits? Maybe we shouldn't celebrate some of today's "technological advances" so much...

Wednesday, December 15, 2010

About a couple of my books

I recently got a question about how the Fundamentals and the Mentoring Course books are different. I thought I'd share the answer here. But before I do, I want to thank you for your interest in my books. I really appreciate the nice feedback I've received, and I hope to continue writing books that earn this kind of praise in the future.

The Fundamentals and the Mentoring Course books focus on different aspects of programming. For example, the Fundamentals books focus more on techique aspects such as how to use inheritance, polymorphism, enumeration, threading, weak references and similar features. It is meant more as a training course on the material I think one should be able to do automatically and without thinking, with the intention of freeing up thinking resources for attacking the design problems that usually drive the choice of which technique to use in the first place. In short, the Fundamentals books say "if you learn all this stuff so it's automatic, you will have more time to think about better designs for your programs".

The Mentoring course takes a different approach. It assumes readers already have a reasonable grasp on Smalltalk, and explores different design methodologies that have an impact in how programs come to be. In particular, the book traces important influences that acted at the time Smalltalk was designed, but which usually remain hidden from view nowadays. For example, the relevance of Laws of Form in Design Principles Behind Smalltalk is evident, and yet few people consider why it was so important that Dan Ingalls paraphrased Laws of Form in his paper. There is a lot of energy behind techniques like test driven development, which emphasizes that one should start by writing tests, but it's much more effective to design and distribute object responsibilities first. It's critical to be more aware of how these factors affect the code we write, because it is only when we consciously use these data points that Smalltalk's powers can be fully realized. In short, the Mentoring Course book says "if you design your programs taking into account these bits of information, the resulting programs will be substantially and measurably better".

So, as you can see, the books focus on different aspects of the problem of how to write effective Smalltalk code. It's hard for me to make recommendations, but I hope these bits can help you choose if you have to.

Now on to other questions I have received. I am currently working on Fundamentals volume 2, and I am having a lot of fun. The draft recently reached 130 pages, and I am getting closer to finishing off chapter 6 (on enumeration). As soon as I am done with that, the next chapter is about recursion. I have so much awesome material to write about, I can't wait! I'd like to be done with volume 2 sometime next year. Volume 3 should be quicker, as (so far) it will have the last chapter of the Fundamentals books, which is about optimization. I hope I won't have to add another chapter, the chapter count is 10 and ten is a good number :).

The code shown in the books was written mostly in VisualWorks. However, I did not mean the code to be tied to any particular dialect. In particular, the books do not talk about any UI specific material, so I think the code should work well on Pharo and others (perhaps with just a small change here and there). I know some readers have already ported some of the code to Squeak / Pharo, so check out the usual code repositories and see if the code is already there.

Regarding coupons, Lulu has a series of coupons for December, and they are running a different coupon a day. I'd check their website and see what's the coupon of the day. For example, today they are offering free second day shipping.

Thank you again for your interest and appreciation. Now, back to the scheduled programming.

Monday, December 06, 2010

Smalltalks 2010 videos online

You can check Smalltalks 2010's videos at FAST's website. Enjoy!

Wednesday, December 01, 2010

Lulu coupon campaign

Lulu started a campaign in which it will offer one coupon per day. Here's the link. Today, they offer free shipping for anything over $35...