3 ms·

I much rather blame the type system designers, however heroic and brilliant they may be, than the folks using them. Especially so in scenarios like large & coll

I much rather blame the type system designers, however heroic and brilliant they may be, than the folks using them. Especially so in scenarios like large & collaborative evolving code bases, legacy, module composition, evolving tools, etc. That some API doesn't conform to the abysmal ergonomics and astounding stupidity of most type systems isn't a problem with the API, but an endemic problem of modern type systems being dumb, weak, and hard-to-use. To an embarrassing extent, even most "advanced" type systems aren't super far from what came out of the 1970s. After writing ML-typed code for years, you learn the disappointingly primitive level of reasoning most textbook solvers can handle, and warp your code style ahead of time to that. Simpler calling conventions, all sorts of hints to inferencers, hacks around IO, etc. Language implementors know these systems have major issues in practice and thus tack layer after layer of weird special forms to handle what is "natural" in modern code. And then you get junior developers on a team, and have to pretend that this is all good and then hope they don't quit when they get byzantine type errors. And not tear your hair out when some library updates around these changes. In a world where you can write 10 words of English and get synthesized a unique photorealistic image, or can sketch some code and get it autocompleted, maybe the problem is most type systems (still) suck. It's not inherent because we can manually reason about code & even run it -- and shifts to previously sacrilegious research like plugging in SMT solvers and neural networks has been changing historically conservative fundamental assumptions at a snails pace -- but that's where we are. So again, I wouldn't categorically blame the poor developers subjected to embarrassingly dumb solvers & UX's.

dmix 4y ago
You’re probably right but much of that is the consequence of having the baggage of using JS and the legacy of popular libraries that will get mashed through typescript with heavy influence on its spec. TS (probably) didnt have the luxury of thinking it out the necessary constraints and foundations for a top tier type system. Of course there were some bad choices like the XOR Union stuff mentioned elsewhere in this thread, but all of those make sense when you consider the type of code typically written in JS (before TS). Typescript was probably never going to become popular if it tried to reach that ideal. But it provides way more safety bumpers for junior devs than JS previously had so regardless it’s a major step forward than whatever custom creation we used to hand each dev.
eyelidlessness 4y ago
Shortly after I joined my current team, I was confounded by how a type (here named Thing) was used and I sought to catalogue it for future reference. I defined the type Thing as best as I could understand its usage throughout the software. My direct supervisor very correctly questioned my effort: “surely that is not what Thing is?” I agreed, and yet, that’s exactly what Thing is. In real usage. The type system can express quite a lot more than “Thing is all possible data merged together and even naming keys depends on where you look”, but the type system can’t lie and tell you thing are or are not contrary to facts. It isn’t the type system’s fault that all things are part of Thing, or that no thing about Thing is knowable. It’s something the type system might have helped, if anyone consulted the type system. Instead we have Thing.
sime2009 4y ago
If you can't explain to the type system what you mean, what makes you think you can explain to your co-worker what you mean?
- Smaug123 4y ago
  That's like asking "If you can't explain to a three-year-old what you mean, what makes you think you can explain to your coworker what you mean?". The entire point of the parent comment is that almost all type systems in wide use today are extremely dumb compared to an actual human.
  - sime2009 4y ago
    I've used and debugged type issues in Redux, but even when we figured out what was going on I was often left with the feeling that it was trying to be too clever. In the same way that we should strive towards simpler and easier to understand code, we should do the same with the types we use. Wanting ways of doing even more complex types using ever more complex type systems, seems like the wrong direction. IMHO, much of that complexity is due to what we desire, not weaknesses in the type systems themselves.
  - lucideer 4y ago
    > almost all type systems in wide use today are extremely dumb compared to an actual human This isn't really true in the specific sense though (obviously it's inherently true in the general sense, but that's less relevant here). Type systems are true & accurate representations of data structure and usage - any given actual human (a) may have an inaccurate mental representation of that at any given time, (b) that mental representation may change over time, (c) that mental representation will almost always be incomplete for any reasonably complex system. Being "dumb" or intelligent isn't about representing data structures in memory, but the particular problem being discussed here is very much about that: in that context, humans are usually "dumber" than type systems.
    - lmeyerov 4y ago
      I'm using "dumb" to refer to computationally limited reasoning for even small programs. Think linear regression vs neural networks, or in this case, ML-family type systems (with all the modern trimmings) vs an SMT solver. The "explaining your code to a three year old vs a professional colleague" comment is spot on.
