gnuvince

~Zig doesn't support TCE.~

Edit: Tried with different optimization levels, it seems it might. I wonder if it's an optimization from LLVM. Nevertheless, I don't think that Zig is the kind of language where you want to use recursion as your primary mean of looping; it's not a functional language, it's a procedural language.

Hijacking this topic to talk about something I've been thinking about lately: literate diffs.

I find that the order of diffs given by git is not optimized for helping a reviewer understand the change. Sometimes the order of files will not be in the most logical way; sometimes unrelated changes (e.g., a text editor removing blanks at the end of lines) create noise; etc.

I've been thinking that it would be interesting to have a tool where the author can take the diff of their commit(s), order them in a way that is conducive to understanding and explain each part of the diff. That'd be similar to having the author do a code walkthrough, but at the pace of the reader rather than the author.

I didn't know much of anything about ASL, but seeing David Cowan at some press conferences in Georgia made me a bit curious. There's a nice video of him on Youtube[1] where he explains that deaf people's native language is ASL, and not English. That was absolutely flabbergasting to me, because I had always imagine, like you said, that it was just "do this gesture to mean this word and this gesture for this other word".

[1] https://www.youtube.com/watch?v=Nd5JGN1jno8

> I’d wager that you have a better chance of translating OCaml or non-fancy Haskell straight into Rust than you do C++.

I found that translating OCaml code to Rust is frustrating, because you cannot easily and cheaply replicate the functional approach. It's much more Rustic to take an object by mutable reference and modify it in-situ than it is to take an immutable reference and return a new object. The reason is that in OCaml, you have structural sharing, i.e., multiple pointers pointing into the same data structure, which is a big no-no in Rust, so if you want to replicate the functional OCaml code, you begin allocating a new, complete data structure every time, and that's costly.

Regarding syntax highlighting, I created my own Emacs theme a few years ago to have only a few constructs highlighted:

* The name of a function being defined

* Comments

* String and character literals

The result is very calm [1], but I can still rely on colors to know orient myself and know when I forgot to close a string literal.

[1] https://vfoley.xyz/syntax-highlighting/purp3.png

> how do you win?

By spending quality time with your friends and having a lot of fun imagining an epic quest?

The problem statement said that the input would be natural numbers.

For people who, like me, thought that this would be slower than repeated division: my crappy benchmark indicates that allocating a new string and taking its length is faster by a factor of 2–2.5x.

Edit: In C, the version that loops is 15 times faster than the version that allocates a new string. Python is weird.

By using a do-while loop, you don't have to handle the special case of zero (although one could argue that the do-while loop is the special handling for zero). Python does not have such a loop, so you need to do an infinite loop with an explicit break and I know some people recoil in horror at the sight of such code.

    def digitlength(n):
        digits = 0
        while True:
            digits += 1
            n /= 10
            if n == 0:
                return digits

There's a download option to have Fantasque Sans Mono without the looped k.

https://github.com/belluzj/fantasque-sans/releases/download/...

That's Hack [1].

[1] https://sourcefoundry.org/hack/

There aren't yet, but Iosevka now has an experimental proportional version. It does not seem to have ligatures yet, however that might just be a question of time.

I used Iosevka for a whole year and it is one of the best fonts I've ever used, amazing quality. I only changed to Input because I wanted to have some variety.

In fairness to Microsoft, Cascadia Code is still a young project. A couple of weeks ago, they had their second release which added Latin characters (vowels with accents, cedillas, etc.) Hopefully they keep adding more.

Practically, we look at text all day long, so having a font that is easy to read is good ergonomics. A font may be good for code, but might not work as well in a tool like htop or gotop.

Monospaced fonts are also interesting from an artistic perspective that resonates with programmers. Font designers are able to be expressive and original despite — or perhaps because of — the constraints of the problem: all characters must have the same width and the text should be readable for long periods of time, often at small sizes.

It's up now (10:04am EDT), but this is the first article on my site that has this much traffic, so it's possible the small Linode instance I use was not able to keep up.

