Hacker News Reader

The sort rules are simple (1). Treat any consecutive sequence of digits as a number when sorting. So for example version numbers (which must be massively more common than decimals in filenames) work correctly, and 5.9 is indeed smaller than 5.10 and the latter is not identical to 5.1 .

Given that this idea goes back more than two decades, has been the default behaviour of the most used OSes for many years, with no major outcry, I think empirically we can be fairly certain that it does not routinely lead to a lot of surprises and confusion.

(1) https://en.m.wikipedia.org/wiki/Natural_sort_order

> The sort rules are simple

In considering the simplicity of the rule, I think you're using a developers perspective here where we automatically classify numbers and have a clear mental model of the separation between value and representation.

But I'm not sure how simple it would be to explain to a non-technical user why size_5, size_10 and size_15 are in order but size_0.25, size_0.5 and size_0.75 are out-of-order.

> with no major outcry

I'm regularly amazed at how little non-developer/technical users complain about strange and confusing behavior.

> I'm regularly amazed at how little non-developer/technical users complain about strange and confusing behavior.

I am a highly technical user that works with a lot of people with traditional engineering degrees but little to no software experience (except as frequent users). The answer here is that they've learned that all computer software is arcane and mysterious, and so they just accept that there will be strange patterns they have to pick up on, and that's their role as a user. They don't complain about strange and confusing behavior because they treat all the behavior as strange and confusing.

    > traditional engineering degrees

What does that mean? What disciplines? I cannot believe that all junior graduates in engineering disciplines in the 2020s are not doing some programming, even if just writing macros in a CAD program.

Most of the people I work with are 35+, but even the juniors in MechE, Aero, etc. tend to have some scripting experience that doesn't necessarily translate to having a robust intuition about DBs, the relationship between frontend and backend design, etc.

> I'm regularly amazed at how little non-developer/technical users complain about strange and confusing behavior.

Because EVERYTHING a computer does to non-developer/technical users is "strange and confusing". With few exceptions, most people have no idea why their computer does something the way it does, or how they could make it do something different even if they wanted it to. And most of the time, when they complain about it to someone knowledgeable the answer will be some variant on "that's just sort of the way it is". Imagine a world where the names are sorting the way that the OP is looking for, you're still having to explain to someone why the first group sorts "out of order" and the second group sorts "in order". And if they complained, they would almost certainly get an answer that is some variant on "that's just sort of the way it is".

And if you explain in detail about how it works, a lot of people (not all, but quite of few of the more obstreperous types who raise these as CRITICAL BUGS with solutions apparently SO SIMPLE MY DOG COULD IMPLEMENT IT) will then say "I don't know why you have to make it all so complicated, things were simpler and better in v(n-12) in 1997".

If you add an option you're making it more complicated, harder to document and less discoverable, if you don't it's "useless", if you use a heuristic it's "too magical". Eventually someone has to be unhappy.

> But I'm not sure how simple it would be to explain to a non-technical user why size_5, size_10 and size_15 are in order but size_0.25, size_0.5 and size_0.75 are out-of-order.

You don't have to explain it if the situation never comes up.

I'd bet 99.9% of computer users don't have any files which would trigger this edge case in a situation they would actually notice. Decimals just aren't that commonly used in this context, and even if you do have decimals the sorting will still work a lot of the time. For the remaining 0.5%, chalk it up to a bug.

I literally had to test this on my Mac just now because I never realized it was broken.

> I'm regularly amazed at how little non-developer/technical users complain about strange and confusing behavior.

It reminds me of the recent article here titled something like "Altoids by the mouthful". We just get used to eating cat poop and we never realize it is not a good idea to eat cat poop, not that we should make it more palatable by chasing the cat poop by chewing Altoids by the mouthful.

Edit: for today's lucky ten thousand

https://news.ycombinator.com/item?id=45343449

> Treat any consecutive sequence of digits as a number when sorting.

Based on this description, I have no idea how the following would be sorted:

• photo.jpg

• photo1.jpg

