In this case, there aren't commas in the data I need. In general, you are right, but this isn't the general case. Treating everything like the general case is usually a lot of wasted effort. I know that the parts of the lines that matter to me won't have the separator character in it.

I'm not screwed to any degree even if there are commas in the data. This little script simply makes the report I needed this morning. It's not controlling medical equipment, nuclear reactors, or air traffic control. If it breaks, I don't lose any money and nobody dies. People don't lose their jobs and the sky does not fall. I'm not even committing the minor sin of uploading this to CPAN.

Perhaps your definition of "screwed" is different than mine, but a text report going a bit wonky just means I do the extra work later, if I need it. For now, I have the report I need, and a month from now if I even remember where I put this script and if I need something different, I'll change it.

Until then, I don't need a perfect or proper script. Joel Spolsky says in "Hard-Assed Bug Fixing" Fixing bugs is only important when the value of having the bug fixed exceeds the cost of the fixing it." Indeed, he goes on to show the economic disadvantage of too much programming.

The point of the exercise is not programming, but results. Anything beyond the results is wasted time, which is why, when I considered it (as noted in the original post), I didn't use a module, but I designed it so that if I change my mind, almost nothing changes. The flow is still the same, and some subroutines at the end of the program change how they do things, although not their interface. The rest of the program doesn't know how I parse a line: it just knows that it gets data. I don't need DBI to do this simple task, and right now I don't need another module.

If you want to spend a lot of quality time with your keyboard, that's fine. I prefer to get things done, and sometimes a "proper" program is just wasted time. Instead of doing everything "properly" from the start, just design things so you can go back and easily change the program later. Use the simplest solution to a part of problem, and stop when it works. Move on to the next part of the problem. Stop when that works. When you get the results you need, stop working. I may never use this script again, so any extra work is a waste. If I do use it again, and it breaks, then I fix it, but I only do it just in time and as needed.

I've met a lot of perfectionists, and in my opinion, most of them don't get that much done.

Sometimes I use a module even if the power it brings could be seen as overkill for the solution at hand.

I put the extra time on the "education" account. When learning something extra while solving a simple problem I spend the time once. Next time I have knowledge to build on. In the meantime I have widened my horizon slightly, and often a more solid solution.

The other day I had to create a very simple HTML page with a ToC for a couple of Doxygen reports. I could have just printed HTML to a file. But I went for using Template Toolkit (which I've used before, but it was some time ago and I needed a refresher). Altogether this took a little longer than printing HTML, but the code was a lot clearer and shorter.

Next time I have to do something similar, I'll get a real good solution in no time.

/J

If you want to spend a lot of quality time with your keyboard, that's fine. I prefer to get things done, and sometimes a "proper" program is just wasted time.

And yet, in the time you wrote this node, you could have fixed the supposed "bug".