egrep ‘^word$’ ospd.txt

YARTLL (Yet Another Reason To Love Linux:).

@echo off
FINDSTR /X “%1″ ospd.txt > NUL
IF ERRORLEVEL 1 (ECHO %1 is BAD) ELSE (ECHO %1 is GOOD)

The switch /X only lets through entire line matches.

For my purposes, I wanted something (a command line tool) that would simply check if the word was in the file, without showing me partial matches, or the surrounding words. So notepad would not fit the bill. The ideal solution would have been the simple FOR statement batch file, above, and I feel annoyed that I did not persevere and figure that out.

I did not know the STL very well, and I still don’t. But normally I could have simply looked it up. However, given my sad lack of familiarity with streams, iterators and the functions of the STL, it would probably have still taken me longer to figure out than the C code.

I agree though that it’s important to learn new things – especially if they can save time in the long run. But there are also sometimes situations where it’s more important to get the task done in the shortest time possible. The key is to be able to judge the difference.

Heh, I just noticed that there’s only one comment in the code, and it’s wrong :)

ifstream stream(“ospd.txt”);
istream_iterator<string> begin(stream), eos;
bool found = find(begin, eos, argv[1]) != eos;
cout << argv[1] << ” is ” << (found ? “GOOD” : “BAD”) << endl;
stream.close();

Are these lines any harder to follow, for someone decently acquainted with C++ and the STL? More importantly, are they any more difficult to write? They do not make explicit use of pointers, dynamic memory allocation, or ASCII control codes, as your code (which is really more C than C++) does at great length. Nevertheless, there is a more important question to be asked.

Did you and your in-laws actually use this program to play a more engaging round of Scrabble? I suspect not; if that was your true goal, Notepad’s “find” feature would have sufficed. No – it seems to me this was borne out of a desire to code something, and rather than tackling something more challenging you simply created work for yourself.

What bothers me most about this post is what it seems to say about Cowboy Programming, if it is to be taken as a “good example” of such. Namely, that Cowboy Programming involves:
- writing unnecessary code for already-solved problems
- sticking to what is familiar when it would be more appropriate to try something new
- ascribing inefficiencies in your code to a language instead of looking to eliminate them
- having a warped sense of perfection that really puts the special in specialization

The last one is truly puzzling; does it not bother you when a problem that can be described in a few words has a code representation that is dozens of lines long? I would say this goes beyond breaking something down into subproblems, to the point where you spend time and space on things that are hardly related to your original task. At that stage, you might as well be working it assembly, although I am quite certain this particular problem could be solved in fewer than 50 lines of x86 code.

In any case, if you happen to be looking for coding practice, I would recommend checking out Project Euler (http://projecteuler.net/). They have a great selection of problems, most of them (in the first 50, anyway) solvable in no more code than would fit on a single screen, if done properly. It is interesting to read the discussion pages – made viewable after solving a particular problem – where people often post their solutions. I’ve been writing all my solutions in C while trying to give those using functional programming languages a run for their money in terms of code length (not an easy task, although not nearly so bad as if I were using Java).

Good luck, and have fun coding while fading into the Western sunset. And don’t let presumptuous elitist programmers get you down.