11 ms·

This is gonna be an unpopular opinion but as someone who learned to program in loosely typed languages, I have never seen the TS appeal. TS feels like somethin

This is gonna be an unpopular opinion but as someone who learned to program in loosely typed languages, I have never seen the TS appeal. TS feels like something that was created to lure programmers who couldn’t wrap their heads around JS loose nature. Almost like it was created to convince Java and C# developers to use JS. It have never felt about it like something that would make my code better or more organized. It definitely slows me down with very little benefits in return. (Again, can’t stress enough that this is a personal opinion based on personal use cases) I appreciate that it forces me to be more intentional about organizing my code but I also get that when I use frameworks. Of course I also appreciate when I can identify that an error is coming from a type mismatch, but as I said I learned to program in loosely typed languages first, so I never created that concept of defining types in my head. I’m always extra-aware of types mismatches in my JS code and is usually the first thing I check when something goes wrong. But I have never felt the need to have a way to explicitly define the types that I’m working with. I honestly fail to see the benefit when a large amount of code that you have to interact with (libraries and such) was written in classic JS. Once again. Probably unpopular opinion, so I don’t mind the downvotes.

deleted 6y ago
[deleted]
halfmatthalfcat 6y ago
You don’t see the benefits of a strongly typed language?
- cheez 6y ago
  Python is strongly typed, don't confuse static and strong typing.
  - whoisjuan 6y ago
    You’re right.
- whoisjuan 6y ago
  I do. But not for JS in particular. At the end of the day 95% of JS that is written in classic JS and is used in thousands of high-scale projects like that.
  - searchableguy 6y ago
    I would say for me, typechecking part of ts is less useful than the information it provides me about the project. I can jump in a new project and quickly see what kind of data structures are there, what are the parameters, get really nice intellisense and documentation. All of this is possible with jsdocs and flow but they are not nearly as powerful as ts and often times verbose. I don't like polluting the comments. You don't need to use typescript everywhere although the popular zeitgeist will tell you to avoid any or ts-ignore. It's fine to write some parts in ts and others in js. Think of ts as eslint, jsdocs or flow. You don't need to be religious about it. Take its benefits wherever you can or do you think all the other tools are useless as well?
echelon 6y ago
You don't have to write as many tests when you use static typing, because your method contracts are solid. You can refactor your entire codebase with a few operations and don't have to worry about anything breaking. Is your timestamp in seconds? Millis? Is it a duration? Does it have a time zone? Have you ever written a method that returns more than one type of thing? Or had polymorphic inputs? Where are your dynamically dispatched calls even used, and how do you know you modified them all? One of the most common operations in building new features is plumbing new state through the system. Types are there to help you in such perilous times. Types are refreshing and reassuring.
- iamleppert 6y ago
  Forgive me, but when I program I know what the variables I am working with are doing, and what kind of data they are storing. That’s the least of my problems. I don’t write a big mess of code, I’m constantly working iteratively on a small piece of code to make it perfect. Usually first pass is to make it perfect, then I refactor it right away to make it readable. I work that way, function by function. I never have the class of bugs in my projects that people seem to laud about typing to solve. It’s kind of ridiculous to me and cumbersome and makes certain dynamic programming concepts difficult or impossible. I don’t want to give up power just because other developers are sloppy. I want my code to be readable, and succinct. A lot of times that requires creating functions dynamically at runtime or some other such thing that would void the benefits of a typing system anyways. I recognize that in working with a team where people have other styles, varying attention to detail levels and skill, they can’t all be trusted to produce bug-free code without the constant nagging and overhead of a pedantic type system. My solution is not to employ another piece of technology to solve this problem, rather it’s just not to work with those people. If you can’t write dynamic code without a bunch of type errors at runtime, learn to be a better programmer first before blaming the tools.
  - hnarn 6y ago
    > Forgive me, but when I program I know what the variables I am working with are doing, and what kind of data they are storing. That sounds fine, as long as no-one else will ever have to read or work on your code.
efficax 6y ago
your viewpoint might change when you're working on a large project with lots of developers and your system goes down in production because of a type mismatch the compiler could have easily let you know about long before you deployed (i speak from experience). All it takes is once and you'll become a statically typed language evangelist.
mimixco 6y ago
I've been programming for 40 years and I agree. Strong typing has a religious quality. You have to believe that most errors are caused by type mismatch, and I simply don't believe that. Most errors, in my experience, are caused by bad architecture, poor documentation, and poor communications strategies between MVC, etc.
- kd913 6y ago
  Why is it one or the other? Type errors also certainly occur. If you eliminate a class of errors by doing so, isn't that still less errors overall?
- ctrl-j 6y ago
  I like typescript not because it prevents most errors in my code, but because it prevents some errors. Those errors, in my experience, tend to be ones that are time consuming to identify and solve. A value of the wrong type passed forward because it's almost the right type can cause errors that make their way into production. I hear you say "so unit test your code!", and to that I reply, we're a c# shop that has only recently started pushing some of our code to the client. If you can convince management that we should shift our paradigm to allow for the time to write tests that don't add much to the sprint we're in, I can send you their email address. The fact is, a large portion of unit tests solve the same problems that strong types solve.
  - Rapzid 6y ago
    I've spent more time helping people hunt down "undefined is not a function" and "Cannot read property of undefined" than just about anything else. Two observations from this: 1.) The fact that I even got involved meant the issues were particularly hard to track down 2.) These errors seem to be more of a time sync within a larger team/project than many realize Typically these were caused by either scope issues and/or some context object that's been riding dirty all day. In the case of the latter hunting down the code that did the naughty can be particularly soul crushing.
