|
Cultural Divide: It's the command-line not the OS
I agree with most of what Joel writes in his article on different cultures. But I'm left wondering how much of the cultural divide he describes is really between Unix and Windows, and how much of it is just Command Line vs "windows"
(I use windows with a small "w" to mean any windows-based OS, such as MacOS, Gnome or even Amiga Workbench)
I think comparing windows applications which "do things for Aunt Madge" with Unix programs that are for programmers is misleading.
I accept that::
- windows-based systems are good for launching useful applications which should work in a purely visual way
and
- command-line shells are good for running tools for programmers, which ideally should work nicely together allowing output from one to be piped as input to another
(MacOS (<= 9) epitomizes the windows systems by not even having a command line. And pretty much any *nix represents command-line system.
Microsoft Windows is a hybrid, but a lousy one: it's windows system is very good, but it's command-line is awful. AmigaDos circa 1986 was a better hybrid, and now of course Apple OS-X is the perfect hybrid.)
Discussing this cultural divide as Unix vs Windows makes sense only inasmuch as Unix is powerful on the command-line and pathetic in the windows department, and MS Windows is the exact opposite. But the difference between what programmers want and what Aunt Madge wants comes down to the command-line not the OS.
By command-line I mean the commands themselves and the shell they run in.
I am a Java application programmer and I work every day, as all but one of my colleagues do, on Windows - never Unix or Linux. I have done so for about five years. Prior to that however, I programmed on various flavors of Unix. To this day I still miss Unix.
And what I miss is the shell. I miss the easy script writing, the back-ticks (Lord, give me the back-ticks!) . I missed awfully the command-line completion of bash, till finally, FINALLY, they gave it to me in Windows 2k.
One day I'll switch to Linux as my main work OS just to get all those things back - being a Java programmer I have that luxury - but there's a lot of inertia to get over to set myself up comfortably in Linux (about five years of inertia) and I have work to do.
This brings me to my real point. Yes, there was a real point. Umm... Oh yeah: It's all about the shell.
MS Windows has a shell: the command prompt. Now Aunt Madge has never used the command prompt and is never going to use the command prompt , doesn't know how to find the shortcut to the command prompt , and sure as heck wouldn't know what to type in it if she did manage to launch it.
So what's it for, this Windows command-prompt?
It's for programmers.
(Sure, it's for system administrators too, but I'm trying to make a point here, and after all as far as shell-scripts go - they're programmers too)
This leads me to the question I've been asking for the last five years: Why does the Windows command-prompt suck so bad?
I mean, I'll grant you that Windows is for Aunt Madge and Unix is for me, but the windows command "dir" has exactly, precisely, no more - no less, the same purpose as the Unix "ls" command. It's the same program for the same kinds of users. Aunt Madge has never heard of either of them.
Even if 99.99% of Windows users are NOT programmers and 99.99% of Unix users ARE, I'll bet you that converted to units of "people", then that 0.01% of Windows users is numerically equal to the 99.99% of Unix users. Perhaps the windows numbers are even higher; certainly among the software engineers I know and work with, the great majority are programming on Windows - even if they don't have to.
To put it another way, perhaps 0.01% of Windows users are programmers, but 99.99% of Windows command prompt users ARE programmers.
So what *real* excuse does windows have for hobbing us with this awful command-line?
And what about those .bat files? They're a programmer's nightmare. Don't tell me they're just for simple two or three-line scripts because I've seen plenty of big complicated ones. But the language of windows commands for batch files is so much more limited than that of even the Unix Bourne shell (which predates DOS batch files by at least a decade) , that complex batch files look like assembly language in comparison to shell scripts.
So I want to know:
o Why aren't Windows command-line programs set up nicely to output in machine readable form, and to input from stdin?
o And why are windows .bat script files so horribly limited that they I still have to use %1 %2 %3 %4 %5 %6 just in case the user passes in up to 9 arguments to be forwarded on to another program being called?
o Why did command-line completion take so long, and why isn't it more configurable?
o Why could I have a nice black-on white shell window in Unix 15 years ago, but I had to put up with that horrendous dark-grey-on-black monstrosity in Windows for soooo many years?
and
o WHERE ARE THE BACK-TICKS?
And don't tell me its about the Windows-for-users versus Unix-for-programmers cultural difference. Both command-line systems are for programmers, and both have similarly sized user-bases*.
(Okay, so that's a wild-arsed guess, but the point is valid)
rhubarb
Wednesday, December 17, 2003
Just one ignorant observation. What programming tools does Microsoft offer & encourage you to use? Aren't they almost completely GUI based? It would seem to me that Microsoft's view of the command line is... it's an annoying and necessary evil, and they'd like to hobble it even more as the future comes along.
www.MarkTAW.com
Wednesday, December 17, 2003
Microsoft's development tools are always available on the command line, first and foremost. The GUIs are drivers for those command line tools.
Many of us doing .NET development in the pre-Visual Studio days were using things like TextPad and nmake.
Brad Wilson (dotnetguy.techieswithcats.com)
Wednesday, December 17, 2003
I guess the simple/obvious answer to your "why does it suck?" questions regarding the Windows command-line interface would be thar Microsoft simply never cared about the command-line experience, having included it strictly for backwards-compatibility only.
Looking forward, though, have you read about the next-gen command shell they're creating for Longhorn? The code name is Monad. It looks to be quite advanced, combining traditional command-line piping with object-oriented concepts. All tied in with .net, of course.
Whether or not it will be any good, or if anybody uses it, or even if it makes it into the initial Longhorn release remains to be seen. But it seems like they're putting a heck of a lot of effort into creating something geniunely new... the command-line interface won't be an afterthought any more.
John Rose
Wednesday, December 17, 2003
rhubarb,
I think windows has one more factor to consider: Basic.
Basic was Mircosofts first product, and Dos through to Windows has always had a variant of basic at the heart of things. From GW-Basic through QBasic right up to VisualBasic. I think that VB.net is the final breaking free from this line.
Where the shell script was central to the Unix programmer, DOS programmers always relied on Basic for automating all but the simplest tasks.
When the system became more complex Microsoft did not look to the shell for advancing the facilities, they looked to Basic and for methods that could be used in Basic.
First of all their was DDE, then there was OLE/ActiveX. These were technologies designed to help the person writing basic code rather than scripting at the shell.
The DOS prompt was only ever used for starting applications. Anything more than that would be taken care of by an application. Before windows you would have been hard pushed to find a DOS computer that did not have something like XTree installed.
To sum it up, I would say that the PC world was always Application orientated. Even before PCs had a GUI the command line was rarely used. Programmers used a language like Basic, Pascal or C. Users used the applications that programmers produced.
In the networked Unix world there were more layers. Where the PC programmer could wastefully squander all of the machines resources the Unix developers had to share and play nicely, and the far more efficient approach based on streams evolved.
Ged Byrne
Wednesday, December 17, 2003
You are right, Jed.
I would like to add a few things:
Microsoft offers the Windows Scripting Host (WSH) which is very powerful.
It allows you to write scripts using JScript or VBScript.
These scripts can access any COM object, work with files and folders, even instantiate MS Word and write something in it, and then print it. You can access MS Access databases, etc.
The problem is, you need documentation for it. You can search for this or get yourself a book.
There are enough alternatives, such as:
- Windows Scripting Host (described above)
- Bash for Windows (yes, bash has been ported to Windows and it works)
- TakeCommand from http://www.jpsoft.com is excellent
- WinBatch is excellent
MX
Wednesday, December 17, 2003
In fact, I think the cultural divede can be traced back to one snippet of code:
Repeat
Until Inkey$>""
The GW-Basic programmer would not have thought twice about using this idiom. Send the processor into a loop just to do nothing while we wait for the customer to catch up.
Whenever your running a windows App that is apparantly doing nothing yet performance monitor shows 100% usage then there's probably a bit of code not unlike the one above churning away.
The above code could never have been acceptable in the Unix world, because the processor was being shared. This is why more complex models such as blocking io had to be developed.
They developed in the Unix world because they were necessary. They did not develop in the Dos world because there was no need.
Ged Byrne
Wednesday, December 17, 2003
Mx,
There are all recent developments, and welcome ones. WSH appeared about the same time as IE. It was part of Microsofts response to the Internet threat.
My mail point is that event before Windows PCs were never a command line environment.
Ged Byrne
Wednesday, December 17, 2003
The biggest problem I have with wsh or likely monad or any other Windows scripting is that it is not an extension of the cmd shell. In Unix I go to a prompt and I interactively type commands. If I want to write a script, I type those SAME commands in a file.
WSH is its own environment with a big disconnect from command shell. In Unix it is the same. If I simply use the command line in Unix I am learning to write scripts at the same time. I can use the command shell in Windows until the end of time and it doesn't help me write WSH scripts.
Mike
Wednesday, December 17, 2003
The Windows command line probably sucks as bad as it does because it was first deployed on a 4.77-MHz system with only 64K of memory and no inter-process memory protection, let alone processes.
Although hardware has evolved since then, MS has seen no need to evolve the software.
David Jones
Wednesday, December 17, 2003
I think there is one basic fact that many fail to see, I don't WANT to remember command programs and their many switches.
Like others, I've developed on various flavors of Unix, DOS, OS/2 and Windows over the years. I happily left the command line behind a long time ago and only rarely miss it. I will admit that when I do miss it, I miss it in a BIG way. But again, rarely.
Frankly I have far too much to remember in my programming career as it is. My brain is crammed to the bursting point already.
What gui's give me, is the ability to easily accomplish tasks without having to remember arcane syntax. Even if the syntax isn't all that arcane, I just find it easier to type text in a text box than to remember whether to quote my string, put a space between it and its switch, etc etc.
So consider me an Aunt Marge programmer. I want my programming tasks to be simple, easy to accomplish, and not involve a large amount of administivia type knowledge that really does little to further my goals of development.
I've always felt that many, but not all, command line jockeys feel some sense of superiority because they know all of the switches and how to pipe them together.
Shrug, I'd rather be focusing on other things than which one of the 18 switches do I need to find a file using ls.
OcccamsRazor
Wednesday, December 17, 2003
Most of the original poster's points about the allegedly terrible Windows command prompt are obsolete, as he himself acknowledged, so I'd just like to point out that this one isn't true either:
"And why are windows .bat script files so horribly limited that they I still have to use %1 %2 %3 %4 %5 %6 just in case the user passes in up to 9 arguments to be forwarded on to another program being called?"
Use %* to represent all parameters, regardless how many. This is an extension in Windows 2000/XP/2003 (and possibly NT). Today Windows batch files can also do subroutines and if-then-else branching, by the way.
The only terrible thing about the current batch file format is the documentation -- it's a bitch to find anything useful about it in Windows Help (though it's all there somewhere).
Chris Nahr
Wednesday, December 17, 2003
Original post is dead on--well said! What killed me when I left OS/2 for Windows 95 (I saw the writing on the wall . . . ) was no more Rexx. No built-in command-line power.
For those missing a real command line on Windows: Cygwin, Cygwin, Cygwin! ( http://www.cygwin.com/ ).
Rob Warner
Wednesday, December 17, 2003
"I think there is one basic fact that many fail to see, I don't WANT to remember command programs and their many switches."
They're reportedly working on getting IntelliSense working for Monad. Now that would rock. :-)
John Rose
Wednesday, December 17, 2003
What Ged is saying appears reasonable. The command prompt in Windows has always been geared to simple administration of the machine, and as DOS machines were standalone and could only run one app at a time there was no need for a complicated shell.
Also bear in mind that the Unix shells and shell commands were developed by thousands of people over twenty-odd years.
Now the command prompt saves time if you really remember the commands - in other words for a limited set of commands you use all the time. Therefore the Windows decision to have a command prompt with a limited repertiore and development tools with GUI's for more complicated stuff does make sense.
Stephen Jones
Wednesday, December 17, 2003
I think the Windows command prompt keeps getting better with each new release. I'd be very *very* surprised if it went away in Longhorn. They're realizing that there is a large contingent or (possibly mainly programmers) who like to use cmd and do so on a regular basis.
I spend a lot of time in there (cdb, running perl scripts to process text files, network diagnostic utilities, UNIX carryovers via cygwin, etc etc.)
You can pry my keyboard out of my cold, dead, hands...
Michael Kale
Wednesday, December 17, 2003
--
I've always felt that many, but not all, command line jockeys feel some sense of superiority because they know all of the switches and how to pipe them together.
Shrug, I'd rather be focusing on other things than which one of the 18 switches do I need to find a file using ls.
--
All other things being equal command line jockeys are better. They know how to do something you are too lazy to bother with.
Reading Joel's last article I sensed that many, but not all, windows developers feel some sense of superiority because they are too "pragmatic and get things done" to be bothered with a command prompt.
If you are serious about getting things done you will use a GUI tool when appropriate and use a command line tool when appropriate as well. I don't have all the command line switches memorized either, but it doesn't take up a lot of brain-space to remember how to find the reference book when I need it.
NathanJ
Wednesday, December 17, 2003
"Why could I have a nice black-on white shell window in Unix 15 years ago, but I had to put up with that horrendous dark-grey-on-black monstrosity in Windows for soooo many years?"
The ability to change the colours has been there since Windows NT 3.51 came out, eight years ago.
John Topley (www.johntopley.com)
Wednesday, December 17, 2003
Ah REXX - fond memories....
DJ
Wednesday, December 17, 2003
Ged - I don't think busy waiting comes into the cultural divide at all. It certainly isn't a windows idiom, you do that crap and the screen won't even paint. The typer won't be able to see his own words.
In fact, the windows api was designed so that it almost looks like you are writing a busy waiting loop in your main procedure, but in truth the windows functions you are calling make sure it is not waisting cycles looking for something that isn't there.
Keith Wright
Wednesday, December 17, 2003
Keith,
Again, I was referring back to the days of Dos programming. Back then this was the standard way to wait for input.
Many bad programmers still use the windows variant:
Repeat
DoEvents
Until Inkey$ = ""
Of course, windows provides a much better message based architecture but I think the attitude of 'the computer is mine, mine I tell you' is still part of the windows programming culture.
Ged Byrne
Wednesday, December 17, 2003
Maybe I'm just backwards here, but I don't think that cmd.exe is all that bad.
I've done Unix programming, most recently under HP/UX with ksh, and I have to say, cmd.exe was *much* more usable than ksh was. I've also used bash, and command line completion in windows works much better than bash.
In bash, if you type a couple of characters and it matches a couple of characters, bash beeps at you. Hit tab again, it gives you a list of potential answers, and you have to type in the one you want.
Cmd.exe gives you the first match. Hit tab again, get the next match. Simple and much cleaner.
As far as dos commands being usable with stdin/stdout, if you look at the options for dir, for example, you can turn off headers & footers, and whatnot. The difference is that in unix, ls defaults to the filter mode, and the user has to always type switches (or use an alias) if they want a decently human readable listing.
Dir defaults to the human readable listing, and if you want a filter, you need to use the switches. Personally I think this is the right approach since the you can just stick the switches in your batch file and forget them.
Chris Tavares
Wednesday, December 17, 2003
To me, there are several level of abstraction:
- GUI are mainly for "hurried end users",
- command line UI are for "devoted users"
- libraries, compilers and linkers are for "programmers".
- assembly is for microprocessors :-)
So i think that the real point of the article is that
"when unix was created there were no end users",
there were just "devoted users", who are naturally
more willing to spend a some time to "fill the gap",
(i.e. read the documentation, and use command line tools).
So, while i definitely agree that for a programmer,
life is much easier under the "unix culture", i think
that THE REAL REASON why the unix culture values
textual interfaces, is NOT because they are somehow
USEFUL to programmers (a programmer only needs libraries,
compilers and linkers), and NOT even because programs
that use textual i/o are clearly EASIER to develop,
read through, and reuse.
I think that the unix culture values textual interfaces
just because traditionally, it assumes a "devoted" user,
which is not necessarily a programmer, but is definitely
"closer to the programming world".
Giampiero Campa
Wednesday, December 17, 2003
Do you know all switches for "for" in cmd by heart?
Useless example of some switches and piping...
(@for /F %i in ('dir /s /b /a-d "i*"') do @echo %~nxi ) | find "doc" | sort
WildTiger
Wednesday, December 17, 2003
Just to echo Michal and Rob...
Cygwin (ie bash, ls, grep.... ) + ruby / python / perl should solve nearly all your command prompt usage needs.
Batch files get you the rest of the way, although sometimes getting the escaping on // and \\ characters can be an absolute pain...
A command shell without decent editing keys or history search is painful to use.
(Using cmd.exe's "F7" key is better than nothing, but not a lot....)
Gordon Hartley
Wednesday, December 17, 2003
"What programming tools does Microsoft offer & encourage you to use? Aren't they almost completely GUI based?"
* Good point. I used VisualJ++ a lot when it was in its hey-day (that is, pre-lawsuit) and while I found it a very effective way to program, a day never passed where I didn't have to type something on the command line and run at least one or two scripts. I still do in fact.
"Microsoft offers the Windows Scripting Host (WSH) which is very powerful.
It allows you to write scripts using JScript or VBScript.
[...]
* The problem is, you need documentation for it. You can search for this or get yourself a book."
Yeah I tried to use WSH once and just found that the learning curve to get started was way too steep for the small task I wanted to automate. Windows batch files and shells scripts have the advantage that you start just by entering normal commands which you already know, and can learn the extra control structures if and when you need them. Having said that, one day I'd like to have another go at WSH, so please point me to the simplest documentation or example.
By the way, whatever happened to that nifty Recorder utility in Windows 3.1? That was very useful and had no learning curve.
"The only terrible thing about the current batch file format is the documentation -- it's a bitch to find anything useful about it in Windows Help (though it's all there somewhere)."
*Sorry, beg to differ on this one. There are many more terrible things about batch files. The old Bourne shell is still way more powerful. Eight years ago I wrote an IRC-like program for chatting around the office in Bourne shell - do that in a .bat file in Windows XP!
"They're reportedly working on getting IntelliSense working for Monad. Now that would rock. :-)"
* Command-line with intellisense - now you're talking!
"The ability to change the colours has been there since Windows NT 3.51 came out, eight years ago."
* Hey, that's still seven years of monstrosity.
"There are enough alternatives, such as:
- Windows Scripting Host (described above)
- Bash for Windows (yes, bash has been ported to Windows and it works)
- TakeCommand from http://www.jpsoft.com is excellent
- WinBatch is excellent"
* I second the nomination for the JP stuff - 4Dos is a big improvement over the windows command line, but still not close to any Unix shell. (I've used all three extensively)
"In bash, if you type a couple of characters and it matches a couple of characters, bash beeps at you. Hit tab again, it gives you a list of potential answers, and you have to type in the one you want.
Cmd.exe gives you the first match. Hit tab again, get the next match. Simple and much cleaner."
* Yeah I like the windows behaviour here too. Is that configurable in bash? Note that 4Dos also does it the windows way (many years before windows did it) and has another very nice feature: For the command history, you can start typing any number of letters before hitting Up-Arrow and it will limit the history choices to matching entries.
"Looking forward, though, have you read about the next-gen command shell they're creating for Longhorn? The code name is Monad. It looks to be quite advanced, combining traditional command-line piping with object-oriented concepts. All tied in with .net, of course."
*Wow, this sounds cool indeed. And it supports my original thesis:
Why are they adding powerful piping functionality and more to the command line in Longhorn? Because they want to be more like Unix? Because they want to bridge the cultural divide? No, I'm sure none of this occurred to them. They just want to make he command line better. Because the command line is for programmers.
So this only goes to prove my point: Piping and other powerful command line features do not indicate a cultural difference between Windows and Unix, they indicate that the Unix command line is *better*. They do not indicate that Unix is more programmer-centric than Windows, because the command lines in both OS's are used by almost exclusively by programmers.
I'm looking forward to Monad
Thanks for all the corrections on the time-lines and new features in the windows command-line.
rhubarb
Wednesday, December 17, 2003
"A command shell without decent editing keys or history search is painful to use."
Are you aware of the Doskey program?
Chris Nahr
Wednesday, December 17, 2003
"There are many more terrible things about batch files. The old Bourne shell is still way more powerful. Eight years ago I wrote an IRC-like program for chatting around the office in Bourne shell - do that in a .bat file in Windows XP!"
I don't know if that would be possible -- but do you? Your posts (and those of others in this thread) indicate that you are completely unaware of the extended batch file commands available since Windows 2000. It's nearly as powerful as 4DOS today, though maybe not powerful enough for this application.
On the other hand, and perhaps more relevant to the cultural divide between Windows and Unix, why on earth would you want to do that? Why not use a real programming language such as Python if you're going to write a real program?
Chris Nahr
Wednesday, December 17, 2003
>All other things being equal command line jockeys are
>better. They know how to do something you are too lazy
>to bother with.
That's exactly the attitude I'm refering to. Why would lazy have anything to do with a desire to not have to remember the arcana of command line syntax?
It incredibly similiar to the Visual project builders, ala ide, vs good ole make or nmake if you are so inclined. I spent many years happily creating all of my make files by hand. Did it work? Yes. Was it fun? No. Was it hard to remember? Absolutelty.
You could argue that knowing all of the command line switches for the linker or compiler are necessary for the "non lazy" programmer. Personally I find it far faster and easier to simply choose the appropriate checkbox next to the option I want in my visual ide.
If you feel "better" thinking those of us who don't want to remember command line syntax are somehow inferior to yourself. Well, by all means go ahead and feel that way. More power to you.
OcccamsRazor
Wednesday, December 17, 2003
OcccamsRazor, how do you automate builds?
Wednesday, December 17, 2003
"In bash, if you type a couple of characters and it matches a couple of characters, bash beeps at you. Hit tab again, it gives you a list of potential answers, and you have to type in the one you want.
Cmd.exe gives you the first match. Hit tab again, get the next match. Simple and much cleaner."
I *hate* the "windows style" autocompletion. The "bash" style makes MUCH more sense to me. I rarely want to complete to the first thing alphabetically (the chances of which obviously go down the more items you have which match), and I can't stand the idea of cycling through the options. The bash style allows you to type the minimum number of characters required to uniquely identify the thing you are trying to autocomplete. It is just much more natural to me to have it fill it as much as it can and then ask me to do type another character for a clue as to which of the remaining choices I want, and then repeating the autocomplete.
If I were choosing between the following words:
autocomplete
automobile
automatic
autonomous
And I wanted "autonomous" it is much more natural for me to hit "a <tab> n <tab>" than to hit "a <tab>" and have it display an item that is totally unrelated to what I want, and force me to cycle through the choices.
I guess the main thing is for me the bash style works much better when you want to do autocomplete multiple times within the word, as when words have the same prefix.
Mike McNertney
Wednesday, December 17, 2003
The problem is that cmd.exe is the least common denominator for windows scripting. Even if such things as cygwin and WSH exist, it is something I can't rely on being available everywhere. The sh and bash shells, however, are the least common denominator for unix scripting and is orders of magnitude more powerful. Process control anyone?
a cywin user
Wednesday, December 17, 2003
"Why would lazy have anything to do with a desire to not have to remember the arcana of command line syntax?"
Windows GUI Hell has involves just as much arcana as any command line program I've ever encountered. "Which tab was that configuration option on again?" Instead of remembering command line arcana such as "x" means extract, "v" turns on verbose output, and "c" means compress for the tar command you have to remember some (often long) series of mouse clicks that takes you to the tab or dialog or wizard that has the feature that you want to use. For example, to turn off the cursed menu option hiding "feature" you have to go into IE and select Tools, then select Internet Options, then dig around through the seven tabs that you're presented with until you finally find the check box on the Advanced tab for Enable Personalized Favorites Menu (if you're lucky enough to remember that is the name of this "feature"). Then you still have to remember another chain of mouse clicks to turn it off for the Start Menu. Even worse, the hierarchy of these dialogs, tabs, and menu options has a tendency to be rearranged in every new release and some of the options are renamed as well. It's really noticeable when you're trying to talk someone through the procedure over the phone and they're using a different version of Windows than the one that you work with most of the time. How all of this is supposed to be any less arcane than remembering "ps -eaf | grep program_name" or "kill -9 pid" is beyond my comprehension. Text is at least relatively easy to memorize.
anon
Wednesday, December 17, 2003
Dear anon,
I think you're right on this one. I often find I'm asking myself the question "Now how the heck did I do this last time". Sometimes it takes me a day to remember, and an hour or so going through the tabs.
The advantage of the GUI is that you can explore. You have a limited number of choices already configured, and can try each one out and see what it does. This is not advisable with the command shell.
If you know the command shell options, are know what you want to do and hit /? in windows, then it is more productive, and arguabley easier to find your way around. But if you are learning or uncertain, then the GUI is a better educational tool.
Stephen Jones
Thursday, December 18, 2003
>OcccamsRazor, how do you automate builds?
I'm not suggesting that I wouldn't choose to create a full make type build environment, command line driven and all, in a production development environment. The needs of that environment largely drive me to the greater power and control of a non gui set of tools.
I am suggesting that in many cases, particularly in company internal application development efforts, I don't need all of that power and the visual build capabilities are quite sufficent.
This all came about from a "lazy programmer" comment.
My point is that lazy and "unneeded complexity" are orthogonal. Because I choose to use a gui development environment the majority of times should not be confused with "lazy".
I have used, and will use the command line again. But I find that I have less and less reasons to do so as gui tools improve in power. Now that I have built in "find and replace in files" type functionality, I have little need, AS A DEVELOPER, to use the command line.
I'm practically forced to a gui development tool today regardless. Yes I know I don't absolutely have to use one, but the productivity gains almost mandate it.
Once I was doing the bulk of my work in a gui I found that the syntax of command line switches just kinda got forgotten and its more difficult, for me at least, to go back and re-remember it when my develoment environment offers much the same abilities within.
OccamsRazor
Thursday, December 18, 2003
>The advantage of the GUI is that you can explore. You
>around. But if you are learning or uncertain, then the GUI
>is a better educational tool.
My feelings exactly. Maybe it is the nature of my work as a consultant. I'm constantly on different platforms, development environments and tools. I can't possibly remember them all over time.
The gui allows me to forget things and find them again with more ease...in my opinion.
But I certainly agree that many times I've been frusterated trying to find that darn dialog I used last month that let me set that crucial option.
I still think its easier with a gui but I'll agree that it is annoying in both cases.
OccamsRazor
Thursday, December 18, 2003
--
That's exactly the attitude I'm refering to. Why would lazy have anything to do with a desire to not have to remember the arcana of command line syntax?
--
It sounds like you are saying that it is too much work to remember the syntax. I'm calling that lazy.
I'm not saying YOU specifically are inferior. I just feel that the GUI-users of the world have their own sense of superiority over the command line users. A lot of them seem proud their brain is too valuable to waste space with meager command line arguments.
To me the whole thing seems similar to the attitude in the US that it's ok to be bad at math because math is too hard and we have calculators that can do it all anyway.
NathanJ
Thursday, December 18, 2003
I agree with Anon too, options dialogs are a nightmare.
Text configuration files win hands down:
1) You can explore them just like a GUI.
2) They can include comments.
3) You can search the text for keywords (this is the clincher)
4) You can be far more expressive with a textual options.
Ged Byrne
Thursday, December 18, 2003
It seems as though bash could use some updating as well.
One this that really drives me crazy is the limited number of command-line interpolations. For example, I might be working with a directory that has 100,000 files in it. When I want to get rid of those files, I type:
rm -f *.txt
And I get this error:
-bash: /bin/rm: Argument list too long
So I have to resort to using perl to do it:
ls | perl -ne 'if (/.*\.txt/){`rm -f $_`}'
I think the bash argument limit is 65,535 or something like that. I know it will interpolate at least 10,000 arguments, but definitely not 100,000.
Bash isn't what I'd imagine if I could conceive of the world's best shell. Far from it.
Admittedly, it's way better than cmd.exe, but I'd like to see both of them improve. Perhaps the new command shell in longhorn will be worthwhile. If so, it will probably spawn a dozen shell-improving projects for unix as well. (Kind of like .NET is the impetus behind Mono and .GNU)
That would be a good thing.
Benji Smith
Thursday, December 18, 2003
Try
find . -name \*.txt -type f -print | xargs rm
Much faster, and a bit more intuitive (to me, anyway). You can leave out the "-type f" if you know that everything that matches *.txt is a regular file. find can produce a list of names of files matching nearly any set of criteria you wish; xargs executes the named command against the list, in as few invocations as possible.
You don't *want* an unlimited buffer of arguments to pass to a command. That way lies buffer overflows and security cracks.
Jay Maynard
Friday, December 19, 2003
>I'm not saying YOU specifically are inferior. I just feel that
>the GUI-users of the world have their own sense of
>superiority over the command line users. A lot of them
>seem proud their brain is too valuable to waste space
>with meager command line arguments.
I'll give you that one. I see that attitude many times, typically from developers that have never worked on Unix. They don't understand, or see, the power the command line does give them. That said, having worked for years with both, I personaly find the gui better. But it is clearly personal.
>To me the whole thing seems similar to the attitude in the
>US that it's ok to be bad at math because math is too
>hard and we have calculators that can do it all anyway.
I agree, and I'll admit to some of that attitude myself.
Deep down I wish I had gone further with calculus that I did. Although I have found absolutely no application for the calculus I did complete in my career, I still feel somehow lessened for it.
OccamsRazor
Friday, December 19, 2003
What I'd like to see is a command line closer to human language. Forgetting a switch is normal enough, forgetting your mother tongue isn't.
However, since it's unlikely to be commercially viable, I'm not holding my breath.
A cynic writes
Friday, December 19, 2003
At the risk of making gross generalization and highly inflamatory remarks (which is what the column seemed to invite)...
It is indeed a cultural difference that is bred by the differences in philosophy of the OSes. Unix treats its users as intelligent creatures, whereas Windows assumes they are idiots. Not idiots in the sense that you're too dumb to use our program, but you're so dumb that one can get away with buggy code if it just paints a pretty picutre on top, or if there is a officious looking dialog telling you, the user, it's really your fault.
Since intelligence is defined differently by each individual, the unix philosophy can often make ease of use and GUI less of a priority. But nothing is worth the contempt Windows has for its users. To demonstrate this cultural difference one can observe how java programs with different backgrounds handle errors in a GUI application.
Anti CodeBiggot
Monday, December 22, 2003
 Recent Topics
Fog Creek Home
|
