David Madore

> Possibly the most natural representation of a UTC instant would be an integer, because fundamentally UTC is a count of milliseconds

It's not! It's a subtle point, but because of leap seconds, the correct representation of UTC is the tuple (year, month, day, hour, minute, second, ...), with the `...` being filled in with your desired precision.

From: http://www.madore.org/~david/computers/unix-leap-seconds.html

> Unlike TAI and UT1, the UTC time scale should not be considered as a pure real number (or seconds count): instead, it should be viewed as a broken-down time (year-month-day-hour-minute-second-fraction) in which the number of seconds ranges from 0 to 60 inclusive (there can be 61 or 59 seconds in a minute); during a positive leap second the number of seconds takes the value 60 (while a negative leap second would skip the value 59, but this has never occurred).

...

> If we attempt to condense UTC to a single number (say, the number of seconds since 1970-01-01T00:00:00 or since 1900-01-01T00:00:00, or the number of 86400s-days since 1858-11-17T00:00:00, or something of the sort), we encounter the problem that the same value can refer to two different instants since the clock has been set back one second (negative leap seconds, of course, would cause no such difficulty).

Most datetime libraries get this wrong. I know because I'm working on a new one that specifically doesn't get this wrong.

Unfortunately "functional" is coming close to being the Next Big Idea, which means it stops meaning anything specific. If you look at unlambda[0] as the kind of Platonic ideal of functional languages you might see what GP is talking about.

It lacks any facility for bindings because any binding is a storage of state. Roughly, since you can refer to every function and value literally, the idea behind unlambda is that you should.

(Note that by this way of looking at things, closures are not "functional" at all and are in fact embeddings of imperative mini-languages.) Historically, closures were more or less developed by accident as LISP codified its scoping rules; in that sense their presence isn't particularly indicative of "functional ness"; it's just that using them requires a GC and 40 years ago only functional languages had one.

[0] http://www.madore.org/~david/programs/unlambda/

I use sakura, since it has great support for unicode (presumably through libvte, which also xfce4-terminal uses). See e.g. https://i.imgur.com/G6arkK9.png using some extracts from http://www.madore.org/~david/misc/unitest/

- xterm just gives up (tried uxterm as well as the .Xresources settings here)

- st prints the arabic backwards (left to right, which I suppose you might prefer if you don't actually plan on reading it), has no colour on the emoji (which again you might prefer!), and completely fails to display the double-composed diacritics (this is a bad one, even if you prefer to KISS)

- I don't know what kitty is doing with the arabic, all I see are some strange rendering artifacts

- sakura (and xfce4-terminal) passes all the tests

In a semi-related, semi-off-topic way, there was this challenge of going through all the subway stations of the Paris underground, during the same day (and if possible in the fastest way possible):

http://www.madore.org/~david/misc/defimetro.html [FR]

The funny part was that they wrote a program to calculate and optimize the time to do that, using the length of the lines and the little public info they had; and I thought it was pretty cool.
http://www.madore.org/~david/misc/metro.tgz

And of course, it was in 2002, so before the OpenData movements...

In French, if you see the written word you can deduce with a few simple rules how it is pronouced. However, information is lost on the way, it's hard to reconstruct how the word is written based on the sound (and there are many homophones where this is just impossible).

In English there is not such deterministic way of simply deducing how a word is pronounced based on how it's written. In fact there are many heteronyms.

You have a tear in your trousers but a tear in your eye.

http://www.madore.org/~david/misc/english-pronunciation.html

CEK[1] machines are very clean way of implementing continuations or other features that can be implemented in terms of them in a language with no support for lambdas or closures. they are also reasonably fast too. i implemented a simple unlambda[2] interpreter in haskell using the cek/cesk style and it was ~20% faster and more memory efficient than the fastest c interpreter i could find.

[1] https://matt.might.net/articles/cek-machines/
[2] http://www.madore.org/~david/programs/unlambda/