- elmo2you 6y ago
  I have a little less experience, only 30 years, but I have to fully agree with you. Not sure why you got down voted (maybe the religious popularity crowd rearing its head). I have seen my share of "innovations" come and go, but I too fail to see the empirical evidence that most bugs/errors are caused by type mismatch. In fact, I would even go as far as to argue that in my experience the benefits of typed languages (and the class of bugs they prevent) do not outweigh the usually larger code size (and often even additional complexity). Maybe I've just tried the wrong languages, but I was never convinced of the great improvements usually promised. At the same time, I have seen other people twist and jump through hoops, while vigorously holding on to their conviction how all that is an improvement. Sure, some errors will move from run time to compile time with typed languages. But if those are a systemic problem in your code, you probably have even bigger things to worry about (the ones you already keenly pointed out). From a cynical point of view, I can understand why corporate entities would love typed languages (for the increased code size and complexity), but that's another story.
ctvo 6y ago
> TS feels like something that was created to lure programmers who couldn’t wrap their heads around JS loose nature. TypeScript adds additional type checking at transpile time to code. The assumption that the people who can write code with these more rigorous checks can't write the same code with it all removed ... I would examine that a little more closely.
AlexMax 6y ago
> TS feels like something that was created to lure programmers who couldn’t wrap their heads around JS loose nature. Almost like it was created to convince Java and C# developers to use JS. On the contrary, as somebody who learned programming with a mix of static and dynamic types, I felt like TypeScript showed me what a good type system was capable of in giving me the best of both worlds. Instead of being pedantry, I felt like the type system was actually on my side for once and helping me to write correct code with fewer unaccounted-for corner cases and unexpected runtime crashes. And it does that while avoiding the feeling I got from previous statically-typed languages I used where the type system felt like a straight jacket incapable of expressing non-trivial concepts and relationships.
- whoisjuan 6y ago
  Perhaps one reason why I feel like I do about it is that I write a lot of prototype code and maybe sub-consciously it makes me feel like I’m losing speed.
meowzero 6y ago
I've developed with JS, PHP, and Ruby for about 5 years. Then I switch to statically type languages for the next 5 years (Scala then to Typescript). If I had to choose, I would choose static typing. For small projects, dynamically typed languages are fine. but as the project grows bigger, the static typing will help and will make thing simpler. As the project grows, refactoring will be an issue. Static typing will make it simpler to refactor. Tests are smaller. Reading the code will be easier since you know the contract of functions. Fewer runtime errors since most errors will be caught at compile time. Also, the stronger the type system it is, the more it will be caught at compile time. I don't think it slows me down that much. It's a little more typing, and there is compile time overhead. In some cases, you have to work your way around the type system. But at least with Scala, I am confident my code will work as intended as long as it compiles successfully. I spend less time debugging in runtime and writing tests. I think static typing might save time in the long run but not short run.
- say-vagnes 6y ago
  Hey, I've also made the trip from Scala to Typescript. We're talking ZIO and Shapeless wrangling. Twitter vs Scala futures. All that fun stuff (and I loved scala nonetheless). Would love to know how your journey was. At first I was super hesitant, but now I am actually floored at the power Typescript has. The ability to tell the compiler to simply "trust me" has enabled me to build many abstractions I'd battle for hours to do in Scala.
  - mbo 6y ago
    Hey, same situation! As the resident rabid FP evangelist at work, people are often surprised by how much I like like TypeScript. Personally, I think structural typing systems are the path forward for functional languages, and that means accepting that Haskell needs to go to move on to a retirement home. I was pleasantly surprised by how well Scala did subtyping with ZIO's `Has` + variance annotations. Shame TypeScript is bivariant with function parameters.
    - kingdomcome50 6y ago
tengbretson 6y ago
The thing I have found the most useful with typescript is that it punishes you for doing the kind of cutesy stuff that permeated the node ecosystem in the early days. "Pass in three parameters with a callback in the fourth position. The second param is configuration so pass in a string, but if you need to really customize stuff actually pass in an object instead and by the way if you don't have a third parameter then just chuck the callback there, why not!?" Typescript is great in that somehow it is technically possible to write types for existing code written like this, but writing new code like that is cumbersome enough to prevent it.
- pragmatic 6y ago
  Actually, you can "type" that call. But I always found the "giant ball if config" style painful. For example, I believe it was done data table library that took over a page of config options to get set up. The problem is, you'd have to have the documentation open to make the slightest tweak to anything. No help from the type system.
- Rapzid 6y ago
  Yes! My pet peeve with public APIs are DTOs that are like this! "This is an array of strings, but it could be an object. If it's an object it will have this key and based on the name of the key it's this type. But it could also have or not have this other key and..." ARghhhh! You can tell what kinda language the back-end was written in with that crap because while TypeScript can actually type most of that stuff it's a huge mess in something like C#, Golang, Java, etc.
