Vincent Gable’s Blog

December 7, 2009

Dot Syntax Solution

Filed under: Cocoa,Design,Objective-C,Programming,Usability | , , , ,
― Vincent Gable on December 7, 2009

Surprisingly, the addition of dot syntax to Objective-C 2.0 has been a major source of controversy. I wonder if there’s some kind of Bike Shed effect at work here: the problem dot-syntax causes is trivial1; while the clarity it brings to code is minor. So it essentially boils down to aesthetics. (For the record, I like the dot, even with it’s current flaws, but I don’t believe it’s worth fighting for).

The Actual Problem

The problem is that when you see a.b = c; you don’t know if it’s:

  1. Assigning the b field of a struct to c. This basically compiles down to one move instruction.
  2. Invoking the -setB: method on an Objective-C object. By convention -setB: should update the b property of the object to hold the value c, and nothing else. But it might have side effects, or be really slow.

A Solution

Using a different symbol to access Objective-C properties would remove all ambiguity. Nobody would mistake a@b = c; as assigning to a C-struct. It’s clearly an Objective-C construct.

But personally, I’m not a big fan of the @ character. It’s ugly; it’s noisy; there’re just too many lines in it. I think U+25B8 ‘BLACK RIGHT-POINTING SMALL TRIANGLE’ would make a better choice,

obj▸property = value;

And since ‘▸’ can’t be part of a valid C identifier, you can basically preprocess your code with s/▸/./, then compile it with existing tools.

Of course, it doesn’t matter what character(s) is picked, so long as it’s clearly different from existing C syntax; and you have a way of replacing it with a . before building it.

1 I’ve heard experienced developers complain that dot-syntax = a steeper learning curve for newbies, and that it can be confusing, but I haven’t actually seen one come out and say ‘I spent X hours debugging a problem that I couldn’t see because of it’. The fact is, any situation that dot-syntax would obscure is already pathological. In the end I just can’t see dot-syntax mattering much.

November 14, 2009

You Can’t Please Everyone

Filed under: Design,Programming,Quotes,Tips,Usability | , , ,
― Vincent Gable on November 14, 2009

I did a project years ago called the “Dollar Dudes”, where we got on the subway with a bucket of dollar bills and announced that we were in the lucky “Dollar Train” and that everyone gets a dollar. Most everyone was delighted (at both the dollar and the ridiculousness of it all) but one guy refused to take the money and snapped at me. I was bummed out to get that reaction, but at the end of the day I didn’t feel that one guy getting irritated made the whole project a failure. The other 40 people had fun. I imagine the type of person who gets mad when offered a dollar by a stranger probably gets mad quite a bit throughout his day. I’m not trying or pretending to please every single person we encounter.

Charlie Todd (of Improv Everywhere fame)

Yes, handing out a bucket of money really does upset someone. You have no chance of pleasing everyone. Make tradeoffs accordingly.

October 24, 2009

Ignorance is Moral Strength

Filed under: Design,Quotes,Security | , , , , ,
― Vincent Gable on October 24, 2009

I have long been impressed with the casino industry’s ability to, in the case of blackjack, convince the gambling public that using strategy equals cheating.

Bruce Schneier

October 23, 2009

GUI is Dead, Long Live UI

Filed under: Design,Programming,Usability | , , , ,
― Vincent Gable on October 23, 2009

The term GUI, Graphical User Interface, pronounced “Gooey” is laughably anachronistic. All interfaces meant for people on modern computers are graphical. The right abbreviation to use today is simply UI, for User Interface, pronounced “You I”.

Believe me, I understand that a command line interface is still useful today. I use them. I’m a programmer. I get the whole UNIX thing. Even without a pipe, a command-line is the highest-bandwidth input mechanism we have today.

But all command lines live inside a graphical OS. That’s how computers work in the 21st century.
Picture 6.png

Whenever I see “GUI” written I can’t help but wonder if the author is dangerously out of touch. Do they still think graphical interfaces are a novelty that needs to be called out?

October 20, 2009

JavaScript Nailed ||

One thing about JavaScript I really like is that its ||, the Logical Or operator, is really a more general ‘Eval Until True‘ operation. (If you have a better name for this operation, please leave a comment!) It’s the same kind of or operator used in Lisp. And I believe it’s the best choice for a language to use.

In C/C++, a || b is equivalent to,

  if a evaluates to a non-zero value:
    return true;
  if b evaluates to a non-zero value:
    return true;
  otherwise:
    return false;

Note that if a can be converted to true, then b is not evaluated. Importantly, in C/C++ || always returns a bool.

But the JavaScript || returns the value of the first variable that can be converted to true, or the last variable if both variables can’t be interpreted as true,

  if a evaluates to a non-zero value:
    return a;
  otherwise:
    return b;

Concise

JavaScript’s || is some sweet syntactic sugar.

We can write,

return playerName || "Player 1";

instead of,

return playerName ? playerName : "Player 1";

And simplify assert-like code in a perl-esq way,

