4 ms·

How about using Typescript? That still seems like a huge improvement, especially because you can implement it incrementally (aka for parts of code where type ch

How about using Typescript? That still seems like a huge improvement, especially because you can implement it incrementally (aka for parts of code where type checking is vitally important). I'm using it now at my work and I'm surprised how much info I'm getting compared to whatever JS is throwing at me.

gfodor 6y ago
Typescript doesn't strike me as a multi-fold improvement. Dynamic vs static typing is an age-old debate, and in general, advocates can be found arguing that moving your code in either direction results in benefits. So, regardless of your stance on it, it seems unlikely to be unambiguously beneficial. Many large programs exist written in dynamic languages that do just fine.
- throwaway894345 6y ago
  It seems like it's trending toward static, at least recently. I think the big driver for this is the popularization of statically typed languages that aren't C++ and Java. A lot of people had painful experiences with C++ and Java and attributed that pain to static typing. It's now more clear that static typing is a net benefit, but it must be implemented reasonably and it doesn't solve other language design issues. Also, C++ and Java have each evolved some rudimentary type inference, which improves ergonomics (although I think excessive type inference a la Haskell actually makes it harder to debug issues--the sweet spot seems to be function-scoped type inference).
  - gfodor 6y ago
    Hard to say. It seems as cyclic as anything else. Hard to tease apart real benefit from the usual fad/hype cycles. Ruby, Python, Erlang/Elixir, Lisp/Clojure, etc, all doing just fine without it. (Some, with some lightweight annotative-oriented typing for a subset of projects.) The best counterargument to static typing I can articulate is that in general, the only way to be sure software works is to run it. And so, ultimately you need to backstop your software with testing, QA, and observability infrastructure to actually execute it and validate it. At that point, the question is what marginal gains remain from catching a subset of those problems at complile time, also incorporating a potential a false sense of security which may lead to less actual execution validation, and more user-facing issues. The other potential tradeoff of static typing is if the software design and architecture changes for better or worse, or if the velocity of shipping changes changes. I believe there isn't yet any hard evidence of which way this tilts in either case. There's also a lot of innovation in the area of validation-by-execution as well, and so I think that will result in continual debate: state-of-the-art static typing may benefit compared to yesterday's testing/fuzzing tools, but may not compared to state-of-the-art testing/fuzzing tools, for example.
    - pacala 6y ago
      One of the greatest boons of static typing is formal documentation of data structures and interfaces. Catching errors early is a bonus :)
    - mercer 6y ago
      I'm not disagreeing per se, but at least in the Elixir community I get the impression that using Dialyzer (the wonderfully cryptic TS-ish gradual typing solution) and typespecs is increasingly advised and there's a thirst for a better solution. But static typing comes up a lot. We're doing fine without, but it's definitely a sore point and I'm one of those developers who has become more and more fond of static typing.
    - throwaway894345 6y ago
      Python is trending toward types via support for type annotations. My extensive experience with Python and Go leads me to the conclusion that it’s very difficult to write even moderately complex and maintainable Python code at scale. This doesn’t mean that no one can make money with Python—far from it—only that they would make even more money via Go (iterate faster and spend less time fixing bugs). Of course this can’t necessarily be extended to other languages. C++ and Rust would not be as productive up front than Python and C++ would probably not save you any time fixing bugs. A lisp might be faster to develop in than Go and Python without incurring too many type errors. There are too many variables to make sweeping statements, but all else equal, in my experience, static typing is better than dynamic typing. But again, there are many other variables that can cause a dynamically typed language to outperform a statically typed language for iteration velocity or bug reduction.
  - mettamage 6y ago
    Yea, this is why I posted it. To me it seems: - Small codebase. Fine, use both. - Medium codebase. Fine, use both. - Large codebase. You're definitely going to have some typing bugs with dynamically typed languages. - Humongous codebase. You're definitely going to have many typing bugs with dynamically typed languages.
    - throwaway894345 6y ago
      I'll say that we have a small-medium code base and we see lots and lots of dynamic typing errors in production every day. I would also say "even though we have lots of people who are experienced Python developers", but I think it's actually because we have so many developers who have only developed seriously in dynamically typed languages and don't "think in types" if you will.
      - blackrock 6y ago
        Can’t you write the Python functions to force check the input parameter for its type? And error out if not. This should enable you to catch most errors immediately during development.
        mixmastamyk 6y ago
        Yes, but easier to just write tests.
        throwaway894345 6y ago
        And easier still just to use static types.
        mixmastamyk 6y ago
        Often not, if the overhead of adding them outweighs their utility for the project.
        throwaway894345 6y ago
  - oalae5niMiel7qu 6y ago
    The trend toward static typing is a fad, like NoSQL in the early 2010s. Who knows what the next fad will be. Perhaps correctness proofs will make a comeback.
