August 07, 2007
Walter Bright wrote:
> I'm a command line interface curmudgeon. The reason is simple- it's more productive, since:
> 
> 1) I can touch-type. There's no such thing as using a mouse without looking. Using a mouse is like being forced to type using only your left pinkie, and every program you use has a different keyboard layout.
> 
> 2) I have muscle memory in my fingers, meaning a lot of complex commands can just spew out with no thought required.
> 
> 3) Pipes are cool. Can't do the equivalent with a gui.
> 
> 4) I routinely write simple batch files to automate whatever I'm doing at the moment. Can't do that with a gui.
> 
> 5) Ever tried to do a series of repeated actions with a gui? Like, one by one, save all the emails in a folder to a text file? It's agonizing. With CLI, I'll just dude up a quick batch file using cut & paste, and it's done.
> 
> 6) Most of the time I need a command, I've already done it, so I just type the first couple characters then F8, bam, I'm flying.
> 
> Guis have their uses - mainly for programs you aren't familiar with. But once you are familiar, CLI is faster.
> 
> P.S. I use microEmacs, not vi. Mainly because I have the source to it and just fix it to work like I want.

what you say assumes that GUIs imply mouse usage. i consider a GUI buggy if it can't be fully and efficiently controlled with the keyboard only (as i hate using the mouse as well). i agree with all your points, but they can apply to GUIs as well.

regarding the batch-file issue: an IDE should actually help you to write more effective batch files by providing you more environment variables (for project management for example) and assign shortcuts to them.

developers of older editors appear not to adapt more recent features like "goto declaration", member auto completion, supporting the debugger for navigating at source level or refactoring stuff. i guess there is little doubt about the usefulness of these features.

i'm using a pretty bare bones editor plus a command line myself, but i consider it a temporary solution. i'd like a bare bones editor with "goto declaration" so i dont have to mock around with search and bookmarks all day :)
August 07, 2007
Derek Parnell wrote:
>> Let me put it another way. How many people use a profiler?
> 
> BTW, I've tried to use the profiler a couple of times now, but the output
> is so obscure I can't work out what the hell it is trying to tell me.

yep, i use -profile regularly but the only portion of the trace.log i use is the one documented (#calls, tree time, func time, etc.). my guesses for the others have failed so far ;)
August 07, 2007
Walter Bright wrote:
> Post a snippet of the output and point out what is unclear, and I'll try to help.

the sections that come first, before the list of functions sorted by "func time":

------------------
    1	_D5seatd6parser9GLRParser5parseMFKAxaPPS5seatd6parser10SyntaxTreeZb
 1095	_D5seatd6parser11MainGrammar5parseMFKAxakkbZb12reduceBranchMFkZb
 1856	_D5seatd6parser11MainGrammar5parseMFKAxakkbZb11shiftBranchMFkZb
_D5seatd6parser11MainGrammar5parseMFKAxakkbZb	2952	122732995	3009972

the sections appear to list the functions that are directly called by the top most in the section. but i can't figure out what the numbers mean and why there are some entries with a single one on the left and some with 3 numbers on the right of the function name.
August 07, 2007
Walter Bright wrote:
> Derek Parnell wrote:
>> On Sun, 05 Aug 2007 11:06:10 -0700, Walter Bright wrote:
>>> FWIW, a lot of hard core programmers still use vi.
>>
>> And I think that some are even still chipping away at granite blocks :)
> 
> I'm a command line interface curmudgeon. The reason is simple- it's more productive, since:
> 

You distort the argument somewhat, by mentioning ahead several tasks which are specific to the command line *shell*, whereas what was being discussed was programming and editing source code.

> 1) I can touch-type. There's no such thing as using a mouse without looking. Using a mouse is like being forced to type using only your left pinkie, and every program you use has a different keyboard layout.
> 

Good GUIs understand this, and understand that it's important to have several available shortcuts for common tasks. Eclipse in particular is designed to be able to work without using the mouse *at all*, and it actually has developers testing it's usability that way (ie, prohibited from using the mouse), to ensure it works well. Eclipse also has an Emacs keybindings setting for text editors.

> 2) I have muscle memory in my fingers, meaning a lot of complex commands can just spew out with no thought required.
> 

Same as above.

> 3) Pipes are cool. Can't do the equivalent with a gui.
> 

Shell-specific point.

> 4) I routinely write simple batch files to automate whatever I'm doing at the moment. Can't do that with a gui.
> 
> 5) Ever tried to do a series of repeated actions with a gui? Like, one by one, save all the emails in a folder to a text file? It's agonizing. With CLI, I'll just dude up a quick batch file using cut & paste, and it's done.
> 

When I have need for such a thing (a more complicated series of actions), I load up the CLI and do it there. That's why I have Cygwin installed in Windows, and why an Explorer context menu option that opens a shell on the selected folder. The remainder 95% of the time is spent using the GUI.
But again this was a shell-specific point. When programming, I don't recall ever *having the need* to do a series of repeated actions in an IDE. Perhaps you can give an example?
(The closest I recall is "refactoring" C++ code, but that's something where the CLI won't help you either)

> 6) Most of the time I need a command, I've already done it, so I just type the first couple characters then F8, bam, I'm flying.
> 
> Guis have their uses - mainly for programs you aren't familiar with. But once you are familiar, CLI is faster.
> 
> P.S. I use microEmacs, not vi. Mainly because I have the source to it and just fix it to work like I want.

GUI based programs intrinsically have more usability potential that text-based ones, just for that fact that you can have a text-based/command-line interface in a GUI (or alternate to it), but the reverse is not true.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
August 07, 2007
Bill Baxter wrote:
> It might be neat to define an API for the compiler.  I mean an api that would let you write programs that link to d-compiler.lib to do various things like get an AST etc.  I know D syntax tries to be easy to parse, but why not just have the spec also specify an api for would-be D compilers.  Giving a compiler a well defined API is not really something specific to D but it would make a lot of things easier.

