7 ms·

> Typescript. You pretty much need that on any reasonable size project unless you are happy to spend your life tracking down runtime bugs I'd say it depends on

> Typescript. You pretty much need that on any reasonable size project unless you are happy to spend your life tracking down runtime bugs I'd say it depends on your teams skill set and level of disciple. The best defence against a buggy codebase isn't a programming language or framework, its good all fashioned discipline.

bambataa 7y ago
Don’t need to catch bugs if you just don’t write them! taps head. It is still worthwhile imo to have something that catches mistakes even great people make.
- orange8 7y ago
  I completely agree. That something is a linter, of which TypeScript is just one of the many options available. This whole idea of you cannot write a big app in JS is just peddled by those who do not understand, or hate JS. A good linter, proper programming practices, discipline will get you there. Anytime someone peddles a language or framework as a magic bullet to clean code, they're either selling you some snake oil or have drunk too much of some koolaid, imho.
  - giantDinosaur 7y ago
    This is the kind of attitude that has resulted in a million code vulnerabilities in C because the idea that it's inherently unsafe is just an idea 'peddled by people unskilled in its application' (to re-express nicely). It's the kind of attitude which will ignore the many inconsistencies in languages which were the result of historical accident instead of good design because it's just a blind acceptance of the way things turned out to be rather than what they _could_ be. Many who go on about 'discipline' are often creating error prone applications and, ironically, peddling 'discipline' as that very magic bullet to cure all ills. I don't know if I've even seen discipline defined beyond some self-referential 'avoid doing these bad things that our language/environment allows by knowing that they're bad before you make the mistakes that show you they're bad'. Do developers just shrug and accept it as a fundamental design constraint to good programming languages when their booleans add with their integers and concatenate with their strings and give essentially random results? Do they not wonder: is there a system, more fundamental than linting, which can solve many of these issues in a general case?
    - orange8 7y ago
      The idea that "A good linter, proper programming practices, discipline will get you there" has resulted in "a million code vulnerabilities in C" !! That is a surprising jump in cause-and-effect logic right there. I do not code any C, but I assure you if I did I'd consider it part of proper programming practice and discipline to write code that avoids those exact vulnerabilities you suggest. But, picking a whole new programming language instead is just lying to yourself, because there is no perfect programming language. None! Zero. Not one, no matter how much in love you are with it. They all have their warts, strengths and weaknesses, and if you are not aware of any in your language of choice, and actively working to avoid and mitigate against them (aka discipline and best practice) then you have fallen prey to exactly what I was talking about: the idea that a framework or language is a magical silver bullet to writing clean code. If you thought I was saying JS (or C, TypeScript, Haskel etc) is this perfect, wonderful language, you completely misunderstood me.
      - nmfisher 7y ago
        > I do not code any C, but I assure you if I did I'd consider it part of proper programming practice and discipline to write code that avoids those exact vulnerabilities you suggest. And yet all of those vulnerabilities came from hundreds of developers who shared the same misplaced confidence in their own abilities. It's the same as hospitals. You can't just say "who needs checklists? Surgeons and assistants should be disciplined enough to not make mistakes in the first place!". In an ideal world they would be, but in this world, they're not and never will be. Not being able to admit this is how you end up with surgery on your left knee when it was meant to be your right. Accept that no-one is 100% perfect, 100% of the time - let alone you - and mould your development around these (very human) failings. "Disciplined programming" will never be as safe as "disciplined programming with guard-rails built into the language". Weigh up the trade-offs - sometimes the performance gain is worth the risk, sometimes it's not.
        orange8 7y ago
        > And yet all of those vulnerabilities came from hundreds of developers who shared the same misplaced confidence in their own abilities. This is a good example of a straw man argument. A comment about a programming language or framework not being a silver bullet to clean code has suddenly been twisted into a comment about developers with misplaced confidence in their abilities. How exactly does using best practice in and discipline equate to overconfidence?! good practice and discipline ≠ misplaced confidence
CapsAdmin 7y ago
I think we all agree on this, but we don't all agree that "just be disciplined" works in practice. "Just don't write bugs", "just write perfect code", etc Given that you and your team has all the discipline you need, you could still argue that type checking the codebase in your head is time consuming and is better spent on higher level concepts. A typesystem can get in the way and slow down development if it's too strict of course, but I feel typescript does a good job of keeping it optional enough. There is no clear answer here, but at least refactoring is much easier and safer given that your types are sound.
- orange8 7y ago
  > "Just don't write bugs", "just write perfect code", etc You are putting words in my mouth. I do not believe that you can write perfect code or avoid bugs. Just like I do not believe there is this perfect programming language or framework out there that magically creates clean code. > you could still argue that type checking the codebase in your head is time consuming This again, depends on the particular history and skill-set of your team. For example, TypeScript fits very well if you are familliar with C#, while CoffeeScript fits very well to those comfortable with python/ruby, ClojureScript for those who like clojure, ESLint for those comfortable with JS ... etc
  - madeofpalk 7y ago
    As a “life long” web/JavaScript developer, ESLint is nowhere near comparable to Typescript. One is a language, and the other is an (overused and over configured) linter. They’re two different things. I’m no C# developer, but the only way it is familiar to Typescript in the sense that it is a typed language. Typescript is a superset of JavaScript, and is remarkably close. If you know JavaScript, typescript will be exceptionally similar because it’s literally the same, just with types added on top.
    - orange8 7y ago
      I have worked with two compile to JS languages, CoffeeScript and TypeScript. > One is a language, and the other is an (overused and over configured) linter. You could also say that one is an extremely opinionated linter and the other is just a linter.