nisten 6y ago
I would avoid doing state management in Typescript. It's still too early in my opinion. Use as many hooks and context as possible and keep your redux store as simple as you possibly can because if you end up with a deprecated state management library (redux-thunk, sagas, easy-peasy) replacing that is like pulling gum out of hair. If you add up the time spent working around typescript errors when dealing with state, it's possible for it to be more time than you need to rewrite the entire app. For backend work then yes, I'd say doing a singleton or an abstract class in typescript makes more sense in hardening your API code and even making it more readable too.
- acemarke 6y ago
  I'm a Redux maintainer, and I'm _strongly_ in favor of using TypeScript for any meaningful app development [0] [1]. Also, I don't know why you're referring to thunks and sagas as "deprecated". Thunks are the recommended default approach for async logic in Redux [2], and we include them out of the box in our Redux Toolkit package [3]. While most apps don't need sagas, they're a great power tool to have in your toolbox. Neither of those is in any way "deprecated". [0] https://blog.isquaredsoftware.com/2019/11/blogged-answers-learning-and-using-typescript/ https://blog.isquaredsoftware.com/2019/11/blogged-answers-le... [1] https://redux.js.org/style-guide/style-guide#use-static-typing https://redux.js.org/style-guide/style-guide#use-static-typi... [2] https://redux.js.org/style-guide/style-guide#use-thunks-for-async-logic https://redux.js.org/style-guide/style-guide#use-thunks-for-... [3] https://blog.isquaredsoftware.com/2020/02/blogged-answers-why-redux-toolkit-uses-thunks-for-async-logic/ https://blog.isquaredsoftware.com/2020/02/blogged-answers-wh...
  - nisten 6y ago
    Sorry I meant as in an older version of a library that an app has been built on and hasn't been updated or maintained for a few months. I should have put that better, the libraries themselves are not deprecated, their dependencies can be. While this negligence problem would be on the fault of the dev team and management for not doing regular package updates it is an all too common issue in many companies. What I am saying is that bad typescript is harder to fix than bad javascript because type errors compound the problems of convoluted code.
kqr 6y ago
In my opinion, if you're going to add a compilation stage to your bundling anyway, you can get far more mileage out of other options (such as Fable) than the tiny improvement TypeScript is. The additional compilation complexity is not worth the small benefits of TypeScript, in my opinion. An even better language, though? I'm in.
- mettamage 6y ago
  Never heard of Fable, will check it out! :D
