6 ms·

A few things I've come to personally believe after spending years developing web and robotics software in Python/JavaScript then spending years having to mainta

A few things I've come to personally believe after spending years developing web and robotics software in Python/JavaScript then spending years having to maintain while constantly adding new features and dealing with company pivots: - The types exist whether you write them down or not. - If they're not written down, they're written down in your head. - Your head is very volatile and hard for others to access. - Typing is an incredibly good form of documentation. - JSDoc and TypeScript are standards/formats for typing. Like any tools, they both have advantages and disadvantages. Neither is objectively better than the other. - Make informed decisions on how you'll describe your types, and then be consistent and unsurprising. - A type checker is the computer saying, "okay then, prove it" about your program's type validity. - Not every program benefits from the same amount of "prove it." - Too much can be as bad as too little. You're wasting resources proving throwaway code. - I like languages that let you decide how much you need to "prove it."

culi 11mo ago
> JSDoc and TypeScript are standards/formats for typing. Like any tools, they both have advantages and disadvantages. Neither is objectively better than the other. Agreed. Just to clarify, my intentions with this post weren't to advocate for one over the other. Just to point out that they are the same thing. They are both TypeScript.
- KPGv2 11mo ago
  > They are both TypeScript. I take issue with this position because this seems to imply "PureScript and JavaScript are both JavaScript" is a true statement merely because one of them turns into the other with tooling.
  - egeozcan 11mo ago
    I think the point here is that all the TS tooling works with JSDoc without any friction. As long as you don't look into the file, from the tooling perspective, a .ts file and a .js file with proper JSDoc annotations are practically the same.
    - aatd86 11mo ago
      Except the js files can work in the browser as is.. not the ts one (fortunately I might add, I find ts syntax very loaded at times) Either one is superseding the other one, or they are simply distant cousins, but this is not interchangeable. TS from JSDoc requires a generative pass to. This is a (expected) level of indirection. (unless some tooling does it automatically)
  - nosianu 11mo ago
    TypeScript is indeed Javascript, all you have to do is remove the type annotations. They are not code. TS does have some minor things like enums that need to be transformed and are actual code, but those are very few, and leftovers from early days of TS, and the TS authors regret having implemented them. For many years now the TS philosophy has been that the CODE part of TS is 100% ECMAscript, and only annotations, which are not code, are added. The initial Babel transpiler for TS => JS, and still the most part of the current one, simply removes annotations. It is recommended not to use the few parts that are actual code and not standard JS. They are certainly not needed any more since ES6. People may get confused because the type syntax itself is almost like a programming language, with conditions and all. But none of that ends up as code, it's not used at runtime. One of the IMHO worst design decisions of TS was to bundle type checking and transpiling into one tool. That caused sooo many misunderstandings and confusion.
    - KPGv2 10mo ago
      > TypeScript is indeed Javascript No, no. JavaScript is TypeScript. TypeScript is not JavaScript. > type annotations are not code Of course they are. If they weren't code, then a malformed type would not trigger an error. You can actually solve the eight-queens problem with TS's type system alone. https://lemoine-benoit.medium.com/eight-queens-puzzle-in-typescripts-type-system-4c7ff1693545 https://lemoine-benoit.medium.com/eight-queens-puzzle-in-typ... The type system itself is Turing-complete!
- mattmanser 11mo ago
  I don't know how anyone can agree with this, because it pivots on this outrageous claim: "Like any tools, they both have advantages and disadvantages" You cannot make any argument based on such a position. Putting aside anyone's views on TS or JSDoc, tooling is of extremely variable quality, and lots of tools ARE objectively much worse than other tools. It we can't point at tools and say this one is better than that one, we might as well give up. I always remember a scene in Will & Grace where Will is trying to get his boss to say one thing is better than the other. He's brought a lovingly hand-crafted sandwich made with amazing, bread, fillings, etc. and a store bought sandwich made with cheap bread/fillings. He asks his boss to try both and say which one he likes more. His boss says something like the store bought one reminds him of his grandma's sandwiches, so invokes nostalgia, and still can't make a decision. Don't be that boss.
  - rpsw 11mo ago
    I don't understand how this an outrageous claim. You might say a luxury sports car is objectively better than a cheap minivan, but that is no good to someone who needs to transport around a family. Or is you problem with the word any instead of many?
