In a way ideas only count for a little in computing, because you kind of have to implement this stuff. This is the part of the story that really makes me clutch at my throat, because every time you implement something, 5 years go away.
March 18, 2010
The Most Depressing Thing I Heard in 2008
February 15, 2010
Usability Problems are Cultural
Obstacles to getting real feedback are now mainly cultural, not technological; any business that isn’t learning from their users doesn’t want to learn from their users.
February 9, 2010
February 6, 2010
All Your Facebook Friend’s Phone Numbers
http://www.facebook.com/friends/?filter=pfp
That’s the link to all your facebook-friend’s phone numbers.
Every time I see one of those “I need ya phone numbers” things on facebook I post that link. Please do the same. At least until the phone companies fix the real problem by automatically backing up contacts from the phone “in the cloud
February 4, 2010
Deus Ex Ignorantia
- Felten’s Third Law
- Given an intractable and complex policy problem, people tend to look to areas they are not experts in to save the day.
For example,
Given a difficult technology policy problem, lawyers will tend to seek technology solutions and technologists will tend to seek legal solutions. … It’s easy to reject non-solutions in your own area because you have the knowledge to recognize why they will fail; but there must be a solution lurking somewhere in the unexplored wilderness of the other area.
– Ed Felton.
January 15, 2010
EULA Today Fail
The EULA1 for the USA TODAY iPhone App starts off
General
These Terms of Service govern your use of the USATODAY.com website (the “Site”) only and do not govern your use of other USA TODAY services, such as services offered by the USA TODAY print newspaper.
Clearly this invalidates the agreement on the iPhone, since the iPhone App is not “the USATODAY.com website”.
This is mildly embarrassing for USA TODAY, and even more of a fumble for Mercury Intermedia, who built the app. But I can’t think of any way this actually hurts anyone, even in theory. Users are already bound by the App Store Terms and Conditions, so why bother putting your own EULA (that nobody’s ever going to read much less care about) in your app?
1To see the EULA, tap that little i near the bottom left of the homescreen, then tap Terms of Service. The text above was copied from version 1.5 of the USA TODAY iPhone App.
January 13, 2010
Splash Screens Are Evil
Splash screens are evil. While branding is important, the proper place for it is in the iconography, optional “About” or “Info” screens, and App Store profiles. The most common interaction pattern with iPhone applications is to launch them frequently, close them quickly, and treat them as part of a set of tools that interact to comprise a single user experience. Splash screens break the perception of seamlessness.
The HIG offers a very useful suggestion for managing launch states, which may be quite slow, depending on the needs of your application. The suggestion is to provide a PNG image file in your application bundle that acts as a visual stand-in for the initial screen of your application. For example, if the main screen for your application is a table full of data, provide an image of a table without data to act as a stand-in. When your data is ready to be displayed, the image will be flushed from the screen, and the user experience will feel more responsive.
In this book, we will explore extensions of this, including a pattern for loading application state lazily
–Toby Boudreaux, iPhone User Experience, page 15; emphasis mine.
I’ve always hated splash screens, from the first time I turned on a computer. They get in the way of what I want to do. I want to write, or draw, or play — but if I launch Word, or Photoshop, or any game, I have to sit through a splash screen before I can get to it.
Branding a splashscreen is putting your name on a purely negative experience. Nobody wants to wait for their computer. Splashscreens, by definition, force you to wait. It’s hard for me to imagine why anyone wants to associate their brand with a computer not doing what customers want.
December 25, 2009
A C &Puzzler[]
Here’s a C-puzzler for you!
given this function,
void foo(char* s){
printf("s is at: %p\n s is: '%s'\n", s, s);
}
and that
char s[] = "Joy!"; foo(s);
prints out
s is at:
0xbffff46b
s is: ‘Joy!’
what will this next line print?
foo(&s); //WHAT WILL THIS DO?
Pick all that apply:
- Print “Joy!”
- Print garbage
- Print the same address for
s - Print the a different address for
s - Crash
- Go into an Infinite loop
Answer
Answer: one and three
Yeah, it’s not what I expected either, especially since:
@encode(__typeof__(s)) = [5c] @encode(__typeof__(&s)) = ^[5c]
In fact, all of these are equvalent (modulo type warnings):
foo(s); foo(&s[0]); foo(&(*s)); foo(&s);
December 18, 2009
Guess Towards the Middle
Survey researchers call this kind of behavior satisficing – it happens when people taking a survey use cognitive shortcuts to answer questions. In the case of questions about personal behaviors that we’re not used to quantifying (like the time we spend online), we tend to shape our responses based on what we perceive as “normal.” If you don’t know what normal is in advance, you define it based on the midpoint of the answer range.
–Aaron Shaw, writing for Dolores Labs
Related:
- Acquiescence Response Bias
the tendency to agree with any assertion, regardless of its content
December 10, 2009
Being a Lisp is a Handicap
Being a Lisp Is a Handicap
There are a large number of people who find Lisp code hard to read. I’m one of them. I’m fully prepared to admit that this is a shortcoming in myself not Lisp, but I think the shortcoming is widely shared.
Perhaps if I’d learned Lisp before plunging into the procedural mainstream, I wouldn’t have this problem — but it’s not clear the results of MIT’s decades-long experiment in doing so would support that hypothesis.
I think it’s worse than that. In school, we all learn
3 + 4 = 7and then
sin(?/2) = 1
and then many of us speak languages with infix verbs. So Lisp is fighting uphill.It also may be the case that there’s something about some human minds that has trouble with thinking about data list-at-a-time rather than item-at-a-time …
…I think I really totally understand the value of being homoiconic, and the awesome power of macros, and the notion of the reader. I want to like Lisp; but I think readability is an insanely important characteristic in programming systems.
Practically speaking, this means that it’d be hard for me to go out there on Sun’s (or Oracle’s) behalf and tell them that the way to take the best advantage of modern many-core hardware is to start with S-Expressions before breakfast.
–Tim Bray (emphasis mine)
I’m afraid he’s on to something. We have an amazing ability to parse language. But people aren’t terribly good at building the kinds of stacks needed to parse LISP with their short term memory.
This is the cheese that the rat that the cat that the dog that the neighbor owned bothered chased ate.
Say what?!
(This is the cheese (that the rat (that the cat (that the dog (that the neighbor owned) bothered) chased) ate)).
See the LISP connection?
All functional languages are fighting an uphill battle to be understood. The world we evolved in is stateful (modal) and imperative. We navigate it in a me-at-a-time way. Unfortunately, LISP’s prefix syntax is another, unnecessary, barrier.
The bottom line is that every word of code spends more time being read than written — so writing in a syntax that most people have a hard time reading is one of the worst programming choices imaginable. I believe functional programming languages are well worth learning; but I don’t believe it’s worth suffering a poor syntax.