4 ms·

Types don't make you write better code. In my opinion TS makes writing bad code easier because intellisense. Every TS project I have worked on is as messy as th

Types don't make you write better code. In my opinion TS makes writing bad code easier because intellisense. Every TS project I have worked on is as messy as the JS projects. I have nothing against type systems. I have years of experience with C, C++, and Java. However, I happen to think functional programming is a lot more "game-changing" and TS makes writing functional code more difficult. But hey... types are enterprise so it must be good. I would truly appreciate it if our industry would dedicate more time to training both new and senior devs to write better code instead of chasing the every popular/new language/framework/build-tool that promises to solve all the things.

smt88 5y ago
Your argument against TS is that it makes writing correct code easier? There is no situation where better autocomplete and compiler errors make code worse. Coding should be as easy as possible, and footguns should be almost impossible to introduce. I've been writing code for 20 years, and TS is the first language I used where I would often find 0 runtime errors in my first version of a project. It takes discipline to achieve that, but TS helps with discipline by saving you the overhead of all the other JS nonsense.
- seer 5y ago
  I think I also agree that TS has made js programs harder, but not in a bad way. You see there was a quote back in the day about a discussion between a senior clojure developer and a java one, and it went something like this. Java dev - “How do you know when you refactor your app that if you change something in one place, it will not cause a problem in another distant part of the app, without the compiler to help you” And the clojure dev answers with “why would you ever write an app where one thing in one place changes another thing in another place?” I forgot where it was from though. Anyway the sentiment is that clojure gives you tools to write an app like that where all the things that affect each other are close by, so it is actually possible to write big apps without types. TS on the other hand gives you tools to write a big app where things _can_ affect different places, but you can still manage it. You can “fit” a bigger app in your brain. JS by itself gives you no tools whatsoever so you’re at your own mercy, so you’re either more careful, or don’t write big programs and stay small. Or alternatively invent strategies that help organize things (redux, express, react). TS allows you to ignore all that, write a horrible mess, and still be able to ship and be productive. It makes bigger messes actually possible. Now I’m a huuuge fan of TS myself and never start a frontend project without it. And I also think it can make code, especially functional code much better and easier to reason about. But we’ve lost the natural selection of JS projects. Before TS, if you’ve not setup your project right, with test, structure, policies and processes it was doomed the moment it grew to a certain size. You either stayed small, did it right or failed and refactored. Now … now you can actually keep going for much much longer with just TS helping you. And god forbid the TS wiz that sets it all up leaves and you’re left with untangling a mess. It’s a nicer mess, but a bigger one.
  - tacotacotaco 5y ago
    Yes thank you. This was the point I was trying to make.
- tacotacotaco 5y ago
  No, my argument is that TS makes writing code easier and that easier does not equal to quality [0]. I have been writing code for more than 20 years. Personally, TS doesn't impress me. This is not meant as a criticism. Personally, I have found functional programming to be revelatory. I am shocked that is as been around as long as it has and that our schools don't teach it (or just mention it) and the majority of people in our industry as resistant to it. "No matter what language you work in, programming in a functional style provides benefits. You should do it whenever it is convenient, and you should think hard about the decision when it isn’t convenient." -- John Carmack [1] [0] "Simple Made Easy" Rich Hickey https://www.youtube.com/watch?v=LKtk3HCgTa8 https://www.youtube.com/watch?v=LKtk3HCgTa8 [1] "John Carmack on Functional Programming in C++" http://sevangelatos.com/john-carmack-on/ http://sevangelatos.com/john-carmack-on/
