Hacker News Reader

Comment by acemarke | Hacker News Reader

I'll agree, and disagree.

I made a similar comment in 2019 about "TS pushes you towards simpler APIs" [0], so I agree that it's both a good thing in principle, and something TS usage leans towards in practice.

At the same time... JS _is_ a very dynamic language, library design reflects that, and library code by its very nature must account for the different ways that users will want to call it. That causes library types to be much more complex than app types.

[0] https://blog.isquaredsoftware.com/2019/11/blogged-answers-le...

View on HN

Python is also very dynamic, yet libraries rarely allow arguments to be number/string/list/dict/function at the same time.

Yet in JavaScript I see this all the time - pass a string URL, but we also accept a function which will return a string URL, or maybe an option object - { url: string, strict: boolean }

So I think it's more of a culture thing.

Luckily these types are not complex at all to type in Typescript. You just enumerate all the options with a | character separating them.

Right, but people compose. They take this union and put it in another object, which also allows multiple types for some field, and then they take that object and put it in another one, and then you have a 10 line type declaration for 3 fields.

Which is why you can have aliases for those types, each level of abstraction can be nicely wrapped up. It just describes the reality.

I’m mostly sitting this out, but I’ll interject here because this is wrong. Union types are often used as an XOR (a | b as “either a or b, but not both”), but they’re an inclusive OR (Partial<a> & Partial<b>, as “some parts of a or b, the parts they share guaranteed”) which is almost never what anyone wants when dealing with objects. The pain is that you can’t distinguish them without a narrowing factor, and if you can’t the types are horridly complex.

I mean, that makes sense. If types `A` and `B` both have a function `doStuff`, is it bad to be able to do `x.doStuff()` without narrowing?

For example: every object’s prototype chain ends with `Object.prototype`, so all objects have a `toString` function. I shouldn’t be forced to narrow my `number|bigint|string` (for example) just to do `x.toString()`. If I was, we’d get this ugly and bloated mess:

    function callToString(x: number | bigint | string)
    {
        if (typeof x === "number")
            x.toString();
        else if (typeof x === "bigint")
            x.toString();
        else
            x.toString();
    }

Regardless, they’re just copying JavaScript’s duck typing feature. It’s not much different than languages like Java and C# that have interfaces. In C#, if my parameter is IClonable, I don’t care what it is, but know there’s a `Clone()` method attached to it.

Python libraries kind of used to do this more, but seem to be doing it less now, in part because highly-polymorphic interfaces are a huge ugly pain in the butt with the Python type hinting system.

What's so painful about writing

   foo: int | str

It gets a lot more complicated than that. One of many, many examples: https://github.com/pandas-dev/pandas-stubs/blob/v1.4.3.22082...

In general, if someone with experience in a domain is complaining that something is hard, it's safe to assume that the thing is actually at least kind of hard, and that they aren't just a crybaby about indentation and formatting.

I don't see what's complicated about this example. It adds overloads, but those aren't hard, either.

Fair, it's not "hard". But I stand by my assertion that it's a huge ugly pain in the butt. That doesn't mean it's not worth doing, but that doesn't make it less huge, ugly, or painful.

I also assert that if NDFrame.loc were less polymorphic (e.g. if you had a separate accessor like NDFrame.mask for boolean subsetting) it would be easier to use, easier to reason about, easier to teach, easier to document, and easier to write type hints for.

The worst situation is when you want to have multiple return types depending on the argument values, like Pandas' inplace=True. Putting aside the problem of dependent types, even supporting only literal True and False requires you to write out every single overload twice, creating a literal combinatorial explosion of overloads.

And that's also ignoring the whole world of parametric polymorphism required for higher-order functions, factory functions etc.

Maybe the situation is no better in something like C++, but I don't know enough C++ to have an opinion on it.

To be fair, there are few things as here-be-dragons as the guts of Pandas. It'd be hard to find a more rarified example, but it served to further the conversation at least.

> Python libraries kind of used to do this more, but seem to be doing it less now…

I’d argue that it has to do with C extensions making it a lot of work to get it right.

Some library code does it (which is where I learned how to do it ‘correctly’) but in general, run of the mill code it is pretty rare. Just something like an overloaded __add__ turns into a page and a half of code and there’s a lot of functions in the numbers protocol struct.

