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."

▲ Culonavirus a day ago | parent | next [-]

> 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 a day ago | parent [-]

"who wrote this garbage?... oh yeah that was me"

	▲	pavel_lishin 21 hours ago \| parent [-]
		Nothing puts you in your place like a `git blame`.

▲ john01dav a day ago | parent | prev | next [-]

> - 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").

	▲	MrJohz a day ago \| parent \| next [-]
		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.
	▲	throawayonthe a day ago \| parent \| prev [-]
		is that not exactly "deciding how much to prove it?"

▲ culi 2 days ago | parent | prev | next [-]

> 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.

▲

mattmanser a day ago | parent | next [-]

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 a day ago \| parent [-]
		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?

▲

KPGv2 a day ago | parent | prev [-]

> 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.

▲

nosianu a day ago | parent | next [-]

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.

▲

egeozcan a day ago | parent | prev [-]

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 a day ago \| parent [-]
		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)

▲ christophilus a day ago | parent | prev | next [-]

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.

▲ jama211 a day ago | parent | prev | next [-]

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 a day ago | parent [-]

> 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 a day ago | parent [-]

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 a day ago | parent [-]

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.

▲ embedding-shape a day ago | parent | next [-]

> 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.

▲ ARandumGuy 21 hours ago | parent [-]

I don't find that dynamic typing reduces the number of places I need to update stuff. It just changes when the error occurs.

If I change the shape of some data (such as renaming object properties), I'll need to update all the code that used that data, regardless of the type system. Static typing just ensures that I catch those cases at compile time, not runtime.

▲ embedding-shape 20 hours ago | parent [-]

Just one simple and contrived example I could come up with the five minutes I had available:

JavaScript:

  // rename host -> hostname, update ONE place
  function connect(opts) {
    const host = opts.hostname ?? opts.host; // compat shim
    return `tcp://${host}:${opts.port}`;
  }

  // old call sites keep working
  connect({ host: "db", port: 5432 });
  connect({ host: "cache", port: 6379 });

  // new call sites also work
  connect({ hostname: "db", port: 5432 });

TypeScript:

  // same compat goal, but types force propagation unless you widen them

  type Opts = { port: number } & ({ host: string } | { hostname: string });

  function connect(opts: Opts) {
    const host = "hostname" in opts ? opts.hostname : opts.host;
    return `tcp://${host}:${opts.port}`;
  }

  // If instead you "just rename" the type to {hostname; port},
  // EVERY call site using {host; port} becomes a compile error.

Again, this is just a simple example. But multiply 100x + way messier codebases where everything are static types and intrinsically linked with each other, and every change becomes "change -> compile and see next spot to change -> change" until you've worked through 10s of files, instead of just changing it in one place.

Personally, I prefer to spend the extra time I get from dynamic languages to write proper unit tests that can actually ensure the absence of specific logic bugs, rather than further ossifying the architecture with static types while changes are still ongoing.

▲ ARandumGuy 20 hours ago | parent [-]

In your Typescript example, the solution would be to use your IDE to refactor hosts to hostnames, a process that takes like 2 seconds. You might have problems if the change exists at a service boundry, but in that case I'd just put the transformation at the service boundry, and keep everything the same internally.

> Personally, I prefer to spend the extra time I get from dynamic languages to write proper unit tests that can actually ensure the absence of specific logic bugs, rather than further ossifying the architecture with static types while changes are still ongoing.

I'd argue static typing makes this much easier, because I know any input types (or output types from other components) will be enforced by the type system. So I don't need to bother writing tests for "what if this parameter isn't set" or "what if this function returns something unexpected". The type system handles all of that, which eliminated a lot of tedious boilerplate tests.

▲ embedding-shape 19 hours ago | parent [-]

> In your Typescript example, the solution would be to use your IDE to refactor hosts to hostnames

Yeah, sure, and with LLMs you can do this, and you can do that. But if we're talking about languages and their features, relying on IDE features feels slightly off-topic.

But regardless, changes is changes, no matter if you, your IDE or your LLM made them. So even if your IDE makes the changes, it seems at least you can now agree that there are more changes needed, it's just that with TypeScript you have a editor who can help you refactor, and with JavaScript you haven't yet found an editor that can do so.

> So I don't need to bother writing tests for "what if this parameter isn't set" or "what if this function returns something unexpected".

Yeah, those unit tests does nothing, and people who write in dynamic languages don't write tests like that either. You test actual logic, in unit tests, and you rely on the signals that gives you.

In fact, I could bet you that if you and me both sat down and wrote the exact same application, one in JS and one in TS, we'd end up with more or less the same amount of unit tests, yet the JS codebase will be a lot more flexible once product requirements start to change.

