_piud

When we first encounter the definition of a continuous function in general topology, it often feels completely backward: Why is a map defined as continuous if the pre-image of every open set is open?

Shouldn't a structure-preserving map send open sets to open sets (open map) instead?

Most texts warn us not to confuse the two, throw a couple of counterexamples, and move on.

Here is an essay building an intuition for why this definition works the way it does and why "pushing forward" fails while "pulling back" works to ensure continuity.

author here. the idea is to see how the Y and Z combinators come out relatively naturally given an extremely constrained context with no loops, no recursion, no bindings. the article is intentionally structured as a sequence of failed attempts that progressively reveal which phenomenon is still responsible for the recursive behaviour.

in the article, i define recursion narrowly as "... call the function `fact` from inside the definition of the function `fact`".

you're right that `factgen` is also not recursive but it is also rejected, but for a different reason: self-reference. declarations are banned precisely because they give a function a "name" that can be referenced later.

please note that the solution which uses Z combinator (given at the end) grows from `(x => x(x))(x => x(x))`, which is NOT self-referential. it achieves self-replication by literally rewriting the content of the function twice, which is different from self-referential recursion of `factgen`.

hope that clears some of the confusion.

thanks for the feedback. a few people have expressed the same criticism. i'm open to producing a variant with less-curly curly brances. please raise an issue, if you want to use it.

as is expected, all codes in the illustrations, especially the C code, are to be judged superficially, ie, by their covers, not content :)

as i mention in the description, Myna doesn't use ligatures. the Unicode sure looks very much like that in the font, though.

designer here. thanks for the feedback. i've updated the serif in `l` after an issue raised the possibility of ambiguity with `1`. alas, that would mean i'd need to regenerate all the images, which i haven't done yet.

i didn't produce a variant for the `l` serif, please check issue #8. if you prefer the variant, please open an issue. can you elaborate on the kerning point, preferably there also?

i've now added a table comparing Myna's symbols with a few other popular fonts in the README.md (without naming the fonts explicitly).

i meant programming in general, not just C.

the inequalities would probably be more common than bitwise/pointer usage in C, most because of for loops, i guess.

but if you consider all the other languages i listed, it is obviously not the case, especially in Haskell and even HTML.

thanks for the suggestion. i'd definitely add it once some obvious rendering bugs on Windows are found and resolved.

i thought the illustrations were enough to decide if one likes the font.

now i have also added a comparison table of Myna with many popular monospace fonts (if that could help gauge the utility).

i understand that there would be many many folks who would find this font ugly and unusable. it is largely a matter of personal preference.

thanks for the feedback. i think the em-dash is not very different in case of this font too. i made the (en-)dash so wide that there was no way to disambiguate within fixed-width constraints. i don't use em-dash at all, so there was no need to disambiguate too.

if you want to use it but em-dash is the only deal-breaker, please try it once and raise a feature request. i'd see what we can change to make it work.