Comment by arjunnarayan | Hacker News Reader

Comment by arjunnarayan | Hacker News Reader

The real difference is that you can take a unix program (which obeys the dont blabber rule, is a command line program with lots of options, etc.) and with a good amount of effort put a GUI on top of it to make it look pretty. Case in point: Ubuntu. It attempts to do this to most tools, and succeeds in many ways. My computer illiterate father was soon able to wrap his head around Synaptic package manager (which is just a wrapper around APT).

But you can't take a Windows-culture program and make it easily programmer accessible. This is a one way street. I think that the Unix-style dual access is far more powerful. Apple doesn't open source its work, but it is BSD based and I get the feeling that internally, Apple follows this "unix culture" (I hesitate to use the article's terminology, but bear with me here) and thus comes out with powerful programs that are command line accessible but have wrappers (albeit beautiful ones) around them. This is what enables them to refactor internal parts like in Snow Leopard that cut out gigabytes of cruft - it starts to sound like this "unix culture" is simply best-practice engineering in terms of modularity and flexibility of individual packages. If Microsoft even attempted to refactor some parts of the OS, they'd break something terrible.

I disagree with Joel where he says Apple follows the Windows culture. It seems that OS X is factored "the unix way" up to a point - where a beautiful API is exposed, and another team (the Steve Jobs insane perfectionist team) takes that and puts a usable beautiful front-end on it, which may, in Joel's mind fit the "Windows-culture", but is thin enough that the unix-culture layers beneath hold the meat of the OS, and thus can be modularly modified rapidly.

Linux lacks this final layer, which leaves it looking so broken and hacked together at the top. It still is an open question if the front end can be created without the dictatorships of a large company like Apple or Microsoft at the helm - but if anyone's got a shot, I think Canonical would come closest.

It's worth considering that both approaches may be one-way streets. It's easy to underestimate the effort required to put a good GUI onto a command-line program of any complexity. Often the UI is an order of magnitude more complex than the "program" part of the program.

Last spring, I wrote a clone of the old video game Master of Orion in javascript. Step one was to get the simulation working, and it took a couple days to effectively model the universe, planetary growth models, ship movement and combat, and basically everything needed for a playable game. At that point, all that was left was to "slap a GUI onto it" so that you could interact with that simulation.

That GUI Slapping took at least 20 times the effort of the game engine itself. UIs are complicated. They have little details and corner cases. They need to correct for human behavior, and more importantly, they need to feel right. That's a ton of work, and it seems to get overlooked every time I hear this unix vs windows culture debate.

So yeah, it's damn near impossible to tack a good command line onto a complicated windows app. It's also damn near impossible to tack a good UI onto a complicated command line app.

(I'll leave it to others to insert the comment about 15 years of "linux on the desktop" being evidence of the above.)

I disagree, look at kfind for instance. It's a great front end to find.

Certainly complexity depends on the program but wrapping most *nix philosophy utilities isn't hard, but it isn't useful either you neuter their power.

The "Windows-culture" way of making something programmer-accessible is to provide an API, usually using COM (preferably with IDispatch support for ease of use and scriptability), or these days .NET. Such an interface is richer than one can normally get using the command-line, which is essentially forced to multiplex possibly multiple threads of control and interaction with many program "objects" through a single bidirectional pipe.

The bidirectional pipe has other benefits, of course; it's easily remoted using ssh or even straight TCP, rather than needing the complexity of DCOM (made easier using IDispatch and variants/type/etc. with built-in remoting support).

Are you saying that a single bidirectional pipe is the only way that two linux programs can communicate?

No, but that's the most obvious way to wrap a GUI around a command-line app.

Just as a side note, the "gigabytes of cruft" mentioned cut from Snow Leopard curiously comes to almost exactly the size of removing the PPC binaries from Leopard.

1. They removed PPC, but added x86-64 (which has larger code size).

2. Binary is not the largest part of an application bundle (e.g. Mail binary [ppc, i386] is 5.7 MB, Mail.app bundle is 286 MB).

Too bad the web browser started on the wrong side of the street.

You mean NeXT, which was Unix?

And whose current version is called MacOS ;-)

Check out Uzbl!

They need to optimize that thing. I may have been an early adopter but the rendering and the speed of rendering was pretty bad. Worse than FF.

Uzbl's gotten a lot faster since it learned to talk to the cookie handler over a socket (rather than spawning a new handler for every request). That was committed a week or two ago.

Thank you. I will. I've been whining for a while about how the web browser isn't Unixy enough.

Reply on news.ycombinator.com