MrJohz

This is one of the more common definitions, yes, but it's not used very consistently. The comment I replied to used a different definition, and I also commonly see the definition that weak typing is the ability to convert a type from one form to another (à la C).

Like I said, if you're going to talk about automatic type conversion, then calling it "automatic type conversion" is probably the simplest option - strong vs weak typing doesn't really need to come into it. Then you avoid any definitional confusion.

That's also true of Python, though, which is traditionally considered a strongly typed language.

I'm increasingly convinced that "strong/weak" has no useful meaning. Some people regularly use it interchangeably with "static/dynamic", others use it to vaguely refer to how much casting exists in a language, or how easy it is to transmute a value of one type into a value of a different type. There is no academic definition at all.

Mostly it gets used as a kind of cheap attack - it's like the meme "it's over, I've portrayed you as the soyjack and me as the chad". Good languages are strong, bad languages are weak, so if I say your favourite language has weak typing, and my favourite language has strong typing, then it's clear that my favourite language must be superior.

In general, I think it's more helpful to just reference the specific language feature you're talking about. Rather than say that JavaScript is a weakly typed language, instead say that there are a lot of implicit type conversations. Rather than say Erlang is strongly typed, say that there is no variable reassignment or shadowing. That way, you avoid the ambiguity about what you actually mean when you talk about strong or weak typing.

In theory yes, in practice, I remember reading forums on my phone in the days before responsive design was a thing, and there was nothing inherent about those sites that worked better on phones...

Not really, no. AAV isn't just a form of slang, it has distinct and measurable grammatical differences from standard American English, such as its own verb tense, or a requirement for negative concord. You can measure these sorts of features quite clearly, and they are distinct from slang.

I don't think it's nationalism per se, more just a national identity. You see independence movements across Europe (Catalan, Wales, Cornwall, some of these have more realistic prospects than others) that tightly bind the idea of nationhood to a collective language - we are all one people because we all speak the same language. And similarly, when larger countries want to suppress these independence movements, cracking down on their ability to learn or even speak that language is often a key tool used to do that.

Tbh, that's exactly what I always liked about forums. They weren't as good as a searchable source of information, but in terms of discussion it really hit the sweet spot for me. A single conversation could meander in different directions, but you still had the first page of the thread as an anchor point, and because there was only so much quoting you could do before it became obnoxious, the conversation remained more cohesive. You had at most 2-3 separate trains of thought happening at once, as opposed to in a threaded forum like HN or Reddit, where the fringes of a conversation feel much more spread out.

Timetables yes, but whenever I've bought a digital watch or set up a new device, the default has always been 12-hour. If you ask people the time in the afternoon, they will almost always give you the 12-hour format. People can understand both, but typically default to 12-hour times.