• photo01.jpg

• photos.jpg

Does it matter?

There's a user expectation that photo20.jpg comes after photo3.jpg.

There's no user expectation around whether photo1.jpg or photo01.jpg comes first. Just like there's no user expectation around whether photo1.jpg or Photo1.jpg comes first. Users also don't have the slightest idea about what order punctuation gets sorted in.

Just sort the things that matter in the way users expect (natural sort order) and come up with something reasonably consistent for the rest.

> There's a user expectation that photo20.jpg comes after photo3.jpg.

my user expectation is the opposite

i get what you're saying but it's not achievable in practice, at least not consistently

It sounds like a problem with too many expectations therefore someone will be disappointed.

> There's a user expectation that photo20.jpg comes after photo3.jpg

I expect photo20.jpg to come first.

> There's no user expectation around whether photo1.jpg or photo01.jpg comes first.

Clearly photo01.jpg comes first.

> Just like there's no user expectation around whether photo1.jpg or Photo1.jpg comes first.

Of course Photo1.jpg comes first because uppercase comes before lowercase.

It really sounds like you're using the word "user" to mean "dumb" and I wonder, what got you to the point that you started considering yourself an expert on "dumb" and feeling the need to defend "dumb" ?

I'm sorry but it all comes off so condescending, like "users" are a different+lower species or something.

> Does it matter?

Yes. An algorithm must be unambiguosly specified for all possible inputs.

> An algorithm must be unambiguosly specified for all possible inputs.

And it is. It's just that some outputs may not match what the user expects. TFA's preferred algorithm (simple lexicographic sorting) matches user expectations 90% of the time. The algorithm actually in use on most OSs (simple lexicographic sorting + treat consecutive digits as combined numbers) matches expectations 99% of the time. An algorithm that matches expectations 100% of the time doesn't exist. Shouldn't we pick the 99% algorithm?

(I am admittedly making up the actual percentages, but you get the point.)

I get your point but I still disagree (also about the percentages btw). Can you also get _my_ point?

Well-designed machines quite _often_ operate against "user" expectations when those expectations are wrong.

For instance say if I charge my phone for an hour, it'll last for a day. How long will it last when I charge it for two hours? Because in practice the answer is either "also a day" or it is "the battery catches on fire", this machine acts _against_ user expectations and stops charging the phone after an hour.

Maybe an even better example: coins! I dunno about coins in the US but but get this: the 5 eurocent coin is _bigger_ than the 10 eurocent coin! I dunno why, or if there even is a good reason for that, but it doesn't seem to bother "users" of money (e.g. everybody) when they have to sort out cash.

Anyway my point is that even if _some_ (but definitely not all!) people may expect numerical sorting, doesn't mean that they're right ... and it's not like lexicographic sorting is rocket science and zero padding .. well I think you said you don't like the way it looks, but I actually think it looks very neat because things line up and it's actually easier to read for me, as well :)

It's dumbing things down, in a bad way. It's like hiding the inner workings of stuff, and it's a mistake to think that even if somebody is not familiar with computers that they are _stupid_. People might even get curious and figure out that numbers come before uppercase and those come before lowercase. And maybe one day someone comes along and says "you know that's because of ASCII?" and they learn a thing! Which is cool.

Instead it's like you're painting people scratching their heads wondering "why number not go up?"

I just tried it on Mac, its sorted in the order you listed. Extending it a bit, the order is:

photo1 photo01 photo001 photo0001 photo2

So the shorter representation of the same number comes first. It does make intuitive sense to me.

But did it show as a list or an ordered collection of folders? And the second time you opened the folder did it rearrange into a haphazard scattering with items off the edge of the window?

> I just tried it on Mac, its sorted in the order you listed. Extending it a bit, the order is:

> photo1 photo01 photo001 photo0001 photo2

What you enumerated is known as "ascending lexicographical ordering" and has nothing to do with "the shorter representation of the same number", but instead the ASCII[0] character values in each file name.

