< mari
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
chi >
[ Page 71 of 76 ]
From: mjinks Date: 07:24 on 03 Sep 2003 Subject: "stone knives and bearskin" they said! ha! This one is minor and picky but it's been smouldering in my guts for years now waiting for the advent of a forum like this one, so. Here's something I hate: File monkeying tools that don't support the same range of expression as the filesystem they shipped with, that the vendor presumably intended them to interact with. Hate, hate, hate. Case in point: find(1) on Solaris. Or cpio(1) on Solaris, depending on your point of view. I'm sure each would blame the other if we asked them, even though the bloody manpage for cpio(1) strongly suggests that the developers intended these two beasts to get along nicely with one another, so let's all hate them again for acting like quibbling, petty siblings. Hate, hate, hate. In case it isn't obvious -- and it apparently wasn't to Sun -- I refer to the fact that you can't use SunOS find(1) to feed a pathname containing a space (legal as sea salt in UFS since heck was a pup!) to the stdin of SunOS cpio(1). For that, you have to use GNU find(1), with a GNU-find(1)-specific option at that, and also GNU cpio(1). Or preprocess that input somehow (How? I dunno, I gave up and punted). Or give up and punt like I did when you find, er, discover that someone who came before was kind enough to equip the system with rsync(1). Ah, rsync(1). I find so little to hate about rsync(1). Somebody help me out here, quick. And no, guilt by association with Samba does not count, though it's a helluva nice try.
From: peter (Peter da Silva) Date: 02:33 on 03 Sep 2003 Subject: I Hate Solomon IV We have this timecard system we use based on some kind of business process package called Solomon IV. I have never seen a program that did as bad a job of following the Windows GUI guidelines (which are, at least in principle, pretty good) as this one. Lotus Notes is better. It looks like they started by screen-scraping a 3270 program and assigned random Windows operations to virtual 3270 buttons, and never bothered changing anything once it was more or less working. First, the program is in two separate windows, One of these windows is nothing but a launcher for the other components, but all the menus are in this window. The other window has no menu, no toolbar, and if you close the first window it generally crashes. Then, none of the entry controls are standard. The first one you come across is the one for the date. It looks at first like a normal text entry. Oh no, that would be too easy. It's got the whole date hilighted in yellow, and if you enter anything in the wrong place it collapses the date to "//" and expects you to enter it again. I haven't quite figured out the rules by which it decides to advance to the next field, so I end up having to reenter the date fairly frequently. If you enter fields in the wrong order you can't go back and correct them, they get locked. You *have* to enter your employee ID (why? It knows who you are, you already logged on!) and then the date and so on. If you need to go back you have to quit and start over. The main entry area is is a fairly conventional looking grid. When you want to enter a job or department number, you don't right-click or double-click, you hit F3. If you double-click it brings up a more detailed view of the current line of the grid, and the only way to make THAT go away to edit another line is to double-click again. Sometimes. It seems there's right and wrong places to doubleclick. There's no indication of this, by the way... aborting is so normal I just aborted it until I happened to doubleclick right and had an epiphany. F3 brings up a new window, containing another grid. For some reason, this grid has scrollbars but you can't use most of the normal scrollbar operations on them: the thumb is a fixed minimum size and locked in the middle. You click above or below them, the grid scrolls, the thumb stays exactly where it is until you get to the top or bottom, when it suddenly jumps to the end. There's a normal pulldown box that shows the status of the card (in progress or complete). As soon as you select "complete" all the fields lock up, the only thing you can do is "save" or close the program and start over, losing all your changes. If you close the window it closes it. No warning. Throws away all your changes. I guess people got tired of having to say OK because aborting the session was such a normal thing to do.
From: David Champion Date: 17:42 on 02 Sep 2003 Subject: DNS * On 2003.09.02, in <20030902162044.GJ23320@xxxx.xxxxxxxx.xxx>, * "David Champion" <dgc@xxxxxxxx.xxx> wrote: > * On 2003.09.02, in <Pine.LNX.4.55.0309021638100.6478@xxx.xxxxxxxxxxxxxx.xxx>, > * "Mark Fowler" <www@xxxxxxxxxxxxxx.xxx> wrote: > > I hate software that doesn't map http://theirdomainname.com to > > http://www.theirdomainname.com. > > But that's asinine. We don't map uchicago.edu to smtp.uchicago.edu, or > to finger.uchicago.edu, or to sunrpc.uchicago.edu, either. Because it's > not. And it's not software's fault, it's people's achievement. > > In a justifiably bad mood, but (unfortunately) not because of software, Oh, all right. I'll take a shot at software, in the spirit of this post. Mapping domain.name to www.domain.name is asinine; I stand by that. But I'll tell you what I hate. I hate DNS. DNS is busted. DNS had a good idea in the MX record: a short and simple way to say "whenever you want this name for SMTP, use this other name instead." A fine concept, a noble goal, and most useful. I can make mail for domain.name go to smtp.domain.name with no trouble. And mail for anywhere else. What a useful paradigm! I need this for my http and finger services, too, as it happens. It should be little surprise, and I imagine a lot of people do. We've mapped finger at domain.name to finger at another box for ages -- since before there was a web, and that coexists fine with mail. Adding a mapping for http might be nice -- it's certainly user-friendly, and good in principle. But it's impossible to map both finger and http jointly with smtp. Why? Because DNS is busted. What DNS should do is to provide a uniform, service-neutral RR mapping a service (or port, if you'd rather) to a host. When my web browser wants to look up http://domain.name, it looks up the service RR instead, and perhaps finds the http mapping saying it should refer to www.domain.name instead. Finger could easily do the same. It could even be built into library routines for constructing sockaddr_in structures, if we wanted to make things easier for the coder. But DNS doesn't do this; it's short-sighted. It would rather push this burden to the application protocol, where it doesn't belong. DNS is busted.
From: Mark Fowler Date: 16:31 on 02 Sep 2003 Subject: Save Dialogs Which idiot came up with the idea of save dialogs? I mean, I have a finder window open here (Explorer, I can see you from here, wipe that grin off your face - you do this too.) It *is* the representation of that directory on the file system. It should be to me one and the same thing. Right, now I want to save this file from this application into that directory. Right, File -> Save As. Okay, now all I have to do is tell the program to save it into this window and all will be fine. What's that, my little application? You want me to navigate to the same place again using the world's smallest dialog? You can't be serious! I've got the window open here! Look, just save it there damnit! No, little application, I have no idea where that finder window is located on the hard drive. You see, I loaded it up from a alias. I think it's in my home directory somewhere? Does that help? This of course, is pure insanity of the worst kind. Whoever came up with the idea of reinventing a whole secondary Finder/Explorer system in order to save a file, rather than using the perfectly good one the user has already, needs a good kicking. Of course, ten years ago, before Windows 95 was all the rage, in this country we had RISC OS computers (that's Acorn to you crazy foreign people.) RISC OS was simple. It popped open a box containing a icon of the file when you wanted to save and you just dragged it to where you wanted to save it to (yes, directly onto the equivalent of the Finder/Explorer window) and it saved it there. It was that easy. Of course, it was more powerful than that. You could drag documents to other applications and it would 'save' them into the application directly. But that's just crazy talk. Next thing people will be having shells that can pipe output from one program to the next. Mark.
From: Mark Fowler Date: 11:13 on 02 Sep 2003 Subject: Mac OS X Finder and changing extensions. Okay, this thing is driving me insane. I want to change my foo.html file to foo.tt2. I want to put some template code in it. Will the finder let me do this? Nope! I click and change it's extension and it just changes it. Keeps the nice HTML icon. Hey, nice I think. Everything runs, but ten minutes later my script can't find the file. Why? Because it's been renamed to foo.tt2.html. Argh! Apparently, if the extension isn't known to the OS then the policy is to just hide the actual extension and show the name that you've changed the file to. This is nice for Ma and Pop when they're using the computer, but I'M TRYING TO GET SOME WORK DONE, OKAY? I really need the file to be called what I renamed it to. So I try renaming the file foo.txt and sure enough it prompts me, saying 'Are you sure you want to change the extension...'. So I click 'use .txt' and the file is renamed to foo.txt (which I check in an xterm, and it really is called that) Then I change it from foo.txt to foo.tt2. And it gives me foo.tt2 in the finder, but the file is now foo.tt2.txt. No closer! So I give up on this. I use 'mv foo.tt2.txt foo.tt2'. Huzzah! The file is called what it needs to be called. Except now the finder displays it as 'foo'. No extension. What is going on? How do I get this thing to stop! Not even Windows Explorer is this braindead.
From: Ann Barcomb
Date: 09:15 on 29 Aug 2003
Subject: Software that won't take no for an answer
I don't know whether to blame Windows or the software in question, since
I only use Windows at work, and then only for dealing with a few things
that I can't do on the development machine.
When the machine is booted, before I can log on, the following box appears:
Norton AntiVirus Corporate Edition
Symantec AntiVirus Realtime Protection failed to load. (OK)
I click OK. It beeps, and the window remains. I click OK. It beeps,
and the window remains. I click OK and I am now allowed to log on.
After I have logged on, a new installer window pops up for the same
program (note that I do not even have access to install the program).
I click the cancel button.
The window is replaced with one which says 'Preparing to install', but
this quickly vanishes and is replaced with the installer window again.
I cancel it. The result is the same. I cancel it for the third time,
and it goes away.
For the remainder of the day, I can just expect yellow pop-ups telling me
the software isn't installed.
Does this constitute a sighting of an Acme::Snark in production code?
From: Simon Wistow Date: 10:59 on 28 Aug 2003 Subject: software with surprising depths of superficiality I'm actually talking about a particular bit of code that I've inherited but I've seen this phenonomem elsewhere so I'll paraphrase. I'm not sure if there's a neat buzzword for this particular species - neither lasagne nor spaghetti code seems to work. Perhaps 'spirelli' code. Anyway, lurching back to the point. I've inherited this code. The task seems simple enough - indeed I have a suspicion that if I was to reimplement it from scratch it would take a week or two. Instead, on and off, I've been poking at it for nigh on six months now. Now to be honest this is a week here and a week there but still. Six months. You could rewrite Emacs in Perl in that space of time. Or Mailman :) Why is this code so bad? Well, its lineage for a start - I can practically see its evolutionary tree. Currently it is a rag tag collection of shell and Perl scripts. Some of the Perl scripts obviously used to be shell scripts to the extent that they actually SHELL OUT TO OTHER PERL SCRIPTS. Not for forking reasons, oh no. Just because, well, the original author had partaken of the crack pipe and not drunk deeply from the cup of refactoring. I have to concede that they did move some of their 'require'-d code into modules but the design of those, plus the fact that they lurk in various lower case namespaces or, and I'm not sure if this is better or worse, in the Test:: namespace, means that this is not enough to let them off the hook. Even as I write this I'm struggling to explain why this has caused me so many problems. On paper, and I know this because I had to write it down yesterday, it all seems perfectly easy. But, obviously there is, otherwise I wouldn't be writing this. My two, no wait, three major issues with this stuff are these : 1. The code is *incredibly* brittle This to the point that if I leave it for a week and then run it again I can practically guarantee that it will not work, often failing silently, and I will spend a full day poking around trying to diagnose the problem. Often there will seem to be no reason for this. 2. It's amazingly hard to follow. There are several reasons for this - my particular favourite being the lack of indenting, the terse variable names, the overuse of hash references (which are normally fine but become incredibly difficult to follow when nested 8 deep and passed between required files to functions with 10 arguments with no consitent naming scheme or ordering), the fact that there are many "actions at a distance" not least the use of Environment Variables as some sort of perverse global variable system, like the author went "well, I'm told globals are bad so if I put then in ENV then nobody will know". Truly, the list goes on and on. I haven't even mentioned the lack of comments and the long, undocumented regexes with unprintable characters in. On and the fact that various libraries are in various people's home directories. Testing is also a problem because a trial run takes 4 hours and requires a full days worth of data meaning that a fix checked in on Monday won't be checkable until after lunch Wednesday. 3. I'm not allowed to refactor. Apparently the main reason I'm not allowed to is that then it won't be 'trust worthy'. I've mentioned Unit tests but these have been roundly ignored. Also, the code has been internationalised from the original which is also being developed (don't ask why there are mutliple branches). So I can't refactor unless I want my life to be a manual patch applying hell. Hell, I can't even use Perl Tidy (I tried - waaaaaay too many spurious deltas) Actually, there's a fourth. 4. It makes me feel shit I know I'm not a bad programmer[0] (stop sniggering Richard). I've written far more compilcated programs than this. Yet it has single handedly been the most disasterous project I've ever worked on. I seem to find it impossible to give, let alone keep, a deadline. It saps my confidence and I have huge problems forcing myself to work on it which in turn makes me feel worse. Et cetera, ad nauseaum, ad infinitum. Right, that's enough moping.
From: peter (Peter da Silva) Date: 20:04 on 27 Aug 2003 Subject: Printing software All software sucks, but, damn, printing software manages to bring suck to whole new levels. Even setting aside Windows, where you have half a billion printer definition files (misnamed as "drivers") which make printers that are almost perfectly compatible from UNIX (because they all implement standard Postscript, so long as the generator doesn't try and get too agressive with corner cases) behave entirely and bizarrely differently. In UNIX, we have BSD printing with its hardcoded definitions for printers and printing technologies that haven't been used in 20 years except among retrocomputing enthusiasts who trade SMD hard drives for Varian paper rolls at swap meets. We have System V printing, which is a moderately nice generic queing system with a bunch of horrible shell-scripts duct-taped to the side to handle the actual printing bit. We have a handful of "improved" print systems that couldn't settle on a communication protocol to save their lives. We have commercial print systems from companies like Adobe that bring the Windows Horror into the UNIX world... It's a measure of the horrible state of printing that the creaky old BSD LPR/LPD system has probably the least suckage of the lot of them. By a whisker. And let's not forget Apple, which used to be all "everything's Postscript, we'll take care of it", but now according to the log files it's using CUPS and running a webserver as part of the scheme...
From: peter (Peter da Silva) Date: 19:20 on 27 Aug 2003 Subject: More hating hates-software... This code has more bugs than the county pound in a heatwave. Latest fun... is it just me or is everone getting errors when you try and read followups?
< mari
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
chi >
[ Page 71 of 76 ]
Generated at 10:28 on 16 Apr 2008 by mariachi