This is in stark constrast to Germany, say, where people colloquially use 24-hour times, with some exceptions for round times (e.g. 17:00 might be called "um fünf", but 17:05 would usually be described as "siebzehn uhr fünf", roughly translated as "seventeen oh five".

This might have changed in the last five years or so since I was living in the UK, but I've never noticed this be different when I was visiting, nor when speaking to British friends or colleagues.

But I think that national identity doesn't exist in the same way, do you know what I mean? Like, being Black/African American in the US is an important part of a person's identity, but it doesn't necessarily have the trappings of nationhood in the same way that Scottish identity does. That's not to say that the identity is any weaker, just that it manifests itself differently.

This means that AAV is culturally important, but there's not necessarily the same sense of "this is a separate language" that there is with Scots, even though in many ways it has all the same claims of being one.

In fairness, I think that's partly because AAV doesn't have the political and national identity that some other similar dialects have. I (as a lay person with no training in linguistics) feel like AAV and Scots are similar in terms of how far away from English they are, and many people would describe Scots as its own language, distinct from English.

Why would you even say something like that? Haven't those people suffered enough?

I don't do the "chips" one, because it's usually clear enough from context, and the people I speak English to generally know me and my foibles. But I do religiously say "half past 6" now, instead of shortening it to "half six". In Germany, you count towards the next hour, so our "half past six" is their "half to seven".

To avoid ambiguity, I always say "half past" in English so that Germans (and I!) remember to compensate for the language barrier. Unfortunately "half to" isn't really a thing in German, so I can't do the opposite when I'm speaking German.

It's more complicated than this and how you say "quarter to eleven" is A Whole Thing in Germany, but everyone agrees on the half hour at least

Once you start going in that direction, a lot of things that British people say can require some amount of translation, see e.g. this table: https://miro.medium.com/v2/resize:fit:640/format:webp/0*0Fs1...

The time format in the UK is mostly 12hr, although people are generally aware of 24hr time. In my experience, while there are usually more similarities between the UK and the rest of Europe, Europeans also have more exposure to American English than to British English, so it ends up being a bit of a wash, particularly when it comes to pronunciation, spelling, or idioms.

You can use one of the following:

`allowImportingTsExtensions: true` (https://www.typescriptlang.org/tsconfig/#allowImportingTsExt..., useful if you're running `tsc` in noEmit mode as a linter)

`rewriteRelativeImportExtensions: true` (https://www.typescriptlang.org/tsconfig/#rewriteRelativeImpo..., useful if you're using `tsc` to compile TS files to JS.

This allows you to use fully-specified imports in TypeScript files, which works basically everywhere — NodeJS, TypeScript, bundlers, etc.

The exceptions are browsers (obviously, only normal JS syntax there), and packages inside `node_modules`, which NodeJS will not do any type stripping for. So if you're writing a library, you'll probably still need to distribute the compiled sources, rather than distributing the raw TypeScript files alone. Or you use the JSDoc syntax for TypeScript, which can do everything that .ts files can do, but is more verbose and idiosyncratic.

The medium is the message — if the majority of people are interacting with a system via one of those mechanisms (say, threaded), then the conversations will look/feel thread-y.

You can see this on Reddit already if you look at live threads, which some subreddits create for live events, episode releases, etc. Typically, the mods will set these to sort by new by default, which leads to something that behaves more like a classic flat forum post, albeit sorted in the "wrong" order. These discussions tend to feel and behave quite differently from discussions in other Reddit posts, simply because the default UI is different.

TS has committed to not adding any more features like that. Features only get added when they reach a certain threshold on the TC39 standardisation track.

The other thing out of date is Svelte using compile-time tracking — Svelte now also uses runtime tracking, i.e. signals.

At this point, I think React and Lit are the only major frameworks not using signals. And I'm not 100% sure about Lit.

Haha, that was part of the reason we originally went down this route. In practice, as soon as you want to implement spills, you lose a lot of the benefits because the contents of a spill can depend on any other cell and affect almost any other cell, and you need to evaluate the spill to figure out which cells are relevant. In the end, we rewrote the spreadsheet engine to use a different mechanism that was simpler and that we could optimise better, and then hooked that into SolidJS for everything else.

I guess technically that part of the application didn't scale so well in SolidJS, but it scaled a lot better than it would have in any other framework, and we got to delay writing the engine "properly" until we'd already built everything else and got it running with real users in production.

I've built quite complex applications (e.g. a spreadsheet app) using SolidJS as a base layer, and in that sense it scales really well. It's very easy to separate data management from the UI, so architecturally it scales well, and performance-wise we rarely had issues with it at all.

The biggest issue is in finding people to work with it. If you're hiring React developers over web developers, they will probably struggle more with SolidJS's differences from React, in part because they just look so similar that there's more to "unlearn". But most web developer (i.e. anyone who can understand beyond just the confines of their favourite framework) should find it relatively easy to understand what's going on.

I think the biggest issue with Deno is that it fixes real issues but in the wrong way.

Take the sandboxing stuff. In theory, you have always been able to sandbox your applications. There are so many tools that let you limit what domains an application can access or restrict access to the file system. This doesn't need to be handled at the language/runtime level. It's just that people were lazy before, and they will continue to be lazy afterwards by running Deno applications with fewer than the minimum set of restrictions because that's easier.

The more complete way of solving the problem would have been capabilities. Rather than sandboxing the whole application, you instead sandbox each individual function. By default a function can make no requests, access no files, execute nothing, etc. But while the application is running, you can pass individual functions a token that grants them limited access to the filesystem, say. This means that trusted code is free to do what is necessary, but untrusted code can be very severely limited. It also significantly reduces what dependencies can do: if you're using something like `lodash` which provides random utilities for iterating over object keys and the like, and suddenly it starts asking for access to the web, then clearly something is wrong, and the runtime can essentially make that impossible.

It's also great for things like build scripts, which are a common attack vector right now. If your runtime enforces that the build script only has access to the files in the project folder, and can't access arbitrary files or run arbitrary commands, then you're in a much safer position than if your build script can do basically anything.

This concept has been explored before, but JavaScript is basically ready-made for it. The language already has everything you need — a runtime that also acts as a sandbox, unforgeable tokens (e.g. `Symbol` or `#private` variables), etc — and you can design an API that makes it easy to use capabilities in a way that enforces the principle of least privilege. The biggest problem is that there's basically no way to make it backwards compatible with almost anything that works with Node, because you'd need to design all the APIs from scratch. But one of the great things about Deno at the start was that they did try and build all of the APIs from scratch, and think about new ways of doing things.

It's usually easier to build something that maintain it for extended periods of time, particularly if that maintenance requires adding new features.

And yet the examples in this post are of slop code, so clearly they're not that long gone.

I mean, it's not that surprising that you'll learn better in a stack you already know well - you know enough there to know what you don't know and need to learn. But if you don't know anything about a language, it will be very difficult for you to sort fact from fiction.

It's basically doing the same thing that, say, `return true` might do to indicate a function succeeded, but with more explicit types. However, because it uses `Result`, it can be used with the `try`/question mark operator which can be convenient in some situations.

That said, a couple of the examples here feel a bit strange - they're clever things you can do, but they're not necessarily things you often have to do, particularly for a relatively simple task like this. I think the problem with the author's approach is that they can't distinguish between "weird because Rust is weird" and "weird because the LLM generated bad code", because they (understandably) don't have enough experience in what good Rust code looks like.

As I understand it, in teaching there's an idea of the "Zone of Proximal Development" (ZPD). Some things you can do without help, other things you can only do if others do it for you, and then in between there's all the stuff that you can do with some amount of assistance. Being in this zone is important for learning, at least in theory.

I suspect that's kind of happening here. If you're trying to learn something too abstract or distant from what you currently know, you'll probably use more polished or eli5-y sorts of material, because you don't yet have the skills to understand a more complex version. You're probably not in the ZPD. But if you can figure some things out by yourself, possibly with some amount of help, then you're in the learning zone and can meaningfully progress.

I have similar experiences to you with 3B1B - it's interesting, but I rarely retain anything meaningful after I've finished - and I think it's because he has to explain every part for me to understand what's going on. I'm not in the zone of proximal development because I can't do enough of the work myself. So the end result is an interesting video where someone explains a cool concept to me, but it's not learning because it's not also doing all the foundation work that gets me to the point where I can understand the video for myself.

This is true, although I have to say as someone who doesn't own a car, good public transport can avoid most of those issues. I live in a small-ish city (500K - 1M pop, depending on how you count it), and I can get pretty much anywhere I need to without worrying about schedules and certainly without worrying about strikes. The biggest issue is getting out of the city - that's when it's usually more important to worry about schedules, but it's still mostly doable - and occasionally transporting furniture or something like that.

On the other hand, the benefits I get from that public transport are incredible - it's cheap, it's always there, it requires minimal logistics in groups (no trying to figure out who goes in what car and needs to be dropped off where at what time), it works regardless of my level of inebriation (admittedly I've not pushed that one to any sort of extreme yet), it's safe enough for children to travel independently (no dropping them off and picking them up), and it's largely accessible for people with difficulties walking or moving about.

I think a big part of the issue is that people have tried out poor public transport infrastructure and recognised - often correctly - that their car is way better for them. But good public infrastructure can often be far more convenient than cars, it just requires people to be motivated enough to build and finance it. A neighbour of mine didn't notice his car had been towed for a week because he used public transport so much and so rarely touched his car. When he'd parked his car it was fine, but then they needed to block of the street to do some work somewhere, and he didn't notice they'd confiscated all the cars there. That's the sort of effect that good public transport can have - so comfortable that you can forget you even have a car.

I'd add jj to that list, tbh. It simplifies a lot of stuff, but in doing so it exposes a lot of those core ideas. That's where I got my list of essential complexity, really - the stuff that comes to the fore when you start using jj.

Did you mean inherent complexity instead of incidental complexity?

I think the inherently complex things in git are (1) the content-accessible object store, snapshots, plus the merkel tree approach to keeping track of commits and parenthood, (2) merges, rebases, and resolving conflicts between two different changes with a common ancestor, (3) possibly syncing commits between different remotes, although I think Git's approach adds accidental complexity to the problem as well.

Everything else is a question of the user interface: how you choose to show a commit, how you choose to update the project files, how you choose to let people create new commits, etc. And I think the Git CLI is a poor user interface in a lot of places. There are a lot of features which are really powerful but difficult to use, whereas actually they could be just as powerful but far more intuitive to use.

In fairness, this is no slight to the Git developers - they are improving a lot of that interface all of the time. And finding a simpler interface is often a lot more hard work than finding the complicated interface, and I don't think I would have figured out how to create something like jj until I'd seen it before.

I don't understand your example. Why haven't you added commit messages? Would you do that with git? In what situation are you creating different branches like that and not using either `jj commit` or `jj describe`?

Or you make tools that are easier to use, so that you can spend that week learning something more useful than the finicky details of branch vs detached head checkouts.