Labor of love really.

"JS _is_ a very dynamic language, library design reflects that"

I would argue it should not. If your API cannot be well expressed in the Typescript type system, it is your API that should change.

Yup.

Especially since types are documentation. If you are using some meta dynamic type garbage, then I as a user of the API am left to wonder "Ok, this takes <U, K extends keyof U>... WTF is it expecting?"

This isn't to say that sort of thing is ALWAYS wrong, but rather it should be the exception and not the rule.

You do types because constraints make code clearer. By having a BF compiler in the middle of your template definition, you've defeated the types and you might as well put an `any` there with docs that say "here there be dragons!"

This is all well and good until you have to deal with other code and other APIs in your library (results from network requests, localstorage, untyped javascript libraries, etc.)

I'd rather not warp my whole project around a typing system if I don't need to. I also might not be the owner of every API I need to consume...

I think TS is great in certain cases- I love being able to get intellisense info from TS. When I download a new library and I get those helpful hints built right in from the libraries TS adoption, I love it. Typescript in this instance is reducing friction in my development workflow.

In my day job I work at an agency where we rapidly deliver a lot of new web properties. I have used Typescript on projects when it was a client requirement, but in our environment using Typescript generally feels like it overall adds friction and time to the project. Some team member inevitably gets stuck spending a bunch of extra time working with TS stuff: setting up the project with proper rules, writing some complex interface to deal with some random API we are either consuming or creating ourselves (in which case it is usually under rapid prototype development and needs to be updated constantly), etc.

I'm sure it is very helpful when working at scale with tons of developers on a highly stable and established project, but in my opinion it isn't generally applicable to every web property that it would be better on Typescript; it really depends on the scale of the project and the scale of the team maintaining it.

> I'd rather not warp my whole project around a typing system if I don't need to.

This sounds to me like MongoDB advocates like "psh! who needs a schema! don't slow me down, I'll just dump JSON into the database however I like." The types exist whether you write them down or not.

I agree with you that TS might not be great for everyone and every use case. But maybe you should just use `any` some more!

Every field in a MongoDB document (we encoded documents in BSON at the driver level) is typed and you can apply a schema to any collection if you choose to do so.

I think allowing people to call functions in a vast variety of ways is a mistake. It's one of the things that frustrates me the most about the javascript ecosystem, it's hard to figure out the call signature for any given function because there's like 15 different ways to call it. I'd argue it's better to just have one well documented way. It's not even like there aren't patterns for it, ie passing an "options" object or something like that (although even then I think that can be an antipattern unless there truly needs to be a variety of options -- ie a db connection or something. Better just to have multiple functions with specific purposes instead of one mega function that does everything)

Agree, 100%. Make your function definition `foo(foo: Foo)` not `foo<T extends comparable | int | Bar>(foo: T)` Flexibility is the enemy of a type system and library design in general.

I don't think allowing users to call libraries in all manner of crazy ways is a good thing at all, and I don't think anyone would really be that put out by following a more pythonic approach of just allowing one way to do something.

Yeah but you're writing libraries in Javascript, that ship has sailed already. You're gonna just need a bit fat switch statement to check your input types on every public function you ever write.

It's never too late to stop making bad designs. I've written plenty of (internal) libraries and if someone asked me to put in a big fat switch statement I'd ask them why they need it.

We’re talking about typescript here

> JS _is_ a very dynamic language, library design reflects that

This is mostly an issue if you're tacking on those types on top of your existing design, rather than starting your design from your types, no?

Case in point, over the weekend I tried creating an npm package for a custom hook. Since it's public-facing, I wanted to use TS so I could expose types for users.

Part of this hook is that users can pass in custom data. I tried to create a type that was basically "an object of any string key, with the type value". Gave up after like an hour of banging my head against my desk. Maybe I'm new to TS, but FFS it should not be that hard to do.

Fortunately that's not too difficult:

  let x: {[key: string]: Type}

But maybe the documentation is lacking here?

For the record, this is equivalent to:

  let x: Record<string, Type>

Pun intended.

Yikes! Why bend over so much for clients of the library?

Because the whole point of a library is to be useful to its clients.

Reply on news.ycombinator.com