valenterry 5y ago
> Types don't make you write better code. I believe they do. There's the concept of "type-driven programming" for a reason, which is essentially taking test-driven development one step further. But yeah, type-systems can also make things harder - but if you want real functional programming _and_ static typing, then maybe you should look into other languages, on the frontend that would for example be PureScript or ScalaJs.
- garren 5y ago
  This is an excellent point. I just finished reading the book “Domain Modeling mad Functional” [0] and it absolutely opened my eyes in terms of the power of strong types and functional design. I believe that strong types can absolutely help to improve a code base, but they can’t do it alone. And they certainly won’t do much if one only associates strong type systems with intellisense. I agree that a strong type system might make some things harder, but I think that’s because you’re design probably requires a bit more thought up front. I don’t know that I agree with your “real functional programming” statement though. JS lends itself to functional design really well. I don’t use TS, but as a superset of JS, I’d be surprised if it didn’t work as well in an FP design. [0] https://pragprog.com/titles/swdddf/domain-modeling-made-functional/ https://pragprog.com/titles/swdddf/domain-modeling-made-func...
  - valenterry 5y ago
    > I agree that a strong type system might make some things harder, but I think that’s because you’re design probably requires a bit more thought up front. Unfortunately it is rather because, as of now, all but the most advanced & academic type-systems are incapable of solving even basic tasks without getting into the way. Easy examples: Pick a statically typed language of your choice and implement a function, that takes any function A that returns a boolean and returns a new function that is just like A but returns the opposite result. E.g.: fun even(input: Number): Boolean = ... even(2) // true fun opposite(function: ?): ? = ... fun odd = opposite(even) odd(2) // false What are the types of the two question-marks? Or: Try to write a function that executes SQL and, based on the SQL, returns a proper return type that contains type-information about what will be returned. Then write a function that can model joins of two of these SQLs. I.e. the compiler must be able to calculate a new type structure, based on two other type structures. Or: Implement a function that "slides" over a list and the sliding size window can be configured. E.g.: fun sliding(size: Number, list: List[String], function: ? => ...) = ... list = List("a", "b", "c", "d", "e") sliding(2, list, (window: ?) => print(window)) // prints (a, b) then (b, c) then (c, d) ... sliding(3, list, (window: ?) => print(window)) // prints (a, b, c) then (b, c, d) then (c, d, e) ... What is the type of the value that will be passed to function: ? => ... The type must depend on the given window-size. But almost all type-system fail to make this possible. Only so called value-dependent type-systems can do that, and some other's that have built-in special features for specific use-cases, but fail to generalize them (e.g. looking at you typescript).
garren 5y ago
Could you elaborate on your statement that intellisense is associated with bad code? Intellisense is available for just about every language under the sun, so clearly this isn’t a TS specific issue. Even dynamically typed FP langs have pretty solid language servers these days. You also seem to suggest that FP and types are somehow opposites. What are your thoughts on a strongly typed functional language like Haskell, Idris, or an ML-derivative? Regarding your thoughts that TS makes FP more difficult, more than, say, C++ or Java? I’ve found that one can write FP style code in just about any language, though some obviously make it easier than others. I don’t use TS, but I would have thought that its JS roots and then fact that it’s fairly flexible regarding how strictly one can adhere to its type system, would lend itself to an FP style well.
- tacotacotaco 5y ago
  Again, I have nothing against type systems. As you pointed out some languages make FP easier than others. C++ and Java's type system, from which TS's type system descends, are not FP languages. You _can_ write functionally but they do not afford much ease. Intellisense does make code easier to write, good code and bad code. Yes, in all languages. My concern is that every colleague I have spoken with about TS conflates this ease of writing code with better code. It's not. They are still writing highly coupled, imperative code but now with types. Garren pointed out in another comment the book "Domain Modeling Made Functional" which I have read and have recommended to several other devs. It provides a great example of using type system effectively. While TS's type system isn't quite the same as F# I think a good portion of this book still applies, both types and composition. JS will be getting a pipeline operator and pattern matching in the near future. I expect TS will be updated to support them. This makes FP more relevant.
flippinburgers 5y ago
What is functional programming without a type system.
machiaweliczny 5y ago
How TS makes functional code harder?
- gherkinnn 5y ago
  Typing curried functions is hard. Ramda can't get it quite right. https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/ramda https://github.com/DefinitelyTyped/DefinitelyTyped/tree/mast...
bichiliad 5y ago
I agree with you that our industry should spend more time training frontend engineers. Frontend is often treated as an afterthought, which ends up being very costly in the long run. That being said, the addition of types was definitely not us chasing a popular framework. Etsy adopts tech really, really slowly. We had a pretty specific set of problems that types had traditionally solved in many other areas of the stack, so we evaluated JavaScript type systems and decided on TypeScript. I don’t really think the “types make bad code, functional programming makes good code” argument here is made in good faith — there are good and bad codebase using any paradigm you can think of. Give TS a try, or at least let me answer some of your specific concerns about it.
- tacotacotaco 5y ago
  I have worked on several TS projects. None of them were good IMO. I'm not blaming TS. I've seen numerous bad JS projects also. I'm not passing judgment on Etsy's code, only sharing my experience. You are correct, there is good and bad code written in all paradigms. My point was that the energy we (as an industry) employ marketing, migrating, and educating on new languages/frameworks/tools might yield more substantial results if we focused on fundamentals.
zaccusl 5y ago
"Types don't make you write better code." I'm going to disagree with this big time. Types allow much easier refactoring. I can refactor a large TypeScript in a few hours that wouldn't even be possible in a few weeks in JavaScript. This makes continuously improving code so much easier. It also allows rapid iteration during development. I can change function signatures and object shapes to improve my code, and even if those functions and objects are used prolifically throughout my source, I can do the updates in a few minutes. Compared to JavaScript where many time I'm like "this would be so much easier if this function took a different parameter and this object was required to have this field, but it would take me 12 hours to change and even then there might be places I miss." Even competent unit testing doesn't save you from these situations. I remember the 2015 JS conf when Douglas Crockford listed "patterns" to "help" with the aforementioned issues but really didn't do much. Then went on to say "real" developers don't need TypeScript even though TypeScript SOLVED every issue he mentioned he was trying to solve. I had to shake my head that day.

