4 ms·

What are you talking about? Lost productivity compared to what, JS? Merge types? You can just use `&` to combine them if need be? Discussing types? Does it matt

by tekkk 8y ago

What are you talking about? Lost productivity compared to what, JS? Merge types? You can just use `&` to combine them if need be? Discussing types? Does it matter that much, and I mean refactoring them isn't a big deal if need be. Two different types represent essentially the same data? You've tried extending interfaces or using generics? Seems like you lack an experienced TS developer in your team and are contributing your lack of experience as a fault of the language itself. The typing has saved my ass maany times and makes the code in our projects actually maintainable for us and for someone outside of our team's bubble. It might take a while longer to code the app, but it'll take less hours in the long run to keep it safe and working.

jondubois 8y ago
I started coding with ActionScript 2 and then switched to ActionScript 3 (ECMAScript with types; basically the same as TypeScript) for years starting at a very early age. Then I did Java and C++ while at uni. Then I used JavaScript for several years (and did some half year stints with TypeScript in between) so I have a more balanced experience with both statically and dynamically typed languages than the vast majority of developers (I have over 15 years of experience in total: Slightly more with dynamically typed languages). I also maintain several open source projects in my own time so I work many hours per week. Also, I'm currently working on a TypeScript project (second time in the past 2 years). Also, I've spoken to several very senior developers (including some influential individuals) who also have broad experience and who share my point of view. So that's why I feel confident when I say that TypeScript does not add any actual safety. I don't have skin on either side (well actually my current employer uses TypeScript so saying bad things about TypeScript does not align with my career interests) and I really did give both a really fair, thorough trial with an open mind. As I said, I even switched back and forth between them for extended periods to gain more perspective. Typescript solves a few small but obvious problems and introduces multiple new problems that are worse but less obvious (it makes the details of the code better, but the overall foundation and the process worse).
- tekkk 8y ago
  I am curious, so do you then prefer JS over TS? It still feels to me that you're doing something wrong, and are finding any reason to blame the language. I had very negative views about TS when I did some hobby project with it was it 3 years ago. I felt it only added confusing boilerplate, that hindered my ability to code. But a lot of it was just my own inexperience with the type system, and I was getting stuck many times because I didn't know how to use it. Now it feels like a breeze and I take shortcuts when I need them, and add the interfaces when it feels necessary. It was a bitter thing to swallow, to admit to myself that I just hadn't understood TS and reverse my views once I got hang of it. Sometimes when you first have a bad experience with well basically anything, you'll be viewing it with the same negative emotion throughout your life. If so many people, experienced and inexperienced developers alike, are saying good things about TS maybe there's something there that you just haven't discovered? >Typescript solves a few small but obvious problems and introduces multiple new problems that are worse but less obvious (it makes the details of the code better, but the foundation worse). Care to elaborate?
  - jondubois 8y ago
    Some problems with TypeScript: - Discourages using external libraries because of type name conflicts. Interface and class names must be universal so if two libraries use the same name for different types, then that makes things difficult. It's also a problem if two libraries use different type names to represent the same concept. This encourages developers to reinvent the wheel as opposed to relying on battle-tested external libraries. There is a workaround for name conflicts but it's not ideal. - Type definitions of third party modules are likely to be or to become out of date. - In terms of code foundation; the way all the logic fits together in TypeScript is rigid and tightly interlocked around arbitrary labels (type names) that developers have invented (and each developer tends to have a different idea about the meaning and use cases of each type). As project requirements evolve, the underlying logic starts to diverge from the meaning of the labels to the point that they lose their meaning completely. Most large TypeScript projects end up with many types that have slightly different meanings but are meant to be used in different ways and impose different constraints on developers (e.g. User, UserInfo, UserConfig, Account, UserAccount, ReadonlyUser...). You might say that this could be avoided by good programming patterns, but if you look at most large popular TypeScript projects, you will see a lot of strangely named types which only make sense to developers who have been working on the project for a long time.