x || throw "x was unexpectedly null!";

It’s interesting that a more concise definition of || allows more concise code, even though intuitively we’d expect a more complex || to “do more work for us”.

General

Defining || to return values, not true/false, is much more useful for functional programming.

The short-circuit-evaluation is powerful enough to replace if-statements. For example, the familiar factorial function,

function factorial(n){
	if(n == 0) return 1;
	return n*factorial(n-1);
}

can be written in JavaScript using && and || expressions,

function factorial2(n){ return n * (n && factorial2(n-1)) || 1;}

Yes, I know this isn’t the clearest way to write a factorial, and it would still be an expression if it used ?:, but hopefully this gives you a sense of what short-circuiting operations can do.

Unlike ?:, the two-argument || intuitively generalizes to n arguments, equivalent to a1 || a2 || ... || an. This makes it even more useful for dealing with abstractions.

Logical operators that return values, instead of simply booleans, are more expressive and powerful, although at first they may not seem useful — especially coming from a language without them.

October 19, 2009

Less is More

Fundamentally, a computer is a tool. People don’t use computers to use the computer, they use a computer to get something done. An interface helps people control the computer, but it also gets in their way. Inevitably, any on-screen widget is displacing some part of the thing the user is trying to manipulate.

As an infamous example, expanding Microsoft Word’s toolbars leaves no room for actually writing something,

word-all-toolbars-small.png

(Screenshot by Jeff Atwood)

Users don’t want to admire the scrollbars. Truth be told, they don’t even want scrollbars as such, they just want to access content and have the interface get out of the way.

Jakob Nielsen

Show The Data

I highly recommend Edward Tufte’s The Visual Display of Quantitative Information. It’s probably the most effective book or cultivating a distaste for graphical excesses.

Tufte’s teachings are rooted in static print. But many of the principles are just as valuable in interactive media. (And static graphics are still very useful in analysis and presentation. Learning how to graph better isn’t a waste of time.)

Tufte’s first rule of statistical graphic design is, “Show the data” , and it’s an excellent starting point for interface design as well.

Cathy Shive has an excellent post expanding on Tufte’s term Computer Administrative Debris.

The Chartjunk blog showcases a few real-world examples of Tuftian redrawings.

Get Out of My Mind

Learning happens when attention is focused. … If you don’t have a good theory of learning, then you can still get it to happen by helping the person focus. One of the ways you can help a person focus is by removing interference.

–Alan Kay, Doing With Images Makes Symbols.

Paradoxically then, the better the design, the less it will be noticed. We should strive to write our interfaces in invisible ink.

October 16, 2009

Hack: Counting Variadic Arguments in C

This isn’t practical, but I think it’s neat that it’s doable in C99. The implementation I present here is incomplete and for illustrative purposes only.

Background

C’s implementation of variadic functions (functions that take a variable-number of arguments) is characteristically bare-bones. Even though the compiler knows the number, and type, of all arguments passed to variadic functions; there isn’t a mechanism for the function to get this information from the compiler. Instead, programmers need to pass an extra argument, like the printf format-string, to tell the function “these are the arguments I gave you”. This has worked for over 37 years. But it’s clunky — you have to write the same information twice, once for the compiler and again to tell the function what you told the compiler.

Inspecting Arguments in C

Argument Type

I don’t know of a way to find the type of the Nth argument to a varadic function, called with heterogeneous types. If you can figure out a way, I’d love to know. The typeof extension is often sufficient to write generic code that works when every argument has the same type. (C++ templates also solve this problem if we step outside of C-proper.)

Argument Count (The Good Stuff Starts Here)

