On Sunday, Nov 16, 2003, at 13:19 US/Pacific, R. Joseph Newton wrote:
Rob Dixon wrote:[..]Joseph wrote:I don't mind it for source files, but having to type "foo.pl" to run the "foo" command strikes me as excessive user hostility.
..and so does double-clicking on the script icon?
Which, to be fair, doesn't allow any command-line parameters apart from those that you thought of yesterday.
Windows uses a graphical interface with a nervous nod towards command-line interaction. It is largely sculpted by marketing considerations.
I would definitely grant that limitation. I'm just not a big fan of
command-line parameters, for the most part.. I'll admit, when I
double-clicked the file I'd been working on to test my point, it was a rare
event. I'm usually running from the prompt in order to get my debugging
info. Bear in mind that that information is not significant to my user. I
only get output to STDOUT when something is going wrong.
before I jump into the 'sorta depends what you want' effort to point out gooder and badder solutions in the GUI v. CLI Jihaud, a brief refresher course on history.
let's skip over the technical details that Windows noticed that Apple's GUI approach was a great way of solving many of the basic simple user interface types of problems. Since that way would take us back to Xerox PARC, and we might not want to get into the problems of Human Interfaces.
At which point we would also need to deal with the slow up take that Microsoft went through in its awakening to the fact that not only was there an internet out there and that the web was not merely some set of Drug Addled behaviors comeing out of CERN and DOE.... So please, do try to remember that some of us here were around when the sysadds at microsoft.com had their little series of email oopsies about correctly configuring their sendmail daemons, et al... Or should we be impolite and chat about the MIT based 'x windows' - currently at X11R6(???) and still a fun solution for various types of cross platform GUI solutions.
If anyone should get smacked around for
... uses a graphical interface with a nervous nod towards
command-line interaction. It is largely sculpted by marketing
considerations.then that would be Steve Jobs, who right up to the release of OS X was trying to convince folks that the 'terminal.app', their CLI tool, was not really something that they were sure was going to still be around in the production release. Mac's were suppose to be 'gui driven' simple 'point and click' tools for 'normal people'. But of course the Freaks who like unix will give up their CLI interfaces ONLY after you have ripped them from their Cold Dead Hands..
That most of the current generation of windows users may not remember the history, let us please not try to re-write it.
That having been said, the problem of 'command line interfaces' is one I soooooo love. If I hate anything its the freaking 'swiss army blade' approach that some folks take to making the One True App with a Gagillion command line options. ( and yes, if you have not read the compiler options, please, do, those people are a leading cause of things like Make and Ant, because, well, no SANE PERSON wants to remember all of that smack and type any of it at the freaking command line... ).
So yes, there are times I so love the simpler 'click this' approach to solving 'issues' on the day to day basis for my desktop system. But there are also many very useful and important places for 'back end systems' that will run a whole lot simpler and leaner without a GUI interface mechanism running to deal with them. The idea of 'headless servers' is still something that makes many 'intel boxes', irregardless of OS, twitch since they have this deep seated need to see the 'monitor, mouse and keyboard' to get through certain stages of their initialization sequence.
So if one is happy in a headless environment, then telnet, ftp, yourFaveHere, can be your best friend. In those cases having simple short commands with a reasonable number of command line options is all one needs. Even IF one is going to be stacking some 'GUI monitoring tool' at some 'front end' to the process, to keep down one's labor costs - it is best to remember how to build those on top of simple basic code that becomes a bit more flexible, and hence maintainable, with an appropriate CLI interface.
If one is never, ever, going to be working with servers, or back end issues, then of course it is paramount that one makes their tool set with the Human in mind.
So when we make the assertion
Its course of life has been the result of user bigotry.
it could be because the servers in the back room are for doing things that do not need to have a lot of human interaction with mouse, monitor, keyboard I/O sub-systems, hence the folks who made their choice of OS's are driven by performance issues that can be less than 'human friendly' - since one only wants to send a human to deal with it on rare occasions, so there is no good reason to install minesweeper on them....
I say this, having solved the generalized management solution in perl, the old fashion way, with a few perl modules that delivered the core common frame work, then some applications. All of which got delivered into production, even though the Really Cool Vendor Supplied, Vendor Supported, Vendor Licensed GUI suite was not picked up. Ironically, of course, the folks in the NOC were still able to 'telnet' into the unix machines on really 'thin pipes' and maintain them with the stock stuff delivered, but had, well, challenges on the non-unix side of the house, since all of that was soooo tied to being GUI only...
In short pick the weapon you need for the mission you are on. Trust me, it's a good maxim in coding as well...
ciao drieux
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