qppo 6y ago
I'm not a huge fan of TS not because I don't appreciate types but because I don't feel like it gives me any real type safety. Not due to the language itself but because I have to connect whatever I write to something else, and I wind up writing the type checking myself. It's the same BS as Python and JS, the lack of typing but fundamental nature of systems that require data to be typed means half my code is checking that everything is properly typed! Dynamic types have their uses, but in general they're more trouble than just writing typed code to begin with. And when your type system is more a suggestion than anything it provides little benefits.
kthejoker2 6y ago
> TS feels like something that was created to lure programmers who couldn’t wrap their heads around JS loose nature. Almost like it was created to convince Java and C# developers to use JS. This is true, and confirmed by the TypeScript team https://stackoverflow.blog/2020/06/15/talking-typescript-with-ryan-cavanaugh/ https://stackoverflow.blog/2020/06/15/talking-typescript-wit... > Do you remember why the team came up with TypeScript, why you wanted to release something like this? > A: When I joined the team, there were a lot of people at Microsoft who wanted to develop JavaScript at what we call “application scale.” Teams like TFS and Office wanted to build large JavaScript applications. A lot of those people had familiarity with statically-typed languages— C++, C#, Java, that kind of thing. They wanted to have that static typing available both for conceptual scalability and for the tooling. > The language experts at Microsoft looked at the situation and said, well, we could try to write a new language like people had done before. There are projects like Script#, which takes C sharp and turns it into JavaScript, or languages like CoffeeScript that said, what if JavaScript had a different syntax? But what they decided instead was to just take JavaScript and add static types on top of that. > At the time, JavaScript was experiencing a renaissance of growth, where they were adding features to the language again for the first time in a pretty long time. People wanted to use those cool new features, like arrow functions and classes, and they didn’t want to wait for all browsers to adopt them. They wanted to be able to use those features right away. I think those were the three things that TypeScript offered upfront: static typing for error finding purposes, leveraging that static type information for tooling, and providing the JavaScript features of tomorrow, today.
- Rapzid 6y ago
  > TS feels like something that was created to lure programmers who couldn’t wrap their heads around JS loose nature Seriously? > They wanted to have that static typing available both for conceptual scalability and for the tooling Sounds like they understood the loose nature pretty darn well.
hota_mazi 6y ago
What you call "Javascript's loose nature" I call a minefield of behaviors and semantics that make writing correct Javascript code so incredibly challenging. I use Typescript everywhere I need Javascript these days, it's a breath of fresh air, and my code feels maintainable, tractable, and much easier to refactor.
IBCNU 6y ago
+100 I'm on your team, 100% agree with your points, TS is a waste of time and I'm encouraging my team to drop it.
kumarvvr 6y ago
> who couldn’t wrap their heads around JS loose nature Ultimately, for any serious work, especially enterprise level work, your team members may include people of different calibers. In such a case, where you have to work with code written by other members of your team, it becomes a serious problem to develop quality code. For lone developers, it should not be a problem. But in enterprise settings, I think that is the reason why Node is not popular.
preek 6y ago
Thank you for the bold statement. I feel the same. I’m at home with Clojure, and Ruby. The same paradigms map well to JS. For the last 9 years, I have been a lecturer at the university of applied sciences in Zurich, Switzerland. In that time, I saw more and more students coming from Java and C# to JS. They like TS a lot. And it’s obvious why. Having said that, I know no “old” programmer who used to prefer a different paradigm to express a wish to switch to TS. Rich Hickey put it well in this quote “ Functional programs are desirable because they are simpler and easier to reason about, due to being mathematical i.e. they are free of time and place.”. I agree.
- Kinrany 6y ago
  That quote is not really relevant: TS is as functional as JS.
  - preek 6y ago
    Not really in the same way, though. I mentioned that paradigms of functional programming languages like Clojure translate well to JavaScript. They do not to typescript, because it is a statically typed language. If you are interested in why are you dynamically typed language has benefits for functional programming, please see this talk: https://youtu.be/oytL881p-nQ https://youtu.be/oytL881p-nQ
    - rendall 6y ago
      Typescript typing is fundamentally optional, so this criticism, even if true regarding statically typed languages, does not apply to Typescript. Typing is optional both for individual variables via the `any` type, and compiler-wide, by configuring it to assume untyped variables are `any` by default.
    - Kinrany 6y ago
      That talk is not about the benefits of dynamically typed languages over statically typed languages. Do you have a specific point in mind?
