17 ms·

Porting to a typed language helped prevent type errors in a typeless language. Who woulda thunk? I am currently also working on a project written in a JS backe

Porting to a typed language helped prevent type errors in a typeless language. Who woulda thunk? I am currently also working on a project written in a JS backend that's slowly porting to TS, for the same reasons, but I still would prefer to go back to C# and take it a level further. I just don't enjoy the TypeScript language all that much.

smt88 7y ago
> Porting to a typed language helped prevent type errors in a typeless language. Who woulda thunk? You say this sarcastically, but every JS-related thread on HN turns into a flamewar between type lovers and haters. The type haters make exactly the argument you're mocking: that typeless languages do not result in more type errors. Their reasoning is along the lines of, "I don't need a type system because I'm a professional and don't make mistakes." That sounds laughable or like an exaggeration, but it's a surprisingly common line of thinking. The buggiest code I ever worked on was a PHP code base written by someone who had been coding for 20 years and had a Master's in CS. Before I inherited the code, he told me, "I code in the terminal. I don't need IDE features because I don't really make mistakes in PHP anymore." Again, seems satirical, but not uncommon.
- giulianob 7y ago
  Those people are also missing the point that not having types means you are inherently writing a slow program.
  - diggan 7y ago
    That's the first time I heard that any language that doesn't have types, is slower than a program with types. I'm unsure if that actually makes sense. You mean slower as in performance? I'm having a hard time understanding how types == performance, so you have to mean something else. I guess assembly would be the language you would use if you really need to squeeze out the maximum amount of performance of a single CPU, and as far as I know, it does not have types. Also languages built on top of LLVM could get by with trading compile times for run time performance. Maybe you meant compiling gets slower without types?
    - Arnavion 7y ago
      Strong typing means that at runtime dynamic behaviors don't need to be accounted for. For a compiled language, the compiler could know that `foo` and `bar` are 32-bit integers, and thus compile `foo + bar` to call the addition function for 32-bit integers. In an interpreted language, the interpreter could do the same thing. Without that typing information, both would have to invoke a generic addition function that detects the types of its arguments at runtime, notices they're both 32-bit integers, and delegates to the corresponding addition function. Of course there are tricks that can be played in the weakly-typed case, like assuming the same call site will always have the same types, so that there can be a short path that assumes that and only branches rarely. That way the first or first few executions might be slow, but eventually they get almost as fast as the statically-typed case. JS engines in particular and JITted runtimes in general usually do this. >I guess assembly would be the language you would use if you really need to squeeze out the maximum amount of performance of a single CPU, and as far as I know, it does not have types. Assembly absolutely does have types. The addition function for 32-bit ints only operates on 32-bit ints, and is distinct from the addition function for 64-bit ints.
      - mr_toad 7y ago
        > Assembly absolutely does have types. The addition function for 32-bit ints only operates on 32-bit ints You can add any bits that will fit in the relevant registers. Assembly cares not whether the programmer thinks they are ints.
        Arnavion 7y ago
        You should read the part of the sentence you cut off in your quote.
    - jbboehr 7y ago
      Dynamically typed languages still have types internally, they just look like this [0] (imagine it all implemented in assembly, without C's types, if you prefer). [0]: https://github.com/php/php-src/blob/3709e74b5e495e210ada8039ed81fafa9cbadcdb/Zend/zend_types.h#L282-L328 https://github.com/php/php-src/blob/3709e74b5e495e210ada8039...
  - dang 7y ago
    Please don't post grand unsubstantive claims to flamewar topics. That's bomb-throwing and usually leads to silly explosions.
    - giulianob 7y ago
      Really look at any significant benchmark or what types of projects use which languages. The evidence is extremely clear and makes sense due to how computers work.
      - dang 7y ago
        Please just stop.
      - tln 7y ago
        The language in question, TypeScript, runs exactly as fast as JavaScript!
        blast 7y ago
        I want to just post "Lol" but that will get flagged, so instead I will thank you for finding the optimal refutation.
  - Roboprog 7y ago
    That was certainly true in 1990. The use of JITs has changed that to a large extent, as frequently used code paths can be rewritten at runtime in many cases. Static types tend to push people towards copy-pasta code, as well, which can even work against performance.
  - smt88 7y ago
    The factors affecting program speed are numerous, and I would guess that types do not have nearly the greatest effect. Most of us are not optimizing for program speed. Machine time is cheap. Human time is expensive. The biggest cost-savers for most programmers will be the ergonomics of a language, not the optimizations available to the compiler.
  - mr_toad 7y ago
    So assembly code is slow?
- diggan 7y ago
  > Their reasoning is along the lines of Now I'm sure that many feel like that, but I don't think it's the majority, but I also don't know. Here are some more arguments against types (don't necessarily agree with all of them myself, but for reference in the future when you want to write from the perspective of someone who feels more productive without types): - There are other, more flexible ways to solve the same problems you solve with typing, the clojure.spec way is one of them - You lose flexibility when suddenly everything is locked to each other by name. Even if Account and Person both has a first and last name fields, you can't use both of them if the function is expecting a Account and only use the first and last name. Then you need to add an interface, name it something, then make Account and Person be based on that. Now the function is locked to the interface, and so on - Type checking is a very basic form of testing that doesn't solve the most common, annoying and hard-to-track down bugs, logic bugs. - Metaprogramming becomes harder. Not impossible, just harder. - Types (at least in TypeScript and other languages I've been using in the past) disappear in runtime, so you can't really use them. It's just a tool for you to tell the compiler what something is so it can say "no, you did wrong here" Now I'm neither a type lover nor hater. I just want to use the right solution for the right problem, sometimes, that's making a program that will take longer time to write but specification is set in stone and requirements won't change, so types will help you a lot. Other times, it's in a very dynamic and experimental environment where you have to be able to apply changes as quickly as possible and minor errors don't matter as much, as long as you can move forward fast and test theories. Then you can go back and refactor things.
  - jakear 7y ago
    > You lose flexibility when suddenly everything is locked to each other by name. TS uses structural typing.
    - diggan 7y ago
      That's good, compared to the nominative type systems, on that point at least! I'm just trying to help the person I'm replying to to see more arguments in favor of dynamic systems without types, not necessarily straightly aimed at TypeScript as they mainly mentioned just types.
- woah 7y ago
  How can you call yourself a programmer if you need a type system babysitting you? EDIT: my apologies to anyone who did not realize this was satirical
- greglindahl 7y ago
  > The type haters make exactly the argument you're mocking Funny, I usually see type haters claiming that they don't actually make the kinds of mistakes that are fixed by strong typing. Which is a completely different sentiment.
  - netghost 7y ago
    I think the more nuanced point folks tend to make is that they catch the errors at Run Time instead of Compile Time, and that the cost of strict typing is greater than that of catching it at Run Time. Personally, I'm agnostic (I make mistakes in all phases and fix most of them eventually ;) )
    - greglindahl 7y ago
      I agree that people make that point, and I agree that it's a good one. But it's irrelevant to this sub-thread, which started with me attempting to convince smt88 that they were misrepresenting the opinion of the people they were laughing at.
  - nohuhu 7y ago
    > Funny, I usually see type haters claiming that they don't actually make the kinds of mistakes that are fixed by strong typing. As your typical type hater, my preferred argument is: yes, static typing prevents a certain class of bugs from happening; no, this class of bugs is not nearly as relevant as type lovers seem to be claiming. By an order of magnitude if not more. Source: 6 years of being a core developer of a front end framework consisting of 1,500,000 lines of ES5 JavaScript and SASS.
    - me_again 7y ago
      I'm having a hard time picturing a 1.5M LOC front end Javascript framework. Can you tell us more?
      - smt88 7y ago
        I would have to assume GP used "framework" differently than you understood it. They may have meant "foundational code of an app".
- dang 7y ago
  That of course is not the argument at all. The argument is that the cost of working with static types exceeds the benefits. Finding type errors is obviously a benefit, while not finding them (or finding them only at runtime) is a cost. The question is what other costs and benefits there are, and how to compare them. Nobody agrees on that, nor ever will. This argument will never be resolved because it's dominated by psychological factors. Once you've adapted to environment A, A's costs (e.g. hoops the compiler makes you jump through / time spent tracking down type errors) become habitual and you don't notice them anymore. Meanwhile the costs of unfamiliar environment B are extremely highlighted in your attention. Similarly, if you like and identify with A, its benefits will be top-of-mind for you, while if you don't like B (and nobody likes B), you'll discount its benefits. It gets worse. Sometimes benefits are costs until you make it through a learning curve. An example is parentheses in Lisp. They stick out like a sore thumb until one day they don't. Later you realize that they were a liberating force all along, and you now have anti-gravity powers you never dreamt of. (<-- This is an example of how people talk when they are adapted to an environment whose costs they no longer count and whose benefits are top-of-mind for them.) We can't even agree on what the costs and benefits are, let alone how to measure them. It's no wonder that people feel so strongly about this dispute. When you don't count the costs of your preferred environment, and only count the benefits, it gets obvious pretty quickly that other people are idiots. For some reason the idiots feel the opposite and perversely insist on it. It gets worse. Imagine that you're a decent, fairminded sort and so, magnanimously as is your wont, you decide to give the idiots a fair shake—you know, just to verify that you're being fair and whatnot. You fire up whatever it is (Clojure? OCaml? needless to say, you make a charitable choice) and start programming for a while. What happens? All the costs of unfamiliarity hit you in the face. Not one of the benefits that has lived at the top of your mind for years is anywhere to be seen. This thing doesn't even catch trivial type errors at compile time! / I can't even execute this bit of code in a REPL! This is a painful experience. It can even be an enraging one, for example if you are forced for some extraneous reason to work on a system you didn't create using tools you don't like. Most people who go through that experience once have their views solidified for life. Meanwhile someone else had the opposite experience. Given how passionately people feel about this and the certainty in forum threads about it, it's curious (or maybe to be expected) that the question of published evidence comes up so rarely. HN user luu did the definitive survey on this: https://danluu.com/empirical-pl/ https://danluu.com/empirical-pl/. The short version is that such studies as there are don't address the core question and/or find insignificant effects and/or their designs tip obviously to one side or the other (and I do mean obviously, like comparing Peter Norvig's code to that of random undergrads). Bias dominates every other factor, put together, times at least 10. As long as that's true, we can't say anything rational without genuinely accounting for bias. Do we actually know how to do that? The studies don't seem able to. These debates certainly don't, nor do they try. Maybe the interesting phenomenon here is actually the bias itself. Maybe it's not that we like an environment because we're more productive in it, but that we're more productive because we like it. Maybe we should get better at liking things. The debate about this tends to remain stuck at a low level because once you've been around the block enough times you realize that it hurts to bang your head against a wall so you stop. Thus the vocal population undergoes a perpetual exodus of the experienced, but makes up for it with a fresh supply of enthusiasts, reminding one of the adage, "I arrive at the office late, but make up for it by leaving early."
- beders 7y ago
  [parent predicts flamewar, starts one with:] > Their reasoning is along the lines of, "I don't need a type system because I'm a professional and don't make mistakes." Nah. Where did you get that? That's so horribly wrong, it's not even funny. Types are one tool in the toolbox to describe a system. It is not the most powerful or expressive one. It just happens to be available at compile-time. It catches trivial bugs, acts as documentation, helps the compiler with memory allocation. It also is static. And that's where the weaknesses begin. A whole class of problems that benefit from domain definitions being available at runtime are clumsy to write in languages that force types on you. Not impossible, of course, but clumsy. (i.e. place-oriented programming) To your point: Everyone makes mistakes. The way to catch them and to prevent them in the future is not by having types. It's by writing tests. Tests > Types > no types at all
  - yakshaving_jgt 7y ago
    > Tests > Types > no types at all You conveniently neglected to include (Types + Tests) at the beginning of your little food-chain there.
    - orange8 7y ago
      Did you miss the part where they said "... at runtime are clumsy to write in languages that force types on you.." That may most likely put "types + tests" at the bottom of their food-chain. And speaking of TS, since it compiles down to JS in production, it can be considered a very basic type of testing, or an advanced type of linting.
      - yakshaving_jgt 7y ago
        > That may most likely put "types + tests" at the bottom of their food-chain. That is totally illogical. If types are better than nothing, and tests are better than nothing, then how could both tests and types together be worse than nothing? > Did you miss the part where they said "... at runtime are clumsy to write in languages that force types on you.." No, I didn't miss it. I just disagree with it. Interpreting values at runtime is called "parsing". The parsing step exists regardless of whether the program is written in a static language or a dynamic language.
- mgkimsal 7y ago
  > Before I inherited the code, he told me, "I code in the terminal. I don't need IDE features because I don't really make mistakes in PHP anymore." Again, seems satirical, but not uncommon. Went to a tech meetup group hosted at a moderate sized local tech company. The tech company had job openings, and I'd looked at a couple earlier that month. Some of their staff came to the meetup, and I got to talking with one of the 'lead' guys. I'd recently started using IntelliJ, and was talking to some others about how much more productive I was being, and it was the best money I'd spent on anything in year. The lead guy jumped in and basically said IDEs were for wimps (more or less). If you're a good developer, you don't need an IDE - he knew everything about their codebase, was very productive, and had been for years. My experience was the opposite - I do a lot of freelance/consulting/dev stuff - my life is jumping between projects every few months or year or so. Having tooling that helps me understand so much more about a project than I could get just from vim (for example) was so eye-opening and transformative to my way of thinking that it made me re-evaluate a lot of previous notions, habits and assumptions about development. I'd explained that using good IDEs had made me better at my craft in every conceivable way. He just sort of shrugged and said he could understand why some people might need an IDE, but they're mostly just crutches for people who don't want to spend the time to learn a codebase the 'real' way. I'd been interested in applying to that company, but didn't bother after realizing I would be having to work with that attitude daily.
  - winrid 7y ago
    It's just someone being elitist. Why not learn the codebase AND use nice tooling? Silly argument.
- valuearb 7y ago
  When I first got into Node.js I went to a Node meetup and mentioned I was having trouble getting typescript set up. They admonished me, saying you don’t need that, you just need test coverage. Ok...
- Lio 7y ago
  Agree with your point but just want to point out that you can have "IDE features" without an IDE and in the terminal if you want them. See either Emacs or any editor using LSP such as Vim/NeoVim.
seanmcdirmid 7y ago
TS has some great typing features that I would miss going back to C#, but I miss the better type error messages I get in a nominal type system.
- protonimitate 7y ago
  TS errors are my only real complaint about TS. Otherwise it's a joy to work in, imo. Trying to go from TS back to JS is a frustrating experience to say the least.
  - karatestomp 7y ago
    TS can generate such good and natural looking JS that, faced with someone insisting on receiving a JS codebase, I’d consider keeping a shadow-repo in TypeScript and handing them its output. Doesn’t work so well with an existing codebase, but still.
- damidekronik 7y ago
  Yea, the structural typing nature of TS drives me nuts. One thing I like in TS is the ability to reference individual "parts of a type", for example Account["email"] instead of "string" in function signatures. Is there something like that in C#?
pathartl 7y ago
Same. The only JS I have to write anymore is for some customization on top of a CRM platform we use. For that I've decided to go with Bridge.NET. They've build .NET libraries based on typings so it has support for almost everything. The resulting JS is FAT, don't get me wrong, but since this is for internal use and it's heavily cached, I don't mind having our users download a 3MB JS file.
chowells 7y ago
A shockingly large number of people tell you that types don't help in the real world. If those people believed this article, I'm sure they'd find it surprising.

smt88 7y ago

> Porting to a typed language helped prevent type errors in a typeless language. Who woulda thunk? You say this sarcastically, but every JS-related thread on HN turns into a flamewar between type lovers and haters. The type haters make exactly the argument you're mocking: that typeless languages do not result in more type errors. Their reasoning is along the lines of, "I don't need a type system because I'm a professional and don't make mistakes." That sounds laughable or like an exaggeration, but it's a surprisingly common line of thinking. The buggiest code I ever worked on was a PHP code base written by someone who had been coding for 20 years and had a Master's in CS. Before I inherited the code, he told me, "I code in the terminal. I don't need IDE features because I don't really make mistakes in PHP anymore." Again, seems satirical, but not uncommon.

giulianob 7y ago
Those people are also missing the point that not having types means you are inherently writing a slow program.
- diggan 7y ago
  That's the first time I heard that any language that doesn't have types, is slower than a program with types. I'm unsure if that actually makes sense. You mean slower as in performance? I'm having a hard time understanding how types == performance, so you have to mean something else. I guess assembly would be the language you would use if you really need to squeeze out the maximum amount of performance of a single CPU, and as far as I know, it does not have types. Also languages built on top of LLVM could get by with trading compile times for run time performance. Maybe you meant compiling gets slower without types?
  - Arnavion 7y ago
    Strong typing means that at runtime dynamic behaviors don't need to be accounted for. For a compiled language, the compiler could know that `foo` and `bar` are 32-bit integers, and thus compile `foo + bar` to call the addition function for 32-bit integers. In an interpreted language, the interpreter could do the same thing. Without that typing information, both would have to invoke a generic addition function that detects the types of its arguments at runtime, notices they're both 32-bit integers, and delegates to the corresponding addition function. Of course there are tricks that can be played in the weakly-typed case, like assuming the same call site will always have the same types, so that there can be a short path that assumes that and only branches rarely. That way the first or first few executions might be slow, but eventually they get almost as fast as the statically-typed case. JS engines in particular and JITted runtimes in general usually do this. >I guess assembly would be the language you would use if you really need to squeeze out the maximum amount of performance of a single CPU, and as far as I know, it does not have types. Assembly absolutely does have types. The addition function for 32-bit ints only operates on 32-bit ints, and is distinct from the addition function for 64-bit ints.
    - mr_toad 7y ago
      > Assembly absolutely does have types. The addition function for 32-bit ints only operates on 32-bit ints You can add any bits that will fit in the relevant registers. Assembly cares not whether the programmer thinks they are ints.
      - Arnavion 7y ago
        You should read the part of the sentence you cut off in your quote.
  - jbboehr 7y ago
    Dynamically typed languages still have types internally, they just look like this [0] (imagine it all implemented in assembly, without C's types, if you prefer). [0]: https://github.com/php/php-src/blob/3709e74b5e495e210ada8039ed81fafa9cbadcdb/Zend/zend_types.h#L282-L328 https://github.com/php/php-src/blob/3709e74b5e495e210ada8039...
- dang 7y ago
  Please don't post grand unsubstantive claims to flamewar topics. That's bomb-throwing and usually leads to silly explosions.
  - giulianob 7y ago
    Really look at any significant benchmark or what types of projects use which languages. The evidence is extremely clear and makes sense due to how computers work.
    - dang 7y ago
      Please just stop.
    - tln 7y ago
      The language in question, TypeScript, runs exactly as fast as JavaScript!
      - blast 7y ago
        I want to just post "Lol" but that will get flagged, so instead I will thank you for finding the optimal refutation.
- Roboprog 7y ago
  That was certainly true in 1990. The use of JITs has changed that to a large extent, as frequently used code paths can be rewritten at runtime in many cases. Static types tend to push people towards copy-pasta code, as well, which can even work against performance.
- smt88 7y ago
  The factors affecting program speed are numerous, and I would guess that types do not have nearly the greatest effect. Most of us are not optimizing for program speed. Machine time is cheap. Human time is expensive. The biggest cost-savers for most programmers will be the ergonomics of a language, not the optimizations available to the compiler.
- mr_toad 7y ago
  So assembly code is slow?
diggan 7y ago
> Their reasoning is along the lines of Now I'm sure that many feel like that, but I don't think it's the majority, but I also don't know. Here are some more arguments against types (don't necessarily agree with all of them myself, but for reference in the future when you want to write from the perspective of someone who feels more productive without types): - There are other, more flexible ways to solve the same problems you solve with typing, the clojure.spec way is one of them - You lose flexibility when suddenly everything is locked to each other by name. Even if Account and Person both has a first and last name fields, you can't use both of them if the function is expecting a Account and only use the first and last name. Then you need to add an interface, name it something, then make Account and Person be based on that. Now the function is locked to the interface, and so on - Type checking is a very basic form of testing that doesn't solve the most common, annoying and hard-to-track down bugs, logic bugs. - Metaprogramming becomes harder. Not impossible, just harder. - Types (at least in TypeScript and other languages I've been using in the past) disappear in runtime, so you can't really use them. It's just a tool for you to tell the compiler what something is so it can say "no, you did wrong here" Now I'm neither a type lover nor hater. I just want to use the right solution for the right problem, sometimes, that's making a program that will take longer time to write but specification is set in stone and requirements won't change, so types will help you a lot. Other times, it's in a very dynamic and experimental environment where you have to be able to apply changes as quickly as possible and minor errors don't matter as much, as long as you can move forward fast and test theories. Then you can go back and refactor things.
- jakear 7y ago
  > You lose flexibility when suddenly everything is locked to each other by name. TS uses structural typing.
  - diggan 7y ago
    That's good, compared to the nominative type systems, on that point at least! I'm just trying to help the person I'm replying to to see more arguments in favor of dynamic systems without types, not necessarily straightly aimed at TypeScript as they mainly mentioned just types.
woah 7y ago
How can you call yourself a programmer if you need a type system babysitting you? EDIT: my apologies to anyone who did not realize this was satirical
greglindahl 7y ago
> The type haters make exactly the argument you're mocking Funny, I usually see type haters claiming that they don't actually make the kinds of mistakes that are fixed by strong typing. Which is a completely different sentiment.
- netghost 7y ago
  I think the more nuanced point folks tend to make is that they catch the errors at Run Time instead of Compile Time, and that the cost of strict typing is greater than that of catching it at Run Time. Personally, I'm agnostic (I make mistakes in all phases and fix most of them eventually ;) )
  - greglindahl 7y ago
    I agree that people make that point, and I agree that it's a good one. But it's irrelevant to this sub-thread, which started with me attempting to convince smt88 that they were misrepresenting the opinion of the people they were laughing at.
- nohuhu 7y ago
  > Funny, I usually see type haters claiming that they don't actually make the kinds of mistakes that are fixed by strong typing. As your typical type hater, my preferred argument is: yes, static typing prevents a certain class of bugs from happening; no, this class of bugs is not nearly as relevant as type lovers seem to be claiming. By an order of magnitude if not more. Source: 6 years of being a core developer of a front end framework consisting of 1,500,000 lines of ES5 JavaScript and SASS.
  - me_again 7y ago
    I'm having a hard time picturing a 1.5M LOC front end Javascript framework. Can you tell us more?
    - smt88 7y ago
      I would have to assume GP used "framework" differently than you understood it. They may have meant "foundational code of an app".
dang 7y ago
That of course is not the argument at all. The argument is that the cost of working with static types exceeds the benefits. Finding type errors is obviously a benefit, while not finding them (or finding them only at runtime) is a cost. The question is what other costs and benefits there are, and how to compare them. Nobody agrees on that, nor ever will. This argument will never be resolved because it's dominated by psychological factors. Once you've adapted to environment A, A's costs (e.g. hoops the compiler makes you jump through / time spent tracking down type errors) become habitual and you don't notice them anymore. Meanwhile the costs of unfamiliar environment B are extremely highlighted in your attention. Similarly, if you like and identify with A, its benefits will be top-of-mind for you, while if you don't like B (and nobody likes B), you'll discount its benefits. It gets worse. Sometimes benefits are costs until you make it through a learning curve. An example is parentheses in Lisp. They stick out like a sore thumb until one day they don't. Later you realize that they were a liberating force all along, and you now have anti-gravity powers you never dreamt of. (<-- This is an example of how people talk when they are adapted to an environment whose costs they no longer count and whose benefits are top-of-mind for them.) We can't even agree on what the costs and benefits are, let alone how to measure them. It's no wonder that people feel so strongly about this dispute. When you don't count the costs of your preferred environment, and only count the benefits, it gets obvious pretty quickly that other people are idiots. For some reason the idiots feel the opposite and perversely insist on it. It gets worse. Imagine that you're a decent, fairminded sort and so, magnanimously as is your wont, you decide to give the idiots a fair shake—you know, just to verify that you're being fair and whatnot. You fire up whatever it is (Clojure? OCaml? needless to say, you make a charitable choice) and start programming for a while. What happens? All the costs of unfamiliarity hit you in the face. Not one of the benefits that has lived at the top of your mind for years is anywhere to be seen. This thing doesn't even catch trivial type errors at compile time! / I can't even execute this bit of code in a REPL! This is a painful experience. It can even be an enraging one, for example if you are forced for some extraneous reason to work on a system you didn't create using tools you don't like. Most people who go through that experience once have their views solidified for life. Meanwhile someone else had the opposite experience. Given how passionately people feel about this and the certainty in forum threads about it, it's curious (or maybe to be expected) that the question of published evidence comes up so rarely. HN user luu did the definitive survey on this: https://danluu.com/empirical-pl/ https://danluu.com/empirical-pl/. The short version is that such studies as there are don't address the core question and/or find insignificant effects and/or their designs tip obviously to one side or the other (and I do mean obviously, like comparing Peter Norvig's code to that of random undergrads). Bias dominates every other factor, put together, times at least 10. As long as that's true, we can't say anything rational without genuinely accounting for bias. Do we actually know how to do that? The studies don't seem able to. These debates certainly don't, nor do they try. Maybe the interesting phenomenon here is actually the bias itself. Maybe it's not that we like an environment because we're more productive in it, but that we're more productive because we like it. Maybe we should get better at liking things. The debate about this tends to remain stuck at a low level because once you've been around the block enough times you realize that it hurts to bang your head against a wall so you stop. Thus the vocal population undergoes a perpetual exodus of the experienced, but makes up for it with a fresh supply of enthusiasts, reminding one of the adage, "I arrive at the office late, but make up for it by leaving early."
beders 7y ago
[parent predicts flamewar, starts one with:] > Their reasoning is along the lines of, "I don't need a type system because I'm a professional and don't make mistakes." Nah. Where did you get that? That's so horribly wrong, it's not even funny. Types are one tool in the toolbox to describe a system. It is not the most powerful or expressive one. It just happens to be available at compile-time. It catches trivial bugs, acts as documentation, helps the compiler with memory allocation. It also is static. And that's where the weaknesses begin. A whole class of problems that benefit from domain definitions being available at runtime are clumsy to write in languages that force types on you. Not impossible, of course, but clumsy. (i.e. place-oriented programming) To your point: Everyone makes mistakes. The way to catch them and to prevent them in the future is not by having types. It's by writing tests. Tests > Types > no types at all
- yakshaving_jgt 7y ago
  > Tests > Types > no types at all You conveniently neglected to include (Types + Tests) at the beginning of your little food-chain there.
  - orange8 7y ago
    Did you miss the part where they said "... at runtime are clumsy to write in languages that force types on you.." That may most likely put "types + tests" at the bottom of their food-chain. And speaking of TS, since it compiles down to JS in production, it can be considered a very basic type of testing, or an advanced type of linting.
    - yakshaving_jgt 7y ago
      > That may most likely put "types + tests" at the bottom of their food-chain. That is totally illogical. If types are better than nothing, and tests are better than nothing, then how could both tests and types together be worse than nothing? > Did you miss the part where they said "... at runtime are clumsy to write in languages that force types on you.." No, I didn't miss it. I just disagree with it. Interpreting values at runtime is called "parsing". The parsing step exists regardless of whether the program is written in a static language or a dynamic language.
mgkimsal 7y ago
> Before I inherited the code, he told me, "I code in the terminal. I don't need IDE features because I don't really make mistakes in PHP anymore." Again, seems satirical, but not uncommon. Went to a tech meetup group hosted at a moderate sized local tech company. The tech company had job openings, and I'd looked at a couple earlier that month. Some of their staff came to the meetup, and I got to talking with one of the 'lead' guys. I'd recently started using IntelliJ, and was talking to some others about how much more productive I was being, and it was the best money I'd spent on anything in year. The lead guy jumped in and basically said IDEs were for wimps (more or less). If you're a good developer, you don't need an IDE - he knew everything about their codebase, was very productive, and had been for years. My experience was the opposite - I do a lot of freelance/consulting/dev stuff - my life is jumping between projects every few months or year or so. Having tooling that helps me understand so much more about a project than I could get just from vim (for example) was so eye-opening and transformative to my way of thinking that it made me re-evaluate a lot of previous notions, habits and assumptions about development. I'd explained that using good IDEs had made me better at my craft in every conceivable way. He just sort of shrugged and said he could understand why some people might need an IDE, but they're mostly just crutches for people who don't want to spend the time to learn a codebase the 'real' way. I'd been interested in applying to that company, but didn't bother after realizing I would be having to work with that attitude daily.
- winrid 7y ago
  It's just someone being elitist. Why not learn the codebase AND use nice tooling? Silly argument.
valuearb 7y ago
When I first got into Node.js I went to a Node meetup and mentioned I was having trouble getting typescript set up. They admonished me, saying you don’t need that, you just need test coverage. Ok...
Lio 7y ago
Agree with your point but just want to point out that you can have "IDE features" without an IDE and in the terminal if you want them. See either Emacs or any editor using LSP such as Vim/NeoVim.

seanmcdirmid 7y ago

TS has some great typing features that I would miss going back to C#, but I miss the better type error messages I get in a nominal type system.

protonimitate 7y ago
TS errors are my only real complaint about TS. Otherwise it's a joy to work in, imo. Trying to go from TS back to JS is a frustrating experience to say the least.
- karatestomp 7y ago
  TS can generate such good and natural looking JS that, faced with someone insisting on receiving a JS codebase, I’d consider keeping a shadow-repo in TypeScript and handing them its output. Doesn’t work so well with an existing codebase, but still.
damidekronik 7y ago
Yea, the structural typing nature of TS drives me nuts. One thing I like in TS is the ability to reference individual "parts of a type", for example Account["email"] instead of "string" in function signatures. Is there something like that in C#?

pathartl 7y ago

Same. The only JS I have to write anymore is for some customization on top of a CRM platform we use. For that I've decided to go with Bridge.NET. They've build .NET libraries based on typings so it has support for almost everything. The resulting JS is FAT, don't get me wrong, but since this is for internal use and it's heavily cached, I don't mind having our users download a 3MB JS file.

chowells 7y ago

A shockingly large number of people tell you that types don't help in the real world. If those people believed this article, I'm sure they'd find it surprising.