3 ms·

Perhaps optimizing for fewer characters typed is optimizing for the wrong thing, no? C-style format strings could be updated to work differently. Instead of ha

Perhaps optimizing for fewer characters typed is optimizing for the wrong thing, no? C-style format strings could be updated to work differently. Instead of having to lookup and memorize the format characters for hex one could use %{hex}. Instead of wondering what %d/%u/%p are for, one could use %{int}, %{unsigned int}, or %{pointer}. For date/time formatting using %{year} vs %{iso-week-year} would solve the specific problem in the OP. %{m} vs %{b} vs %{B} requires both explanation and memorization. It also suffers from capital letter confusion, with m/M catastrophically poisoning the output while b/B is merely somewhat incorrect. %{month} vs %{month-name-short} vs %{month-name-full} requires no explanation and makes it impossible to confuse minute vs month. A better-designed string formatting system would require minimal explanation, little memorization, be trivial to review for correctness, be self-documenting, and be easily learned by example.

Yen 8y ago
I agree we don't need to optimize for characters typed, and needing to memorize/lookup formatting directives is a time sink. What I _do_ want to see optimized for is readability - and this often is related to more compact representations. This is not hard-and-fast, and there's tradeoffs in both directions. This tradeoff becomes more tricky as you need to express finer grained control over formatting. Consider %{year}-%{month}-%{date} %{year-4-digit}-%{month-2-digit}-%{date-2-digit} %YYYY-%MM-%DD Or, outside the context of dates, Computed %u records in %u seconds (%0.3f MB/s) Computed %{unsigned int} records in %{unsigned int} seconds (%{float-precision-3} MB/s) Computed %{correctlyProcessedRecordsCount} in %{totalProcessingTime as seconds} (%{processingRate as megabytes-per-second with 3 digits precision} MB/s) I don't have a great solution here, I just want to point out that the verbose cases can also get ungainly. I think, if we try to optimize for "format strings read approximately like the text they output", that probably gets close to the best middle ground.
- DCoder 8y ago
  And you haven't even touched localization (digit grouping, decimal separators, singular/plural noun forms, currency formats, week/month names with correct capitalization, …) yet.
andrepd 8y ago
I would also be unwieldly verbose, and break backward compatibility. Besides, what's stopping you from writing a template/preprocessor solution that "transpiles" to printf-strings?
squiggleblaz 8y ago
I don't think any of these solutions is really right. formatted = Calendars::gregorian->format("y-m-d h:m:s z", date) is prefectly fine. And when you want to do week-year formatting formatted = Calendars::weekyear->format("y-m-d h:m:s z", date) will get you there. And you can use the Islamic or Chinese or Persian or Javanese or Julian calendars without having to have additional confusions. You could reconstruct your own Gregorian lunar calendar and use it. One of the major problems in the article is mixing two unrelated things into one package: the customary western calendar and the ISO week-year calendar. You can see why someone might want to do that (because some businesses like to use them both simultaneously for different purposes) but that was bad design (you can tell, because there's the same concept - the year - with two different possible values). Since we can't always be precise, we need to make sure that we always improve our libraries so that they are confusion-proof. If it's explicit, it's good.

Yen 8y ago

I agree we don't need to optimize for characters typed, and needing to memorize/lookup formatting directives is a time sink. What I _do_ want to see optimized for is readability - and this often is related to more compact representations. This is not hard-and-fast, and there's tradeoffs in both directions. This tradeoff becomes more tricky as you need to express finer grained control over formatting. Consider %{year}-%{month}-%{date} %{year-4-digit}-%{month-2-digit}-%{date-2-digit} %YYYY-%MM-%DD Or, outside the context of dates, Computed %u records in %u seconds (%0.3f MB/s) Computed %{unsigned int} records in %{unsigned int} seconds (%{float-precision-3} MB/s) Computed %{correctlyProcessedRecordsCount} in %{totalProcessingTime as seconds} (%{processingRate as megabytes-per-second with 3 digits precision} MB/s) I don't have a great solution here, I just want to point out that the verbose cases can also get ungainly. I think, if we try to optimize for "format strings read approximately like the text they output", that probably gets close to the best middle ground.

DCoder 8y ago
And you haven't even touched localization (digit grouping, decimal separators, singular/plural noun forms, currency formats, week/month names with correct capitalization, …) yet.

andrepd 8y ago

I would also be unwieldly verbose, and break backward compatibility. Besides, what's stopping you from writing a template/preprocessor solution that "transpiles" to printf-strings?

squiggleblaz 8y ago

I don't think any of these solutions is really right. formatted = Calendars::gregorian->format("y-m-d h:m:s z", date) is prefectly fine. And when you want to do week-year formatting formatted = Calendars::weekyear->format("y-m-d h:m:s z", date) will get you there. And you can use the Islamic or Chinese or Persian or Javanese or Julian calendars without having to have additional confusions. You could reconstruct your own Gregorian lunar calendar and use it. One of the major problems in the article is mixing two unrelated things into one package: the customary western calendar and the ISO week-year calendar. You can see why someone might want to do that (because some businesses like to use them both simultaneously for different purposes) but that was bad design (you can tell, because there's the same concept - the year - with two different possible values). Since we can't always be precise, we need to make sure that we always improve our libraries so that they are confusion-proof. If it's explicit, it's good.