kiliancs 6y ago
It's sad that you have to be worried about downvotes for an opinion. I disagree, though. Instead of going with a lengthy list of why I think TS is great and disproving your arguments, which I assume everyone else will do, I'll admit that types can be hard, and so doing them right, or even doing them as best as one can, will always take some time. For a small project or a small team, that time might be hard to justify. But I think this is resolved with a good understanding TypeScript. Even so, TypeScript might not make sense for many projects or small teams, but I find it hard to defend that TypeScript won't be a net win for any medium team or medium-size project. This was my believe before, but I've seen multiple teams go from JS to Flow or TypeScript and the result has always been, when there's expert guidance, extremely positive. Productivity goes up, more bugs are fixed because there's more confidence in the safety of the changes, more people feel confident to work on any part of the codebase (vs just the people that originally built it or have worked more on it), and the defect rate dropped dramatically.
jondubois 6y ago
I've moved back and forth between statically typed and dynamically typed languages many times over a couple of decades and I've come to the exact same conclusion as you. People who are equally skilled with both paradigms will prefer dynamically typed languages; simply because there is almost no added value of having static types and in TypeScript's case it's not worth the extra transpilation step and all the problems that it creates. Accidentally mixing incompatible types is mostly a problem for junior developers. I'm much more likely to accidentally put on my pants, socks and shoes in the reverse order in my daily life than mix up incompatible types in my code. The solution is not to add stickers all over your clothes to remind you which way is the front or what order you need to put them on; you don't need more tools, you just need more focus.
cletus 6y ago
Static typing shows you to eliminate the class of tests I like to call “spelling mistakes tests”, something I grew to loathe in Puthon. You have a method called doSomething. You’d better make sure your code isn’t trying to call doSomethign. Compile time errors are much quicker and cheaper to detect and fix than runtime errors.
honkycat 6y ago
"That's just like, your opinion, man." So sick of opinion in this industry. We should not accept such lazy arguments anymore. If you want to make an assertion, back it up. I will make my argument for why types are a good thing below: I don't agree with you. I don't think that loose typing is based on opinion, and I do not think it is because people who start out in statically typed languages are unable to "grasp" loose typing. I think we are seeing a people abandon loose typing because the industry has observed that loose typing is harmful to even small, a few thousand lines, projects. Static typing catches bugs. It makes your code easier to maintain. It makes your code safer to refactor. It checks your code to ensure correctness. It provides documentation about variables. It reduces the amount of code you have to read in order to understand a specific piece of code. These are empirically good things that you do not get in loosely typed languages. An untyped value does not carry any information or explicit assertions about the variable. Take a URL for example: A "string" URL does not carry any information about weather or not the url string is a valid URL. In an untyped environment, only by understanding ALL upstream code are we able to make assumptions about downstream code. We know that the "string URL" is a sequence of characters, and nothing more. However, if we have a type, we can have a "URL" type. Since we have a type, we do not need to concern ourselves with all upstream code, only the code associated with the "URL" type. So, instead of potentially thousands of places to seek information about our "URL" variable, we have only one: The "URL" type. We look at the implementation of that type, and we know weather or not the URL has been validated. Types dramatically reduce the amount of code you have to read in order to understand a given piece of your application. This makes your application more secure, more readable, and easier to maintain.
- luord 6y ago
  > "That's just like, your opinion, man." So sick of opinion in this industry. We should not accept such lazy arguments anymore. Oh, wow, given this unnecessarily combative start, am I about to finally read conclusive proof that will stop that over sixty years old flamewar? > I think we are seeing a people abandon loose typing because the industry has observed that loose typing is harmful to even small, a few thousand lines, projects. People are not abandoning or adopting anything, both static and dynamic typing have existed for as long as computers have been a thing. Hell, LISP is older than pretty much every statically typed language still widely used, methinks. > Static typing catches bugs. It makes your code easier to maintain. It makes your code safer to refactor. It checks your code to ensure correctness. It provides documentation about variables. It reduces the amount of code you have to read in order to understand a specific piece of code. These are empirically good things that you do not get in loosely typed languages. Where's this empiric evidence of all these advantages you mention? I'm a bit shocked that I managed to miss it... And that so did half the industry. Such conclusive study would have ended that and the industry would have coalesced into this unquestionably superior type system you mention. > An untyped value does not carry any information or explicit assertions about the variable. Take a URL for example: A "string" URL does not carry any information about weather or not the url string is a valid URL. Can't do that with static languages either. Call it a type (or class), call it a parsing function, ultimately the result is the same. You need something to ensure that it is an url. Those exist in dynamically typed languages and are not obviated in static ones. > Types dramatically reduce the amount of code you have to read in order to understand a given piece of your application. Conversely, types substantially increase the amount of overall code one has to write. These has never been a matter of opinions. The flamewar still rages after decades because what's the factually best type system hasn't been found. Hell, we might be likely closer to prove that that question has no answer. In short, ultimately everything you said was just, like, your opinion, man.
nsonha 6y ago
The entire comment did not mention testing so it sounds like you never have to continue working on a codebase and eventually face the challenges of refactoring something that you didn't write or remember writing. How about self-documnted code how often do you work with others?
- whoisjuan 6y ago
  I do work with others in non-TS codebases. I think I just been conditioned to think like that. I’m a product of my environment. I know my opinion is biased and after reading many of these comments I understand why people get a lot of value from it. I mean, I have always known that. Otherwise it wouldn’t be as popular. It just happens to be that I have never been exposed to the circumstances that would make me re-evalute TypeScript merits.
rstuart4133 6y ago
Are unit tests a regular habit of yours? If they are, you will remember the time you came to lean on them to make your programming faster. Sure, they are lot of work upfront, but the pay off when when you modify code with units tests later is you feel safer, you write code faster and looser, and yet providing the you keep the unit test habit up the quality is the same or even better. People who use types regularly feel the same way about typed languages. Types don't test as many things of unit tests of course, but feedback you get on what they do test is immediate - literally as you type in a IDE. The speed of that feedback is important. It's a well know in quality circles that errors discovered later cost far more to repair. In the case of types in makes you don't write a hundred lines of code under the expectation a type provides method foo(), only do find out later the foo() provided takes an argument argument you don't happen to having lying around. While payback for types over unit tests is smaller, the effort required to use types is at least commensurately smaller, and the amount of typing required is way smaller, particularly now we have type inference. Also in my experience unit test's need to reach every line of your code forces some pretty tight constraints on how you structure it. Who hasn't had to refactor some block of code so you could test some obscure corner case catering to an unexpected error? Types don't require that - the compiler always sees everything. None of this matters much if you are going to write unit tests anyway of course, but no one does that for small projects. This is another advantage of the type system - it's always there, even for 5 five liner. Finally, types come with an added bonus. They give the compiler more information to work with, which means the compiler can make programs run faster. Rust talks about cost free abstractions, which the extreme case: the compiler knows so much about what you are doing it generates no code at all. In rusts case it rarely has to check for if a pointer references null before accessing, and greatly reduces the number of array bounds checks, has no garbage collector, and the pattern of a function checking the number and type or argument in order to implement overloads just disappears - along with the runtime overhead of doing the checking.