wegs 6y ago
TypeScript? Erm... Not for me. There were many such systems in the past. CoffeeScript was a big improvement over 2010 JavaScript. Before that was GWT, which was sooo much nicer than 2006-era JavaScript. I could list a bunch of others. If you used any of them, you're now stuck with a legacy system(+), and you'll find fewer and fewer people able to read/write your code, and otherwise. I'm also not a big fan of static typing. And if you do static typing, you should at least do it properly, which is not what TypeScript does. Types should be things like "This is an integer between 0 and 100," "Meters/second," or similar. We've known this for a long time. Ada is now 40 years old and was mandated for military work since if you added feet and inches without a conversion, that was a problem, and that resulted in more robust systems (TypeScript would make them both of type "number" and never catch the error). If you tried to have 120% of your fuel tank full, you'd violate an assertion as well. Those were turned on in dev and in your test suite (but generally turned off in your deployment system, which was running on a 33MHz CPU if you were lucky). C++ templates let you define things like "This is a list of lengths, in meters." Duck types languages like Python won't do this statically, but it's easy enough to do dynamically; while you won't catch errors at compile-time, at run-time, you'll get a clear exception. (+) Standard disclaimers apply.
- rowanG077 6y ago
  Dependently typed language can check at compile time if you violate a ranged integer value among many other things. I'm curious though why you are not a fan of static typing? I feel like if you have a language with inference it's pretty good. I mean you could imagine python with type inference and you could essentially write anything in it you can today (baring stuff like heterogenous data structures) without specifying the type manually.
  - wegs 6y ago
    (1) I like generic code which I can use as I see fit later. In Scheme, I can write: (lambda (x) (* x (+ 3 x))) A half-decade later, someone can take that code, pass a pair of specially-crafted objects to it to introspect what it does, and take a symbolic derivative, pretty-print that derivative with LaTeX, combine it with a few other pieces, and compile it into native code (and yes, that does happen). But a lot of my code is generic in a way where types get in the way. (2) If I do have typing, the type should usually be specified manually, but it should have semantic meaning, not be based on inferring whatever types my programming language happens to have built-in. What's important isn't that something is an integer, but that it's a count-of-apples. I should be able to compare a count-of-apples to a count-of-oranges without first converting them to a count-of-fruit. This is especially important for numerical code, and especially in education. A lot of Scratch tutorials have little kids add a velocity to a position, without first multiplying it by a time. That leads to deep-rooted misconceptions. I don't mind type inference if it's designed to give me feedback. I've seen a few systems (designed for students) which do things like take JavaScript: let x=5; let y="hello"; let z=x+y; And flag that in the IDE. That's kinda nice. And obviously, many systems do optimization at runtime based on inferred types. That's not a problem either. So there's a fuzzy layer in between. But the discussion was about TypeScript, not that fuzzy layer.
pacala 6y ago
Typescript greatest features are optional types and the extensive type inference. On small projects this can work well, but on larger ones I can see overly rigid style guides requiring typing everything explicitly in triplicate becoming cumbersome in an Enterprisey way. Curious what people's experiences are.
mercer 6y ago
Typescript, for me, makes JS jump from 'good enough' to 'might use it even if I have other options'. I still prefer using other languages when I can (back-end), but hypothetically, if I had to choose between Ruby and Typescript I'd actually go for the latter. And I like Ruby!

gfodor 6y ago

Typescript doesn't strike me as a multi-fold improvement. Dynamic vs static typing is an age-old debate, and in general, advocates can be found arguing that moving your code in either direction results in benefits. So, regardless of your stance on it, it seems unlikely to be unambiguously beneficial. Many large programs exist written in dynamic languages that do just fine.

throwaway894345 6y ago
It seems like it's trending toward static, at least recently. I think the big driver for this is the popularization of statically typed languages that aren't C++ and Java. A lot of people had painful experiences with C++ and Java and attributed that pain to static typing. It's now more clear that static typing is a net benefit, but it must be implemented reasonably and it doesn't solve other language design issues. Also, C++ and Java have each evolved some rudimentary type inference, which improves ergonomics (although I think excessive type inference a la Haskell actually makes it harder to debug issues--the sweet spot seems to be function-scoped type inference).
- gfodor 6y ago
  Hard to say. It seems as cyclic as anything else. Hard to tease apart real benefit from the usual fad/hype cycles. Ruby, Python, Erlang/Elixir, Lisp/Clojure, etc, all doing just fine without it. (Some, with some lightweight annotative-oriented typing for a subset of projects.) The best counterargument to static typing I can articulate is that in general, the only way to be sure software works is to run it. And so, ultimately you need to backstop your software with testing, QA, and observability infrastructure to actually execute it and validate it. At that point, the question is what marginal gains remain from catching a subset of those problems at complile time, also incorporating a potential a false sense of security which may lead to less actual execution validation, and more user-facing issues. The other potential tradeoff of static typing is if the software design and architecture changes for better or worse, or if the velocity of shipping changes changes. I believe there isn't yet any hard evidence of which way this tilts in either case. There's also a lot of innovation in the area of validation-by-execution as well, and so I think that will result in continual debate: state-of-the-art static typing may benefit compared to yesterday's testing/fuzzing tools, but may not compared to state-of-the-art testing/fuzzing tools, for example.
  - pacala 6y ago
    One of the greatest boons of static typing is formal documentation of data structures and interfaces. Catching errors early is a bonus :)
  - mercer 6y ago
    I'm not disagreeing per se, but at least in the Elixir community I get the impression that using Dialyzer (the wonderfully cryptic TS-ish gradual typing solution) and typespecs is increasingly advised and there's a thirst for a better solution. But static typing comes up a lot. We're doing fine without, but it's definitely a sore point and I'm one of those developers who has become more and more fond of static typing.
  - throwaway894345 6y ago
    Python is trending toward types via support for type annotations. My extensive experience with Python and Go leads me to the conclusion that it’s very difficult to write even moderately complex and maintainable Python code at scale. This doesn’t mean that no one can make money with Python—far from it—only that they would make even more money via Go (iterate faster and spend less time fixing bugs). Of course this can’t necessarily be extended to other languages. C++ and Rust would not be as productive up front than Python and C++ would probably not save you any time fixing bugs. A lisp might be faster to develop in than Go and Python without incurring too many type errors. There are too many variables to make sweeping statements, but all else equal, in my experience, static typing is better than dynamic typing. But again, there are many other variables that can cause a dynamically typed language to outperform a statically typed language for iteration velocity or bug reduction.
