> not such a great default

This is a tangent, but it reminds me of a personal policy of mine: if I'm thinking about changing a default, I ask myself if there should be a default at all.

The consequences of having the wrong default were serious enough that it even came to my attention. So by changing the default, am I potentially exchanging one set of problems for another?

Sometimes it would be better overall if the user is forced to explicitly state which way they want it. Not always, of course, but I like to ask the question.

Right! I had a bug in a SQL statement to fetch tasks “order by priority” and then execute them in that order. A stupid mistake, but I must have looked at that code tens of times and I just couldn’t spot it. The bug was that that statement found then executed the lowest priority items first.

It’s not clear to me that an “order by” should have a default direction. I don’t know why one direction is more likely to be used than the other. Without a default, I would have been forced to think about the direction and wouldn’t have had that bug.

A similar example is in a "filtering" operation. I mostly have this in functional programming where you pass a predicate to filter on. But what's the perspective of the filter? Are you filtering poison from your water, or are you sifting the water looking for gold nuggets. I prefer to use functions remove and retain (respectively) to be more explicit.

GNU Make has this naming problem too $(filter pat,list ...) and $(filter-out pat,list ...).

That’s an ambiguity in English. “Foo is priority #1, bar priority #2, so foo has the higher priority” is perfectly valid English.

The only way to ‘solve’ that would be by banning priorities higher than 1, for example by numbering them 1, 0, -1,… or by using floats in the range (0,1] for priorities.

I would say this is a problem with type systems. Programming languages (including SQL) mostly just have one type for “integers”, or possibly a few types for different numbers of bytes of storage.

“Priority” and “array index” and “number of cantaloupes” and “age on 1-Jan-2020” may all be represented by integers but they’re all very different types.

Hungarian tried to solve this, sort of, but it’s at the wrong level. It’s not going to know which ones of these sort in which direction.

Isn't everything usually ABC and 123 by default?

I suppose countdowns aren't but there's a clue in the name…

Right, priority was 1..5 where 5 was a higher priority. So “order by priority” delivered priority=1 items first, and processed them in that order, which was the opposite of what I wanted.

It was absolutely my mistake, but “order by priority” reads so well in English, so my eye just couldn’t see the mistake.

I mean I’d been programming for decades at that point, I knew the syntax, I know our data model, I stared at the code and I still couldn’t see it. (Eventually I did see it of course..)

Since then I’ve been of the belief it would be better if SQL forced you to put “asc” or “desc” when using “order by”. Then you’d be forced to think about it.

So I was agreeing with the previous poster, who said that defaults aren’t always a good idea.

This is also an example of how difficult naming can be. This is arguably a "ranking" (1=low, 5=high), not a "priority" (1=high, 5=low).

That’s a very good point.

However people say things are “high priority” which, at least to my mind, implies higher numbers, so I don’t think ”priority” is necessarily the wrong term here.

right, and you execute tasks in descending priority order, not just the priority order.

> “order by priority” reads so well in English

I had my suspicions that programming reads very different to native speakers, and I guess here's a case when it's better to have English as a second language: I heard a ding-a-ling in my head immediately upon seeing the absence of ‘desc’.

It's a good question but in this case, I wouldn't be surprised if 99% of the usage don't fallthrough.

My perl script which scans C/C++ source code for typos would emit a warning (case 19) for a case statement that fell through to the next case statement. The script handled the 'fall through'-comment situation as well.

You can read the 1999 Perl Conference paper for the perl script at https://sites.google.com/site/typopl2/afastandeasywaytofindb...