deleted 6y ago

[deleted]

halfmatthalfcat 6y ago

You don’t see the benefits of a strongly typed language?

cheez 6y ago
Python is strongly typed, don't confuse static and strong typing.
- whoisjuan 6y ago
  You’re right.
whoisjuan 6y ago
I do. But not for JS in particular. At the end of the day 95% of JS that is written in classic JS and is used in thousands of high-scale projects like that.
- searchableguy 6y ago
  I would say for me, typechecking part of ts is less useful than the information it provides me about the project. I can jump in a new project and quickly see what kind of data structures are there, what are the parameters, get really nice intellisense and documentation. All of this is possible with jsdocs and flow but they are not nearly as powerful as ts and often times verbose. I don't like polluting the comments. You don't need to use typescript everywhere although the popular zeitgeist will tell you to avoid any or ts-ignore. It's fine to write some parts in ts and others in js. Think of ts as eslint, jsdocs or flow. You don't need to be religious about it. Take its benefits wherever you can or do you think all the other tools are useless as well?

echelon 6y ago

You don't have to write as many tests when you use static typing, because your method contracts are solid. You can refactor your entire codebase with a few operations and don't have to worry about anything breaking. Is your timestamp in seconds? Millis? Is it a duration? Does it have a time zone? Have you ever written a method that returns more than one type of thing? Or had polymorphic inputs? Where are your dynamically dispatched calls even used, and how do you know you modified them all? One of the most common operations in building new features is plumbing new state through the system. Types are there to help you in such perilous times. Types are refreshing and reassuring.

iamleppert 6y ago
Forgive me, but when I program I know what the variables I am working with are doing, and what kind of data they are storing. That’s the least of my problems. I don’t write a big mess of code, I’m constantly working iteratively on a small piece of code to make it perfect. Usually first pass is to make it perfect, then I refactor it right away to make it readable. I work that way, function by function. I never have the class of bugs in my projects that people seem to laud about typing to solve. It’s kind of ridiculous to me and cumbersome and makes certain dynamic programming concepts difficult or impossible. I don’t want to give up power just because other developers are sloppy. I want my code to be readable, and succinct. A lot of times that requires creating functions dynamically at runtime or some other such thing that would void the benefits of a typing system anyways. I recognize that in working with a team where people have other styles, varying attention to detail levels and skill, they can’t all be trusted to produce bug-free code without the constant nagging and overhead of a pedantic type system. My solution is not to employ another piece of technology to solve this problem, rather it’s just not to work with those people. If you can’t write dynamic code without a bunch of type errors at runtime, learn to be a better programmer first before blaming the tools.
- hnarn 6y ago
  > Forgive me, but when I program I know what the variables I am working with are doing, and what kind of data they are storing. That sounds fine, as long as no-one else will ever have to read or work on your code.

efficax 6y ago

your viewpoint might change when you're working on a large project with lots of developers and your system goes down in production because of a type mismatch the compiler could have easily let you know about long before you deployed (i speak from experience). All it takes is once and you'll become a statically typed language evangelist.

mimixco 6y ago

I've been programming for 40 years and I agree. Strong typing has a religious quality. You have to believe that most errors are caused by type mismatch, and I simply don't believe that. Most errors, in my experience, are caused by bad architecture, poor documentation, and poor communications strategies between MVC, etc.

kd913 6y ago
Why is it one or the other? Type errors also certainly occur. If you eliminate a class of errors by doing so, isn't that still less errors overall?
ctrl-j 6y ago
I like typescript not because it prevents most errors in my code, but because it prevents some errors. Those errors, in my experience, tend to be ones that are time consuming to identify and solve. A value of the wrong type passed forward because it's almost the right type can cause errors that make their way into production. I hear you say "so unit test your code!", and to that I reply, we're a c# shop that has only recently started pushing some of our code to the client. If you can convince management that we should shift our paradigm to allow for the time to write tests that don't add much to the sprint we're in, I can send you their email address. The fact is, a large portion of unit tests solve the same problems that strong types solve.
- Rapzid 6y ago
  I've spent more time helping people hunt down "undefined is not a function" and "Cannot read property of undefined" than just about anything else. Two observations from this: 1.) The fact that I even got involved meant the issues were particularly hard to track down 2.) These errors seem to be more of a time sync within a larger team/project than many realize Typically these were caused by either scope issues and/or some context object that's been riding dirty all day. In the case of the latter hunting down the code that did the naughty can be particularly soul crushing.
