A popular verse from today’s Sunday school lesson in a lesser known form:
But he’s already made it plain how to live, what to do, what God is looking for in men and women. It’s quite simple: Do what is fair and just to your neighbor, be compassionate and loyal in your love, and don’t take yourself too seriously—take God seriously.
—Micah 6:8 (The Message)
This is about Javascript programming. If you’re not interested in Javascript programming, bail now.
Say you have a Javascript array of strings that you want to convert to numbers.
['1', '2', '3'].map(parseInt) ⇒ [1, NaN, NaN]
Hmm. Why didn’t that work? Because parseInt takes an optional parameter (the radix)...
parseInt('ff', 16) ⇒ 255
parseInt('2', 1) ⇒ NaN // Because a radix of 1 always returns NaN
parseInt('3', 2) ⇒ NaN // Because 3 isn’t a valid binary digit
...and map passes an optional second parameter (the index).
[1, 2, 3].map(function(n, i) [n, i]) ⇒ [[1, 0], [2, 1], [3, 2]]
Occasionally it is very handy to have map give you that index. Often, however, I want to give map a function—like parseInt—that wasn’t explicitly designed to be used with map.
Here’s how to fix it.
['1', '2', '3'].map(function(_){return parseInt(_);});
Yuck. Not only is that verbose, it looks downright silly since the closure looks pointless.
Expression closures can address the verbosity...
array.map(function(_) parseInt(_));
..., but (currently) only Firefox versions 3.0 and later support that. Plus, it still obscures why you’re doing it.
In Scheme, I’d use cute from SRFI 26. It allows you to specify some parameters of a function. The “<>” is used for parameters that you don’t want to specify.
(map (cute string->number <> 10) '("1" "2" "3"))
Of course, while string->number takes an optional radix parameter like parseInt, Scheme’s map doesn’t pass the index, so this isn’t necessary.
Back to Javascript. A “unaryize” function looks nicer than an explicit closure and makes what you’re doing clearer.
function unaryize(f) {
return function(_) {
return f(_);
}
}
['1', '2', '3'].map(unaryize(parseInt)) ⇒ [1, 2, 3]
We could generalize unaryize to naryize.
function naryize(f, n) {
return function() {
return f.apply(null,
Array.prototype.slice.call(arguments, 0, n));
}
}
['1', '2', '3'].map(naryize(parseInt, 1)) ⇒ [1, 2, 3]
In practice, I’ve run into uses of unaryize several times, but I haven’t yet run into a need for naryize. Also, naryize is less efficient than unaryize.
What if we want to specify a radix? We could create a Javascript version of cute. I’ll use undefined instead of “<>” for the slot specifier.
function cute() {
var cutargs = Array.slice(arguments);
var f = cutargs.shift();
return function() {
var args = Array.slice(arguments);
var fargs = [];
var i;
for(i = 0; i < cutargs.length; ++i) {
if(undefined === cutargs[i]) {
fargs.push(args.shift());
} else {
fargs.push(cutargs[i]);
}
}
return f.apply(null, fargs);
};
}
['a', 'b', 'c'].map(cute(parseInt, undefined, 16)) ⇒ [10, 11, 12]
Again, I haven’t yet run into many cases where I’d want to use cute that unaryize doesn’t suffice. In this specific case, I think I’m happy with the explicit closure.
['a', 'b', 'c'].map(function(_){return parseInt(_, 16);});
Additional notes:
Array.map can be implemented in Javascript and added without any changes to the interpreter. I’m using Prototype’s.
Expression closures can’t be added without changes to the interpreter, but they can be faked with strings. See Functional Javascript
While cute can be implemented as a function, SRFI-26’s cut has to be a macro. Likewise, a cute macro is more efficient than the procedure implementation.
In Call It an ‘App Phone’ (A What?), David Pogue suggests “iPhone-like” devices should be called “app phones”. (The link in to nytimes.com, so you either have to register to read it.)
Calling it a “phone” at all seems silly to me. The phone is just one feature and not the most important one.
These are palmtop computers. “PDA” would fit; I just never liked that term.
If you aren’t a computer programmer, no doubt you’ve been really frustrated by an unhelpful error message. Actually, programmers get frustrated by it too.
The thing is, when you’re developing software you often run into places where an error could happen, but you have no idea what could cause such an error. You might know a low-level, programmer-speak reason for the error, but you aren’t aware of the bigger picture that would allow you to write an error message that would be useful to end-users.
This lack of context isn’t for a lack of trying to understand. It is because our computers are very complex system with lots of hardware and software created by many different people and many different organizations. It’s just too complex to know all the different behaviors that can emerge. Not to mention that you will expect my software to work with hardware and other software that I don’t even know exists.
Even when you have the context to write a good end-user error message, there’s a good chance that the same error will happen in a completely different context that you couldn’t have anticipated, which will make your helpful error message misleading instead.
So, often, the best you can do is write a message that will help you know what went wrong. Then when the customer calls, you can figure it out. Then you can fix the problem for that customer and make sure you have a more helpful message in the next release.
There’s still a good chance, however, that a completely different circumstance will then trigger the same error and this helpful message will end up being misleading for those users.
Since error messages that are useful for debugging end up frustrating end-users more than generic error messages, they tend to get discouraged. So we end up with the worst of all worlds: Error messages that are completely useless to everybody.
Discussion about my recent post on Van Halen’s 1984 brought up Steve Vai, who worked with David Lee Roth after he left Van Halen. Which brought to mind this blog post started in April that I’d never finished about another album that was released in 1984.
I originally had Steve Via’s Flex-Able on cassette tape. Must’ve been around 1987? I think my guitar teacher told me about it. Earlier this year, I reäcquired it in digital format.
This album isn’t your typical shred-guitar solo album. It’s not like Vai’s other albums. At least, to the extent that I’ve heard his other stuff. None of it that I’ve heard has appealed to me like the stuff on Flex-Able.
I think this album was one of the reasons I bought my first four-track recorder.
Guitar World did a 25th anniversary piece on the making of the album. While working for Frank Zappa, Steve built his own studio to record this album. He promised his friends who helped him out that one day he would pay them scale with interest for working on the album, and he eventually did. He refused to sign the deals that the record companies offered and did it all the work of releasing the album himself. Quite an accomplishment in 1984.
A trio of interesting things found today. (All thanks to Daring Fireball, I believe.)
In “Flatland”, Lukas Mathis presents a very good rebuttal to some of Tog’s viewpoint. I think I may agree with everything Lukas says there.
Lukas’s blog then pointed me to 10/GUI. I think they hit the nail on the head with the idea that the next step in GUIs is not from two-dimensions to three but to fewer dimensions. I don’t know if they have the answer, but I know that the answer involves the user spending less time managing windows.
In “Spammers, Evildoers, and Opportunists”, Derek Powazek says that “search engine optimization” is a racket, which has been my gut feeling about it. Although, I suspect that the things he calls “obvious” are—sadly enough—not obvious to a lot of people. Those things, however, aren’t really about SEO. They’re just about making a good web site.
Mac OS X 10.6, a.k.a. Snow Leopard, no longer uses an old Mac method of deciding which application to launch when you open a document. The upshot of it is that, by the old method, a document would usually be opened by the application that created it. With the new system, all documents of the same type will be opened by the same application regardless of which application created the document.
Also, the system will ignore the older way of marking the type of the file in favor of filename extensions. (Which are the “.html”, “.txt”, “.doc”, &c. at the end of a file’s name.)
There is still a way to tell the system to open a specific file with a specific application, but this can only be done “by hand” through the Finder. Other programs cannot safely do this.
“Metadata madness” by John Siracusa does a good job of explaining it all in more detail.
Personally, I avoid letting the system choose what app to open files with unless I am very sure of what it’s going to do. I can’t disagree with those who say that the functionality of creator codes ought to be restored, whether in the old form or a newer one. I won’t personally miss it, though.
I think something like Quicksilver is the future. Quicksilver is an application that allows you to quickly find documents and specify what you want to do with them. Even better, it learned from the user and was expandable. Google Quick Search Box seems to be the successor to Quicksilver, though it hasn’t caught up with all of Quicksilver’s features yet.
The biggest problem with the old Mac creator and type codes is that there was never a user-friendly way to manage them. Users could easily get into a situation in which they needed to set or modify the type code for a document, but the system didn’t give them a way to do it. There were utilities to do it, but they typically exposed the codes directly rather than providing the good user-interface you’d expect on the Mac.
UTIs are fine upgrade for type codes. Although, I’m ambivalent about UTI’s depending upon filename extensions. Filename extensions are an awful way to store file type metadata. Yet, I can’t argue with their practicality.
Examining the contents of a file to determine its type is often better than any type of metadata, though there are times when metadata is better. (Mac OS X actually comes with a Unix command-line utility that determines file type by contents.) I think a combination is probably the best choice.
Putting aside the issue that the system doesn’t use bundle identifiers in the same way, they are a fine upgrade for creator codes.
