Mokka mit Schlag » 2009 » January

So I stop by my local Circuit City this evening to see if anything worth buying is on sale. I actually have a couple of items in mind. However, the game I want is selling at full list price, despite the going out of business “sale”. The camera I want is actually 10% off, at which price it is still a couple of hundred dollars more expensive than the same camera on Amazon. I do pick up one cheap game that is actually 14 cents less than the price on Amazon, sales tax included.

For all the talk about how Wal-mart killed Circuit City, I’ve never found especially good prices on electronics at Wal-mart (or Target, or K-Mart, or similar); and I’ve never found competent service at Circuity City either, even before the layoffs. It’s Amazon and eBay other web stores that are killing the big box retailers, especially for high margin items that don’t cost a lot to ship. It’s amazing that anyone still buys anything at brick-and-mortar stores like Circuit City and Best Buy.

myAny :: (a -> Bool) -> [a] -> Bool
myAny f [] = False
myAny f (x:xs) = foldr step False xs
     where step x acc = acc || f x 

I’m beginning to hate type inference. Yes the compiler can figure out the types, but the human (i.e. me) often can’t without running the compiler. Redundancy and verbosity are not bugs. They are features. Human language (e.g. English) is verbose and redundant for good reason. Redundancy helps humans understand.

The source code is not just for the compiler. Otherwise we’d write in machine language. User interface factors need to be considered in the design of programming languages.

It took me long enough to realize that foldr still moves from the beginning to the end of a list. Somehow I thought it started at the right (i.e. the tail) of the list. Once I realized that Exercise 7 was easy:

Write your own definition of the standard takeWhile function, first using explicit recursion, and then foldr.

(more…)

Probably not a coincidence, but all this lifecycle stuff reminds me of applets, albeit with somewhat more complicated argument lists and fancier names. There are certain patterns that show up again and again. Event listeners are one. Event loops are another. And life cycle methods are a third. Sometimes the trick to learning a new system is recognizing the old patterns in new language. Of course, this can trip you up badly when the pattern is something truly new, and when you try to fit it into old mental models. You can also get tripped up by assuming that certain contingent details are the same in the new instantiation of the pattern as in the old one.

The tab key doesn’t work like you’d expect–it doesn’t advance from one field to the next. I’m not sure if this is a limitation of the framework or just the sample app. This is completely irrelevant on a phone, but may become important if third parties start using the Android platform as a base for netbooks.

Too much copy and paste , and not enough thinking in the tutorial. I should try to work backwards from the sample app on the screen to understand where the different fields are coming from. Let’s see there are:
(more…)

Real World Haskell, Exercise 4, p. 98:

The asInt_fold function uses error, so its callers cannot handle errors. Rewrite it to fix this problem.
(more…)

Perhaps just because it’s an initial tutorial, but the event handling model feels like a sort of monolithic Java 1.0/Mac OS 6 event loop rather than the more flexible event listener based approaches of Swing and other more modern GUI frameworks.

Local variable access is much more efficient than field access in the VM. I guess the CPU (or battery) is too underpowered to do fancy JIT tricks, as I’d expect a good optimizer to account for this. Worth remembering. Hmm, does Dalvik even have a just-in-time compiler? Apparently not.
(more…)