elmo2you 6y ago
I have a little less experience, only 30 years, but I have to fully agree with you. Not sure why you got down voted (maybe the religious popularity crowd rearing its head). I have seen my share of "innovations" come and go, but I too fail to see the empirical evidence that most bugs/errors are caused by type mismatch. In fact, I would even go as far as to argue that in my experience the benefits of typed languages (and the class of bugs they prevent) do not outweigh the usually larger code size (and often even additional complexity). Maybe I've just tried the wrong languages, but I was never convinced of the great improvements usually promised. At the same time, I have seen other people twist and jump through hoops, while vigorously holding on to their conviction how all that is an improvement. Sure, some errors will move from run time to compile time with typed languages. But if those are a systemic problem in your code, you probably have even bigger things to worry about (the ones you already keenly pointed out). From a cynical point of view, I can understand why corporate entities would love typed languages (for the increased code size and complexity), but that's another story.

ctvo 6y ago

> TS feels like something that was created to lure programmers who couldn’t wrap their heads around JS loose nature. TypeScript adds additional type checking at transpile time to code. The assumption that the people who can write code with these more rigorous checks can't write the same code with it all removed ... I would examine that a little more closely.

AlexMax 6y ago

> TS feels like something that was created to lure programmers who couldn’t wrap their heads around JS loose nature. Almost like it was created to convince Java and C# developers to use JS. On the contrary, as somebody who learned programming with a mix of static and dynamic types, I felt like TypeScript showed me what a good type system was capable of in giving me the best of both worlds. Instead of being pedantry, I felt like the type system was actually on my side for once and helping me to write correct code with fewer unaccounted-for corner cases and unexpected runtime crashes. And it does that while avoiding the feeling I got from previous statically-typed languages I used where the type system felt like a straight jacket incapable of expressing non-trivial concepts and relationships.

whoisjuan 6y ago
Perhaps one reason why I feel like I do about it is that I write a lot of prototype code and maybe sub-consciously it makes me feel like I’m losing speed.

meowzero 6y ago

I've developed with JS, PHP, and Ruby for about 5 years. Then I switch to statically type languages for the next 5 years (Scala then to Typescript). If I had to choose, I would choose static typing. For small projects, dynamically typed languages are fine. but as the project grows bigger, the static typing will help and will make thing simpler. As the project grows, refactoring will be an issue. Static typing will make it simpler to refactor. Tests are smaller. Reading the code will be easier since you know the contract of functions. Fewer runtime errors since most errors will be caught at compile time. Also, the stronger the type system it is, the more it will be caught at compile time. I don't think it slows me down that much. It's a little more typing, and there is compile time overhead. In some cases, you have to work your way around the type system. But at least with Scala, I am confident my code will work as intended as long as it compiles successfully. I spend less time debugging in runtime and writing tests. I think static typing might save time in the long run but not short run.

say-vagnes 6y ago
Hey, I've also made the trip from Scala to Typescript. We're talking ZIO and Shapeless wrangling. Twitter vs Scala futures. All that fun stuff (and I loved scala nonetheless). Would love to know how your journey was. At first I was super hesitant, but now I am actually floored at the power Typescript has. The ability to tell the compiler to simply "trust me" has enabled me to build many abstractions I'd battle for hours to do in Scala.
- mbo 6y ago
  Hey, same situation! As the resident rabid FP evangelist at work, people are often surprised by how much I like like TypeScript. Personally, I think structural typing systems are the path forward for functional languages, and that means accepting that Haskell needs to go to move on to a retirement home. I was pleasantly surprised by how well Scala did subtyping with ZIO's `Has` + variance annotations. Shame TypeScript is bivariant with function parameters.
  - kingdomcome50 6y ago

tengbretson 6y ago

The thing I have found the most useful with typescript is that it punishes you for doing the kind of cutesy stuff that permeated the node ecosystem in the early days. "Pass in three parameters with a callback in the fourth position. The second param is configuration so pass in a string, but if you need to really customize stuff actually pass in an object instead and by the way if you don't have a third parameter then just chuck the callback there, why not!?" Typescript is great in that somehow it is technically possible to write types for existing code written like this, but writing new code like that is cumbersome enough to prevent it.

pragmatic 6y ago
Actually, you can "type" that call. But I always found the "giant ball if config" style painful. For example, I believe it was done data table library that took over a page of config options to get set up. The problem is, you'd have to have the documentation open to make the slightest tweak to anything. No help from the type system.
Rapzid 6y ago
Yes! My pet peeve with public APIs are DTOs that are like this! "This is an array of strings, but it could be an object. If it's an object it will have this key and based on the name of the key it's this type. But it could also have or not have this other key and..." ARghhhh! You can tell what kinda language the back-end was written in with that crap because while TypeScript can actually type most of that stuff it's a huge mess in something like C#, Golang, Java, etc.

qppo 6y ago

I'm not a huge fan of TS not because I don't appreciate types but because I don't feel like it gives me any real type safety. Not due to the language itself but because I have to connect whatever I write to something else, and I wind up writing the type checking myself. It's the same BS as Python and JS, the lack of typing but fundamental nature of systems that require data to be typed means half my code is checking that everything is properly typed! Dynamic types have their uses, but in general they're more trouble than just writing typed code to begin with. And when your type system is more a suggestion than anything it provides little benefits.

kthejoker2 6y ago

