[tallpapab]

I agree that many underestimate the power of bash for development. Make, in particular, is much more widely usable. However, there are some things that I find very convenient in an IDE that are harder to do at the command line. Finding usages of a name (variable or function); finding the definition of same. Renaming same throughout the code base. Yes, I know about "find | xargs grep", but it's a bit more convoluted than IDE usage. Maybe I just don't know enough. Can anyone point to command line or vim tools to accomplish these tasks? Code analysis and warnings are another thing IDEs seem to do better.

[babarock]

I'm going to be a tad pedantic and note the following:

- bash and make are completely separate programs. As a matter of fact, I spend half of my time developing with ksh and Solaris make. The two programs you mention don't go 'hand in hand'.

- `find | xargs grep` is a terrible construct. 99% of the time (if not a lot more) you'd prefer using something like `find -exec`, I have yet to come across a version of `find` that wouldn't work that way.

My point is not to be an arrogant prick, and criticize the parent post. These kind of misconceptions usually indicate poor understanding of the larger Unix philosophy. By her own admission, my parent "just do[es]n't know enough".

I believe that in order to truly use Unix as an IDE, one has to go beyond the (arguably bad) reflexes taught by common GUI IDEs. It's not simply a matter of "What command can replace feature X from Netbeans/Eclipse/Visual Studio/...?" Modern IDEs weren't conceived with sed/awk in mind, aren't (for the most part) scriptable like most Unix shells are, and aren't sitting on top of a freaking Lisp machine like emacs is (you know the whole enlightment deal, lisp is superior, bla bla bla).

I am sounding like an evangelist, Unix tend to do that to me. I am trying to make a simple point:

It's normal to feel that something is missing if one is simply transposing her knowledge from point-and-click IDEs to the Unix shell.

(To answer your question, a combination of sed and awk does wonder to rename across the code base. And SO much more ...)

[tallpapab]

Uh oh. After a few decades of Unix I _still_ have a poor understanding, sniff. I have in years past used sed and awk and perl -e and other such to rename as well other things. However, the regular expressions to ensure you're not including things you don't want involves a bit of effort. I'm in the Unix choir, but I still like the shiny new IDEs which save me time (especially with Java as noted elsewhere).

[slurgfest]

There needs to be far better evangelism/PR to tell people the right way to do all these things so that they understand how to do all the IDE stuff, the truth is that the number of use cases people need is not unlimited... of course it is good to know the full range of flexible tools, but it's far from obvious to most people whether or not find | xargs grep is good or not, or how to do a method rename

[npsimons]

of course it is good to know the full range of flexible tools, but it's far from obvious to most people whether or not find | xargs grep is good or not, or how to do a method rename

It's also far from obvious whether a for or a while loop best fits the problem at hand. How does one figure these things out? By learning about the tools/constructs and using them (experience). Furthermore, it is expected of software developers to know these things.

It's all well and good to be an IDE jockey, but being a software developer entails more than clicking through wizards and filling in some logic. Learning tools (such as UNIX CLI tools) opens up a whole other world of untold power in accomplishing not just programming tasks, but everyday tasks as well (how many people know that there is a CLI unit conversion program that not only has more units than you can shake a stick at, but is scriptable and has a tiny footprint to boot?). Not to mention that these tools have been around and ported to just about everything, and will probably continue to be around for ever, and eat less RAM and CPU while being more flexible and powerful than their GUI counterparts.

Edit: I didn't mean to come off condescending and scolding, but I forgot to insert some helpful links in response to your statement that there should be better evangelism/PR for shell programming; hope these links fit the bill:

http://www.bashoneliners.com

http://www.commandlinefu.com

http://www.shell-fu.org

http://noone.org/blog/English/Computer/Debian/CoolTools

http://noone.org/blog/English/Computer/Shell

[slurgfest]

You don't have to sell me on using the shell at all and I have seen one-liner databases (which are really only fun once you have a pretty good level of mastery)

I find that IDEs make everything so needlessly complex and inflexible - I don't want 2000 little icons in 200 drawers managed by 54 XML files that I will eventually be expected to edit.

The observation is that they are winning anyway. In fact, people even think they are easier, AND they think their IDE does things that can't even be done otherwise! These people are smart enough to develop software, yet they are opting for what we think are dumb tools. Either we are just wrong, or there is just a misunderstanding about the relative easiness of IDEs.