smt88 5y ago

Your argument against TS is that it makes writing correct code easier? There is no situation where better autocomplete and compiler errors make code worse. Coding should be as easy as possible, and footguns should be almost impossible to introduce. I've been writing code for 20 years, and TS is the first language I used where I would often find 0 runtime errors in my first version of a project. It takes discipline to achieve that, but TS helps with discipline by saving you the overhead of all the other JS nonsense.

seer 5y ago
I think I also agree that TS has made js programs harder, but not in a bad way. You see there was a quote back in the day about a discussion between a senior clojure developer and a java one, and it went something like this. Java dev - “How do you know when you refactor your app that if you change something in one place, it will not cause a problem in another distant part of the app, without the compiler to help you” And the clojure dev answers with “why would you ever write an app where one thing in one place changes another thing in another place?” I forgot where it was from though. Anyway the sentiment is that clojure gives you tools to write an app like that where all the things that affect each other are close by, so it is actually possible to write big apps without types. TS on the other hand gives you tools to write a big app where things _can_ affect different places, but you can still manage it. You can “fit” a bigger app in your brain. JS by itself gives you no tools whatsoever so you’re at your own mercy, so you’re either more careful, or don’t write big programs and stay small. Or alternatively invent strategies that help organize things (redux, express, react). TS allows you to ignore all that, write a horrible mess, and still be able to ship and be productive. It makes bigger messes actually possible. Now I’m a huuuge fan of TS myself and never start a frontend project without it. And I also think it can make code, especially functional code much better and easier to reason about. But we’ve lost the natural selection of JS projects. Before TS, if you’ve not setup your project right, with test, structure, policies and processes it was doomed the moment it grew to a certain size. You either stayed small, did it right or failed and refactored. Now … now you can actually keep going for much much longer with just TS helping you. And god forbid the TS wiz that sets it all up leaves and you’re left with untangling a mess. It’s a nicer mess, but a bigger one.
- tacotacotaco 5y ago
  Yes thank you. This was the point I was trying to make.
tacotacotaco 5y ago
No, my argument is that TS makes writing code easier and that easier does not equal to quality [0]. I have been writing code for more than 20 years. Personally, TS doesn't impress me. This is not meant as a criticism. Personally, I have found functional programming to be revelatory. I am shocked that is as been around as long as it has and that our schools don't teach it (or just mention it) and the majority of people in our industry as resistant to it. "No matter what language you work in, programming in a functional style provides benefits. You should do it whenever it is convenient, and you should think hard about the decision when it isn’t convenient." -- John Carmack [1] [0] "Simple Made Easy" Rich Hickey https://www.youtube.com/watch?v=LKtk3HCgTa8 https://www.youtube.com/watch?v=LKtk3HCgTa8 [1] "John Carmack on Functional Programming in C++" http://sevangelatos.com/john-carmack-on/ http://sevangelatos.com/john-carmack-on/

valenterry 5y ago

> Types don't make you write better code. I believe they do. There's the concept of "type-driven programming" for a reason, which is essentially taking test-driven development one step further. But yeah, type-systems can also make things harder - but if you want real functional programming _and_ static typing, then maybe you should look into other languages, on the frontend that would for example be PureScript or ScalaJs.

garren 5y ago
This is an excellent point. I just finished reading the book “Domain Modeling mad Functional” [0] and it absolutely opened my eyes in terms of the power of strong types and functional design. I believe that strong types can absolutely help to improve a code base, but they can’t do it alone. And they certainly won’t do much if one only associates strong type systems with intellisense. I agree that a strong type system might make some things harder, but I think that’s because you’re design probably requires a bit more thought up front. I don’t know that I agree with your “real functional programming” statement though. JS lends itself to functional design really well. I don’t use TS, but as a superset of JS, I’d be surprised if it didn’t work as well in an FP design. [0] https://pragprog.com/titles/swdddf/domain-modeling-made-functional/ https://pragprog.com/titles/swdddf/domain-modeling-made-func...
- valenterry 5y ago
  > I agree that a strong type system might make some things harder, but I think that’s because you’re design probably requires a bit more thought up front. Unfortunately it is rather because, as of now, all but the most advanced & academic type-systems are incapable of solving even basic tasks without getting into the way. Easy examples: Pick a statically typed language of your choice and implement a function, that takes any function A that returns a boolean and returns a new function that is just like A but returns the opposite result. E.g.: fun even(input: Number): Boolean = ... even(2) // true fun opposite(function: ?): ? = ... fun odd = opposite(even) odd(2) // false What are the types of the two question-marks? Or: Try to write a function that executes SQL and, based on the SQL, returns a proper return type that contains type-information about what will be returned. Then write a function that can model joins of two of these SQLs. I.e. the compiler must be able to calculate a new type structure, based on two other type structures. Or: Implement a function that "slides" over a list and the sliding size window can be configured. E.g.: fun sliding(size: Number, list: List[String], function: ? => ...) = ... list = List("a", "b", "c", "d", "e") sliding(2, list, (window: ?) => print(window)) // prints (a, b) then (b, c) then (c, d) ... sliding(3, list, (window: ?) => print(window)) // prints (a, b, c) then (b, c, d) then (c, d, e) ... What is the type of the value that will be passed to function: ? => ... The type must depend on the given window-size. But almost all type-system fail to make this possible. Only so called value-dependent type-systems can do that, and some other's that have built-in special features for specific use-cases, but fail to generalize them (e.g. looking at you typescript).

