Bear Skins And Stone Knives

: "I'm endeavouring, Ma'am, to construct a mnemonic memory circuit using stone-knives and bear-skins."

Spock to Edith Keeler, "The City On the Edge of Forever".

Some of us prefer the simplest possible tools - it's amazing what you can do with them, and besides, it seems to us that much (if not all) of the productivity of the fancier tools gets eaten up in installing them, configuring them, learning them, maintaining them, and working around their bugs. -- WayneConrad

Amen to that. I keep saying to to the IdeOlogues: there are no bugs in the MakeTool.

Complex tools exist to solve someone's vision of a problem using a particular method. Besides all the defects listed by WayneConrad, complex tools "make things easier" by removing freedom. I find myself always in a struggle with any complex tool. My vision of a simple solution is always at odds with the solution the guiding hand of the tool's creator wants to force me to accept. -- LeoScott

My co-workers have been trying to get me to install VisualAge for months. They will eventually force me. In the mean time, I've got at least a 2:1 productivity edge over them. There are things they can do much quicker than I, but they eat away that advantage by installing new versions, working around bugs, and going to training sessions. I'm using the time I save to refactor my code so that any fool can understand and modify it. They're rushing through their code because the tool isn't leaving them enough time to make it right.

I use compilers, assemblers, editors, shells, and a host of other tools which I have to learn, maintain, etc. The difference between my co-workers and I is that I adopt a tool only when I'm convinced it's mature enough to be transparent to me - that I won't have to spend much time thinking about the tool or mucking with it. It helps if the tool has a gentle, linear learning curve, so that I can be productive immediately and slowly add to my knowledge of it. My experience is that big-bang tools don't lend themselves to an incremental build-up of knowledge. That is, you don't seem to get a lot of productivity out of the tool until you "get it"; the process of "getting it" taking quite a bit of practice and training.

With web development especially, development times are so short that it's difficult to bury that learning curve in the schedule. If I make this project take longer to learn the tool, will I gain it back on the next project? Only if the next project uses that tool, or if the tool teaches me a concept or skill that is applicable to a similar tool or situation.

I like tools very much. I just prefer those which I can hold in my hand and understand over those with a label saying "no user serviceable parts inside." -- WayneConrad

It's a question of The best tool or the tool I know best. Being very productive with simple tools (meaning the tools I know best - the MakeTool is hardly simple) is fine. Being sure to learn a new tool every year is another good thing too!

Last year I learned Emacs, Bash, Linux, XML, SQL, and Wiki. I played with enough XP, MySQL, Python, JSP, Apache, Xitami and Tomcat to feel familiar with them (although not learned). We troglodytes aren't sitting still, and we aren't ignoring technology and tools. We're just focusing our effort where it will do us the most good. DoTheSimplestThingThatCouldPossiblyWork. -- WayneConrad

I wonder how people in general feel about Wiki itself. There are discussion systems with more bells and whistles than Wiki. To me as an occasional visitor, it's not clear that Wiki is further up the power tool scale than "make". (Actually, it's also like "make" in another, related way. If you don't have an implementation, only the idea, then reimplementing the basics gets you to the point of usefulness pretty fast.) Is Wiki a stone knife? Does anyone worry about not leveraging his communication time/skills/resources/etc. effectively when he uses Wiki instead of some wonderwhiz integrated tool? -- Bill Newman

Stone knives are initially sharper than steel, but they dull quickly. Hence they require frequent retouching (but perhaps have a future in surgeries). Leather is superior to cloth and nylon for many uses - but it does have a "break in" period, and should be maintained (cleaned and oiled). If VisualAge is a more powerful tool, but requires more futzing with installations and workarounds, perhaps you all have the analogy backwards.

The thing about most of these "complex" tools is that they make some things much easier and other things much harder or impossible. If you only need to work within the boundries that the tool provides to you then more power to you. I've often found however that these tools never quite do exactly what I want them to.

Long live ASCII & scripting. The great tool integrators.

-- GlenStampoultzis

But GnuMake+Vim+Bash+(all the other *nix tools) are an Integrated Development Environment. It's just that they usually don't display as much pretty pictures (usually, I say: the newest Vim can actually display such a row of nice, useless pictures.) -- StephanHouben

I hadn't thought about it this way before, but I guess I gravitate toward BearSkinsAndStoneKnives: my Java development environment is the free JDK compiler, emacs, JUnit, and (for some projects) ClearCase (which I can mostly ignore).

I don't even use Make: I have a file that lists the javac compiler options and all my source files; I put a # before any line I want to suppress (most, usually: java lets you incrementally compile most of the time). When I compile, I use a tcsh alias that does

 grep -v "^#" ~/sourcefiles

in backquotes as the command-line arguments for javac, then runs the unit tests.

Now, emacs has a Java mode (which I mostly use for indentation and brace-matching), and I have a macro that lets me jump to compiler errors, and another that jumps to runtime exceptions (finally figured it would pay off). But that's bascially it: if I don't need it, I don't have it.

I don't think this makes me like those Civil War re-enactors who won't even use nylon thread; I think it just reflects that nobody cares what tools I use, so I use tools that work, and automate the simple things that become repetitive. From a cost perspective:

Emacs: $0 JDK: $0 tcsh: $0 Time spent creating new software instead of wrestling with someone else's: priceless.

This works well for me, it's cross-platform (works on Solaris and on NT after grabbing CygWin) and I intend to keep doing it until (a) someone gives me a RefactoringBrowserForJava or (b) I write one or (c) emacs swallows up that particular bit of functionality as well (kind of like the homeward-bound V*Ger in StarTrek I).

Of course, to use the caveman analogy, emacs isn't a bear skin or a stone knife: it's the cave. -- GeorgePaci

Try editing XML with VI instead of XmlSpy? or other tools. -- VhIndukumar

Of course, XML is far from being a bear skin or a stone knife when EssExpressions can express the same information without the excess bandwidth usage and effort spent closing tags.