koolba 8y ago
> It might take a while longer to code the app, but it'll take less hours in the long run to keep it safe and working. I'd argue it's faster to market, not just faster to fix, with TypeScript over vanilla JS. Static type checking means significantly better auto completion and the immediate elimination of the vast majority of "stupid me" type JS errors from typos, misnamed arguments, and more.
- jondubois 8y ago
  >> "stupid me" type JS errors from typos, misnamed arguments That is true but these errors are very easy to fix in any language. The difficult and most important part of programming is getting the system design/structure/architecture right. Avoiding bad design is the real challenge of programming e.g. code paths are too long and traverse too many different files, it's not clear where objects are coming from in the code (bad DI), files are poorly named, directory structure makes no sense, exceptions are not thrown or handled correctly, logging is absent or not detailed enough, testing is focused on the least important functionality, validation logic for external data is wrong or hard to follow, system doesn't scale, components don't have clear separation of concerns, component abstractions are leaking lower level concepts into the higher level logic, access control layer has gaps, etc... Static typing doesnt add any value for any of these things. Static typing can help find class or function definitions and usages in the code more easily but only if the classes, functions and methods are poorly named to begin with (if classes and methods have good, highly relevant names, then they're always easy to find in any language). For a senior developer; design problems are the real hard problems. The rest is minor stuff and we shouldn't spend all our effort on those.
  - koolba 8y ago
    > That is true but these errors are very easy to fix in any language. No they're not. Language without static type checks end up with unit tests as an ersatz type check. > The difficult and most important part of programming is getting the system design/structure/architecture right. TypeScript is literally JavaScript with typing added. The underlying runtime is the exact same as whatever will be running your non-tranpiled-from-TypeScript JavaScript. The big changes for class syntax and enums are simply more tools in your belt but you do not have to use them. Any valid pure-JS design translates immediately to usage in TypeScript. It's strictly superior. > Avoiding bad design is the real challenge of programming e.g. code paths are too long and traverse too many different files, it's not clear where objects are coming from in the code (bad DI), files are poorly named, directory structure makes no sense, exceptions are not thrown or handled correctly, logging is absent or not detailed enough, testing is focused on the least important functionality, validation logic for external data is wrong or hard to follow, system doesn't scale, components don't have clear separation of concerns, component abstractions are leaking lower level concepts into the higher level logic, access control layer has gaps, etc... Static typing doesnt add any value for any of these things. > Static typing can help find class or function definitions and usages in the code more easily but only if the classes, functions and methods are poorly named to begin with (if classes and methods have good, highly relevant names, then they're always easy to find in any language). Static typing isn't just grep on steroids. It catches entirely different classes of errors as well. Being able to immediately hop from a usage to its declaration is convenient, going in the other direction is amazing. Refactoring the signature, not just body, of a function and feeling confident that all usages have been updated to reflect the change even before you run the app is empowering. It lowers the bar to change and allows your code to evolve more quickly. > For a senior developer; design problems are the real hard problems. The rest is minor stuff and we shouldn't spend all our effort on those. Exactly why analysis of problems that computers can solve better than humans (ex: "Is variable fooBarXyz in scope here?") should be deferred to computers.
randallsquared 8y ago
> Discussing types? Does it matter that much [?] Well, if you've decided to use TypeScript for some reason other than momentary whim, it must matter a lot...
- tom_ 8y ago
  I assume the point is that creating new types is very simple, so if you need a new one, then you can just make one, call it what you like, put whatever you need inside it, and start to use it. You don't need to have interminable discussions about this. If you need more stuff in the type later, you can add it. If the name turns out to be wrong, you can change it. If you need to remove something, you can do that. If you just decide that it was a bad idea, you can get rid of it entirely. In each case, you can just make the change, and the compiler will show you all the code that has to change because of it. If this is some public-facing or versioned thing then some discussion would be warranted - but you would have had to do that already, types or no! (But even if the worst happens, and some new type gets added in, and it's kind of wrong, and it gets exposed anyway: at least you know about it.)
  - tekkk 8y ago
    You gave a better answer than I could have done myself :). Yes, more or less so. Sometimes there can be tricky typing issues but in those cases somebody wiser often comes in and the problem is solved together. At times it's better for individual developers to try to solve say a typing problem on their own instead of somebody else giving them an immediate answer. Maybe it decreases productivity a little bit, but in the long run it's better for developers' individual growth. Though incase the problem is too difficult, I can't emphasize enough the importance of the wisdom of experienced developers.
  - deleted 8y ago
    [deleted]