lucideer 4y ago
> I much rather blame the type system designers Your comment may (or may not) be a reasonable criticism of designed-from-scratch languages, I don't really know for sure, but either way none of it applies whatsoever to Typescript. Typescript is by definition an imperfect and over-complicated typed system because they have set themselves the task of levering typings onto a mature (i.e. "has legacy issues") language that was never designed with the intent of being typed. It's even "worse" than similar cases like PHP, where after many versions the core devs have begun slowly implementing weak types on top of the previously-untyped language, because at least they have the luxury of being the core language devs and having the power to deprecate & change APIs if they choose. ECMA have no intent to type JS, nor to do anything explicitly to make life easier for the Typescript project. Despite all the above, Typescript is brilliant because the unnecessary complexity is not layered, it's feature-based. Best-practice features of JS are easy to type in TS. If you're struggling with complex TS features, you're either writing a DefinitelyTyped package for a pre-existing project, or otherwise it's probably a strong hint that you're doing something wrong.
- lmeyerov 4y ago
  One project I'm particularly thinking of here was around the weakness & stupidity of the type system, and major issues around scaling (federated code evolution), for what was intended to be carefully typed ecosystem code. The JS aspects had very little to do with it.

dmix 4y ago

You’re probably right but much of that is the consequence of having the baggage of using JS and the legacy of popular libraries that will get mashed through typescript with heavy influence on its spec. TS (probably) didnt have the luxury of thinking it out the necessary constraints and foundations for a top tier type system. Of course there were some bad choices like the XOR Union stuff mentioned elsewhere in this thread, but all of those make sense when you consider the type of code typically written in JS (before TS). Typescript was probably never going to become popular if it tried to reach that ideal. But it provides way more safety bumpers for junior devs than JS previously had so regardless it’s a major step forward than whatever custom creation we used to hand each dev.

eyelidlessness 4y ago

Shortly after I joined my current team, I was confounded by how a type (here named Thing) was used and I sought to catalogue it for future reference. I defined the type Thing as best as I could understand its usage throughout the software. My direct supervisor very correctly questioned my effort: “surely that is not what Thing is?” I agreed, and yet, that’s exactly what Thing is. In real usage. The type system can express quite a lot more than “Thing is all possible data merged together and even naming keys depends on where you look”, but the type system can’t lie and tell you thing are or are not contrary to facts. It isn’t the type system’s fault that all things are part of Thing, or that no thing about Thing is knowable. It’s something the type system might have helped, if anyone consulted the type system. Instead we have Thing.

sime2009 4y ago

If you can't explain to the type system what you mean, what makes you think you can explain to your co-worker what you mean?

Smaug123 4y ago
That's like asking "If you can't explain to a three-year-old what you mean, what makes you think you can explain to your coworker what you mean?". The entire point of the parent comment is that almost all type systems in wide use today are extremely dumb compared to an actual human.
- sime2009 4y ago
  I've used and debugged type issues in Redux, but even when we figured out what was going on I was often left with the feeling that it was trying to be too clever. In the same way that we should strive towards simpler and easier to understand code, we should do the same with the types we use. Wanting ways of doing even more complex types using ever more complex type systems, seems like the wrong direction. IMHO, much of that complexity is due to what we desire, not weaknesses in the type systems themselves.
- lucideer 4y ago
  > almost all type systems in wide use today are extremely dumb compared to an actual human This isn't really true in the specific sense though (obviously it's inherently true in the general sense, but that's less relevant here). Type systems are true & accurate representations of data structure and usage - any given actual human (a) may have an inaccurate mental representation of that at any given time, (b) that mental representation may change over time, (c) that mental representation will almost always be incomplete for any reasonably complex system. Being "dumb" or intelligent isn't about representing data structures in memory, but the particular problem being discussed here is very much about that: in that context, humans are usually "dumber" than type systems.
  - lmeyerov 4y ago
    I'm using "dumb" to refer to computationally limited reasoning for even small programs. Think linear regression vs neural networks, or in this case, ML-family type systems (with all the modern trimmings) vs an SMT solver. The "explaining your code to a three year old vs a professional colleague" comment is spot on.

lucideer 4y ago

> I much rather blame the type system designers Your comment may (or may not) be a reasonable criticism of designed-from-scratch languages, I don't really know for sure, but either way none of it applies whatsoever to Typescript. Typescript is by definition an imperfect and over-complicated typed system because they have set themselves the task of levering typings onto a mature (i.e. "has legacy issues") language that was never designed with the intent of being typed. It's even "worse" than similar cases like PHP, where after many versions the core devs have begun slowly implementing weak types on top of the previously-untyped language, because at least they have the luxury of being the core language devs and having the power to deprecate & change APIs if they choose. ECMA have no intent to type JS, nor to do anything explicitly to make life easier for the Typescript project. Despite all the above, Typescript is brilliant because the unnecessary complexity is not layered, it's feature-based. Best-practice features of JS are easy to type in TS. If you're struggling with complex TS features, you're either writing a DefinitelyTyped package for a pre-existing project, or otherwise it's probably a strong hint that you're doing something wrong.

lmeyerov 4y ago
One project I'm particularly thinking of here was around the weakness & stupidity of the type system, and major issues around scaling (federated code evolution), for what was intended to be carefully typed ecosystem code. The JS aspects had very little to do with it.