> TS feels like something that was created to lure programmers who couldn’t wrap their heads around JS loose nature. Almost like it was created to convince Java and C# developers to use JS. This is true, and confirmed by the TypeScript team https://stackoverflow.blog/2020/06/15/talking-typescript-with-ryan-cavanaugh/ https://stackoverflow.blog/2020/06/15/talking-typescript-wit... > Do you remember why the team came up with TypeScript, why you wanted to release something like this? > A: When I joined the team, there were a lot of people at Microsoft who wanted to develop JavaScript at what we call “application scale.” Teams like TFS and Office wanted to build large JavaScript applications. A lot of those people had familiarity with statically-typed languages— C++, C#, Java, that kind of thing. They wanted to have that static typing available both for conceptual scalability and for the tooling. > The language experts at Microsoft looked at the situation and said, well, we could try to write a new language like people had done before. There are projects like Script#, which takes C sharp and turns it into JavaScript, or languages like CoffeeScript that said, what if JavaScript had a different syntax? But what they decided instead was to just take JavaScript and add static types on top of that. > At the time, JavaScript was experiencing a renaissance of growth, where they were adding features to the language again for the first time in a pretty long time. People wanted to use those cool new features, like arrow functions and classes, and they didn’t want to wait for all browsers to adopt them. They wanted to be able to use those features right away. I think those were the three things that TypeScript offered upfront: static typing for error finding purposes, leveraging that static type information for tooling, and providing the JavaScript features of tomorrow, today.

Rapzid 6y ago
> TS feels like something that was created to lure programmers who couldn’t wrap their heads around JS loose nature Seriously? > They wanted to have that static typing available both for conceptual scalability and for the tooling Sounds like they understood the loose nature pretty darn well.

hota_mazi 6y ago

What you call "Javascript's loose nature" I call a minefield of behaviors and semantics that make writing correct Javascript code so incredibly challenging. I use Typescript everywhere I need Javascript these days, it's a breath of fresh air, and my code feels maintainable, tractable, and much easier to refactor.

IBCNU 6y ago

+100 I'm on your team, 100% agree with your points, TS is a waste of time and I'm encouraging my team to drop it.

kumarvvr 6y ago

> who couldn’t wrap their heads around JS loose nature Ultimately, for any serious work, especially enterprise level work, your team members may include people of different calibers. In such a case, where you have to work with code written by other members of your team, it becomes a serious problem to develop quality code. For lone developers, it should not be a problem. But in enterprise settings, I think that is the reason why Node is not popular.

preek 6y ago

Thank you for the bold statement. I feel the same. I’m at home with Clojure, and Ruby. The same paradigms map well to JS. For the last 9 years, I have been a lecturer at the university of applied sciences in Zurich, Switzerland. In that time, I saw more and more students coming from Java and C# to JS. They like TS a lot. And it’s obvious why. Having said that, I know no “old” programmer who used to prefer a different paradigm to express a wish to switch to TS. Rich Hickey put it well in this quote “ Functional programs are desirable because they are simpler and easier to reason about, due to being mathematical i.e. they are free of time and place.”. I agree.

Kinrany 6y ago
That quote is not really relevant: TS is as functional as JS.
- preek 6y ago
  Not really in the same way, though. I mentioned that paradigms of functional programming languages like Clojure translate well to JavaScript. They do not to typescript, because it is a statically typed language. If you are interested in why are you dynamically typed language has benefits for functional programming, please see this talk: https://youtu.be/oytL881p-nQ https://youtu.be/oytL881p-nQ
  - rendall 6y ago
    Typescript typing is fundamentally optional, so this criticism, even if true regarding statically typed languages, does not apply to Typescript. Typing is optional both for individual variables via the `any` type, and compiler-wide, by configuring it to assume untyped variables are `any` by default.
  - Kinrany 6y ago
    That talk is not about the benefits of dynamically typed languages over statically typed languages. Do you have a specific point in mind?

kiliancs 6y ago

It's sad that you have to be worried about downvotes for an opinion. I disagree, though. Instead of going with a lengthy list of why I think TS is great and disproving your arguments, which I assume everyone else will do, I'll admit that types can be hard, and so doing them right, or even doing them as best as one can, will always take some time. For a small project or a small team, that time might be hard to justify. But I think this is resolved with a good understanding TypeScript. Even so, TypeScript might not make sense for many projects or small teams, but I find it hard to defend that TypeScript won't be a net win for any medium team or medium-size project. This was my believe before, but I've seen multiple teams go from JS to Flow or TypeScript and the result has always been, when there's expert guidance, extremely positive. Productivity goes up, more bugs are fixed because there's more confidence in the safety of the changes, more people feel confident to work on any part of the codebase (vs just the people that originally built it or have worked more on it), and the defect rate dropped dramatically.

jondubois 6y ago

I've moved back and forth between statically typed and dynamically typed languages many times over a couple of decades and I've come to the exact same conclusion as you. People who are equally skilled with both paradigms will prefer dynamically typed languages; simply because there is almost no added value of having static types and in TypeScript's case it's not worth the extra transpilation step and all the problems that it creates. Accidentally mixing incompatible types is mostly a problem for junior developers. I'm much more likely to accidentally put on my pants, socks and shoes in the reverse order in my daily life than mix up incompatible types in my code. The solution is not to add stickers all over your clothes to remind you which way is the front or what order you need to put them on; you don't need more tools, you just need more focus.

cletus 6y ago

Static typing shows you to eliminate the class of tests I like to call “spelling mistakes tests”, something I grew to loathe in Puthon. You have a method called doSomething. You’d better make sure your code isn’t trying to call doSomethign. Compile time errors are much quicker and cheaper to detect and fix than runtime errors.

honkycat 6y ago

