Free Your Technical Aesthetic from the 1970s • Hacker News Board

Re: Free Your Technical Aesthetic from the 1970s

#21

Post by lucifer » Sun, Jul 18, 2010, 3:52 AM UTC

_delirium wrote: post #2

There seem to be two sort of unrelated criticisms here. One's a preference for GUI (or at least full-screen console-mode) interfaces over CLIs, and generally for fewer config files and command-line options. The other is a dislike of chaining piped commands, and a suggestion that integrated scripting languages like Perl are the replacement. But those seem like two pretty wildly different directions to go in. And there…

The essay was about programming aesthetics. (Related: http://www.jwz.org/doc/worse-is-better.html)

My read of it was that systems 'like' Unix are in a cooperative relationship with their end-users, and are not the 'servant'. This burden on the user is rewarded with the 3 cited characteristics.

He further framed this relationship in terms of "dated" main frame style programming and concerns -- scarce computational resources and subsequent minimalist (some would say cryptic) approach to defining the API for the OS.

Certainly you can put a pretty GUI on top of Unix: http://artbinaire.com/blog/wp-content/uploads/2010/04/iphone... (Hello?:) That's not the point.

The point is that that pretty shiny GUI is not as stable as the underlying OS. But the reward here is that the "system" is in a master-servant relationship. ("man pages" ...)

Re: Free Your Technical Aesthetic from the 1970s

#22

Post by djacobs » Sun, Jul 18, 2010, 4:04 AM UTC

I just finished reading The Art of Unix Programming. Eric Raymond gives insight into exactly why this is a bad analysis.

Regarding the anti-CLI argument:

GUIs are helpful for one-time tasks... things that don't require much repetition. They are discoverable (i.e., the learning curve can be easier) and easier for non-technical users.

However, as one understands the CLI and the power of DRY code, one gravitates towards it for its power, simplicity, reusability, and transparency.

Commandline options only make the programs more versatile and scriptable, further boosting productivity.

Of course we could do a bug-by-bug comparison of standard Unix tools to standard MSFT tools, but I'd rather not go there.

Re: Free Your Technical Aesthetic from the 1970s

#23

Post by djacobs » Sun, Jul 18, 2010, 4:09 AM UTC

0bfusct3 wrote: post #20

moomba wrote: post #17

Earlier quoted context omitted.

I'm wondering why you're saying linux has no place in distributed computing. Most supercomputers and distributed systems run linux. Not sure what paradigm shifts are going to have a significant impact on the OS. The only changes I've seen are in hardware/programming syntax as of late.

Sure they do but they use extremely specialized software that probably took years to apply to the platform let alone developing the software. Linux is the top in distributed computing because it filled a niche (free) and has momentum if BSD, L4, etc was created then / didn't have some sort of issue we'd all be using kernel x instead of linux

What, specifically, about the Linux kernel and Unix structure makes them bad for distributed applications, again?

Re: Free Your Technical Aesthetic from the 1970s

#24

Post by 0bfusct3 » Sun, Jul 18, 2010, 4:47 AM UTC

djacobs wrote: post #23

0bfusct3 wrote: post #20

Earlier quoted context omitted.

Sure they do but they use extremely specialized software that probably took years to apply to the platform let alone developing the software. Linux is the top in distributed computing because it filled a niche (free) and has momentum if BSD, L4, etc was created then / didn't have some sort of issue we'd all be using kernel x instead of linux

What, specifically, about the Linux kernel and Unix structure makes them bad for distributed applications, again?

c, capabilties (or lack there of), self healing, runtime based optimizations, concurrency, locking, threading and just generally the way it's structured it's not meant to be a distributed operating system the applications developed for it show this. Have you seen how glusterfs, lustre or any other distributed FS works? They bend over backwards trying to implement a POSIX API usually with hideous hacks.

Re: Free Your Technical Aesthetic from the 1970s

#25

Post by njonsson » Sun, Jul 18, 2010, 4:50 AM UTC

Looks like somebody's gone off his meds.

Re: Free Your Technical Aesthetic from the 1970s

#26

Post by [deleted] » Sun, Jul 18, 2010, 4:54 AM UTC

djacobs wrote: post #23

0bfusct3 wrote: post #20

Earlier quoted context omitted.

Sure they do but they use extremely specialized software that probably took years to apply to the platform let alone developing the software. Linux is the top in distributed computing because it filled a niche (free) and has momentum if BSD, L4, etc was created then / didn't have some sort of issue we'd all be using kernel x instead of linux

What, specifically, about the Linux kernel and Unix structure makes them bad for distributed applications, again?

[deleted]

Re: Free Your Technical Aesthetic from the 1970s

#27

Post by djacobs » Sun, Jul 18, 2010, 4:54 AM UTC

0bfusct3 wrote: post #24

djacobs wrote: post #23

Earlier quoted context omitted.

What, specifically, about the Linux kernel and Unix structure makes them bad for distributed applications, again?

c, capabilties (or lack there of), self healing, runtime based optimizations, concurrency, locking, threading and just generally the way it's structured it's not meant to be a distributed operating system the applications developed for it show this. Have you seen how glusterfs, lustre or any other distributed FS works? They bend over backwards trying to implement a POSIX API usually with hideous hacks.

As far as I know, building small is the best way to do concurrency. (And the functional programming paradigm is in some ways an extension of the principle of building small.) Also, traditional Unix philosophy (the kind this author is arguing against) rejects threads in favor of lightweight, inexpensive processes and IPC and sockets.