madeofpalk 7y ago
Typescript is not a product for teams of low skill of disciple, and it's pretty insulting to suggest it is.
- orange8 7y ago
  That is certainly not what I was suggesting.
  - madeofpalk 7y ago
    You literally said "[Whether you need Typescript or not] depends on your teams skill set and level of disciple".
    - orange8 7y ago
      level of discipline ≠ low discipline
IshKebab 7y ago
Yep, just like the best defence against dying in a car crash isn't a seatbelt or airbags, it's good old fashioned being awesome at driving like me.
- orange8 7y ago
  > the best defence against dying in a car crash isn't a seatbelt or airbags This is the kind of madness I'm talking about. An opinionated code linter is now being compared to seatbelt and airbags. Dont forget your bullet proof vest and gas mask too, driving is dangerous!
branko_d 7y ago
It's not just about bugs. Static typing is crucial for productivity whenever the codebase overflows your brain's working memory. Navigating through code, refactoring, or simply figuring out what to pass as function input can become a challenge in the absence of types.
- smnplk 7y ago
  That's why god invented comment blocks. But some people view them as code smell, which i find very strange. And no, good naming is not always enough.
  - IshKebab 7y ago
    So you're saying it's a good idea to write what your types are in your code, but rather than writing them in a form that can be automatically checked by a computer and used for code completion and refactoring, you prefer to write them in a comment?
    - smnplk 7y ago
      No, I said no such thing. If you happen to be in a dynamic environment, then yes, I see no foul in describing inputs to a function inside a comment above function declaration. Use comments to describe your intents on non trivial parts of your code. There is no amount of code readability that will help your colleague, if she doesn't understand your thought process at the time of writing the code.
  - michaelcampbell 7y ago
    "not always enough" is still better than "none". This feels like a classic "good being the enemy of the perfect" issue.
jkaptur 7y ago
I think you mean “old fashioned”... which goes to show that even skilled, disciplined, knowledgeable folks can make simple mistakes. When the stakes are high, it’s important to use tools to augment human judgement.

bambataa 7y ago

Don’t need to catch bugs if you just don’t write them! taps head. It is still worthwhile imo to have something that catches mistakes even great people make.

orange8 7y ago
I completely agree. That something is a linter, of which TypeScript is just one of the many options available. This whole idea of you cannot write a big app in JS is just peddled by those who do not understand, or hate JS. A good linter, proper programming practices, discipline will get you there. Anytime someone peddles a language or framework as a magic bullet to clean code, they're either selling you some snake oil or have drunk too much of some koolaid, imho.
- giantDinosaur 7y ago
  This is the kind of attitude that has resulted in a million code vulnerabilities in C because the idea that it's inherently unsafe is just an idea 'peddled by people unskilled in its application' (to re-express nicely). It's the kind of attitude which will ignore the many inconsistencies in languages which were the result of historical accident instead of good design because it's just a blind acceptance of the way things turned out to be rather than what they _could_ be. Many who go on about 'discipline' are often creating error prone applications and, ironically, peddling 'discipline' as that very magic bullet to cure all ills. I don't know if I've even seen discipline defined beyond some self-referential 'avoid doing these bad things that our language/environment allows by knowing that they're bad before you make the mistakes that show you they're bad'. Do developers just shrug and accept it as a fundamental design constraint to good programming languages when their booleans add with their integers and concatenate with their strings and give essentially random results? Do they not wonder: is there a system, more fundamental than linting, which can solve many of these issues in a general case?
  - orange8 7y ago
    The idea that "A good linter, proper programming practices, discipline will get you there" has resulted in "a million code vulnerabilities in C" !! That is a surprising jump in cause-and-effect logic right there. I do not code any C, but I assure you if I did I'd consider it part of proper programming practice and discipline to write code that avoids those exact vulnerabilities you suggest. But, picking a whole new programming language instead is just lying to yourself, because there is no perfect programming language. None! Zero. Not one, no matter how much in love you are with it. They all have their warts, strengths and weaknesses, and if you are not aware of any in your language of choice, and actively working to avoid and mitigate against them (aka discipline and best practice) then you have fallen prey to exactly what I was talking about: the idea that a framework or language is a magical silver bullet to writing clean code. If you thought I was saying JS (or C, TypeScript, Haskel etc) is this perfect, wonderful language, you completely misunderstood me.
    - nmfisher 7y ago
      > I do not code any C, but I assure you if I did I'd consider it part of proper programming practice and discipline to write code that avoids those exact vulnerabilities you suggest. And yet all of those vulnerabilities came from hundreds of developers who shared the same misplaced confidence in their own abilities. It's the same as hospitals. You can't just say "who needs checklists? Surgeons and assistants should be disciplined enough to not make mistakes in the first place!". In an ideal world they would be, but in this world, they're not and never will be. Not being able to admit this is how you end up with surgery on your left knee when it was meant to be your right. Accept that no-one is 100% perfect, 100% of the time - let alone you - and mould your development around these (very human) failings. "Disciplined programming" will never be as safe as "disciplined programming with guard-rails built into the language". Weigh up the trade-offs - sometimes the performance gain is worth the risk, sometimes it's not.
      - orange8 7y ago
        > And yet all of those vulnerabilities came from hundreds of developers who shared the same misplaced confidence in their own abilities. This is a good example of a straw man argument. A comment about a programming language or framework not being a silver bullet to clean code has suddenly been twisted into a comment about developers with misplaced confidence in their abilities. How exactly does using best practice in and discipline equate to overconfidence?! good practice and discipline ≠ misplaced confidence

