I'm curious how this sentiment of pg's rhymes with his two languages, Arc and Bel. As a person who has written a Bel implementation, I find one of the traits the language has is that it's trying to be "straightforward" in the same way spoken language is.

Fun side note on this:

Bel's macros are definitely macros and not Kernel-style operatives. Here is a comparison, for clarity:

(A) Bel's macros do a syntax->syntax transformation, but this expansion happens (according to the spec) in the evaluator, after concluding that the operator is a macro and not a function. (B) In the greater Lisp-and-Scheme tradition, macros do a syntax->syntax transformation, but at compile time. (Usually after "read" but before "eval".) In this sense, they are small compilers themselves. (This puts limitations on macros: they have to be "statically visible" in the code. You can't late-compute a macro at runtime in this system.) (C) Kernel's operatives do a syntax->"side effect" transformation, at that same late stage as Bel's macros. Kernel operatives are essentially functions, except that the evaluation of the operands (syntax) into arguments (values) has been suppressed. In this sense, operatives are small interpreters.

If an (A) macro is well-behaved, you can often "optimize" it either to a (B) form or a (C) form. In my Bel implementation, it took me ages to notice that I could do the latter. I documented it here: https://github.com/masak/alma/issues/302#issuecomment-992556...

Hooray! Another Bel implementation!

As someone who is on their third year of Bel implementation -- getting there -- I recognize many of the insights in this post about continuations and about the well-chosen Bel built-ins. Great work, and thanks for writing this post.

Your project looks great! Appreciate the kind words :)

As a westerner living in mainland China, I might be able to weigh in on this. China's data does indeed look hard to believe from basically anywhere outside of China (and New Zealand). I don't expect to sway anyone who doesn't want to be swayed.

But I can say this: (a) there really is a pervasive nationwide effort to track and trace, which affects everybody and everything, and (b) the minor outbreaks that do happen get shard pretty faithfully on social media -- even if there is also censorship, it seems it's not as fast as the grassroots spread of news.

This reply is a good example of how "strongly typed" ends up meaning practically nothing -- except possibly "the kind of type system I prefer".

I once attended a talk where the speaker had identified half a dozen axes that papers or projects were calling "strong"/"weak" with relation to type systems. Some were not even consistent with themselves, switching definitions halfway.

Type systems are tools, whose formal properties can be described and analyzed in precise detail. Unfortunately, that kind of precision is hard, so semantically empty words like "strong" get used a lot instead. This message is intended to raise awareness about that fact.

Well one can analyze that type systems are till the hell freezes over. I personally do not care as this precise knowledge (assuming it is formalized and exists) is of zero value to me. When I want to walk I just do. I do not dwell on the details of the walking process.

Anyways most likely you do know well what I meant. JS vs C++ for example.

Neither the type system of C++ nor the type system of TS is sound, in the sense of "the type system rejects all incorrect programs".

If what you meant by "strong" is just "you can declare types on variables", then both TS and C++ qualify as strong, but JS doesn't.

Your use of the word is based on feeling, not fact. Which was my point.

Typescript compiles down to Javascript. And this is the problem. When I say uint16_t in C++ I know how it will be kept in RAM and what I can do with it, how I can pack things together etc. etc. TS lacks this abilities. You can play with terminology all you want but it does not change simple facts.

You could (probably can) compile C++ to JS. What will that be? In the end, code is just data operating on data with no semantics. Your uint16_t is only meaningful to the compiler, the same way as TypeScript types are (with a few caveat).

The two behaviors don't seem very related.

In `if a == b == c`, the value of `b` is evaluated only once, even if `b` is in fact a bigger/side-effecting expression, and `c` might not be evaluated at all.

In `a = b = c`, the `c` is evaluated first, and then `a` and `b` are assigned to, left-to-right.

If I may be so bold as to recommend my in-progress Bel implementation: https://github.com/masak/bel

Caveat: I'm still working towards being able to recommend Bel _unconditionally_, not just for small programs. Right now you'll experience unreasonable slowness, terse/uninformative error messages, and missing documentation -- probably in that order. All of those are being addressed. But already today, it's fun to play with.

He's poking fun at himself with the whole "programming has never been my forté" -- the fact that he kept count of all the bugs in TEX and METAFONT is the amazing thing.

At the risk of stating the obvious, iTeX is not a real successor of TeX, it's a deliberately-vaporware joke.

I know the Swedish like to repeat that there is no second wave like in the other European countries, but... I've been looking at this graph for the past few weeks: https://ourworldindata.org/coronavirus/country/sweden?countr...

Now, it might be that the new cases this time are less severe, I don't know. But it's a second wave.

So, I've been thinking about this comment a lot over the weekend.

It is interesting to consider a "cool kids" demographic, of developers who stray far enough outside of the mainstream to find small but worthy languages. These would include Scala, Haskell, Kotlin, Clojure, Racket, and Rust. (Plus anyone's favorite non-mainstream language, which I in my haste totally forgot!)

Earlier this year I found that, at a rough approximation, language mind-share in 2020 consists of 25% Java, 25% JavaScript, 25% Python, and 25% everything else. (My source for that is https://www.youtube.com/watch?v=Og847HVwRSI -- and I'm sure there are any number of possible objections against those numbers... but I think my point holds even if they're several percentage points off.) We live in the strongest language oligoculture since FORTRAN and COBOL in the 1960s. These top three languages, and their communities, act as strong attractors. People flock around these languages because they're popular and established.

Despite that, I'm hopeful. I think there's room for experimentation and playfulness. I think evolution in programming languages is still happening, and that solid/interesting ideas are coming mostly from that fringe, not from the established languages.

Both Arc and Bel have a decidedly hobbyist feel. Maybe that's why they are not drawing large crowds. I think the target audience consists of people who like to "sketch in code" and whip something up in 10 minutes using a REPL and highly interactive development rather than something heavyweight and serious-feeling. A language that "sparkles joy" a little bit, where easy things feel easy. And I don't think it's too late for that, or that the fringe has run out of room for such language attempts.