5 ms·

> it will happily allow you to say that a method always returns a string when sometimes it returns a number Just replace "say" with "assume" and you have the j

by Udik 7y ago

> it will happily allow you to say that a method always returns a string when sometimes it returns a number Just replace "say" with "assume" and you have the javascript situation: javascript is just typescript with documentation stripped off. > Typescript is just documentation that compiles. Exactly. And we're arguing whether code should contain documentation or not.

danShumway 7y ago
This is kind of a subtle idea, but in some instances, the illusion of safety can be harmful. It is occasionally (not always) better not to give people the illusion of safety when that safety doesn't actually exist. Sometimes putting an ineffective railing along a mountain path increases accidents, because it's human nature for people walking on that path to watch their footing less when they see the railing. >> Do not use random libraries. A good library should have even some basic docs outline its API and how to use it. > A whole lot of the time, especially in Javascript land you will join projects where libraries are being used, and where documentation is lacking. Your advice here is basically to not be part of those projects? Instead of developing and using tooling that will ensure that these situations no longer happen? I'm not here to hate on Typescript, I think it has its uses. I use Typescript in some places. I generally avoid it for personal projects, but I would probably encourage it for larger orgs. But the idea that Typescript protects you from needing to care about interfaces is exactly the problem with over-reliance on Typescript, and is the source of a lot of really badly written code that treats interface design like an afterthought. If you're using Typescript for documentation and you're treating it like a tool, you can write some really elegant code, you can catch some shallow bugs around types and assumptions, you can integrate your documentation into your IDE. If you're looking at Typescript and saying, "this is an efficient way for me to document what my code does", then this is all very good. But if you're using Typescript and saying, "now I can pull in any dependency I want", then Typescript is doing you more harm than good. The specific advice orange gives in those two sentences is good advice. If Typescript is giving you a false sense of confidence about using random libraries, then that's a real negative. I use both pure JS and Typescript almost daily, and I consume plenty of dependencies written in Typescript. I still occasionally need to debug the stack traces in those dependencies. I still occasionally need to read through their source code to figure out what they're doing. Badly documented dependencies are not a problem that Typescript solves.
- Udik 7y ago
  > in some instances, the illusion of safety can be harmful > you can catch some shallow bugs around types > If Typescript is giving you a false sense of confidence about using random libraries > Badly documented dependencies are not a problem that Typescript solves. Seriously, what is your claim? That if you have a badly documented third party library with wrong typings then typescript doesn't help? Well, that's some news! Try the same library with no documentation at all then, so you won't get a false sense of safety. If that is your problem, why don't you just avoid importing typings for libraries? And I don't get this insistence on bugs and safety. Sure, typescript probably prevents you from doing really stupid stuff sometimes, but that's not the main reason I use it. I use it because it both allows me to write much more complex code and speeds up dramatically the development- because the tool takes on itself what is otherwise a heavy cognitive load: remembering and inferring interfaces and signatures that are there all the time, even if implicitly.
  - danShumway 7y ago
    > If that is your problem, why don't you just avoid importing typings for libraries? Yes? That's exactly what people are doing when they import a dependency written in Typescript into a pure JS project. > A whole lot of the time, especially in Javascript land you will join projects where libraries are being used, and where documentation is lacking. Your advice here is basically to not be part of those projects? Instead of developing and using tooling that will ensure that these situations no longer happen? My claim is that Typescript does not solve the problem of joining a project with poorly written, undocumented libraries. I'm not bashing on Typescript. If the primary way you use it is as an organizational tool to reduce cognitive load and make interfaces more explicit, then that's great. You're using Typescript as intended. And there are some scenarios where a compile-time type-checker is just obviously the right tool for the job. You started this thread by asking how JS devs could manage 3rd-party interfaces without Typescript. I assume you genuinely want an answer to that question. The answer is that for some people on some projects, using well defined interfaces and keeping a reference page open with documentation is about as fast and about as easy as using Typescript, and that following that process doesn't increase their bug count or cognitive load to the point where they feel the need to introduce a compilation step.
orange8 7y ago
> javascript is just typescript with documentation stripped off. JS, at its core is a dynamically typed, functional language. Typescript aims to model a strongly typed, OPP language. The two programming paradigms have their own strengths, weaknesses and most importantly: patterns and best practices. If the only difference between your pure javascript code and your typescript code is the annotations, you are doing it wrong.
- Udik 7y ago
  > Typescript aim to model a strongly typed, OPP language. Do you think? I just take TS for what it gives me, documentation and static code analysis. I can write down my knowledge and expectations about the code and have the tool keep track of it for me, removing the cognitive load of doing it myself- which I'd have to otherwise. Can you give me an example of a pattern that is "good" in JS and not in TS, or the other way round? I'm curious.
  - orange8 7y ago
    A good indirect example is an actual feature added to JS recently, which are classes. Classes are the main unit of OOP, while functions are the main unit in the functional paradigm. The class syntax in JS is not a real new structure added to the language, but just syntax sugar. Underneath it all, the JS compiler just converts it to a regular JS function using a specific pattern. You could, if you wanted, save the compiler that work by just coding using that pattern to begin with. When using TS the class syntax fits in perfectly for me, an in pure JS I'd stick to functions.
    - Udik 7y ago
      So you're giving a javascript feature as an example of a pattern that doesn't fit javascript. Then you claim to use an equivalent but syntactically different form in js? How does this constitute a different pattern?