CapsAdmin 7y ago

I think we all agree on this, but we don't all agree that "just be disciplined" works in practice. "Just don't write bugs", "just write perfect code", etc Given that you and your team has all the discipline you need, you could still argue that type checking the codebase in your head is time consuming and is better spent on higher level concepts. A typesystem can get in the way and slow down development if it's too strict of course, but I feel typescript does a good job of keeping it optional enough. There is no clear answer here, but at least refactoring is much easier and safer given that your types are sound.

orange8 7y ago
> "Just don't write bugs", "just write perfect code", etc You are putting words in my mouth. I do not believe that you can write perfect code or avoid bugs. Just like I do not believe there is this perfect programming language or framework out there that magically creates clean code. > you could still argue that type checking the codebase in your head is time consuming This again, depends on the particular history and skill-set of your team. For example, TypeScript fits very well if you are familliar with C#, while CoffeeScript fits very well to those comfortable with python/ruby, ClojureScript for those who like clojure, ESLint for those comfortable with JS ... etc
- madeofpalk 7y ago
  As a “life long” web/JavaScript developer, ESLint is nowhere near comparable to Typescript. One is a language, and the other is an (overused and over configured) linter. They’re two different things. I’m no C# developer, but the only way it is familiar to Typescript in the sense that it is a typed language. Typescript is a superset of JavaScript, and is remarkably close. If you know JavaScript, typescript will be exceptionally similar because it’s literally the same, just with types added on top.
  - orange8 7y ago
    I have worked with two compile to JS languages, CoffeeScript and TypeScript. > One is a language, and the other is an (overused and over configured) linter. You could also say that one is an extremely opinionated linter and the other is just a linter.

madeofpalk 7y ago

Typescript is not a product for teams of low skill of disciple, and it's pretty insulting to suggest it is.

orange8 7y ago
That is certainly not what I was suggesting.
- madeofpalk 7y ago
  You literally said "[Whether you need Typescript or not] depends on your teams skill set and level of disciple".
  - orange8 7y ago
    level of discipline ≠ low discipline

IshKebab 7y ago

Yep, just like the best defence against dying in a car crash isn't a seatbelt or airbags, it's good old fashioned being awesome at driving like me.

orange8 7y ago
> the best defence against dying in a car crash isn't a seatbelt or airbags This is the kind of madness I'm talking about. An opinionated code linter is now being compared to seatbelt and airbags. Dont forget your bullet proof vest and gas mask too, driving is dangerous!

branko_d 7y ago

It's not just about bugs. Static typing is crucial for productivity whenever the codebase overflows your brain's working memory. Navigating through code, refactoring, or simply figuring out what to pass as function input can become a challenge in the absence of types.

smnplk 7y ago
That's why god invented comment blocks. But some people view them as code smell, which i find very strange. And no, good naming is not always enough.
- IshKebab 7y ago
  So you're saying it's a good idea to write what your types are in your code, but rather than writing them in a form that can be automatically checked by a computer and used for code completion and refactoring, you prefer to write them in a comment?
  - smnplk 7y ago
    No, I said no such thing. If you happen to be in a dynamic environment, then yes, I see no foul in describing inputs to a function inside a comment above function declaration. Use comments to describe your intents on non trivial parts of your code. There is no amount of code readability that will help your colleague, if she doesn't understand your thought process at the time of writing the code.
- michaelcampbell 7y ago
  "not always enough" is still better than "none". This feels like a classic "good being the enemy of the perfect" issue.

jkaptur 7y ago

I think you mean “old fashioned”... which goes to show that even skilled, disciplined, knowledgeable folks can make simple mistakes. When the stakes are high, it’s important to use tools to augment human judgement.