I think that commercial platforms and products aimed at consumers (including developers) tend to have people paying careful attention to marketing and experience, to add a layer of glitz and wow and accessibility. It isn't that it could not be done but no one is bothering, once you know the efficient way then there is no point dressing it up.

I also think we have built up a culture which is somewhat punitive to newbies. Too many people treat programming and composition of command line tools as some kind of dick swinging competition rather than the inherently simplest and most straightforward way of doing things, which is SUPPOSED TO make your life easier and let you do things you couldn't otherwise do.

[pjungwir]

`grep -r` works pretty well, too.

[enduser]

This is a significant reason that many Unix hackers prefer languages like C or Common Lisp where the same symbol means the same thing system-wide. Plain text grep, sed, and ex commands make refactoring quite simple and don't require fancy plugins to figure out what a name means in a given context.

[kevinnk]

> "This is a significant reason that many Unix hackers prefer languages like C or Common Lisp where the same symbol means the same thing system-wide."

I don't know about lisp, but that's not even close to true for C. typedef struct A { int A; } A; is an easy counter example and that doesn't even take into account macros or any of the other tools that play horribly with grep and friends.

The reason Unix hackers prefer C is because it's rock solid, extremely well supported and plays nicely with hardware. And it doesn't hurt that it's old enough and popular enough that a huge number of people have extensive experience with it.

[pka]

Not true for Lisp (Clojure) either: (defn a (let [a ...] (+ a a)))

[lubutu]

You're looking for ctags or cscope, the first of which is mentioned in the blog. As for code analysis and warnings, surely that's a property of the compiler being used?

[tallpapab]

Thanks for the reply. ctags is a great tool, but it is not as easy as an IDE. IDEs keep track without my having to explicitly rebuild the tag data base. IDEs have plugins for different languages. The dynamic flagging of errors and warnings without having to explicitly compile is a time saver. Refactoring tools can also save quite a bit of time. Renaming a function becomes trivial in an IDE.

Of course, there are many things for which vim and bash (":%! sort -n" anyone?) are far superior to an IDE. I tend to use both.

[NickPollard]

There are some things IDEs do better, but these Unix tools give you more choice.

It should be pretty simple to add a hook to vim to rebuild the tags whenever you save a buffer, for example. That should take the load off your mind. The issue with IDEs I find is that this stuff is automatic and no way to turn it off, and then I find at the worst time that Visual Studio is crawling to a halt as it runs a load of complex parsing in the background on my 500k lines of C++, just when all I wanted to do was write some code.

Think of it as separation of concerns - you wouldn't write a program where all the code was in one tightly bound monolithic system. Why do so for your tools?

[tallpapab]

As quickly as you can turn your back on Visual Studio. (Sorry, just kidding ... sort of.) Eclipse and NetBeans are a couple IDEs (there are others) that use a module system to build what can appear to be a monolith. Look into OSGi which is an attempt to standardize modularizing GUIs. Of course, I haven't run these tools on 500k lines of C++ just half that of java code. P.S. I used "find . -name \*.java | xargs cat | wc -l" to count the lines of java code. I did not use the IDE for that, giggle.

[truncate]

Plus ctags isn't really that smart, or you can say the way it is used. For example I have a struct "foo" that has different independent declarations in several files in my source tree. Whenever, I would try to open that tag, list of all tags would show up regardless the files included in the current source files. This is quite irritating.

Another not-so-smart feature is auto completion (in C++ at least) and refactoring.

However I can live with these missing features as once you get used to something like Vim or Emacs, its quite frustrating to work on bloated IDE's.

[tallpapab]

How does ctags do when a variable name is repeated in a different scope? I do rather wish for a really good vim type replacement for the editor in NetBeans though. I keep inadvertently entering vim motion commands in my java text - sigh.

[falcolas]

It picks the "best" one (typically the one in the scope of your current file), and lets you change which one to go to, without ruining your tag stack.

For example, if I Ctrl-] over `open`, and it pops me to the wrong one, I can then type :ts and pick the proper entry (typically with info about the file, type, and container). I can then Ctrl-t back to the previous context as normal.

[Symmetry]

Well, if you're using ctags through vim it guesses by default, or you can use :ts to get a list of the possibilities. Not ideal, I know, but often good enough.