garren 5y ago

Could you elaborate on your statement that intellisense is associated with bad code? Intellisense is available for just about every language under the sun, so clearly this isn’t a TS specific issue. Even dynamically typed FP langs have pretty solid language servers these days. You also seem to suggest that FP and types are somehow opposites. What are your thoughts on a strongly typed functional language like Haskell, Idris, or an ML-derivative? Regarding your thoughts that TS makes FP more difficult, more than, say, C++ or Java? I’ve found that one can write FP style code in just about any language, though some obviously make it easier than others. I don’t use TS, but I would have thought that its JS roots and then fact that it’s fairly flexible regarding how strictly one can adhere to its type system, would lend itself to an FP style well.

tacotacotaco 5y ago
Again, I have nothing against type systems. As you pointed out some languages make FP easier than others. C++ and Java's type system, from which TS's type system descends, are not FP languages. You _can_ write functionally but they do not afford much ease. Intellisense does make code easier to write, good code and bad code. Yes, in all languages. My concern is that every colleague I have spoken with about TS conflates this ease of writing code with better code. It's not. They are still writing highly coupled, imperative code but now with types. Garren pointed out in another comment the book "Domain Modeling Made Functional" which I have read and have recommended to several other devs. It provides a great example of using type system effectively. While TS's type system isn't quite the same as F# I think a good portion of this book still applies, both types and composition. JS will be getting a pipeline operator and pattern matching in the near future. I expect TS will be updated to support them. This makes FP more relevant.

flippinburgers 5y ago

What is functional programming without a type system.

machiaweliczny 5y ago

How TS makes functional code harder?

gherkinnn 5y ago
Typing curried functions is hard. Ramda can't get it quite right. https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/ramda https://github.com/DefinitelyTyped/DefinitelyTyped/tree/mast...

bichiliad 5y ago

I agree with you that our industry should spend more time training frontend engineers. Frontend is often treated as an afterthought, which ends up being very costly in the long run. That being said, the addition of types was definitely not us chasing a popular framework. Etsy adopts tech really, really slowly. We had a pretty specific set of problems that types had traditionally solved in many other areas of the stack, so we evaluated JavaScript type systems and decided on TypeScript. I don’t really think the “types make bad code, functional programming makes good code” argument here is made in good faith — there are good and bad codebase using any paradigm you can think of. Give TS a try, or at least let me answer some of your specific concerns about it.

tacotacotaco 5y ago
I have worked on several TS projects. None of them were good IMO. I'm not blaming TS. I've seen numerous bad JS projects also. I'm not passing judgment on Etsy's code, only sharing my experience. You are correct, there is good and bad code written in all paradigms. My point was that the energy we (as an industry) employ marketing, migrating, and educating on new languages/frameworks/tools might yield more substantial results if we focused on fundamentals.

zaccusl 5y ago

"Types don't make you write better code." I'm going to disagree with this big time. Types allow much easier refactoring. I can refactor a large TypeScript in a few hours that wouldn't even be possible in a few weeks in JavaScript. This makes continuously improving code so much easier. It also allows rapid iteration during development. I can change function signatures and object shapes to improve my code, and even if those functions and objects are used prolifically throughout my source, I can do the updates in a few minutes. Compared to JavaScript where many time I'm like "this would be so much easier if this function took a different parameter and this object was required to have this field, but it would take me 12 hours to change and even then there might be places I miss." Even competent unit testing doesn't save you from these situations. I remember the 2015 JS conf when Douglas Crockford listed "patterns" to "help" with the aforementioned issues but really didn't do much. Then went on to say "real" developers don't need TypeScript even though TypeScript SOLVED every issue he mentioned he was trying to solve. I had to shake my head that day.