0 - https://man.freebsd.org/cgi/man.cgi?query=ascii&apropos=0&se...

With ASCII lexicographic ordering, photo01 would come before photo1.

> With ASCII lexicographic ordering, photo01 would come before photo1.

Good catch. I did not closely inspect the ordering initially presented, which was:

  photo1 photo01 photo001 photo0001 photo2

This does not represent a valid sort order based solely on file names produced by `ls`, which would be:

  photo0001 photo001 photo01 photo1 photo2

1 and 0 aren't even in the alphabet so in "alphabetical order" I still wouldn't know a prior how that's sorted.

I guess?

  photo.jpg
  photo[nine].jpg
  photos.jpg
  photos[zero][one].jpg

There is a standard algorithm - CLDR collation. There are several options available but, generally speaking, it’s a standard.

The specific option for numeric sorting is “kn”.

As far as I can tell, every operating system and many other interfaces tend to use this standard algorithm.

https://www.unicode.org/reports/tr35/tr35-collation.html#CLD...

> If the answer is no to any of these questions, it's likely to lead to surprise/confusion.

Worse, if the answer is yes to any of these questions, it's also likely to lead to surprise/confusion. The only way to win is not to play.

The entire idea that numbers would be treated on a character by character basis rather than as numbers is somewhat intuitive for developers and not for non-technical people.

The answer to all of those questions is no for lexicographic ordering. Lexicographic ordering leads to surprise and confusion as a result.

> It's like a feature request that initially sounds reasonable and useful but once you explore the requirements in detail you realize there are too many edge cases to be able to meet the request in a non-brittle way.

It's been on windows and macOS for coming up on 25 years, and is in practically every modern UI. It’s reasonable.

Are filenames likely to include those representations? I feel like probably not (can you even include commas in Windows filenames?)

More to the point of the article--if you want things sorted by date, sort by date. I think most laypeople aren't looking at long CHAR1234_5678 filenames anyway, they're looking at thumbnails and dates.

> can you even include commas in Windows filenames?

Yes.

> Use any character in the current code page for a name, including Unicode characters and characters in the extended character set (128–255), except for the following: The following reserved characters:

< (less than)

> (greater than)

: (colon)

" (double quote)

/ (forward slash)

\ (backslash)

| (vertical bar or pipe)

? (question mark)

* (asterisk)

https://learn.microsoft.com/en-us/windows/win32/fileio/namin...

> if you want things sorted by date, sort by date

Unfortunately it doesn't work. When I copy the files, they all get new dates in whatever random order they happened to be copied in.

The most common date format used in Europe uses period separators so can often appear in filenames. Commas are probably more rare. Things like versions are often fractional like v1.3 or v1.11 and can appear embedded in filenames.

That's not fractional though.

Proper fractional, 1.11 is smaller than 1.3.

In versions, 1.11 is larger than 1.3

Ah, the classic filenames with decimal points and scientific notation in them, so common...

Here's a different scenario: filenames with dates in them. Consider September Budget and October Budget. September is the equivalent of 9, October of 10. Which comes first for natural sorting? Remember, the file modify date may not be useful here since you may have wrapped up the September budget on October 1st while the prior edit to the October budget may have been on September 20th.

The problem is that there is no such thing as natural, and it is quite hard to determine what is more common. (Quite often more common is culturally dependent or, worse, contex dependent).

So the argument is that because this doesn't solve the challenge of ordering all possible strings by semantic meaning it should not be used?

Even though it increases the match between semantic meaning and string sorting in many important cases and is a simple and consistent rule?

the one true way: budget_09.csv, budget_10.csv

Then `budget_100.csv` comes by and now you need to rename 99 files.

It’s been about two thousand years since the number of months in a year has been increased. I don’t think we’re getting 88 new ones anytime soon.

Sure, but if in this case the number would have only indicated the month you have an issue way earlier than 100 actually, you already have an issue on month 13 when you would go back got 01 and now you are overriding the old one.

Presumably there is a separate directory for every year.

And it's been about 25 years since we had to increase the number of digits for a year.

