Hacker News Reader

Comment by krapp | Hacker News Reader

> There's even the future possibility of much of its type syntax being absorbed back into JavaScript: https://github.com/tc39/proposal-type-annotations

... as comments. Which superficially resemble the syntax of type hints but do nothing. Which has to be one of the worst language design decisions of all time.

View on HN

I'd disagree that its a poor decision, some help is better than no help when reading code - and if it's inline then it's intrinsically meaningful.

By no means is it perfect, the language doesn't enforce the type rules, but that the developer has the option is far better than not. As far as I can tell the proposal would pretty similar to Python; one can misleadingly or accidentally misuse type hints like the following:

  def myfn(a: int) -> str:
    return int(a)
  
  print(myfn("42"))

But when done right, it gives you a leg up when you come back to read your own code or scan over someone else's. When you're reading over other's code in group programming assignments, comments make a world of difference (a niche example).

It is a choice, but its use in code might just inspire someone to investigate further - my own introduction to types in programming came when I wondered what these oddly placed colons and arrows were in some Python I came across. If they do add these annotations to JavaScript, some future programmer browsing the source of a web page may well just stumble upon types and have a whole new world of theory opened up to them - I'm all for it.

That's fine for atomic types like string or int, but typescript goes a lot deeper than that with powerful generics. For example, I'm working on a library of functional data wrappers. This would be useless without Typescript and impossible to type without generics.

There's also no way to share and reuse types in comments. Do you copy paste comments to "type" things? What about complex objects? What happens if the comments get out of sync? How do you test them?

I used to be a typescript skeptic too, but much of that skepticism tends to come from drastically underestimating the power of the TS type system.

I just want to note that it seems incorrect to call this a superficial resemblance in terms of syntax. I went and read through the whole thing, and the syntax for the type hints seems to be as close to 100% TypeScript as possible, which is to say, it is very close. There may be some features missing that TS supports, but the bulk of it is there, and what's there is basically Typescript, which is the best thing that could possibly be accomplished here.

Typescript has been doing a fantastic job, and this proposal is continuing in that same vein, truly absorbing as much of that as possible back into JS!

Kudos to everyone involved, great effort!

And re "[the type hints] do nothing": The section at the end of the proposal clearly explains why that must necessarily be the case: Evolutions of JS must not break the web (especially) for the users.

Quoting: "TypeScript's model -- which has been highly successful for JS developers -- is around non-local, best-effort checks. (...) Additionally, defining a type system to run directly in the browser means that improved type analyses would become breaking changes for the users of JavaScript applications, rather than for developers. This would violate goals around web compatibility (i.e. "don't break the web"), so type system innovation would become near-impossible. Allowing other type systems to analyze code separately provides developers with choice, innovation, and freedom for developers to opt-out of checking at any time."

So this proposal provides the best possible path forward for JS, based on what folks are voting for with their feet by using TS: Making JS compatible with TS-style type hints that can be used by external tools (i.e. not the JS engines executing the code at runtime) to validate the code in a best-effort manner while the developer is looking at it, while not changing JS runtime semantics and thus never breaking the code while the user is running it.

I don't see the problem with this design decision.

I'm not the biggest fan of static type checking (especially in a language like Javascript, where it isn't used for safety guarantees), but it has its uses.

The "as comments" part of it isn't about syntax. They really mean no runtime overhead/behavior. (I don't think they should have put it that way -- it's just going to cause confusion.)

Is there really any question that "no runtime overhead" needs to be an option? (I think any proposal that didn't include this would be DOA.)

It also seems clear to me it needs to be the default option, for multiple reasons (language changes should be backwards compatible as much as possible, it should be easy to adopt new language features incrementally, type usage is an application-level concern.

Note: there's nothing in this proposal that prevents run-time enforcement. Good design limits scope but keeps your options open.

...as optional hints that don't require you to buy into a whole new toolchain.

I would prefer if they actually had a purpose in the language in which they were used (JS.) Add optional type hinting to JS itself, if it's that important, don't add pretend type hinting to it because typescript users don't want to have to use their compilers anymore.

I know a lot of people like it but it just seems like an ugly hack to me, extra syntax for the sake of an abritrary third party tool. I know I'm a dinosaur. I want to go back to the days of JQuery modules and FTP. Feh.

Reply on news.ycombinator.com