- tekkk 8y ago
  What is your argument? If we are not "discussing with colleagues what types should be called" we are only using TypeScript for no other reason than momentary whim? For his next points, sure you have to give it a pause before you decide to implement your interfaces. I do not know what type of app he is building, but I myself and our team have clear established patterns that we use. And if something bothers someone, they'll be discussed in a code review or be refactored at some point. But without more context, I can't give a better answer.

by tekkk 8y ago

jondubois 8y ago

I started coding with ActionScript 2 and then switched to ActionScript 3 (ECMAScript with types; basically the same as TypeScript) for years starting at a very early age. Then I did Java and C++ while at uni. Then I used JavaScript for several years (and did some half year stints with TypeScript in between) so I have a more balanced experience with both statically and dynamically typed languages than the vast majority of developers (I have over 15 years of experience in total: Slightly more with dynamically typed languages). I also maintain several open source projects in my own time so I work many hours per week. Also, I'm currently working on a TypeScript project (second time in the past 2 years). Also, I've spoken to several very senior developers (including some influential individuals) who also have broad experience and who share my point of view. So that's why I feel confident when I say that TypeScript does not add any actual safety. I don't have skin on either side (well actually my current employer uses TypeScript so saying bad things about TypeScript does not align with my career interests) and I really did give both a really fair, thorough trial with an open mind. As I said, I even switched back and forth between them for extended periods to gain more perspective. Typescript solves a few small but obvious problems and introduces multiple new problems that are worse but less obvious (it makes the details of the code better, but the overall foundation and the process worse).

tekkk 8y ago
I am curious, so do you then prefer JS over TS? It still feels to me that you're doing something wrong, and are finding any reason to blame the language. I had very negative views about TS when I did some hobby project with it was it 3 years ago. I felt it only added confusing boilerplate, that hindered my ability to code. But a lot of it was just my own inexperience with the type system, and I was getting stuck many times because I didn't know how to use it. Now it feels like a breeze and I take shortcuts when I need them, and add the interfaces when it feels necessary. It was a bitter thing to swallow, to admit to myself that I just hadn't understood TS and reverse my views once I got hang of it. Sometimes when you first have a bad experience with well basically anything, you'll be viewing it with the same negative emotion throughout your life. If so many people, experienced and inexperienced developers alike, are saying good things about TS maybe there's something there that you just haven't discovered? >Typescript solves a few small but obvious problems and introduces multiple new problems that are worse but less obvious (it makes the details of the code better, but the foundation worse). Care to elaborate?
- jondubois 8y ago
  Some problems with TypeScript: - Discourages using external libraries because of type name conflicts. Interface and class names must be universal so if two libraries use the same name for different types, then that makes things difficult. It's also a problem if two libraries use different type names to represent the same concept. This encourages developers to reinvent the wheel as opposed to relying on battle-tested external libraries. There is a workaround for name conflicts but it's not ideal. - Type definitions of third party modules are likely to be or to become out of date. - In terms of code foundation; the way all the logic fits together in TypeScript is rigid and tightly interlocked around arbitrary labels (type names) that developers have invented (and each developer tends to have a different idea about the meaning and use cases of each type). As project requirements evolve, the underlying logic starts to diverge from the meaning of the labels to the point that they lose their meaning completely. Most large TypeScript projects end up with many types that have slightly different meanings but are meant to be used in different ways and impose different constraints on developers (e.g. User, UserInfo, UserConfig, Account, UserAccount, ReadonlyUser...). You might say that this could be avoided by good programming patterns, but if you look at most large popular TypeScript projects, you will see a lot of strangely named types which only make sense to developers who have been working on the project for a long time.

koolba 8y ago

> It might take a while longer to code the app, but it'll take less hours in the long run to keep it safe and working. I'd argue it's faster to market, not just faster to fix, with TypeScript over vanilla JS. Static type checking means significantly better auto completion and the immediate elimination of the vast majority of "stupid me" type JS errors from typos, misnamed arguments, and more.