- iaml 7y ago
  > Typescript aims to model a strongly typed, OPP language That's a rather puzzling statement, to be honest. Strong type system is explicitly one of the non-goals[0]. I write typescript code everyday and most of it is functional. Things like fp-ts[1] make it even more enjoyable. [0] https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi... [1] https://github.com/gcanti/fp-ts https://github.com/gcanti/fp-ts

by Udik 7y ago

danShumway 7y ago

This is kind of a subtle idea, but in some instances, the illusion of safety can be harmful. It is occasionally (not always) better not to give people the illusion of safety when that safety doesn't actually exist. Sometimes putting an ineffective railing along a mountain path increases accidents, because it's human nature for people walking on that path to watch their footing less when they see the railing. >> Do not use random libraries. A good library should have even some basic docs outline its API and how to use it. > A whole lot of the time, especially in Javascript land you will join projects where libraries are being used, and where documentation is lacking. Your advice here is basically to not be part of those projects? Instead of developing and using tooling that will ensure that these situations no longer happen? I'm not here to hate on Typescript, I think it has its uses. I use Typescript in some places. I generally avoid it for personal projects, but I would probably encourage it for larger orgs. But the idea that Typescript protects you from needing to care about interfaces is exactly the problem with over-reliance on Typescript, and is the source of a lot of really badly written code that treats interface design like an afterthought. If you're using Typescript for documentation and you're treating it like a tool, you can write some really elegant code, you can catch some shallow bugs around types and assumptions, you can integrate your documentation into your IDE. If you're looking at Typescript and saying, "this is an efficient way for me to document what my code does", then this is all very good. But if you're using Typescript and saying, "now I can pull in any dependency I want", then Typescript is doing you more harm than good. The specific advice orange gives in those two sentences is good advice. If Typescript is giving you a false sense of confidence about using random libraries, then that's a real negative. I use both pure JS and Typescript almost daily, and I consume plenty of dependencies written in Typescript. I still occasionally need to debug the stack traces in those dependencies. I still occasionally need to read through their source code to figure out what they're doing. Badly documented dependencies are not a problem that Typescript solves.

Udik 7y ago
> in some instances, the illusion of safety can be harmful > you can catch some shallow bugs around types > If Typescript is giving you a false sense of confidence about using random libraries > Badly documented dependencies are not a problem that Typescript solves. Seriously, what is your claim? That if you have a badly documented third party library with wrong typings then typescript doesn't help? Well, that's some news! Try the same library with no documentation at all then, so you won't get a false sense of safety. If that is your problem, why don't you just avoid importing typings for libraries? And I don't get this insistence on bugs and safety. Sure, typescript probably prevents you from doing really stupid stuff sometimes, but that's not the main reason I use it. I use it because it both allows me to write much more complex code and speeds up dramatically the development- because the tool takes on itself what is otherwise a heavy cognitive load: remembering and inferring interfaces and signatures that are there all the time, even if implicitly.
- danShumway 7y ago
  > If that is your problem, why don't you just avoid importing typings for libraries? Yes? That's exactly what people are doing when they import a dependency written in Typescript into a pure JS project. > A whole lot of the time, especially in Javascript land you will join projects where libraries are being used, and where documentation is lacking. Your advice here is basically to not be part of those projects? Instead of developing and using tooling that will ensure that these situations no longer happen? My claim is that Typescript does not solve the problem of joining a project with poorly written, undocumented libraries. I'm not bashing on Typescript. If the primary way you use it is as an organizational tool to reduce cognitive load and make interfaces more explicit, then that's great. You're using Typescript as intended. And there are some scenarios where a compile-time type-checker is just obviously the right tool for the job. You started this thread by asking how JS devs could manage 3rd-party interfaces without Typescript. I assume you genuinely want an answer to that question. The answer is that for some people on some projects, using well defined interfaces and keeping a reference page open with documentation is about as fast and about as easy as using Typescript, and that following that process doesn't increase their bug count or cognitive load to the point where they feel the need to introduce a compilation step.

orange8 7y ago

> javascript is just typescript with documentation stripped off. JS, at its core is a dynamically typed, functional language. Typescript aims to model a strongly typed, OPP language. The two programming paradigms have their own strengths, weaknesses and most importantly: patterns and best practices. If the only difference between your pure javascript code and your typescript code is the annotations, you are doing it wrong.

Udik 7y ago
> Typescript aim to model a strongly typed, OPP language. Do you think? I just take TS for what it gives me, documentation and static code analysis. I can write down my knowledge and expectations about the code and have the tool keep track of it for me, removing the cognitive load of doing it myself- which I'd have to otherwise. Can you give me an example of a pattern that is "good" in JS and not in TS, or the other way round? I'm curious.
- orange8 7y ago
  A good indirect example is an actual feature added to JS recently, which are classes. Classes are the main unit of OOP, while functions are the main unit in the functional paradigm. The class syntax in JS is not a real new structure added to the language, but just syntax sugar. Underneath it all, the JS compiler just converts it to a regular JS function using a specific pattern. You could, if you wanted, save the compiler that work by just coding using that pattern to begin with. When using TS the class syntax fits in perfectly for me, an in pure JS I'd stick to functions.
  - Udik 7y ago
    So you're giving a javascript feature as an example of a pattern that doesn't fit javascript. Then you claim to use an equivalent but syntactically different form in js? How does this constitute a different pattern?
iaml 7y ago
> Typescript aims to model a strongly typed, OPP language That's a rather puzzling statement, to be honest. Strong type system is explicitly one of the non-goals[0]. I write typescript code everyday and most of it is functional. Things like fp-ts[1] make it even more enjoyable. [0] https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi... [1] https://github.com/gcanti/fp-ts https://github.com/gcanti/fp-ts