By using variadic macros, and stringification (#), we can actually pass a function the literal string of its argument list from the source code — which it can parse to determine how many arguments it was given.

For example, say f() is a variadic function. We create a variadic wrapper macro, F() and call it like so in our source code,

x = F(a,b,c);

The preprocessor expands this to,

x = f("a,b,c",a,b,c)

Or perhaps,

x = f(count_arguments("a,b,c"),a,b,c)

where count_arguments(char *s) returns the number of arguments in the string source-code string s. (Technically s would be an argument-expression-list).

Example Code

Here’s an implementation for, iArray(), an array-builder for int values, very much like JavaScript‘s Array() constructor. Unlike the quirky JavaScript Array(), iArray(3) returns an array containing just the element 3, [3], not an uninitilized array with 3 elements, [undefined, undefined, undefined]. Another difference: iArray(), invoked with no arguments, is invalid, and will not compile.

#define iArray(...) alloc_ints(count_arguments(#__VA_ARGS__), __VA_ARGS__)

This macro is pretty straightforward. It’s given a variable number of arguments, represented by __VA_ARGS__ in the expansion. #__VA_ARGS__ turns the code into a string so that count_arguments can analyze it. (If you were doing this for real, you should use two levels of stringification though, otherwise macros won’t be fully expanded. I choose to keep things “demo-simple” here.)

unsigned count_arguments(char *s){
	unsigned i,argc = 1;
		for(i = 0; s[i]; i++)
			if(s[i] == ',')
				argc++;
	return argc;
}

This is a dangerously naive implementation and only works correctly when iArray() is given a straightforward non-empty list of values or variables. Basically it’s the least code I could write to make a working demo.

Since iArray must have at least one argument to compile, we just count the commas in the argument-list to see how many other arguments were passed. Simple to code, but it fails for more complex expressions like f(a,g(b,c)).

int *alloc_ints(unsigned count, ...){
	unsigned i = 0;
	int *ints = malloc(sizeof(int) * count);
	va_list args;
    va_start(args, count);
	for(i = 0; i < count; i++)
		ints[i] = va_arg(args,int);
	va_end(args);
	return ints;
}

Just as you'd expect, this code allocates enough memory to hold count ints, and fills it with the remaining count arguments. Bad things happen if < count arguments are passed, or they are the wrong type.

Download the code, if you like.

Parsing is Hard, Let's Go Shopping

I didn't even try to correctly parse any valid argument-expression-list in count_arguments. It's non trivial. I'd rather deal with choosing the correct MAX3 or MAX4 macro in a few places than maintain such a code base.

So this kind of introspection isn't really practical in C. But it's neat that it can be done, without any tinkering with the compiler or language.

October 6, 2009

‘Yum!’

Filed under: Design,iPhone,MacOSX,Programming | , , , , ,
― Vincent Gable on October 6, 2009

I give Microsoft’s current Mac software some shit, but I think it’s deserved. So it’s only fair I mention their glory days.

From “Classic” Mac OS 8.1 in 1998 through Mac OS X 10.2 Microsoft’s Internet Explorer (for Mac) was the default web browser Apple chose for Mac OS. The very fist iMac? It came with IE:mac, just like the first version of Mac OS X.

And IE:mac wasn’t so bad, for it’s era. (It was the first browser to have color correcting PNGs, by the way!) There was one really neat feature that I think is worth calling out: it would match your iMac’s color, automagically.

Technical Details That I Only Half Remember

If you have a better understanding of how this worked, please let me know! I couldn’t find any details online. Mostly, I’m writing down what I remember before I forget.

The poorly named Gestalt function lets you check information about the Mac OS runtime, like “what version of Mac OS is this?“. You pass it a FourCharCode, and replies with a 32-bit value or an error code — old stuff from the “Classic” Mac OS days.

There was an undocumented code, 'yum!' 1, that returned the color of an the iMac or iBook case. IE:mac would check this when it first started, and choose a color scheme to match the operator’s Mac. It was a seamless personal touch that really impressed me.

It’s the sort of thing I’d like to see more of on today’s multi-colored iPods and iPhones.

1It might have been 'Yum!', I don’t remember exactly, and Gestalt() returns gestaltUndefSelectorErr, -5551, for all of variations on my MacBook Pro under Snow Leopard.

July 22, 2009

Anti-Sustainable Design

Filed under: Design | , , ,
― Vincent Gable on July 22, 2009

I’ve previously written about how design encourages sustainability. The gist is that people keep well-designed things, so good design encourages conservation, discourages waste.

But there is an obvious dark side to attractive things: we want to have more of them. So good design encourages over-consumption.

This article on reusable grocery bags is the perfect example. Reusable canvas bags should be more sustainable than single-use plastic bags in the long run, even though they are 400x more expensive to make. But people who use well-designed bags them like them so much, they tend to acquire too many of them!

I’m guilty here too. As I wrote,

I still shave with straight razors that are 60-80 years old. Although manufacturing, say a new Thiers-Issard razor, is expensive, the legions of disposable shavers it nullifies will grow for decades, possibly centuries.

That sounds good. But note the plural in “straight razors”. Because I like them, I have more than I strictly need from a utilitarian standpoint. And the truth is, over half of my razors were are new, not heirlooms (which are harder to get in good condition). Granted, I’ve used these “new” razors for 5 years, and will continue to use them for decades. But it’s still a big resource-debt to work off. If I start buying new razors regularly, I’ll never even the score.

The very same attractive qualities of good design that transform disposable goods into artifacts of lasting utility also encourage people to use more items than they need.

July 17, 2009

Color Me Explosive

Filed under: Design,Quotes | , , , , ,
― Vincent Gable on July 17, 2009

From Wikipedia, a story of color-coding gone horribly wrong in Afghanistan,

HDRs (Humanitarian Daily Rations) are typically air-dropped into the disaster area on large pallets. The HDRs initially dropped in Afghanistan were yellow, before it was realized that the packages were the same color, and approximately the same size, as American cluster bombs, which were also dropped in Afghanistan.[1] Later packages were made in an orange-pink color described as “salmon“.[3]

(Emphasis mine, some links altered, perminant link to the quoted Wikipedia revision.)

I’ve written before about pitfalls of color coding.

« Newer PostsOlder Posts »

Powered by WordPress