Is there any evidence that sans-serif typefaces are more readable? I’ve previously seen headlines claiming the opposite.

You can find evidence for both sides, because life is more complicated than that. Do you have 20/20 vision? Hi-def screen? High contrast? Floaters in your eyes? Cataracts? Are you tired? How is the text laid out? Line spacing?

Literally all of these can impact the answer.

Ok, now insert "broadly" or "generally" into the previous comment and respond to what they actually meant.

Mixed evidence like they said, it depends

I love the use of the famous “goes to” operator.

  for (int j = i; j --> 0;)

*homonymous (a synonym is the opposite of a homonym)

Are you sure that a synonym is the opposite of a homonym, rather than say, the logical inverse corollary of a homonym? I'd think "the opposite of a homonym" would just be a word spelled differently from the target word, no?

A synonym is a different word with the same meaning. A homonym is the same word with a different meaning.

True, thanks. Had forgot this term even existed.

You’re assuming that people choose languages based on merit and not based on how much money someone will give them for using them.

You're assuming something better on merit wouldn't make more money as a result, and I'm questioning the actual merits as a result

That's a bit of an ad feminam attack, isn't it? Just because I used the phrase "business concepts", somehow money is the only thing I care about when it comes to language choice? And yet, in my top-level post I said I went and learned lisp and clojure and read SCIP, and I will add that I did both of those things for fun. So no, I don't only think of programming languages as a way to make money. Elegance and expressiveness are interesting for their own sake. I trained as a mathematician; of course I think that.

But TFA was riffing on Paul Graham's old essay Beating the Averages, which argued precisely that the expressiveness of Lisp gave his startup a business edge. That was the context of my comment. I'd add that most of what most of us do in our day jobs is to use programming languages to make money, and there's no shame in that at all. And if you want to talk about why certain languages get widespread adoption and others not, you have to talk about the corporate context: there is no way around it.

But I'll rephrase my question, just for you: "what abstract problems can you solve or thoughts can you express in Clojure that you can’t express in Python or Rust?"

How on Earth did you turn that into a sexist attack? Unless you two actually know each other IRL, and the GP shows sexism to you...

Oh, I didn’t say GP was making a sexist attack. If I thought that I would have said it clearly and distinctly. Ad feminam is just the feminine version of ad hominem. I like Latin.

I’m sympathetic to looking down on the obsession with money. But there’s something deep and important about the monetary element. Engineering is about solving real-world, practical problems. The cost is a real factor in whether a potential solution is a useful one.

I think the money question is a red herring here. I’d phrase it more like: what problem in a user’s problem space is expressible only like this? And if the only user is the programmer, that’s alright, but feels more aligned with pure academia. That’s important, too! But has a much smaller audience than engineering at large.

some people only think about life as a way to make money. unfortunately coding was best-in-slot career for too long and these kinds of people hijacked the culture.

There are GC algorithms that don’t require stopping the world.

By your definition, is Nim a GC language?

So by that definition yes, as of Nim 2.0 ORC is the default. You need to opt-out of it.

I'm not sure this opt-in/out "philosophical razor" is as sharp as one would like it to be. I think "optionality" alone oversimplifies and a person trying to adopt that rule for taxonomy would just have a really hard time and that might be telling us something.

For example, in Nim, at the compiler CLI tool level, there is opt-in/opt-out via the `--mm=whatever` flag, but, at the syntax level, Nim has both `ref T` and `ptr T` on equal syntactic footing . But then in the stdlib, `ref` types (really things derived from `seq[T]`) are used much more (since it's so convenient). Meanwhile, runtimes are often deployment properties. If every Linux distro had their libc link against -lgc for Boehm, people might say "C is a GC'd language on Linux". Minimal CRTs vary across userspaces and OS kernel/userspace deployment.. "What you can rely on/assume", I suspect the thrust behind "optionality", just varies with context.

Similar binding vagueness between properties (good, bad, ugly) of a language's '"main" compiler' and a 'language itself' and 'its "std"lib' and "common" runtimes/usage happen all the time (e.g. "object-oriented", often diluted by the vagueness of "oriented"). That doesn't even bring in "use by common dependencies" which is an almost independent axis/dimension and starts to relate to coordination problems of "What should even be in a 'std'-lib or any lib, anyway?".

I suspect this rule is trying to make the adjective "GC'd" do more work in an absolute sense than it realistically can given the diversity of PLangs (sometimes not so visible considering only workaday corporate PLangs). It's not always easy to define things!

> I think "optionality" alone oversimplifies and a person trying to adopt that rule for taxonomy would just have a really hard time and that might be telling us something.

I think optionality is what gives that definition weight.

Think of it this way. You come to a project like a game engine, but you find it's written in some language and discover for your usage you need no/minimal GC. How hard is it to minimize or remove GC. Assume that changing build flags will also cause problems elsewhere due to behavior change.

> Similar binding vagueness between properties (good, bad, ugly) of a language's '"main" compiler' and a 'language itself' and 'its "std"lib' and "common" runtimes/usage happen all the time (e.g. "object-oriented", often diluted by the vagueness of "oriented")

Vagueness is the intrinsic quality of human language. You can't escape it.

The logic is fuzzy, but going around saying stuff like "Rust is a GC language" because it has an optional, rarely used Arc/Rc, is just off the charts level of wrong.

Do you consider ORC a tracing GC, even though it only uses tracing for cyclic types?

By modularizing the compiler, it will presumably be easier to create syntactic skins for Nim. I’m planning to make an S-expression syntax if nobody else does.

On the other hand, it’s more ergonomic and readable because you don’t need to declare a new name.

  if name != nil:
    echo name

versus

  case name
  of Some(unwrappedName):
    echo unwrappedName

Compared to HTML, Markdown is very bad at being mahcine-readable.