James Kanze said:
That's what I generally used to think: you wouldn't really want
an IDE in a professional environment
All good pragmatic methodology I read had a chapter "Sharp tools".
, but for learning, they
would permit you to abord one thing at a time.
That sounds like massive prejudice.
Now that I've
actually used one a bit, I'm less sure. (But maybe that's just
because of my frustration.)
James, please, from what you write it is evident you didn't *use* one in the
professional sense. So your conclusions are premature.
Looking back, i started quite every new thing with RTFM. Really. Before
(maybe instead
the install. Not aiming to memorize all the details,
but make a point to read through all the all the controls and use cases.
So later I have some figure if something is or is not there.
I see many other people just jump into it, and try to pick up as it goes --
the result is ceratinly they never discover 95% of the functionality, and
loudly express what sucks -- or just stay improductive and frustrated about
it.
My experience is that doing the tutorials absolutely worth the time
investment.
And the usual wisdom -- never be shy to ask those who are ahead. Especially
if they gladly offer the help.
The software is full of genuine sources of frustration, why increase it
voluntarily?
Without such support, I guess I'd have to agree. (I was very
frustrated with the restrictions in the IDE when I wrote my
first posting.) On the other hand, can you really learn C++
effectively without some initial support?
I did it, so it is possible -- but no way would I suggest anyone that way
when by now support is easily available. Some support at least.
Certainly the ideal way is (IMO) to get into a team with a good expert
mentor. (hardly easy in practice, while getting into a WTF environment has
wide chances...)
I don't find that to be the case, at least not in professional
environments. Everywhere I've been before, most people worked
most of the time from the shells.
And that "everywhere: is mostly unix-or-like? ;-)
But sure, of course people use shells, what would they. explorer.exe in win
is a shell too. Certainly a single shell hardly good for all tasks, so we
use more than one. I use FAR manager for traditional reasons, to company to
explorer, most people I saw use Total Commander. but there is no
shortage...
And they are there to work -- though during development I'm sure spend most
of the time in an editor.
Where I am now (the first
100% Windows environment for me), it's not so much the case, but
the shells are used for any number of scripts and other things.
And very often, when there's something more complicated that
needs to be done, I can get it done faster from the shell than
the Windows experts can do from the GUI.
Of course. Different tasks ask for different tools. And a professional
development env surely use many stock ustils, and even more homegrown ones
that cover for the usual cases.
Having graphics and mouse is an ability -- not a handcuff that would deny
other ways. TMK "usable without mouse" is still an aim un UI design for
graphic desktops, wherever makes sense. (And is pretty frustrating indeed to
see that some applications did not bother to straighten the tab order or use
duplicate or missing accelerators. What doesn't need a line of code....)
What I was trying to say above in the () is that IME the atomic tools are
not executed directly from the command line all that often. But from more
specific tools.
Eg. I can't recall when I launched pkzip directly the last time. But have a
plenty of "scripts" that use it.
That isn't the issue. In practice, you really only want to do
one thing at an ATM. Developing software requires a large
number of different activities, from designing UML, writing HTML
documentation, writing code, compiling, setting up code reviews,
etc. Some of this is supported by the usual tools, but in
practice, you're almost always doing something a little bit
more than what they offer.
That is the whole point.
Deep inside the machine there sit the atomic elements, maybe that non-quoted
image that is invoked like
atm -withdraw -v:$ -amount:50
but on the face there exist a single button that can be punched to that
effect.
Like on my last unix project, how many times I issued make on command line?
Quite never. There was a script buildPackage, that asked what platform, what
target kind, label, etc, then invoked ant here, make there. How many times
I invoked buildPackage? Again quite never, I fixed it to accept answers from
command line, then has a script 'bp' that issued the params that were fixed.
And for partial builds there was 'm' that issued make in the directory with
some magic arguments and capture the output and filters it and presents me
the errors/warnings at the end.
Also there was a dozen aliases that navigated to the most used
directories -- and you could make the observation of "using the shell all
day" though it was most time sitting there and the history like
cdm
m
m
m
cdvox
bp
cdm
.... repeat ... ;-)
In my vocubulary that part in not the "work".
(I also shall mention my sad observation that some other people got stuck at
the buildPackage level and typing the answer to the 5-6 question every time;
one answer being like XXXX-64-java-linux that could be pasted from the list
of possibilities written to the terminal. And hope the problems stay within
terminal's history range, as redirection does not play with
interactivity...)
Back to the point, IME the *bulk* of the commands issued on command line.
And so could be invoked from something else -- hotkey, menu, button, etc.
All of which is present with a good editor/shell combination
under Unix (or Windows, with bash and gvim). I suppose that you
could call it partially integrated, but if you invoke make from
vim, it will position you on the error.
Will it? Interesting, my people did use vim and didn't have that feature.
Guess it is not out of the box, or is picky to something -- or they were
just ignorant. While those using IDE not really had the option to miss the
auto-navigation to errors.
OTOH, if you have your environment with all those featires, in my vocabulary
it is an IDE. And surely not "just an editor" when it actually invokes
build on one end, and processes the build's output on the other.
And we hopefully adree that professional development needs that kind of
integration, and it brings better productivity compared to really separate
editors that have no feed to or from, and have no clue about usual cases
like the compile-fix-typos cycle and the others.
Plus a lot of other
things. (I find that when restructuring code, I make a lot of
use of :argdo g/.../... for example.)
And why typing :argdo more sexy than ctrl-H (or alt-E R or hitting the
Replace button on the toolbar?)
Actually you can do it even almost that way, as the toolbar box for the
search text can invoke macros, and it is no problem to write a macro that
separates the arguments then invoke replace with the all-open-files
option=yes. Customization only goes 99.5%, so possibly it should look look
like
but I'd rather keep a 1-key and try to open the regular dialog with the
option set to all-files, and type in the text. I use that operation way
to rarely to bother about the extra click.
dislike about Visual Studios is that it doesn't support your
third point; it presents a lot of not particularly relevant
information, but still makes it very hard to find the relevant
information.
My experience is different. For very long (in up to 6.0) I mostly used just
the find-in-files (the builtin grep on steroids).
In my last project, that was some 3MLOC monster with every possible and
impossible WTF put together in 15 years, starting with
"no-documentation-figure out from code", I pushed it under VS2008, and
switched to the code-browser facilities. The difference is drastic. (
Like you need all invocations of Foo:
rocess(void) -- hopeless case for
grep )
Still not perfect, and it is really annoying that it does not present some
info it surely knows (i.e. calls of auto-generated funcitions), or that I
can't query the browser database sql-like (or just export it to text to
solve some cheesy questions myself...)
But it is tremendous help, and way superior to anything dumb and "just text"
based.
Also it actually *can* search in the files that belong to the project, as
the IDE knows the fileset -- while non-integrated tools are limited to crude
approach, like directories.
IUC your argdo g/... works on files opened in the editor -- can you do it
for the project's all files? That is just another option seletcion....
We're using subversion, so there is no check-out. I'm not sure
I like this aspect, however. I don't like the fact that I can
accidentally modify a file I happen to be looking at. (Of
course, in vim, I'll open it read only, so there's no problem.
I'm lazy to start VS to check, but for-readonly is traditionally part of the
open interface of programs.
But that is not the mainstream approach -- keep the files with read-only
flag in the filesystem. Then it will not edit, or you get prompted.
VSS works like that.
We used CVS, and I tried a free plugin that integrated it with VS, (Maybe
Iglo-something?) it worked, though I didn't like it. The source control
interface was made wth VSS in mind, and doesn't fit too well with others,
though you might find it so. As 'editors' can be used non-exclusively, and
provide info for the team. The non-free plugin was quite impressive on
its brag-sheet, I didn't try that one.
If Visual Studios has this option, I'm not aware of it.) For
the rest, it's all there from a normal editor and the shell.
If you insist that an editor that reads compiler output like ctags is
'normal'...
To me having a single frame around the whole bunch of editors (like those
for resources) and the debugger is also a gain on productivity.
I'm light on debugger usage, so wouldn't die from separation, but don't see
its virtue. Like DRY in coding. ;-)
Search and replace, for starters. You still have to enter the
regular expression and the replacement text. By the time you've
gotten the dialog box open and your hands back to the keyboard,
I've finished the command.
Huh? What hands back? The box can open on any kind of trigger -- including
keyboard. And starts with the search part prepopulated with text under the
cursor or selected, that is quite usual. And history in the box, that is
the other usual case.
If something bugs me it is redundant typing. May be some fundamental viring
difference in brains -- as in the "fill-the-query" case mentioned above.
But for search I rarely use the full dialog, just the "what" box on the
toolbar (activated by ctrl-D instead of ctrl-F) or even more frequently
ctrl-F3 F3/shift-F3 that captures the selected text or the current word if
no selection. (And selection certainly does not need the mouse either, just
shift...)
When editing (entering text), anything which requires using the
mouse is a minus, since it requires taking your hands away from
the base position on the keyboard.
Yep. Now do you really think that all the zillion users of VS, or
mouse-capable systems in general are all unaware of that? instead of
using the mouse when that fits, and the keyboard otherwise?
(When just browsing, of
course, other rules hold, and I do tend to use the mouse for
most browsing.)
And the wheel is the greatest invention since sliced bread too -- I feel
like maimed ocasionally sitting on a wheel-less mouse.
One frequent operation for me is grepping for every place where
some function is used.
You can do that? How? I couln't figure a method. (unless you mean to find
every place plus all the zillion other places that is not that function call
just a textual match.)
Though the operation is indeed one really important, and I can do it with
the browse info. (that in vs2008 painfully misses to point the place where
the function is not invoked but its address stored. :-( )
Then invoking the editor on just those
files, running through the first modification, memorizing the
keystrokes in a macro as I do, then undoing it, and invoking it
on all of the files I'm editing (and only on those files---with
a bit of care in my original search string, I can only modify
specific uses of my function).
Well, macros are really count as normal function of editor. With VS you
certainly can record at will or write, all the MS palette speaks VBA for
whatever. So beyond editing you can do practically anything.
As above. Or modifying all of the project files (in about
twenty different projects in the solution) in a similar way (but
the modification depends partially on the directory in which the
project file is found).
Well, if the stock "search/replace" in whole project is no player, then
indeed you either go half-manual or write the if-logic into the macro.
but if you can do it in vim I don't see why you couldn't do it just the
same/similar way -- the 'argdo' equivalent is surely more verbose, I'd guess
some foreach in application.documents, but if it is usual task, you write it
once and can call argdo for the rest of life.
Like written on top (no offense) this story reads to me not as whet an IDE
or VS can do, just you know how to do it in X and not (yet) in Y.
Just for completeness' sake, there's no problem to bring your shell to
windows and execute the tasks in your familiar way if the whole run is not
big. After all when the text-editing is done, no one can tell how it got
in the state. (I recall myself using "ms-word for dos" for semi-automated
text reshaping waaaay long, havin a bunch of other editors that also have
macros. The one thing that counts is to do the job with least sweat.
who cares how a one-shot macro or script looked like? ;-)))
