4 ms·

Most people do not care about types, they care about smart intellisense and detecting errors such as a misspelled property.

by z3t4 8y ago

austincheney 8y ago
I disagree. Perhaps I am in the minority on this, I don't know. I care about types and don't care about intellisence. I write lots of atomic algorithms that are super-independent, independent of each other but also compensating for the changes by each other, and make heavy use of scope. It is very important to my code that things execute efficiently and accurately.
- z3t4 8y ago
  I do not understand what you mean. But it sounds like you are into functional programming !? Which works fine without type annotations. For example: const sum = (number, number) => number+number Where type annotations becomes unnecessary verbose.
  - austincheney 8y ago
    True. Consider this example: props.removes[cc] !== props.last.margin TypeScript's strict types will see the error if the those are not the same data type. A TypeScript aware editor will yell at me before I compile the code. Perhaps what I really wanted is: props.removes[cc][0] !== props.last.margin In JavaScript I would have to execute the code. If the code doesn't throw an error then I would have to examine the output to see if the resulting data structure matches what I expect. If not I have to run tests and track down the error. Then once the error is found and resolved I have to write unit tests for this scenario.
    - z3t4 8y ago
      You can use an auto-generated intermediate format when running the tests, that check each member object, give test coverage, etc. Eg. a tool that parses the code and inserts a bunch of checks above each member access. So you start with plain JavaScript, and you ship plain JavaScript.
ethelward 8y ago
And a smart intellisense and efficient detection of misspelled properties are themselves strongly dependent on a decent types system.
- z3t4 8y ago
  JavaScript will always convert a value to a type. It's dynamic, but very strongly typed. JavaScript engines do not care about type annotations, only TypeScript does. You might have annotated something as a number, but the JavaScript engine might chose to convert it to a string ... I think type annotations is a unnecessary chore, and that types should be inferred.
  - ethelward 8y ago
    Types cannot be inferred in dynamic typing systems. That is the whole point of dynamic type systems: type might change during runtime.
Vanit 8y ago
So types then?
sebazzz 8y ago
Types are documentation, very useful in large dynamically- typed code bases.
- z3t4 8y ago
  Type annotations does not replace proper documentation. And with properly named parameters the annotations are not needed. It's also a convention among JavaScript programmers that each function should not only check the parameters, but also convert them, so you can leave out optional arguments, pass a notated object {foo: "bar"}, or pass a string and have the function convert it to an array so you can write foo(bar) instead of foo([bar]) when calling the function. Or convert an object if it's not of the correct instance. This is more fun then annotating types and having a compiler shout out weird errors at you.
abdulkareemsn 8y ago
Actually types enable suggestion (in visual studio parlance intellisense )
- z3t4 8y ago
  TypeScript is already good at inferring the types, so you can get suggestions on unannotated code, but I think TypeScript should get even better at inferring by getting closer to what a JS engine do and closer to the JS spec (eg. get rid of the type annotations)
WorldMaker 8y ago
I'm not sure I agree with the quantity "most", but clearly the Typescript team also cares about the people that don't need/want types, but do care about smart intellisense and detecting basic errors. A large part of this roadmap directly deals with that directly, because Typescript is powering more and more JS experiences in editors. The most direct section on this in the roadmap is the one titled: "JavaScript: TypeScript beyond TypeScript". But also a good majority of the "Developer productivity tools and integration" directly or indirectly involves both JS without types and TS with types. If you use Atom or VSCode or any of the other growing number of editors that use Typescript to power their JavaScript/ECMAScript experiences, this Roadmap should help reassure you that the team still has you in mind and wants you to be happy. (One of the interesting parts here is the reveal that Typescript is moving to use ESLint everywhere instead of TSLint. It's an interesting investment into the lint experience across the board for both JS and TS.)

Most people do not care about types, they care about smart intellisense and detecting errors such as a misspelled property.

by z3t4 8y ago

Most people do not care about types, they care about smart intellisense and detecting errors such as a misspelled property.

austincheney 8y ago

I disagree. Perhaps I am in the minority on this, I don't know. I care about types and don't care about intellisence. I write lots of atomic algorithms that are super-independent, independent of each other but also compensating for the changes by each other, and make heavy use of scope. It is very important to my code that things execute efficiently and accurately.

z3t4 8y ago
I do not understand what you mean. But it sounds like you are into functional programming !? Which works fine without type annotations. For example: const sum = (number, number) => number+number Where type annotations becomes unnecessary verbose.
- austincheney 8y ago
  True. Consider this example: props.removes[cc] !== props.last.margin TypeScript's strict types will see the error if the those are not the same data type. A TypeScript aware editor will yell at me before I compile the code. Perhaps what I really wanted is: props.removes[cc][0] !== props.last.margin In JavaScript I would have to execute the code. If the code doesn't throw an error then I would have to examine the output to see if the resulting data structure matches what I expect. If not I have to run tests and track down the error. Then once the error is found and resolved I have to write unit tests for this scenario.
  - z3t4 8y ago
    You can use an auto-generated intermediate format when running the tests, that check each member object, give test coverage, etc. Eg. a tool that parses the code and inserts a bunch of checks above each member access. So you start with plain JavaScript, and you ship plain JavaScript.

ethelward 8y ago

And a smart intellisense and efficient detection of misspelled properties are themselves strongly dependent on a decent types system.

z3t4 8y ago
JavaScript will always convert a value to a type. It's dynamic, but very strongly typed. JavaScript engines do not care about type annotations, only TypeScript does. You might have annotated something as a number, but the JavaScript engine might chose to convert it to a string ... I think type annotations is a unnecessary chore, and that types should be inferred.
- ethelward 8y ago
  Types cannot be inferred in dynamic typing systems. That is the whole point of dynamic type systems: type might change during runtime.

Vanit 8y ago

So types then?

sebazzz 8y ago

Types are documentation, very useful in large dynamically- typed code bases.

z3t4 8y ago
Type annotations does not replace proper documentation. And with properly named parameters the annotations are not needed. It's also a convention among JavaScript programmers that each function should not only check the parameters, but also convert them, so you can leave out optional arguments, pass a notated object {foo: "bar"}, or pass a string and have the function convert it to an array so you can write foo(bar) instead of foo([bar]) when calling the function. Or convert an object if it's not of the correct instance. This is more fun then annotating types and having a compiler shout out weird errors at you.

abdulkareemsn 8y ago

Actually types enable suggestion (in visual studio parlance intellisense )

z3t4 8y ago
TypeScript is already good at inferring the types, so you can get suggestions on unannotated code, but I think TypeScript should get even better at inferring by getting closer to what a JS engine do and closer to the JS spec (eg. get rid of the type annotations)

WorldMaker 8y ago

I'm not sure I agree with the quantity "most", but clearly the Typescript team also cares about the people that don't need/want types, but do care about smart intellisense and detecting basic errors. A large part of this roadmap directly deals with that directly, because Typescript is powering more and more JS experiences in editors. The most direct section on this in the roadmap is the one titled: "JavaScript: TypeScript beyond TypeScript". But also a good majority of the "Developer productivity tools and integration" directly or indirectly involves both JS without types and TS with types. If you use Atom or VSCode or any of the other growing number of editors that use Typescript to power their JavaScript/ECMAScript experiences, this Roadmap should help reassure you that the team still has you in mind and wants you to be happy. (One of the interesting parts here is the reveal that Typescript is moving to use ESLint everywhere instead of TSLint. It's an interesting investment into the lint experience across the board for both JS and TS.)