- mettamage 6y ago
  Yea, this is why I posted it. To me it seems: - Small codebase. Fine, use both. - Medium codebase. Fine, use both. - Large codebase. You're definitely going to have some typing bugs with dynamically typed languages. - Humongous codebase. You're definitely going to have many typing bugs with dynamically typed languages.
  - throwaway894345 6y ago
    I'll say that we have a small-medium code base and we see lots and lots of dynamic typing errors in production every day. I would also say "even though we have lots of people who are experienced Python developers", but I think it's actually because we have so many developers who have only developed seriously in dynamically typed languages and don't "think in types" if you will.
    - blackrock 6y ago
      Can’t you write the Python functions to force check the input parameter for its type? And error out if not. This should enable you to catch most errors immediately during development.
      - mixmastamyk 6y ago
        Yes, but easier to just write tests.
        throwaway894345 6y ago
        And easier still just to use static types.
        mixmastamyk 6y ago
        Often not, if the overhead of adding them outweighs their utility for the project.
      - throwaway894345 6y ago
- oalae5niMiel7qu 6y ago
  The trend toward static typing is a fad, like NoSQL in the early 2010s. Who knows what the next fad will be. Perhaps correctness proofs will make a comeback.

nisten 6y ago

I would avoid doing state management in Typescript. It's still too early in my opinion. Use as many hooks and context as possible and keep your redux store as simple as you possibly can because if you end up with a deprecated state management library (redux-thunk, sagas, easy-peasy) replacing that is like pulling gum out of hair. If you add up the time spent working around typescript errors when dealing with state, it's possible for it to be more time than you need to rewrite the entire app. For backend work then yes, I'd say doing a singleton or an abstract class in typescript makes more sense in hardening your API code and even making it more readable too.

acemarke 6y ago
I'm a Redux maintainer, and I'm _strongly_ in favor of using TypeScript for any meaningful app development [0] [1]. Also, I don't know why you're referring to thunks and sagas as "deprecated". Thunks are the recommended default approach for async logic in Redux [2], and we include them out of the box in our Redux Toolkit package [3]. While most apps don't need sagas, they're a great power tool to have in your toolbox. Neither of those is in any way "deprecated". [0] https://blog.isquaredsoftware.com/2019/11/blogged-answers-learning-and-using-typescript/ https://blog.isquaredsoftware.com/2019/11/blogged-answers-le... [1] https://redux.js.org/style-guide/style-guide#use-static-typing https://redux.js.org/style-guide/style-guide#use-static-typi... [2] https://redux.js.org/style-guide/style-guide#use-thunks-for-async-logic https://redux.js.org/style-guide/style-guide#use-thunks-for-... [3] https://blog.isquaredsoftware.com/2020/02/blogged-answers-why-redux-toolkit-uses-thunks-for-async-logic/ https://blog.isquaredsoftware.com/2020/02/blogged-answers-wh...
- nisten 6y ago
  Sorry I meant as in an older version of a library that an app has been built on and hasn't been updated or maintained for a few months. I should have put that better, the libraries themselves are not deprecated, their dependencies can be. While this negligence problem would be on the fault of the dev team and management for not doing regular package updates it is an all too common issue in many companies. What I am saying is that bad typescript is harder to fix than bad javascript because type errors compound the problems of convoluted code.

