Every test starting with T and a number is an example created from a corresponding issue in their tracker. And there is, well, a lot of them.

The other problem is ensuring that such casting is safe, but that requires runtime checking even in dynamically typed languages.

Small nitpick:

> One drawback of this sound type system is that converting untyped input from the outside world into data of known types requires some additional code which would not be required in unsound systems.

It isn't really consequence of its sound type system, but its runtime representation - assuming it requires type information to be safely constructed and manipulated, you really need to generate code to do so, but the compiler could instead choose to use more dynamic representation, e.g. compiling to ordinary Erlang maps / JS objects.

Specifically, this online book (mentioned in that discussion) may be a good resource, I've used author's content as a reference several times: https://www.metalevel.at/prolog

It's not the easiest thing to do, trying to address audience without any feedback, looking at a black object sitting in a room, in multiple attempts and with random interruptions needed to fix technical issues or change shot, while pretending that it is all part of normal, continuous discussion.

People watch him because he is genuinely good at what he does, not because of his presentation or editing skills.

2 questions:

Support for TS in notebooks in VSCode(ium) is currently broken; are there plans for resolving issues with definitions used across different cells?

Future plans for bundler sound interesting - is it something potentially able to replace e.g. esbuild for bundling frontend applications? I'm specifically curious because that would imply (static) Deno's import resolution for browser-run apps - one can use @luca's esbuild plugin, which is nice, but interacts poorly with other, custom plugins and has some rough edges.

``` import Data.Function

main = do let it = fix error print it ```

This article from Guardian touched on this: https://www.theguardian.com/books/2020/may/09/the-real-lord-...

I can certainly have thoughts not accompanied by a language, for example visualizing graph-like or higher-dimensional operations from math/CS more quickly than I could come up with their description. Or "simulating" physical objects, or even whole visual scenarios resembling real life.

But it makes me wonder whether it once again isn't about training or being "wired" for different types of thought. And if it's training, then specific language features may as well force people to exercise and improve specific ways of thinking about problems. It's just that it doesn't have to be limited to language.

Of course there's difference between eastern and western slavic languages, because western ones use latin. In those, I've mostly seen "haha", both when talking in english and in $SLAVIC. At the same time, they can easily write ":)".

It's really trickier than algebraic effects make it seem though. Haskell-ish "monad transfomers" as a stack of wrappers may pick concrete ordering of effects in advance (e.g. there's difference between `State>` and `Result>`, using Rust syntax), but effect systems like one in Koka either have to do the same decision by using specific order of interpreters, or by sticking to single possible ordering, e.g. using one, more powerful monad. And then there're questions around higher order effects - that is, effects with operations that take effectful arguments - because they have to be able to "weave" other effects through themselves while preserving their behaviour, and this weaving seems to be dependent on concrete choice of effects, thus not being easily composable. In a sense, languages like Koka or Unison have to be restricted in some way, giving up on some types of effects. I'm not saying that's a bad thing though, it's still a improvement over having single effect (IO) or no effects at all.