FWIW, i'm writing a library like that ATM.
i'm testing it with various D code right now. it parses phobos, i'm going through tango now. dstress will be next.
August 07, 2007
Reply to Bruno,

> Walter Bright wrote:
> 
>> 1) I can touch-type. There's no such thing as using a mouse without
>> looking. Using a mouse is like being forced to type using only your
>> left pinkie, and every program you use has a different keyboard
>> layout.
>> 
> Good GUIs understand this, and understand that it's important to have
> several available shortcuts for common tasks. Eclipse in particular is
> designed to be able to work without using the mouse *at all*, and it
> actually has developers testing it's usability that way (ie,
> prohibited from using the mouse), to ensure it works well. Eclipse
> also has an Emacs keybindings setting for text editors.
> 

If I ever manage an app development team, for the first GUI demonstration I'm going to walk in with a pair of tin snips and cut off the mouse. A bit dramatic, but I will show how well the UI works from the keyboard.

>> 3) Pipes are cool. Can't do the equivalent with a gui.
>> 
> Shell-specific point.
> 

But should it be? How nice would it be to have the full UNIX tool kit available inside of find and replace (find this pattern, run it through this pipeline, replace with output). And why stop there? Just yesterday I was mucking around in some C# and due to some refactoring, I had to add gobs of casts. I would almost have killed for a semantically aware find and replace (find all errors where function X has no overload resolution, If adding a cast to Y for the args fixes it, do that) How about a more general functionality, find and replace with SQL queries? I could go on but just imagine.

>> 5) Ever tried to do a series of repeated actions with a gui? Like,
>> one by one, save all the emails in a folder to a text file? It's
>> agonizing. With CLI, I'll just dude up a quick batch file using cut &
>> paste, and it's done.
>> 
> When I have need for such a thing (a more complicated series of
> actions), I load up the CLI and do it there.

I generally don't even bother with a shell script, just use a pipeline ending in " | bash"

> When programming, I don't
> recall ever *having the need* to do a series of repeated actions in an
> IDE. Perhaps you can give an example?

build a switch block from an enum where their will be one case per value


August 08, 2007
Bruno Medeiros wrote:
> But again this was a shell-specific point. When programming, I don't recall ever *having the need* to do a series of repeated actions in an IDE. Perhaps you can give an example?

Here are some:

. global file renaming
. running automated test suites
. interfile search/replace across a subset of the project files
. copying a subset of the project files into another directory
. running the debugger with the same complex set of commands, over and over

> (The closest I recall is "refactoring" C++ code, but that's something where the CLI won't help you either)

Sure it does, the CLI has very powerful text processing tools available to it.
August 08, 2007
Jascha Wetzel wrote:
> Walter Bright wrote:
>> Post a snippet of the output and point out what is unclear, and I'll try to help.
> 
> the sections that come first, before the list of functions sorted by "func time":
> 
> ------------------
>     1    A
>  1095    B
>  1856    C
> D      2952    122732995    3009972
> 
> the sections appear to list the functions that are directly called by the top most in the section. but i can't figure out what the numbers mean and why there are some entries with a single one on the left and some with 3 numbers on the right of the function name.

I renamed the functions for simplicity.

D is called 2952 times. 1 of those calls comes from A. 1095 come from B.  1856 come from C. Note that 1+1095+1856 = 2952. (The A, B, C counts are called the "fan in".) The "fan out" is a list of counts of what D calls, and follows the line for D.

The total number of timer ticks spent in D is 3009972, excluding whatever D calls. The total number of timer ticks in D, including whatever D calls, is 122732995.

From this information you can not only determine where the time is being consumed, but *why*, as you know where the calls are coming from. You can do this to determine the runtime relationships between functions, which can be used to set the link order (and this is output by the profiler in the form of a .def file).
August 08, 2007
Walter Bright wrote:
>  From this information you can not only determine where the time is being consumed, but *why*, as you know where the calls are coming from. You can do this to determine the runtime relationships between functions, which can be used to set the link order (and this is output by the profiler in the form of a .def file).

thanks, this is very useful!
August 08, 2007
What about automatic code refactoring?

Try renaming a method that is overloaded with batch files.

Walter Bright escribió:
> Derek Parnell wrote:
>> On Sun, 05 Aug 2007 11:06:10 -0700, Walter Bright wrote:
>>> FWIW, a lot of hard core programmers still use vi.
>>
>> And I think that some are even still chipping away at granite blocks :)
> 
> I'm a command line interface curmudgeon. The reason is simple- it's more productive, since:
> 
> 1) I can touch-type. There's no such thing as using a mouse without looking. Using a mouse is like being forced to type using only your left pinkie, and every program you use has a different keyboard layout.
> 
> 2) I have muscle memory in my fingers, meaning a lot of complex commands can just spew out with no thought required.
> 
> 3) Pipes are cool. Can't do the equivalent with a gui.
> 
> 4) I routinely write simple batch files to automate whatever I'm doing at the moment. Can't do that with a gui.
> 
> 5) Ever tried to do a series of repeated actions with a gui? Like, one by one, save all the emails in a folder to a text file? It's agonizing. With CLI, I'll just dude up a quick batch file using cut & paste, and it's done.
> 
> 6) Most of the time I need a command, I've already done it, so I just type the first couple characters then F8, bam, I'm flying.
> 
> Guis have their uses - mainly for programs you aren't familiar with. But once you are familiar, CLI is faster.
> 
> P.S. I use microEmacs, not vi. Mainly because I have the source to it and just fix it to work like I want.