kqr 6y ago

In my opinion, if you're going to add a compilation stage to your bundling anyway, you can get far more mileage out of other options (such as Fable) than the tiny improvement TypeScript is. The additional compilation complexity is not worth the small benefits of TypeScript, in my opinion. An even better language, though? I'm in.

mettamage 6y ago
Never heard of Fable, will check it out! :D

wegs 6y ago

TypeScript? Erm... Not for me. There were many such systems in the past. CoffeeScript was a big improvement over 2010 JavaScript. Before that was GWT, which was sooo much nicer than 2006-era JavaScript. I could list a bunch of others. If you used any of them, you're now stuck with a legacy system(+), and you'll find fewer and fewer people able to read/write your code, and otherwise. I'm also not a big fan of static typing. And if you do static typing, you should at least do it properly, which is not what TypeScript does. Types should be things like "This is an integer between 0 and 100," "Meters/second," or similar. We've known this for a long time. Ada is now 40 years old and was mandated for military work since if you added feet and inches without a conversion, that was a problem, and that resulted in more robust systems (TypeScript would make them both of type "number" and never catch the error). If you tried to have 120% of your fuel tank full, you'd violate an assertion as well. Those were turned on in dev and in your test suite (but generally turned off in your deployment system, which was running on a 33MHz CPU if you were lucky). C++ templates let you define things like "This is a list of lengths, in meters." Duck types languages like Python won't do this statically, but it's easy enough to do dynamically; while you won't catch errors at compile-time, at run-time, you'll get a clear exception. (+) Standard disclaimers apply.

rowanG077 6y ago
Dependently typed language can check at compile time if you violate a ranged integer value among many other things. I'm curious though why you are not a fan of static typing? I feel like if you have a language with inference it's pretty good. I mean you could imagine python with type inference and you could essentially write anything in it you can today (baring stuff like heterogenous data structures) without specifying the type manually.
- wegs 6y ago
  (1) I like generic code which I can use as I see fit later. In Scheme, I can write: (lambda (x) (* x (+ 3 x))) A half-decade later, someone can take that code, pass a pair of specially-crafted objects to it to introspect what it does, and take a symbolic derivative, pretty-print that derivative with LaTeX, combine it with a few other pieces, and compile it into native code (and yes, that does happen). But a lot of my code is generic in a way where types get in the way. (2) If I do have typing, the type should usually be specified manually, but it should have semantic meaning, not be based on inferring whatever types my programming language happens to have built-in. What's important isn't that something is an integer, but that it's a count-of-apples. I should be able to compare a count-of-apples to a count-of-oranges without first converting them to a count-of-fruit. This is especially important for numerical code, and especially in education. A lot of Scratch tutorials have little kids add a velocity to a position, without first multiplying it by a time. That leads to deep-rooted misconceptions. I don't mind type inference if it's designed to give me feedback. I've seen a few systems (designed for students) which do things like take JavaScript: let x=5; let y="hello"; let z=x+y; And flag that in the IDE. That's kinda nice. And obviously, many systems do optimization at runtime based on inferred types. That's not a problem either. So there's a fuzzy layer in between. But the discussion was about TypeScript, not that fuzzy layer.

pacala 6y ago

Typescript greatest features are optional types and the extensive type inference. On small projects this can work well, but on larger ones I can see overly rigid style guides requiring typing everything explicitly in triplicate becoming cumbersome in an Enterprisey way. Curious what people's experiences are.

mercer 6y ago

Typescript, for me, makes JS jump from 'good enough' to 'might use it even if I have other options'. I still prefer using other languages when I can (back-end), but hypothetically, if I had to choose between Ruby and Typescript I'd actually go for the latter. And I like Ruby!