"That's just like, your opinion, man." So sick of opinion in this industry. We should not accept such lazy arguments anymore. If you want to make an assertion, back it up. I will make my argument for why types are a good thing below: I don't agree with you. I don't think that loose typing is based on opinion, and I do not think it is because people who start out in statically typed languages are unable to "grasp" loose typing. I think we are seeing a people abandon loose typing because the industry has observed that loose typing is harmful to even small, a few thousand lines, projects. Static typing catches bugs. It makes your code easier to maintain. It makes your code safer to refactor. It checks your code to ensure correctness. It provides documentation about variables. It reduces the amount of code you have to read in order to understand a specific piece of code. These are empirically good things that you do not get in loosely typed languages. An untyped value does not carry any information or explicit assertions about the variable. Take a URL for example: A "string" URL does not carry any information about weather or not the url string is a valid URL. In an untyped environment, only by understanding ALL upstream code are we able to make assumptions about downstream code. We know that the "string URL" is a sequence of characters, and nothing more. However, if we have a type, we can have a "URL" type. Since we have a type, we do not need to concern ourselves with all upstream code, only the code associated with the "URL" type. So, instead of potentially thousands of places to seek information about our "URL" variable, we have only one: The "URL" type. We look at the implementation of that type, and we know weather or not the URL has been validated. Types dramatically reduce the amount of code you have to read in order to understand a given piece of your application. This makes your application more secure, more readable, and easier to maintain.

luord 6y ago
> "That's just like, your opinion, man." So sick of opinion in this industry. We should not accept such lazy arguments anymore. Oh, wow, given this unnecessarily combative start, am I about to finally read conclusive proof that will stop that over sixty years old flamewar? > I think we are seeing a people abandon loose typing because the industry has observed that loose typing is harmful to even small, a few thousand lines, projects. People are not abandoning or adopting anything, both static and dynamic typing have existed for as long as computers have been a thing. Hell, LISP is older than pretty much every statically typed language still widely used, methinks. > Static typing catches bugs. It makes your code easier to maintain. It makes your code safer to refactor. It checks your code to ensure correctness. It provides documentation about variables. It reduces the amount of code you have to read in order to understand a specific piece of code. These are empirically good things that you do not get in loosely typed languages. Where's this empiric evidence of all these advantages you mention? I'm a bit shocked that I managed to miss it... And that so did half the industry. Such conclusive study would have ended that and the industry would have coalesced into this unquestionably superior type system you mention. > An untyped value does not carry any information or explicit assertions about the variable. Take a URL for example: A "string" URL does not carry any information about weather or not the url string is a valid URL. Can't do that with static languages either. Call it a type (or class), call it a parsing function, ultimately the result is the same. You need something to ensure that it is an url. Those exist in dynamically typed languages and are not obviated in static ones. > Types dramatically reduce the amount of code you have to read in order to understand a given piece of your application. Conversely, types substantially increase the amount of overall code one has to write. These has never been a matter of opinions. The flamewar still rages after decades because what's the factually best type system hasn't been found. Hell, we might be likely closer to prove that that question has no answer. In short, ultimately everything you said was just, like, your opinion, man.

nsonha 6y ago

The entire comment did not mention testing so it sounds like you never have to continue working on a codebase and eventually face the challenges of refactoring something that you didn't write or remember writing. How about self-documnted code how often do you work with others?

whoisjuan 6y ago
I do work with others in non-TS codebases. I think I just been conditioned to think like that. I’m a product of my environment. I know my opinion is biased and after reading many of these comments I understand why people get a lot of value from it. I mean, I have always known that. Otherwise it wouldn’t be as popular. It just happens to be that I have never been exposed to the circumstances that would make me re-evalute TypeScript merits.

rstuart4133 6y ago

Are unit tests a regular habit of yours? If they are, you will remember the time you came to lean on them to make your programming faster. Sure, they are lot of work upfront, but the pay off when when you modify code with units tests later is you feel safer, you write code faster and looser, and yet providing the you keep the unit test habit up the quality is the same or even better. People who use types regularly feel the same way about typed languages. Types don't test as many things of unit tests of course, but feedback you get on what they do test is immediate - literally as you type in a IDE. The speed of that feedback is important. It's a well know in quality circles that errors discovered later cost far more to repair. In the case of types in makes you don't write a hundred lines of code under the expectation a type provides method foo(), only do find out later the foo() provided takes an argument argument you don't happen to having lying around. While payback for types over unit tests is smaller, the effort required to use types is at least commensurately smaller, and the amount of typing required is way smaller, particularly now we have type inference. Also in my experience unit test's need to reach every line of your code forces some pretty tight constraints on how you structure it. Who hasn't had to refactor some block of code so you could test some obscure corner case catering to an unexpected error? Types don't require that - the compiler always sees everything. None of this matters much if you are going to write unit tests anyway of course, but no one does that for small projects. This is another advantage of the type system - it's always there, even for 5 five liner. Finally, types come with an added bonus. They give the compiler more information to work with, which means the compiler can make programs run faster. Rust talks about cost free abstractions, which the extreme case: the compiler knows so much about what you are doing it generates no code at all. In rusts case it rarely has to check for if a pointer references null before accessing, and greatly reduces the number of array bounds checks, has no garbage collector, and the pattern of a function checking the number and type or argument in order to implement overloads just disappears - along with the runtime overhead of doing the checking.