4 ms·

>This is a good example of the object oriented, strongly typed way of thinking. Explore languages that follow different paradigms, where interfaces just don't a

>This is a good example of the object oriented, strongly typed way of thinking. Explore languages that follow different paradigms, where interfaces just don't apply. I'm not sure whether you intended this to sound so patronizing, but wow. What languages should I explore while talking about Javascript? You are called to edit a function that takes 2 arguments: function handle_req(request, options): What is request in this context and what is options? What makes me more productive, going up the stack and seeing who might call this function and with what argument, or instantly knowing what the domain of values it operates on is and being able to treat this as a separate unit? >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? Okay.

danShumway 7y ago
> that will ensure that these situations no longer happen? Well... but Typescript doesn't ensure those situations won't happen, ironically because it's a superset of Javascript and it's not strict enough. Typescript is just documentation that compiles. If a library has bad documentation, it's likely to have bad Typescript as well, and bad Typescript can be a giant curse. Typescript will happily allow you to force a typecast that doesn't reflect reality -- it will happily allow you to say that a method always returns a string when sometimes it returns a number, and it will happily compile in those scenarios. Tracking those bugs down are a giant pain. I don't hate Typescript, but people who look at this and think, "I don't have to care about what libraries I'm using, I can just trust the interface" are fooling themselves. I've debugged plenty of errors in Typescript code that ended up being the result of me trusting an interface that didn't reflect the reality at runtime. There's value in Typescript for some projects, but it does not remove the need to be careful about documentation and dependencies, because it's so easy for both dependencies and downstream code to circumvent the protections Typescript gives you.
- 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.
orange8 7y ago
> I'm not sure whether you intended this to sound so patronizing, but wow. What languages should I explore while talking about Javascript? Why would the suggestion to explore non OOP, strongly typed languages sounds patronizing to you? The more different languages you play with, the broader your mental modelling toolset becomes. It is painfully obvious to me that someone worried about interfaces in JS is not very familiar with more dynamically typed or/and functional languages. JS is a VERY FLEXIBLE language which can be coded in any style, which is why I've suggest playing with something more opinionated to get the gist. Languages like XSLT, Erlang, LISP, Haskell etc. > You are called to edit a function that takes 2 arguments: > function handle_req(request, options): > What is request in this context and what is options? The fact that you can edit handle_req means it is application code. So how you figure that out comes down to the structure and patterns you and your team use (if any) and the available documentation (if any). You'd be surprised how far Eslint and JSDoc will take you. TypeScript accomplishes the same, and I've no problem using it within a team that needs it but personally, it feels like an overkill I don't really need to. > 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? The decision to use TypeScript or any other tooling should really be made at the BEGINING of a project, so why are we talking about projects that already missed the boat, and even worse lack documentation and tests? This just proves my point, what you really need is discipline (documentation, tests, best praise etc) and a good linter, not a whole new language or programming paradgim.

danShumway 7y ago

> that will ensure that these situations no longer happen? Well... but Typescript doesn't ensure those situations won't happen, ironically because it's a superset of Javascript and it's not strict enough. Typescript is just documentation that compiles. If a library has bad documentation, it's likely to have bad Typescript as well, and bad Typescript can be a giant curse. Typescript will happily allow you to force a typecast that doesn't reflect reality -- it will happily allow you to say that a method always returns a string when sometimes it returns a number, and it will happily compile in those scenarios. Tracking those bugs down are a giant pain. I don't hate Typescript, but people who look at this and think, "I don't have to care about what libraries I'm using, I can just trust the interface" are fooling themselves. I've debugged plenty of errors in Typescript code that ended up being the result of me trusting an interface that didn't reflect the reality at runtime. There's value in Typescript for some projects, but it does not remove the need to be careful about documentation and dependencies, because it's so easy for both dependencies and downstream code to circumvent the protections Typescript gives you.

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.

orange8 7y ago

> I'm not sure whether you intended this to sound so patronizing, but wow. What languages should I explore while talking about Javascript? Why would the suggestion to explore non OOP, strongly typed languages sounds patronizing to you? The more different languages you play with, the broader your mental modelling toolset becomes. It is painfully obvious to me that someone worried about interfaces in JS is not very familiar with more dynamically typed or/and functional languages. JS is a VERY FLEXIBLE language which can be coded in any style, which is why I've suggest playing with something more opinionated to get the gist. Languages like XSLT, Erlang, LISP, Haskell etc. > You are called to edit a function that takes 2 arguments: > function handle_req(request, options): > What is request in this context and what is options? The fact that you can edit handle_req means it is application code. So how you figure that out comes down to the structure and patterns you and your team use (if any) and the available documentation (if any). You'd be surprised how far Eslint and JSDoc will take you. TypeScript accomplishes the same, and I've no problem using it within a team that needs it but personally, it feels like an overkill I don't really need to. > 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? The decision to use TypeScript or any other tooling should really be made at the BEGINING of a project, so why are we talking about projects that already missed the boat, and even worse lack documentation and tests? This just proves my point, what you really need is discipline (documentation, tests, best praise etc) and a good linter, not a whole new language or programming paradgim.