jondubois 8y ago
>> "stupid me" type JS errors from typos, misnamed arguments That is true but these errors are very easy to fix in any language. The difficult and most important part of programming is getting the system design/structure/architecture right. Avoiding bad design is the real challenge of programming e.g. code paths are too long and traverse too many different files, it's not clear where objects are coming from in the code (bad DI), files are poorly named, directory structure makes no sense, exceptions are not thrown or handled correctly, logging is absent or not detailed enough, testing is focused on the least important functionality, validation logic for external data is wrong or hard to follow, system doesn't scale, components don't have clear separation of concerns, component abstractions are leaking lower level concepts into the higher level logic, access control layer has gaps, etc... Static typing doesnt add any value for any of these things. Static typing can help find class or function definitions and usages in the code more easily but only if the classes, functions and methods are poorly named to begin with (if classes and methods have good, highly relevant names, then they're always easy to find in any language). For a senior developer; design problems are the real hard problems. The rest is minor stuff and we shouldn't spend all our effort on those.
- koolba 8y ago
  > That is true but these errors are very easy to fix in any language. No they're not. Language without static type checks end up with unit tests as an ersatz type check. > The difficult and most important part of programming is getting the system design/structure/architecture right. TypeScript is literally JavaScript with typing added. The underlying runtime is the exact same as whatever will be running your non-tranpiled-from-TypeScript JavaScript. The big changes for class syntax and enums are simply more tools in your belt but you do not have to use them. Any valid pure-JS design translates immediately to usage in TypeScript. It's strictly superior. > Avoiding bad design is the real challenge of programming e.g. code paths are too long and traverse too many different files, it's not clear where objects are coming from in the code (bad DI), files are poorly named, directory structure makes no sense, exceptions are not thrown or handled correctly, logging is absent or not detailed enough, testing is focused on the least important functionality, validation logic for external data is wrong or hard to follow, system doesn't scale, components don't have clear separation of concerns, component abstractions are leaking lower level concepts into the higher level logic, access control layer has gaps, etc... Static typing doesnt add any value for any of these things. > Static typing can help find class or function definitions and usages in the code more easily but only if the classes, functions and methods are poorly named to begin with (if classes and methods have good, highly relevant names, then they're always easy to find in any language). Static typing isn't just grep on steroids. It catches entirely different classes of errors as well. Being able to immediately hop from a usage to its declaration is convenient, going in the other direction is amazing. Refactoring the signature, not just body, of a function and feeling confident that all usages have been updated to reflect the change even before you run the app is empowering. It lowers the bar to change and allows your code to evolve more quickly. > For a senior developer; design problems are the real hard problems. The rest is minor stuff and we shouldn't spend all our effort on those. Exactly why analysis of problems that computers can solve better than humans (ex: "Is variable fooBarXyz in scope here?") should be deferred to computers.

randallsquared 8y ago

> Discussing types? Does it matter that much [?] Well, if you've decided to use TypeScript for some reason other than momentary whim, it must matter a lot...

tom_ 8y ago
I assume the point is that creating new types is very simple, so if you need a new one, then you can just make one, call it what you like, put whatever you need inside it, and start to use it. You don't need to have interminable discussions about this. If you need more stuff in the type later, you can add it. If the name turns out to be wrong, you can change it. If you need to remove something, you can do that. If you just decide that it was a bad idea, you can get rid of it entirely. In each case, you can just make the change, and the compiler will show you all the code that has to change because of it. If this is some public-facing or versioned thing then some discussion would be warranted - but you would have had to do that already, types or no! (But even if the worst happens, and some new type gets added in, and it's kind of wrong, and it gets exposed anyway: at least you know about it.)
- tekkk 8y ago
  You gave a better answer than I could have done myself :). Yes, more or less so. Sometimes there can be tricky typing issues but in those cases somebody wiser often comes in and the problem is solved together. At times it's better for individual developers to try to solve say a typing problem on their own instead of somebody else giving them an immediate answer. Maybe it decreases productivity a little bit, but in the long run it's better for developers' individual growth. Though incase the problem is too difficult, I can't emphasize enough the importance of the wisdom of experienced developers.
- deleted 8y ago
  [deleted]
tekkk 8y ago
What is your argument? If we are not "discussing with colleagues what types should be called" we are only using TypeScript for no other reason than momentary whim? For his next points, sure you have to give it a pause before you decide to implement your interfaces. I do not know what type of app he is building, but I myself and our team have clear established patterns that we use. And if something bothers someone, they'll be discussed in a code review or be refactored at some point. But without more context, I can't give a better answer.