Is this really verb-noun/noun-verb or verb-object/object-verb?

Popularity ≠ Quality.

Zig is a simpler language, but that simplicity comes at a cost: the memory bugs that exist in C also exist in Zig. Users bear the cost of the programmer using a simple language.

Rust is a more complex language, but it eliminates a number of classes of memory error. In this case, the programmer bears the cost of users having safer programs.

Although I find Zig very interesting—and I wish Andy the best of success with it—the trade-off that the Rust offers is more in line with my values and my ethics.

> Boldface strikes me as a lack of respect for the reader. An adult reader is supposed to read the whole text.

Yeah, that's bullshit. Open any CS book on your shelf and you'll see different fonts, different sizes, different weights, different background colors, etc. Those books are not written for kids, they're written for adults—for professionals. The goal of a writer is to control the reading process; changing what the text looks like is one way to do that.

We separate the text into paragraphs to delineate different ideas, but also to space out the text and give the reader a chance to breathe. We organize points into bullet points because they're easy to spot, easy to scan, and we don't need to make the text longer by adding flow between each point. We sometimes use frames and a darker background for summaries, auxiliary information, etc. to show that it's not part of the main text. We use large letters to identify different chapters and sections. We use a monospaced font for code examples. We write technical terms in italics when we first introduce them and want to highlight that fact to the reader.

There are a multitude of ways in which we format text so that readers can better follow. Bold is just one extra tool in that arsenal. Don't abuse it, but don't forbid it entirely either.

One big problem with Fira Code is its lack of italics.

There are too many colors in too many places. Everything is highlighted and nothing stands out.

Damn near impossible to read the code in those blockquote blocks :(

Dan Luu has an article titled exactly the same: https://danluu.com/wat/

> Rust couldn't solve all of these bugs, but it certainly would have drastically reduced the total amount.

Well there's certainly a chronological argument that it couldn't have, but I agree with the sentiment. It saddens me that our industry is one in which people _do_ let perfect be the enemy of better.

I'm interested to know how the language handles memory; automatic memory reclamation without a GC and that is simpler than Rust seems like a very attractive proposition.

I admit that I'm very unexcited about non-lexical lifetimes—the cost-to-benefit ratio seems worse than the current model. The current lifetime system is simple to understand: a value is live until its owning variable goes out of scope. It can be a bit restrictive sometimes (though it seems that after a while you learn how to work around those issues easily enough), but it's easy to keep in your head and reason about code. With non-lexical lifetimes, I think that we'll have a harder time understanding lifetimes, it'll be more difficult to teach them and to debug them.

If you don't mind a bit of a re-education, Rust allows you to write programs that are as fast as those written in C or C++ and you'll be more confident that they don't have strange memory bugs. (Reason: the ownership model of Rust prevents a lot of bugs that are found in C or C++, but this model also rejects many correct programs, so you need to re-learn how to write some programs.)

The sad thing is that Rich Hickey had some very good videos when Clojure was a new thing back in 2008–2009. Unfortunately, I've disagreed vehemently with most of his talks since then. In this case, it's completely illogical that a function `Maybe a -> b` should be callable as if it were a function `a -> b`. Do you want to know how I know? Because it would be just as illogical to allow a function `Vec a -> b` to be called as `a -> b`. And Rich must agree because Clojure itself does not support that!

I've learned that videos of his talks are just not worth my time.

(Also non-native English speaker) I feel the same way. I think that when I speak, my listener gives me cues (e.g., nodding or frowning) and I react to them: I reformulate if they seem confused or I keep going if they look satisfied. When I write, I don't have that immediate feedback, and I typically write more than is necessary. My writing suffers because it takes too long to convey ideas that are not confusing, but that I fear may be. The old adage "keep it simple, stupid" applies also to writing, and it's really hard.

By the way, I thought that this paragraph that you wrote was perfect, very easy to understand. If you write like this all the time, then don't worry: people will understand you.