Six Laws of the New Software

LordFoom writes "Still suffering from post-dotcom stress disorder, I keep my eye out for gentle balm to sooth my ravaged psyche. The manifestos at ChangeThis are not it. The most popular manifestos range from irritating to enlightening, with none of them particularly comforting. In particular the recent Six Laws of the New Software have done my dreams of writing lucrative code no good - although it has changed my idea of what money-making code is."

Comments

In a nutshell

[winkydink]

Keep it simple
Keep it small
You're not gonna be the next Microsoft
Do many releases
Comply with relevant standards

Re:In a nutshell

[cyber_rigger]

7. Don't post a link on /. to your development machine.

Re:In a nutshell

[darkpixel2k]

The sixth rule of the new software is: you do not talk about the new software!

In the end of last century...

[melted]

There was a widespread belief among physicists that there's nothing more to discover in physics. They were wrong. This guy is also wrong.

Re:In the end of last century...

[Brian Brian]

Anyone proclaiming the end of anything has just demonstrated the limits of their mind.

Here's another law to add

[Dancin_Santa]

When developing a web browser, if a plug-in needs to be launched, don't let the plug-in's loading cause all other instances of the browser to lock up.

I'm looking at you, Firefox.

What's the deal with the PDF-format anyway? The document is 17 pages of Powerpoint-like slides. I'm sure some nice, simple HTML could have displayed that much more quickly. And not locked up Firefox for a minute.

Re:Here's another law to add

[Leo McGarry]

This old saw needs to die, now. It's completely false to say that "the whole graphics subsystem is built on PDF." That simply isn't so. Let me explain where that came from.

Back in the olden days, there was this thing called QuickDraw. QuickDraw was pretty incredible. It consisted of a full-featured set of routines for drawing on the screen, and the whole business fit inside something like 32 KB of ROM.

QuickDraw was based on the idea of pixels. Everything was a pixel. Drawing with QuickDraw was based entirely around pixels.

Quartz abandoned the idea of pixels in order to give programmers a device- and resolution-independent graphics toolbox. Quartz consists of two parts: a drawing library called Quartz 2D, and a windowing and real-time compositing system originally called Quartz Compositor. A couple years back, Quartz Compositor was re-implemented in GPU code and re-christened Quartz Extreme. (Quartz Compositor still runs on Macs without programmable GPUs.)

The imaging model used for Quartz 2D was inspired by both Display PostScript and PDF, but it's not the same as either of them. Unlike QuickDraw, where everything was about pixels, in Quartz 2D it's all about paint. Quartz 2D establishes a floating-point coordinate system called a context, and the programmer draws on the context by defining regions and filling them with paint. Internally, everything is represented as a display list, as opposed to a bitmap like in the old days. The display list gets rendered to the screen by Quartz Extreme.

Because Quartz 2D uses a similar imaging model to PDF's, Quartz 2D display lists can be translated to PDF trivially. The whole business is handled for you. All you have to do is request a Core Graphics PDF context instead of a regular Core Graphics context and draw to it just like you were drawing to a window. Core Graphics is responsible for translating your Quartz 2D display list into PDF.

So let's be totally clear here: None of the graphics on your Mac are represented internally in PDF format until your program explicitly requests that a display list be saved in PDF format. Internally, everything is a Quartz 2D display list. The computer converts to and from Quartz 2D quickly and easily through the use of some highly optimized Core Graphics code.

Now, you wanna know why Acrobat is so much slower than Preview? Because Acrobat uses its own PDF interpreter to go from PDF to QuickDraw. This takes a ton of CPU time, compared to going from PDF to a Quartz 2D display list. So Acrobat is both much bigger (because it includes a whole PDF interpreter) and much slower than Preview.

On Windows or Linux or whatever other incredibly lame operating system you want to consider, a PDF reader is necessarily going to be big and slow, because it's gonna have to translate from PDF into some bitmap format. Old operating systems don't have the advantage of having an internal display-list graphics format that's conceptually similar to PDF, or a hardware-accelerated compositor that's responsible for turning those display lists into pixels. But that still doesn't change the fact that the PDF specification is wide open, and anybody who wants to should be able to write his or her own PDF reader for those old operating systems.

Incidentally, Quartz 2D used to be notably slower than QuickDraw for doing lots of basic tasks. If you take antialiasing and transparency off the table and just deal with drawing lines, QuickDraw used to kick Quartz 2D's ass. No more, though, because Quartz 2D has recently been rewritten to take advantage of programmable GPUs, just like Quartz Compositor was rewritten and became Quartz Extreme. Now, depending on the kind of GPU you have, Quartz 2D can be anywhere up to 40 times faster than QuickDraw ...and that's with antialiasing and transparency. It's pretty amazing.

Frankly, it kinda makes me wonder why more people aren't raving about Quartz. I guess it's probably because most people don't unde

Next time I'll check the link better.

[Anonymous Coward]

Actual pdf

Law 7

[DrKyle]

All the good stuff has already been thought of, but not everyone knows they exist. Try to find really good ideas by looking back at least 10 years for a piece of software that never took off and has been abandoned and remarket it as the next big thing. Remember: Marketing people could sell blood to a turnip.

Hint: How to avoid PDF lock-up in Firefox

[QuestionsNotAnswers]

Tools | Options | Downloads | Plugins

Untick PDF.

Now whenever you click on a PDF link you are prompted if you want to view it in Adobe PDF viewer.

Works for me!

The "Collaborate" Suggestion and Unix

[Zergwyn]

Most of these suggestions are common sense to anyone who has a couple of serious software projects under their belt, which isn't to say that they aren't worthwhile to look through. However, one in particular made me think of an old question of mine, having to do with the way unix works vs the modern GUI. On page 6, the pdf discusses the "Collaborate Law". It says:

"Forget enterprise systems that do everything possible within your field. They're too large, clumsy and require too much development time. Instead, create small discrete software that can collaborate seamlessly with the technology that the end users are currently using."

This, in a nutshell, seems to be the core philosophy behind much of the original Unix. Most Unix apps (and in particular, all the 'commands' which are small applications) have the concept of standard in (stdin), standard out (stdout), and standard error (stderr). Because most commands can operate to accept stdin, do its purpose, and then send to stdout, it is both possible, intuitive, and very practical to chain together many small commands to accomplish a single task very easily. I suspect there is some terminology for this process, but as I don't know what it is I generally think of it as being a "stream centered" approach. You have many discrete components operating on a stream of information. However, I know of no similar functionality in most modern GUIs, which are all basically application-centered approaches (though Windows tends to present itself as being document-centered). Each application is a single thing that you open up, and has its own self contained operations, usage, etc. I would like to see this more object-oriented stream approach exist in more GUIs today, because it is really a very useful paradigm for many tasks. It allows developers to concentrate on doing a single task extremely well, and then allows users to chain that task in as many ways as they can imagine, which is always more then what the original developer could think of. In Mac OS X 10.4, the Automator feature sounds like it might very well be close to what I have in mind, though a lot will depend on how easily and powerfully developers can make new 'Actions' (Apple's terminology for single task apps/commands). However, these days I really think that is an old concept that is time tested and very useful and just waiting for the right re-implementation to become critical for a new generation.

Re:pdftotext

[coopaq]

Would everyone just GO AHEAD AND PRINT this already!!!