_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.

i totally get what you mean.

i've not been faithful to the original design of Source Code Pro or even Fira Mono or Ubuntu Mono (from which i also derived a lot) but do try to stick to a simple geometrical ideal with only a few exceptions.

Myna's predecessor was a customised version of Source Code Pro. but i've changed a lot of glyphs by borrowing designs and modifying glyphs. so, it may not look like it at all now.

yes, indeed. "condensed" means smaller width and less space between characters, in general. it allows for slightly more code to be shown on the screen horizontally.

i think that you also maintained that it is impossible to reconcile monospace with Unicode.

what would be ideal is a variable-width font which covers most Unicode characters consistently. some Unicode characters (eg, arrow) would need space of 2 characters and so on. making it elegant would require quite a lot of work to ensure Unicode does't look out of place (eg, arrow in your comment).

these are the problems which make me feel full Unicode editing is difficult to achieve in the short run. not to mention the obvious issue of typing Unicode characters from the ASCII keyboard.

i've included a reasonable subset of Unicode in Myna but it may not look very good. don't get me wrong, i appreciate the Unicode advocacy. but until we've something good-looking and well-behaving tooling on that side, using it would be quite frustrating.

any particular glyph you find surprising in Myna? feel free to open a feature request.

i have addressed this in one of the other comments. it is impossible to achieve both elegance (good look) and consistency (monospace width) in these cases. many folks, like yourself, are pioneering full Unicode editing. we, on the other end, are just trying to make editing without ligatures elegant because ASCII, i believe, would remain predominant for a long time to come.

thanks for the feedback. if that be the case, i'm afraid Myna might not be of much use to you.

thanks for pointing it out. i mostly program in ASCII range. Myna covers a reasonable subset of Unicode but one can indeed use Julia as a fallback for Myna to cover Unicode if one wishes.

agreed. formulae are essential LaTeX. are there any particular glyphs compositions which you'd suggest?

if you're looking for those Haskell operators, you'd find them in the huge banner at the start. maybe i should also add them in the illustrations too.

thanks for the feedback. i'd like to think it's just a preference issue.

i didn't know about Go Mono. it looks alright but monospace serifs are probably not for me.

thanks for the feedback. i didn't think about it until a few people commented here. if you use it and want it changed, please open a feature request. just like the curly braces, a disambiguating variant of Myna can be issued in the next release. i gather removing the left stroke at the bottom of the `l` would fix it for you. i think changing the `1` won't make sense as that's how it always is.

thanks for testing it. if i can suggest, a wider space between letter helps, for me at least.

Ubuntu Mono is great. many glyphs in Myna are directly borrowed from Ubuntu Mono, just more condensed and better aligned.

thanks! in TypeScript, i've not noticed any glaring combination mismatches. i think most common combinations are covered by considering C and Perl. but feel free to try and report them if you find any.

good idea. since i don't code in J, can you supply a 2-3 line quintessential J example to demonstrate this?

thanks for the suggestion. i'd think about adding screenshots of other fonts.

about the alignment, i think the README might give an impression that it's solely about vertical alignment, but it's more about uniform flow of characters along with some resemblance with an actual symbol (which we can not have in ASCII).

for example, take the `<-` combination. i think you're correctly pointing out that in most fonts they are indeed vertical-aligned properly. but there are other details (horizontal alignment, angle between strokes, weights, etc) which i found missing. in most monospace fonts, these less-than and more-than signs are not designed with the view that their most common usage is indeed not checking for inequality but for bitwise operators and struct pointer dereferencing (C), function declaration and monadic/applicative/functorial programming (Haskell), shell redirection (bash), function composition (OCaml, Elixir), tags (HTML), and countless others. if you think about it that way, it makes sense to not make the angle between strokes too small. many monospace fonts do it because they respect classical typographic conventions regarding space and design. the same goes for the designs for backquote, tilde, comma, colon. in most monospace fonts, backquote is so small it's barely visible and tilde looks too much like the hyphen, etc.

Myna is my attempt to break some of these conventions to make things look a little bit even for programmers.

i don't think that qualifies. because the alignment issue is about multi-line alignment of upward arrows. APL usage is clearly meant to be covered by some single Unicode glyph.

Iosevka is a beautiful font indeed. the condensed look of Myna was inspired by Iosevka. i saw it once in a coding demo and decided to make it condensed. the predecessor of Myna (called Hera, available on my profile) was just a customised version of Source Code Pro (and is non-condensed, just like Source Code Pro).

thanks for the feedback. almost all of the Latin extended and quite a reasonable subset of Unicode is covered. the word "naïve", for example, renders perfectly because the "i with diaeresis" is present in Myna. if you find any which are not covered and want them added, please create a feature request. about the fallback font, you can use any monospace font you like. i don't use any fallback generally because i work almost exclusively in the ASCII range in the editor.