john01dav 11mo ago
> - I like languages that let you decide how much you need to "prove it." Rust is known for being very "prove it," as you put it, but I think that it is not, and it exposes a weakness in your perspective here. In particular, Rust lets you be lax about types (Any) or other proved constraints (borrow checker bypass by unsafe, Arc, or cloning), but it forces you to decide how the unproven constraints are handled (ranging from undefined behavior to doing what you probably want with performance trade-offs). A langauge that simply lets you not prove it still must choose one of these approaches to run, but you will be less aware of what is chosen and unable to pick the right one for your use case. Writing something with, for example, Arc, .clone(), or Any is almost as easy as writing it in something like Python at the start (just arbitrarily pick one approach and go with it), but you get the aforementioned advantages and it scales better (the reader can instantly see (instead of dredging through the code to try to figure it out) "oh, this could be any type" or "oh, this is taken by ownership, so no spooky action at a distance is likely").
- throawayonthe 11mo ago
  is that not exactly "deciding how much to prove it?"
- MrJohz 11mo ago
  In practice, though, writing stuff with `Arc` or `.clone()` or `Any` is not as easy as it would be in Python because you've got to write a bunch of extra boilerplate. It's much easier to have local `i64` values that you can pass around as `Copy`. So if all you need are local i64s, then you'll take the easier option and do that. The same is true at multiple levels. `.clone()` is relatively easy to use, although once you learn the basic rules for referencing, that also becomes easier. `Arc` solves a specific problem you run into at a certain point sharing data between threads, but if you're not sharing data between threads (and most of the time you're not), it's just boilerplate and confusing, so you might avoid it and at worst use `Rc`. `Any` is rarely an obvious choice for most contexts, you really are going to only use it when you need it. The result is that for most simple cases, the precise and "proven" option is typically the easiest to go for. When you deal with more complicated things, the more complicated tools are available to you. That seems exactly what the previous poster described, where you can decide yourself how much you need to prove a given thing.
user3939382 11mo ago
I'll take a more definite position. Build pipelines are the devil. Every square inch of surface complexity you add to whatever you're doing, you will pay for it. If there's a way to get the benefits without the build step, that's your choice. You may need runtime type enforcement, so that's not JSDoc, and you're doing that with... JS so that's already suspicious but the use case def exists. JS, the DOM, HTTP, this whole stack is garbage at this point so arguing about the type system is a little idk hard to care about personally. I have a solution that lets you discard most of the web stack, that's more interesting to me.
jama211 11mo ago
And if your boss is the type to pivot way too often and want it done yesterday, then they don’t deserve code that is prove in the right places so you just get an LLM to add typing to everything after the fact…
- jve 11mo ago
  > then they don’t deserve code that is prove I don't get it. Types are a way to write code. Nothing to do with how fast/much the code changes.
  - scotty79 11mo ago
    Typed code is significantly more cumbersome to change (because there's more code to change). At least until you reach a certain size of your spaghetti bowl. Then both typed and untyped are cumbersome and people endlessly discuss which one is more.
    - skydhash 11mo ago
      I don’t think so. With a good editor, you change the type and run the compiler which will warn you with all the locations you’ll need to edit. Then you can quickly navigate to those locations.
      - scotty79 11mo ago
        Yeah, tooling for strongly typed languages is way better than 20 years ago. They are getting very being usable.
      - embedding-shape 11mo ago
        > which will warn you with all the locations you’ll need to edit This is true, but with a program built with a dynamic language, taking advantage of the fact that it's written in a dynamic language, doesn't need to make those changes at all. I'm fan of static typing in many situations, but it's hard to deny it doesn't lead to more changes as you need to properly propagate changes.
scotty79 11mo ago
> I like languages that let you decide how much you need to "prove it." I love that too. Are there any other languages than TS that have this as a core design feature?
- jve 11mo ago
  As I understand that is the core design feature of any strongly typed language.
  - matt_kantor 11mo ago
    I believe they're talking about gradual typing[0]. [0]: https://en.wikipedia.org/wiki/Gradual_typing https://en.wikipedia.org/wiki/Gradual_typing
  - scotty79 11mo ago
    Not really. Strongly typed languages don't usually support not having any types in your code (or any amount of gradual typing). At least not with any convenient syntax. There's usually some one clumsy "dynamic" type that doesn't interact with the rest of the system well and you'd be crazy to start writing your code using only this dynamic type. I can't just write C++ like: any a = 1; a = "Hi!"; I also can't tell JS this shouldn't be allowed. But I can tell this to TS, at any stage of evolution of my program.
    - fulafel 11mo ago
      Nitpick: In the "static, dynamic, strong, weak" quad, C/C++ are considered weakly but statically typed because you can nonchalantly bypass the type system. In this case you'd need to be pretty explicit about the bypassing but you could write int a = 1; strcpy((char *)&a, "hi"); (and it'll even kind of work in this instance since "hi" fits in an int, if on your C/C++ implemnentation int happens to be sized 3 bytes or more)
Culonavirus 11mo ago
> Your head is very volatile and hard for others to access. One of the lessons you learn while doing this job is that "others" includes "yourself in the future". (Of course people will tell you this way before you find out yourself, but what do they know...)
- have_faith 11mo ago
  "who wrote this garbage?... oh yeah that was me"
  - pavel_lishin 11mo ago
    Nothing puts you in your place like a `git blame`.
christophilus 11mo ago
Yeah. I learned this lesson 25 years ago in university. SQL, Lisp, and whatever scripting language I was learning at the time were always much harder to reason about vs statically typed languages— particularly in team projects. Over the years, I’ve gotten comfortable with SQL, but I always prefer static typing when I can get it.
dominicrose 11mo ago
> The types exist whether you write them down or not That's easy to say when we're talking about primitive arguments in private functions, or primitive local variables, but let's not ignore the fact that it takes much more work to write a C# program than a Ruby program for instance. We can see that by looking at a vanillajs library's typescript typings that were created after the js library when typescript didn't exist. The types are insanely complex and if you get one type wrong you can break compilation of some library user's program (its happened to me). That being said I'm aware that dynamic programming languages are a "use at your own risk" type of language.
- dzonga 11mo ago
  are dynamic languages really a "use at your own risk" ? or it's about changing frame of mind ? my take is if you treat your program as a series of data flows - then use primitives such as maps | arrays - then you don't need as much typing or typing at all. a map doesn't need to take a shape or a Person | Manager - either the keys exist or they don't and almost every language has guards to ensure you can safely navigate existence of keys. but then again my realm is mostly around - web | data systems - if I was dealing with OS level systems and needed to make sure i have i64 ints then yeah typing would be crucial.
  - dominicrose 11mo ago
    Well we take risks in either direction. The risk of using Java is becoming bored to death and having delays. The risk of PHP is that you know bugs are going to happen in production, even if you have something like Sentry to monitor them, even if they're not critical bugs.

culi 11mo ago

> JSDoc and TypeScript are standards/formats for typing. Like any tools, they both have advantages and disadvantages. Neither is objectively better than the other. Agreed. Just to clarify, my intentions with this post weren't to advocate for one over the other. Just to point out that they are the same thing. They are both TypeScript.

KPGv2 11mo ago
> They are both TypeScript. I take issue with this position because this seems to imply "PureScript and JavaScript are both JavaScript" is a true statement merely because one of them turns into the other with tooling.
- egeozcan 11mo ago
  I think the point here is that all the TS tooling works with JSDoc without any friction. As long as you don't look into the file, from the tooling perspective, a .ts file and a .js file with proper JSDoc annotations are practically the same.
  - aatd86 11mo ago
    Except the js files can work in the browser as is.. not the ts one (fortunately I might add, I find ts syntax very loaded at times) Either one is superseding the other one, or they are simply distant cousins, but this is not interchangeable. TS from JSDoc requires a generative pass to. This is a (expected) level of indirection. (unless some tooling does it automatically)
- nosianu 11mo ago
  TypeScript is indeed Javascript, all you have to do is remove the type annotations. They are not code. TS does have some minor things like enums that need to be transformed and are actual code, but those are very few, and leftovers from early days of TS, and the TS authors regret having implemented them. For many years now the TS philosophy has been that the CODE part of TS is 100% ECMAscript, and only annotations, which are not code, are added. The initial Babel transpiler for TS => JS, and still the most part of the current one, simply removes annotations. It is recommended not to use the few parts that are actual code and not standard JS. They are certainly not needed any more since ES6. People may get confused because the type syntax itself is almost like a programming language, with conditions and all. But none of that ends up as code, it's not used at runtime. One of the IMHO worst design decisions of TS was to bundle type checking and transpiling into one tool. That caused sooo many misunderstandings and confusion.
  - KPGv2 10mo ago
    > TypeScript is indeed Javascript No, no. JavaScript is TypeScript. TypeScript is not JavaScript. > type annotations are not code Of course they are. If they weren't code, then a malformed type would not trigger an error. You can actually solve the eight-queens problem with TS's type system alone. https://lemoine-benoit.medium.com/eight-queens-puzzle-in-typescripts-type-system-4c7ff1693545 https://lemoine-benoit.medium.com/eight-queens-puzzle-in-typ... The type system itself is Turing-complete!
mattmanser 11mo ago
I don't know how anyone can agree with this, because it pivots on this outrageous claim: "Like any tools, they both have advantages and disadvantages" You cannot make any argument based on such a position. Putting aside anyone's views on TS or JSDoc, tooling is of extremely variable quality, and lots of tools ARE objectively much worse than other tools. It we can't point at tools and say this one is better than that one, we might as well give up. I always remember a scene in Will & Grace where Will is trying to get his boss to say one thing is better than the other. He's brought a lovingly hand-crafted sandwich made with amazing, bread, fillings, etc. and a store bought sandwich made with cheap bread/fillings. He asks his boss to try both and say which one he likes more. His boss says something like the store bought one reminds him of his grandma's sandwiches, so invokes nostalgia, and still can't make a decision. Don't be that boss.
- rpsw 11mo ago
  I don't understand how this an outrageous claim. You might say a luxury sports car is objectively better than a cheap minivan, but that is no good to someone who needs to transport around a family. Or is you problem with the word any instead of many?

john01dav 11mo ago

> - I like languages that let you decide how much you need to "prove it." Rust is known for being very "prove it," as you put it, but I think that it is not, and it exposes a weakness in your perspective here. In particular, Rust lets you be lax about types (Any) or other proved constraints (borrow checker bypass by unsafe, Arc, or cloning), but it forces you to decide how the unproven constraints are handled (ranging from undefined behavior to doing what you probably want with performance trade-offs). A langauge that simply lets you not prove it still must choose one of these approaches to run, but you will be less aware of what is chosen and unable to pick the right one for your use case. Writing something with, for example, Arc, .clone(), or Any is almost as easy as writing it in something like Python at the start (just arbitrarily pick one approach and go with it), but you get the aforementioned advantages and it scales better (the reader can instantly see (instead of dredging through the code to try to figure it out) "oh, this could be any type" or "oh, this is taken by ownership, so no spooky action at a distance is likely").

throawayonthe 11mo ago
is that not exactly "deciding how much to prove it?"
MrJohz 11mo ago
In practice, though, writing stuff with `Arc` or `.clone()` or `Any` is not as easy as it would be in Python because you've got to write a bunch of extra boilerplate. It's much easier to have local `i64` values that you can pass around as `Copy`. So if all you need are local i64s, then you'll take the easier option and do that. The same is true at multiple levels. `.clone()` is relatively easy to use, although once you learn the basic rules for referencing, that also becomes easier. `Arc` solves a specific problem you run into at a certain point sharing data between threads, but if you're not sharing data between threads (and most of the time you're not), it's just boilerplate and confusing, so you might avoid it and at worst use `Rc`. `Any` is rarely an obvious choice for most contexts, you really are going to only use it when you need it. The result is that for most simple cases, the precise and "proven" option is typically the easiest to go for. When you deal with more complicated things, the more complicated tools are available to you. That seems exactly what the previous poster described, where you can decide yourself how much you need to prove a given thing.

user3939382 11mo ago

I'll take a more definite position. Build pipelines are the devil. Every square inch of surface complexity you add to whatever you're doing, you will pay for it. If there's a way to get the benefits without the build step, that's your choice. You may need runtime type enforcement, so that's not JSDoc, and you're doing that with... JS so that's already suspicious but the use case def exists. JS, the DOM, HTTP, this whole stack is garbage at this point so arguing about the type system is a little idk hard to care about personally. I have a solution that lets you discard most of the web stack, that's more interesting to me.

jama211 11mo ago

And if your boss is the type to pivot way too often and want it done yesterday, then they don’t deserve code that is prove in the right places so you just get an LLM to add typing to everything after the fact…

jve 11mo ago
> then they don’t deserve code that is prove I don't get it. Types are a way to write code. Nothing to do with how fast/much the code changes.
- scotty79 11mo ago
  Typed code is significantly more cumbersome to change (because there's more code to change). At least until you reach a certain size of your spaghetti bowl. Then both typed and untyped are cumbersome and people endlessly discuss which one is more.
  - skydhash 11mo ago
    I don’t think so. With a good editor, you change the type and run the compiler which will warn you with all the locations you’ll need to edit. Then you can quickly navigate to those locations.
    - scotty79 11mo ago
      Yeah, tooling for strongly typed languages is way better than 20 years ago. They are getting very being usable.
    - embedding-shape 11mo ago
      > which will warn you with all the locations you’ll need to edit This is true, but with a program built with a dynamic language, taking advantage of the fact that it's written in a dynamic language, doesn't need to make those changes at all. I'm fan of static typing in many situations, but it's hard to deny it doesn't lead to more changes as you need to properly propagate changes.

scotty79 11mo ago

> I like languages that let you decide how much you need to "prove it." I love that too. Are there any other languages than TS that have this as a core design feature?

jve 11mo ago
As I understand that is the core design feature of any strongly typed language.
- matt_kantor 11mo ago
  I believe they're talking about gradual typing[0]. [0]: https://en.wikipedia.org/wiki/Gradual_typing https://en.wikipedia.org/wiki/Gradual_typing
- scotty79 11mo ago
  Not really. Strongly typed languages don't usually support not having any types in your code (or any amount of gradual typing). At least not with any convenient syntax. There's usually some one clumsy "dynamic" type that doesn't interact with the rest of the system well and you'd be crazy to start writing your code using only this dynamic type. I can't just write C++ like: any a = 1; a = "Hi!"; I also can't tell JS this shouldn't be allowed. But I can tell this to TS, at any stage of evolution of my program.
  - fulafel 11mo ago
    Nitpick: In the "static, dynamic, strong, weak" quad, C/C++ are considered weakly but statically typed because you can nonchalantly bypass the type system. In this case you'd need to be pretty explicit about the bypassing but you could write int a = 1; strcpy((char *)&a, "hi"); (and it'll even kind of work in this instance since "hi" fits in an int, if on your C/C++ implemnentation int happens to be sized 3 bytes or more)

Culonavirus 11mo ago

> Your head is very volatile and hard for others to access. One of the lessons you learn while doing this job is that "others" includes "yourself in the future". (Of course people will tell you this way before you find out yourself, but what do they know...)

have_faith 11mo ago
"who wrote this garbage?... oh yeah that was me"
- pavel_lishin 11mo ago
  Nothing puts you in your place like a `git blame`.

christophilus 11mo ago

Yeah. I learned this lesson 25 years ago in university. SQL, Lisp, and whatever scripting language I was learning at the time were always much harder to reason about vs statically typed languages— particularly in team projects. Over the years, I’ve gotten comfortable with SQL, but I always prefer static typing when I can get it.

dominicrose 11mo ago

> The types exist whether you write them down or not That's easy to say when we're talking about primitive arguments in private functions, or primitive local variables, but let's not ignore the fact that it takes much more work to write a C# program than a Ruby program for instance. We can see that by looking at a vanillajs library's typescript typings that were created after the js library when typescript didn't exist. The types are insanely complex and if you get one type wrong you can break compilation of some library user's program (its happened to me). That being said I'm aware that dynamic programming languages are a "use at your own risk" type of language.

dzonga 11mo ago
are dynamic languages really a "use at your own risk" ? or it's about changing frame of mind ? my take is if you treat your program as a series of data flows - then use primitives such as maps | arrays - then you don't need as much typing or typing at all. a map doesn't need to take a shape or a Person | Manager - either the keys exist or they don't and almost every language has guards to ensure you can safely navigate existence of keys. but then again my realm is mostly around - web | data systems - if I was dealing with OS level systems and needed to make sure i have i64 ints then yeah typing would be crucial.
- dominicrose 11mo ago
  Well we take risks in either direction. The risk of using Java is becoming bored to death and having delays. The risk of PHP is that you know bugs are going to happen in production, even if you have something like Sentry to monitor them, even if they're not critical bugs.