10 ms·

Do you believe static typing is harmful (to the type of company you want to join), or is this a personal preference (which is totally valid)? Honestly curious.

by sqs 7y ago

wintorez 7y ago
I don't like static typing, as a personal preference. I like the rapid prototyping of dynamic typing, and a type system often times gets in the way of that.
- wwwigham 7y ago
  Even if you don't opt in to full TypeScript, please do remember that the same engine powering the TypeScript language is also what powers IDE support and completions for JS in vscode and VS, so even if you're not using TypeScript _the language_, you're potentially still using TypeScript, _the static analysis tool_. Even without opting in to full type safety, having those tools available can still be a huge quality of life improvement.
- wvenable 7y ago
  That's funny, I don't like dynamic typing for the same reason. Rapid prototyping without types makes the whole process so much slower! With dynamic typing, you don't get the immediate feedback of breaks when making frequent changes. You don't get the safety of automatic refactoring. You don't get auto-complete and easy of discovery of APIs. I really don't understand the idea behind dynamic typing being better for prototyping unless that "prototype" is only a few lines long.
benatkin 7y ago
It's a personal preference. Being able to make, fix, and guard against (with testing) type errors is a freedom that I've enjoyed with ruby, python, lisp (scheme/racket), scheme, and JavaScript.
- deleted 7y ago
  [deleted]
- deleted 7y ago
  [deleted]
Ididntdothis 7y ago
I am starting to wonder if the preference static vs dynamic is some kind of character trait like introvert vs extrovert. I personally prefer static typing and use it to my advantage during development but I know very smart people who hate static typing and think it impedes them. Both sides have valid arguments but seem to prioritize things differently. However I think it’s important to have used both for a while so you can make a good decision what you prefer.
- ajxs 7y ago
  At first I thought I was going to read "I am starting to wonder if the preference static vs dynamic is some kind of character trait like intelligent vs ignorant", which would have been much closer to the truth. I think you're very incorrect. Maintaining a codebase of any sufficient size and complexity without static typing is a poor investment of development time. It can be done, obviously, but it's a nightmare. Typescript is a bandaid for web-development's biggest open wound. Taken on its own merits ( ignoring the garbage ecosystem, terrible tooling, etc ) Typescript is a decent enough language, but it's not a clever one. Is Typescript better than vanilla Node.js? Absolutely. Is it worth introducing to an area without Node.js? Absolutely not. If your project is any more complex than a four page CRUD app, in my opinion you're better off going with a bigger player like Java/.Net. These languages are more robust, more mature, there's better tooling, better community... The list goes on.
  - Ididntdothis 7y ago
    I am not sure if I want to work with you if you think it’s about “intelligent vs ignorant"... Even though I seem to be in the “intelligent” camp by your definition.
    - ajxs 7y ago
      That's fine.
- Old_Thrashbarg 7y ago
  > However I think it’s important to have used both for a while so you can make a good decision what you prefer. Exactly, I always found static typing to be annoying clutter and Python seemed to work even at scale. I removed the few type hints the codebase had. Then I had to spend a year in C# professionally. At the end, I was fine with both, no preference. Then I jumped back into our Python and only then realized the utility of typing - it felt chaotic, my (IntelliJ) IDE was no longer helping me and every time I had Prod type related bug, it feeling dumb. Ended up type hinting the critical parts of the Python.
eleclady 7y ago
Personal preference is valid only to an extent. At a certain point, with enough scale/team size/complexity TypeScript becomes invaluable. I've worked on projects that would have been intractable without TypeScript. This is a huge problem with front-end. Too many people who don't know what they don't know, and think their use case is the only one.
lewisl9029 7y ago
I've found that the kinds of errors that static typing guards against are often things that would have been trivial to debug and fix in the first place (mostly things like typos). Given that you have a good system for monitoring errors in production and a low friction deploy process so you can quickly and easily fix errors when you discover them, I feel these kinds of errors are honestly not worth guarding against in most contexts outside of those where getting everything perfectly right the first time is a hard requirement (health, fintech, other safety-critical industries, etc). Of course, most companies lack either or both of these ( a good system for monitoring errors in production and a low friction deploy process), so they use static typing as a clutch to try to reduce the chance of errors making it into prod simply because they know they'd be slow to fix/detect those errors. That's a poor reason to choose static typing IMO, but I think that's by far the most common reason.
- almostdeadguy 7y ago
  I think “debugging errors in prod” is not generally how I like to spend my working life, with or without excellent logging and tooling for surfacing errors.
  - lewisl9029 7y ago
    How this works in practice is usually 1) deploy some change, 2) errors start showing up that correspond to that change, 3) click a button to revert the change instantaneously (some systems can even do this automatically), 4) debug the change in dev
    - almostdeadguy 7y ago
      There is no way any of this process takes less time to solve than "I got a red squiggle in my editor and fixed the variable spelling". I don't think typos are really the only things type systems fix (type systems provide powerful ways of preventing screw-ups by allowing you to encode invariants about a piece of data and how it may be used), but if typos are indeed the extent of it, it seems unimaginable to me that the process to fix would be faster by going through code review -> CI pipeline -> deploy and then back again, no matter how fast it is to revert a change in production. Honestly that's just the compile-time safety advantage of types, half the time saved in typescript is just not spending time having to read someone else's source code to figure out how a function may be used because cowboy js devs were too lazy to document them (knex is an especially egregious offender in this regard that I thankfully don't have to use anymore).