But again, YMMV and all that, it's a highly personal preference. I don't think there is a ground truth here, different minds seem to prefer different things. I mostly work in environments where the requirements can change from day to day, and being able to adopt to those without introducing new issues is the most important thing for me, so with JS I stay.

▲ ARandumGuy 19 hours ago | parent [-]

> Yeah, sure, and with LLMs you can do this, and you can do that. But if we're talking about languages and their features, relying on IDE features feels slightly off-topic.

Refacoring tools (such as renaming properties) have been supported by IDEs for decades. And in Typescript specifically, the language is designed with these tools in mind, which are developed and distributed directly by the Typescript team. For all intents and purposes, IDE integration using the Typescript language server is a feature of Typescript.

And if somehow these tools don't work, the compiler will catch it immediately! This means I can refactor with confidence, knowing any type issues will be caught automatically.

It seems like you're vastly overestimating the time and effort it takes to change types in Typescript. In my experience it's something that takes basically no time and effort, and has never caused me any issues or headaches.

▲ embedding-shape 14 hours ago | parent [-]

You're changing the point though, you claimed "I don't find that dynamic typing reduces the number of places I need to update stuff", which just because your editor makes the change, doesn't suddenly make the change not show up in the diff for you and others. A change is a change, regardless of how it's made, unless you don't keep your code in a SCM that is, which I'm assuming most of us do.

I'm not saying it's hard to change types in TypeScript, I understand that your IDE is connected with the language and they're used together, but again my argument was that having types leads to having to change things in more places. Which is true too, and it's a good thing, it's on purpose, and the tools you use help with that, so yay for that! But it's still more changes, and at least for me it's important to be honest about the tradeoffs our choices leads us to.

As I mentioned earlier, I'm fan of static typing in many situations, just not all of them. And I'm not blind to the negatives they can bring too, I guess I just see more nuance in the static typing vs dynamic debate.

▲ skydhash 14 hours ago | parent [-]

Regardless of how dynamic typing is, the contract being enforced stays the same. It's just less enforced by tools. So with dynamic typing, you will have to change the same amount of code if you want your code to stay correct. The only variation in code changes comes from the annotation for the type system.

▲ scotty79 12 hours ago | parent [-]

> So with dynamic typing, you will have to change the same amount of code if you want your code to stay correct.

No, because if a piece of data is pushed through multiple layers you can just change its type at the source and the destination and not in all the layers the data is pushed through. And you can still be correct.

Imagine you have a thing called target which is a description of some endpoint. You can start with just a string, but at one point decide that instead of string you'd prefer object of a class. In dynamic language you just change the place where it originates and the place where it's used. You don't need to change any spot in 3 layers that just forearded target because they were never forced assumed it's a string.

You can achieve that in staticly typed language if you never use primitive types in your parametrs and return types or if you heavily use generics on everything, but it's not how most people write code.

Tools can help you with the changes, but such refactors aren't usually available in free tools. At least they weren't before LLMs. So the best they could do for most people was to take them on a journey through 3 layers to have them make manual change from string to Target at every spot.

	▲	skydhash 11 hours ago \| parent [-]
		In some type systems, you don't need to change it either. Errors will happens only if you've written code that assumes that `target` is a string. If I write a function with the following signature: `fn split(str: string) => string[]` And you called it with const first_el = split(target)[0] If you decide `target` to suddenly be an object, then the code you wrote is incorrect, because semantically, `split` only makes sense when the argument is a string. Which is why, even with dynamic typing, you'll see that the documentation of a function will state what kind of parameters it expects. If you a call chain like `fn1 \| fn2 \| fn3 \| fn4 \| split`, Then yeah you need to ensure what reaches `split` is in fact a string. If you're against updating fn[1-4]'s signature, let's say that it's harder to find which function needs to change in a dynamic typing systems. Dynamic typing is useful for small programs and scripts because they are easy to iterate upon. But for longer programs, I'll take static typing anytime.

▲ scotty79 a day ago | parent | prev [-]

Yeah, tooling for strongly typed languages is way better than 20 years ago. They are getting very being usable.

▲ dominicrose 21 hours ago | parent | prev | next [-]

> 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 18 hours ago \| parent [-]
		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.

▲ scotty79 a day ago | parent | prev | next [-]

> 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 a day ago | parent [-]

As I understand that is the core design feature of any strongly typed language.

▲ matt_kantor 20 hours ago | parent | next [-]

I believe they're talking about gradual typing[0].

[0]: https://en.wikipedia.org/wiki/Gradual_typing

▲ scotty79 14 hours ago | parent | prev [-]

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 7 hours ago \| parent [-]
		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)

▲ user3939382 a day ago | parent | prev [-]

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.