budget_97.csv, budget_98.csv, budget_99.csv, budget_2000.csv

> It’s been about two thousand years since the number of months in a year has been increased.

What? What are you thinking of? The number of months in a year is always 12 or 13 in any calendar system because they start by reflecting the moon. If you mean the Christian calendar, it was fixed at 12 months to the year well over 2000 years ago. If you mean any calendar, it's probably been more like one year since the number of months in a year has been increased. 12 lunar months falls short of a solar year by about 11 days, so any given lunar calendar will generate an extra month about every three years, and there are lots of different lunar calendars.

(For example, the Chinese calendar occasionally repeats full months in order to keep the month of the year lined up with the season. Whenever this happens, there will be 13 months in the year, of which two share the same name.)

The ancient Romans claimed to have had a 10-month calendar [1], which is what I assume the reference is. Either that, or when month 6 got renamed August in honor of Emperor Augustus

[1] https://en.wikipedia.org/wiki/Roman_calendar#Legendary_10-mo...

> The ancient Romans claimed to have had a 10-month calendar [1], which is what I assume the reference is.

Well, in the first place (as you note), there is no reason to believe that claim - the ancient Romans never made such a claim, but the classical Romans made that claim about the ancient Romans - but more importantly even if it were true the months would have been added many centuries prior to "about two thousand years" ago. Nothing related to additional months happened two thousand years ago.

Given that 09 and 10 refer to months, that wont ever gonna be a problem. And if you want to differentiate them years too, you can prefix with 2025- or put them in a 2025/, 2026/ etc folder.

Even better, I'd prefer to have more semantic meaning, and for budget-2025-09.csv, buget-2025-10.csv to work everywhere...

>September is the equivalent of 9, October of 10. Which comes first for natural sorting? Remember, the file modify date may not be useful here since you may have wrapped up the September budget on October 1st while the prior edit to the October budget may have been on September 20th. The problem is that there is no such thing as natural

Yeah, but there is such a thing as "give a predictable and consistent way I can name the files so that they sort as I want everywhere" which (if different OSes don't try to be "smart") would have been to prefix them with the numeric date zero padded.

Budget 2025-09.ods and Budget 2025-10.ods would sort reliably.

The options explode infinitely if you start trying to guess what people want in terms of semantic grouping. One user might want to see "September Budget" beside "September Sales Projections" and "September Calendar", and another might want to group it with "October Budget" and "November Budget".

If you have simple, stupid, but predictable tools, people can work around that, by picking naming conventions and even directory groupings that achieve what they want.

The worst is when you have an enforced sort that's not what you want. I think in Windows now, even if you say "Sort by name" in the Downloads directory, it insists on sub-grouping by age. I want every version of the Foobaz spec I downloaded, and no, I don't remember if all of them were in the last 3 months!

There is a simple criteria for ordering file names: treat sequences of characters as alphabetical, and sequences of digits as numbers.

It's easy to understand and predictable; it just happens to not be based on ASCII character codes, which is a legacy technology method only ever meaningful to US developers.

You can easily disable grouping in Windows Explorer.

Date is already in the metadata, it doesn't need to be in the filename.

Have you ever copied a file?

Yes, have you never edited the metadata? Also most filesystems these days preserve it when copied, e.g. my camera's EXFAT filesystem on an SD card gets the creation date preserved when I copy it to my PC or NAS, or between NAS & laptop later.

> Yes, have you never edited the metadata?

I don't even know what that means.

And just because some OS's copy the creation date doesn't mean all of them do. Specifically, the most popular desktop OS -- Windows -- doesn't.

(And it has nothing to do with your filesystem. It's your OS.)

>I don't even know what that means

Obviously something like:

  touch -t 202309271530 myfile.txt

And I'm supposed to do that manually for each of the couple hundred photos I copy...?

I'm sorry if I have a hard time taking that suggestion seriously.

>Yes, have you never edited the metadata?

Is your suggestion that people edit the metadata to get the sorting they want? madness...