Do you believe static typing is harmful (to the type of company you want to join), or is this a personal preference (which is totally valid)? Honestly curious.

by sqs 7y ago

Do you believe static typing is harmful (to the type of company you want to join), or is this a personal preference (which is totally valid)? Honestly curious.

wintorez 7y ago

I don't like static typing, as a personal preference. I like the rapid prototyping of dynamic typing, and a type system often times gets in the way of that.

wwwigham 7y ago
Even if you don't opt in to full TypeScript, please do remember that the same engine powering the TypeScript language is also what powers IDE support and completions for JS in vscode and VS, so even if you're not using TypeScript _the language_, you're potentially still using TypeScript, _the static analysis tool_. Even without opting in to full type safety, having those tools available can still be a huge quality of life improvement.
wvenable 7y ago
That's funny, I don't like dynamic typing for the same reason. Rapid prototyping without types makes the whole process so much slower! With dynamic typing, you don't get the immediate feedback of breaks when making frequent changes. You don't get the safety of automatic refactoring. You don't get auto-complete and easy of discovery of APIs. I really don't understand the idea behind dynamic typing being better for prototyping unless that "prototype" is only a few lines long.

benatkin 7y ago

It's a personal preference. Being able to make, fix, and guard against (with testing) type errors is a freedom that I've enjoyed with ruby, python, lisp (scheme/racket), scheme, and JavaScript.

deleted 7y ago
[deleted]
deleted 7y ago
[deleted]

Ididntdothis 7y ago

I am starting to wonder if the preference static vs dynamic is some kind of character trait like introvert vs extrovert. I personally prefer static typing and use it to my advantage during development but I know very smart people who hate static typing and think it impedes them. Both sides have valid arguments but seem to prioritize things differently. However I think it’s important to have used both for a while so you can make a good decision what you prefer.

ajxs 7y ago
At first I thought I was going to read "I am starting to wonder if the preference static vs dynamic is some kind of character trait like intelligent vs ignorant", which would have been much closer to the truth. I think you're very incorrect. Maintaining a codebase of any sufficient size and complexity without static typing is a poor investment of development time. It can be done, obviously, but it's a nightmare. Typescript is a bandaid for web-development's biggest open wound. Taken on its own merits ( ignoring the garbage ecosystem, terrible tooling, etc ) Typescript is a decent enough language, but it's not a clever one. Is Typescript better than vanilla Node.js? Absolutely. Is it worth introducing to an area without Node.js? Absolutely not. If your project is any more complex than a four page CRUD app, in my opinion you're better off going with a bigger player like Java/.Net. These languages are more robust, more mature, there's better tooling, better community... The list goes on.
- Ididntdothis 7y ago
  I am not sure if I want to work with you if you think it’s about “intelligent vs ignorant"... Even though I seem to be in the “intelligent” camp by your definition.
  - ajxs 7y ago
    That's fine.
Old_Thrashbarg 7y ago
> However I think it’s important to have used both for a while so you can make a good decision what you prefer. Exactly, I always found static typing to be annoying clutter and Python seemed to work even at scale. I removed the few type hints the codebase had. Then I had to spend a year in C# professionally. At the end, I was fine with both, no preference. Then I jumped back into our Python and only then realized the utility of typing - it felt chaotic, my (IntelliJ) IDE was no longer helping me and every time I had Prod type related bug, it feeling dumb. Ended up type hinting the critical parts of the Python.

eleclady 7y ago

Personal preference is valid only to an extent. At a certain point, with enough scale/team size/complexity TypeScript becomes invaluable. I've worked on projects that would have been intractable without TypeScript. This is a huge problem with front-end. Too many people who don't know what they don't know, and think their use case is the only one.

lewisl9029 7y ago

I've found that the kinds of errors that static typing guards against are often things that would have been trivial to debug and fix in the first place (mostly things like typos). Given that you have a good system for monitoring errors in production and a low friction deploy process so you can quickly and easily fix errors when you discover them, I feel these kinds of errors are honestly not worth guarding against in most contexts outside of those where getting everything perfectly right the first time is a hard requirement (health, fintech, other safety-critical industries, etc). Of course, most companies lack either or both of these ( a good system for monitoring errors in production and a low friction deploy process), so they use static typing as a clutch to try to reduce the chance of errors making it into prod simply because they know they'd be slow to fix/detect those errors. That's a poor reason to choose static typing IMO, but I think that's by far the most common reason.

almostdeadguy 7y ago
I think “debugging errors in prod” is not generally how I like to spend my working life, with or without excellent logging and tooling for surfacing errors.
- lewisl9029 7y ago
  How this works in practice is usually 1) deploy some change, 2) errors start showing up that correspond to that change, 3) click a button to revert the change instantaneously (some systems can even do this automatically), 4) debug the change in dev
  - almostdeadguy 7y ago
    There is no way any of this process takes less time to solve than "I got a red squiggle in my editor and fixed the variable spelling". I don't think typos are really the only things type systems fix (type systems provide powerful ways of preventing screw-ups by allowing you to encode invariants about a piece of data and how it may be used), but if typos are indeed the extent of it, it seems unimaginable to me that the process to fix would be faster by going through code review -> CI pipeline -> deploy and then back again, no matter how fast it is to revert a change in production. Honestly that's just the compile-time safety advantage of types, half the time saved in typescript is just not spending time having to read someone else's source code to figure out how a function may be used because cowboy js devs were too lazy to document them (knex is an especially egregious offender in this regard that I thankfully don't have to use anymore).