Hacker News Reader

Comment by Semiapies | Hacker News Reader

An unsatisfying story. The first half of the story is about an algorithm to produce ovals. Then most of the rest is Steve Jobs convincing the guy that rounded rectangles are desirable. Then, without any narrative about this actual central problem (which the guy had no idea how to do when the conversation with Jobs ends), we're told that he just happened to solve it.

EDIT: I find the bouncing up and down of votes for this interesting, particularly the reasons people give for disagreeing.

View on HN

I disagree. Rounded rectangles are a signature Mac OS user interface feature. Thanks to post-Steve Jobs Apple, there is renewed interest in everyhing Apple, and rounded rectangles are truly everywhere. You would have a hard time finding a popular web site not using them.

What is really interesting in this story is not the algorithm itself, but how Steve Jobs convinced Bill Atkinson by taking a walk outside with him to show how common rounded-corners are in "real-life".

What does the importance of rounded rectangles have to do with how satisfying or well-told a story is?

A story can be satisfying because of its relevance. I think that is the case here. The topic is interesting to developers who want to understand how Apple approaches design, even though the story's structure might have some flaws.

You're misunderstanding my objection.

It does not matter how relevant you find some aspect of this story, it's still poorly told - and this should be especially clear if the focus on the the interaction between Atkinson and Jobs is what you consider key. Half of the story is about details of an algorithm that simply don't matter if the core of the story is Jobs badgering Atkinson into being willing to code rounded rectangles.

The background about the algorithm helps you understand why Bill is reluctant to go back and implement a new different drawing primitive. His reluctance is the reason why Steve needs to work hard at convincing him, which demonstrates the theme of the story.

I agree that it's probably too detailed in the first bit, but I don't see it as a major flaw for a series of articles about the development of the original Macintosh. The intended audience consists of hackers and developers who get intrigued by technical details.

If the first algorithm is worth spending time on, so is the second. If the second isn't, then the first isn't.

A bad story that is relevant, can still be interesting.

A bad story that is about some subject no one cares about, can not.

Depends what you're looking for. This isn't a story about some bit of code. It's a story about someone (Steve Jobs) who knows how to inspire and motivate people, and a practical example of how he inspired this excellent programmer to push beyond what he thought was capable, by getting across exactly why it was so important.

Most of the story isn't about that. If that's the center of the story, then the first half of it is merely going off on a tangent. It's a badly-composed story.

Nor do we need more "I told the programmer we needed this thing he said was problematic and he did it" management just-so stories.

> Nor do we need more "I told the programmer we needed this thing he said was problematic and he did it" management just-so stories.

Why would that be? Is this a kind of story you disagree with for some reason? Are you arguing that it's a bad story because it's badly composed or because you don't like the theme?

This story wasn't written by the manager in question, so I also don't see how you can personify the author in the first person in your pseudo-quote.

In order: because I think they're harmful, yes, and as I stated, both.

Also, I was not personifying the author.

Showing how clever the oval algorithm was gives us the right emotional setup to the conflict--Atkinson is justly proud of his own cleverness until Jobs, almost dismissively, demands even more from him. The central conflict of the story isn't between Atkinson and the problem, it's between Atkinson and Jobs, and the story holds itself to the emotionally salient facts about how that conflict is resolved--the rounded rectangles work and Atkinson is again very proud and happy.

Well, either that or Hertzfeld never got around to learning how roundrects were implemented.

I get your complaint, because that's not the conflict you wanted the story to center around, but given the conflict it does center around, I don't think it's that poorly composed.

Well, I'd rather the story center more firmly around the Atkinson/Jobs conflict or the whole sweep of Atkinson going from clever hack to being convinced about the rounded rectangles to figuring them out as well. I don't need to know the math to appreciate the trickiness of making quick ovals on Lisa hardware, but if we're going into that, I want to know how he worked out the roundrects as well.

I agree...I want to see the algorithm for drawing rounded rectangles! I assume that he was able take his oval rendering code and use it for the corners of the square. Never mind, that would probably still leave the story unsatisfying.

Fine, here's the source file. http://github.com/jrk/QuickDraw/raw/master/RRects.a

Edit: Luc already linked to the source archive in this thread, so I changed my link specifically to the RRects.a file.

Because everyone understands Assembly?

Don't worry, 68k assembly is easier to read than x86 assembly. This code is nicely structured and heavily commented. Don Knuth called Atkinson's QuickDraw and MacPaint code some of the best ever written.

Of course, if I'd actually read the code before linking to it, I'd have realized that this file doesn't really answer avgarrison's question because the algorithm is in DrawArc.a (see Luc's post earlier in this thread for an archive with the rest of the files).

Should we take it from your username and the comment about 68k assembly that you've played with the MC68332 a bit or is it just coincidence :-)

Haha, just coincidence :-)

Thanks! It's weird that a) Bill Atkinson also used all-caps for his mnemonics, as did I when I grew up on the MC68k; b) how it brings me back to the Amiga (yes, I know this code pre-dates the Amiga, but still).

Not sure if you mean to be pointlessly snarky or not, but hearing about his thought process and how he got a quick algorithm for a harder problem to work would have been much more interesting - and from a storytelling POV, would have been much better - than an abrupt "and then he came up with the solution", especially after the long bit on how he generated ovals.

I'm actually endeared by the story being a dump of everything the author witnessed, rather than being carefully engineered (with some stuff expanded on, some stuff dropped) to provoke a particular reaction in the reader.

Except, of course, that it isn't "a dump of everything the author witnessed" without things expanded or or dropped. A big chunk of it is exposition about an algorithm - and not even the one in question.

When you relate events, you inevitably "engineer" them, even if only unconsciously or by your judgement of what's relevant or not. Storytelling is about how to engineer usefully and usually entertainingly, particularly to the people you're telling the story to.

I especially don't buy the idea that Bill Atkinson, after demonstrating fast ellipses, would then claim that rounded rects would be "really hard." Indeed, the enhancement would be trivial.

I think that Atkinson probably thought that roundrects would be a useless addition that would bloat the library. (Remember, the entire Mac OS and applications needed to fit in 128K!)

It's easier to dismiss something as "entirely too hard" than to get into an argument about whether it's worth implementing.

I disagree. I think round rects have more edge cases than ovals (such as a 10 pixels high rectangle with corner radii of 8 pixels)

It could also be that he thought it would be too hard because he knew he only had 42 bytes of ROM space to play with.

A lot of the best inventions seem obvious after the first person comes up with them. Especially when it comes to code.

I found this in the comments of the posted article’s website:

http://news.ycombinator.com/item?id=1637442

It's not that doing rounded rects would be hard, but that doing them really fast would be hard.

Everything is trivial in hindsight.

This story has probably been told repeatedly, and it lost something being written down instead of told…

See the comment I quoted here:

http://news.ycombinator.com/item?id=1637442

Reply on news.ycombinator.com