Comments for Vincent Gable

Comment on open source just isn’t a very good strategy for fixing ugly by Vincent Gable

Vincent Gable — Sat, 28 Jun 2008 19:20:31 +0000

Open-sourcing something is inherently design by committee — because you are letting everyone have input. Design by committee does not not make pretty; you need an individual vision, and consistency for that.

I tried to find pictures of ubuntu, and they didn’t strike me as “bam, pretty open source.” I wouldn’t say hideous, but I wouldn’t say pretty.

Comment on open source just isn’t a very good strategy for fixing ugly by mike

mike — Wed, 25 Jun 2008 20:17:49 +0000

Should have left that in the context of symbian. open source has actually done a damn good job of fixing ugly. go look at slackware, then ubuntu, then a customized ubuntu install with all kinds of fancy compiz plugins. bam, pretty open source.

Comment on Nobody Likes a Pimp by Demosthenes

Demosthenes — Sun, 22 Jun 2008 08:06:26 +0000

It’s about fucking time. His “I’m so bad-ass” and “Man I never get any” attitude often turned me off to him. Very cool/smart guy, but seemingly unversed in how to make friends.

Comment on Objects that Won’t Hide by ZachR

ZachR — Mon, 26 May 2008 16:28:47 +0000

There’s also -[NSView enclosingScrollView] as an alternative to superview/superview

Comment on Low Level Optimization Decays With Time by Vincent Gable » Blog Archive » memcopy, memmove, and Speed over Safety

Vincent Gable » Blog Archive » memcopy, memmove, and Speed over Safety — Sat, 24 May 2008 19:42:42 +0000

[…] less value then changing the algorithm that’s requiring all that duplication. It may even suddenly become slower when hardware is […]

Comment on Useful Mac OS X Text-Editing Shortcuts by Vincent Gable

Vincent Gable — Tue, 08 Apr 2008 04:30:48 +0000

ctrl-a/e and some emacs bindings do work in Carbon text-fields, but I’m not sure what the hard and fast rule is. ctrl-k does not seem to be supported as often. I wish these shortcuts would be officially documented by Apple, because they are useful.

Personally I’ve never found ctrl-t to be useful, and that’s why it’s not in the list. Usually I correct words through the spell checker, and in cases like “teh” I’m not sure that carefully positioning the insertion-point between e and h, then hitting ctrl + t is that much faster then double-clicking on the whole word “teh” (faster then fine positioning) and typing t + h + e (probably slower then recalling and invoking the transpose command). Truth is, ctrl-t is probably slightly faster ergonomically, especially for people who spell better then me — but I’ve never found it useful so it’s not on this list.

Comment on Useful Mac OS X Text-Editing Shortcuts by Jason Petersen

Jason Petersen — Fri, 28 Mar 2008 18:26:34 +0000

Oh yeah, and I noticed you missed ctrl-t, which I find a bit weird but useful; it’s “transpose” and switches the two characters around the cursor.

So if you typed yuor, put the cursor between u and o and hit ctrl-t to fix.

Comment on Useful Mac OS X Text-Editing Shortcuts by Jason Petersen

Jason Petersen — Fri, 28 Mar 2008 18:25:24 +0000

I could be wrong, but i think these commands only work in Cocoa widgets.

Comment on Low Level Optimization Decays With Time by Vincent Gable

Vincent Gable — Fri, 07 Mar 2008 23:59:31 +0000

Yeah, the dividing line between “low level” and “algorithmic” optimizations isn’t always clear. Sometimes hardware drives what algorithm is most appropriate. Vectored processors can make a hash/look-up-table based approaches a lot more appealing, for example.

Comment on Low Level Optimization Decays With Time by Zach Beane

Zach Beane — Fri, 07 Mar 2008 14:03:50 +0000

Unfortunately, many hand-tuned Lisp programs must work with the limitations of the implementation today, such as the native machine word size or the performance of various built-in operators.

For example, I wrote a CRC32 routine that had to split up work into 16-bit halves to deal with the tiny fixnums of LispWorks (they’ve since gotten bigger), and I had to write my own routine to copy parts octet-arrays because REPLACE was just too slow by default.

If the implementation improves, I have to revisit the code…