4 ms·

I wonder if most opposition (or even ambivalence) towards strong typing comes from never having used it. If your entire career has been JavaScript, Python, shel

I wonder if most opposition (or even ambivalence) towards strong typing comes from never having used it. If your entire career has been JavaScript, Python, shell scripts, etc.; then you have zero experience with it.

randomdata 3y ago
Python is strongly typed. If your entire career has been Python, you will have a lot of experience with it. Static typing, maybe not so much.
- tonyedgecombe 3y ago
  I wonder if most opposition (or even ambivalence) towards strict typing comes from never having used it. If your entire career has been JavaScript, Python, shell scripts, etc.; then you have zero experience with it. @irrational Sorry for the plagiarism.
siva7 3y ago
You probably mean static type checking. I've used strong typing in the first half of my career and have no hard feelings about it. So no, the opposition isn't about no experience with one or the other.
ilaksh 3y ago
I taught myself Turbo Pascal in middle school (34 years ago) and C/C++ in high school. (Both typed). Over the years, I have done programming with C, C++, Java, C#, PHP, Python, OCaml, Lua, Nim, Golang, Rust, Objective-C, Flash, Bash, D, Scala, TypeScript, assembly, PL/SQL, F#, and a few that I am forgetting. Compile time type checking can definitely make things easier. But for dynamic languages that I have been programming in for many years to have types shoehorned into them as an afterthought feels like a kludge. And it's a tradeoff. I got used to developing in Node or Python with vim without auto completion (although I had those things as a kid in IDEs for other languages and they can be great). And without compile time type checks. You can pass JSON around and literally never do a database migration. This stuff will lead to more runtime errors initially, but also means more streamlined code. And you have to do thorough testing regardless. TypeScript might be a choice for a large project with several developers. But I would also argue that an even better choice would be just to use a different language that has the typing system you want built in rather than awkwardly bolted on. What I see in most TypeScript projects is a half-assed attempt that still results in run time type errors, but with the added "benefit" of an awkward bolted on typing system and the need for more tools as well as losing any dynamic benefit. They drop the idea of using JSON and make everything related to the database compile time checked if possible. I'm not saying that those checks can't be useful but if are going that route it would make more sense to just drop the dynamic language. Having all of the dynamism can be a convenience and save you time and effort in other ways. But not if you treat it as a poor man's static language and shoehorn in types in a half assed way using a traditional database. Part of this is that people think software engineering is about your choice of stack or adding processes to development. What matters most is probably the feedback loop between the users and the developers. Starting with the requirements engineering. Second to that would be details of the software design and organization. Leveraging existing code effectively can be key. Using descriptive but relatively concise identifiers, short functions, good code organization. But diving into and evaluating all of that stuff in detail takes effort and a lot of skill and so many make snap judgements based on surface level processes or tool selection.

randomdata 3y ago

Python is strongly typed. If your entire career has been Python, you will have a lot of experience with it. Static typing, maybe not so much.

tonyedgecombe 3y ago
I wonder if most opposition (or even ambivalence) towards strict typing comes from never having used it. If your entire career has been JavaScript, Python, shell scripts, etc.; then you have zero experience with it. @irrational Sorry for the plagiarism.

siva7 3y ago

You probably mean static type checking. I've used strong typing in the first half of my career and have no hard feelings about it. So no, the opposition isn't about no experience with one or the other.

ilaksh 3y ago

I taught myself Turbo Pascal in middle school (34 years ago) and C/C++ in high school. (Both typed). Over the years, I have done programming with C, C++, Java, C#, PHP, Python, OCaml, Lua, Nim, Golang, Rust, Objective-C, Flash, Bash, D, Scala, TypeScript, assembly, PL/SQL, F#, and a few that I am forgetting. Compile time type checking can definitely make things easier. But for dynamic languages that I have been programming in for many years to have types shoehorned into them as an afterthought feels like a kludge. And it's a tradeoff. I got used to developing in Node or Python with vim without auto completion (although I had those things as a kid in IDEs for other languages and they can be great). And without compile time type checks. You can pass JSON around and literally never do a database migration. This stuff will lead to more runtime errors initially, but also means more streamlined code. And you have to do thorough testing regardless. TypeScript might be a choice for a large project with several developers. But I would also argue that an even better choice would be just to use a different language that has the typing system you want built in rather than awkwardly bolted on. What I see in most TypeScript projects is a half-assed attempt that still results in run time type errors, but with the added "benefit" of an awkward bolted on typing system and the need for more tools as well as losing any dynamic benefit. They drop the idea of using JSON and make everything related to the database compile time checked if possible. I'm not saying that those checks can't be useful but if are going that route it would make more sense to just drop the dynamic language. Having all of the dynamism can be a convenience and save you time and effort in other ways. But not if you treat it as a poor man's static language and shoehorn in types in a half assed way using a traditional database. Part of this is that people think software engineering is about your choice of stack or adding processes to development. What matters most is probably the feedback loop between the users and the developers. Starting with the requirements engineering. Second to that would be details of the software design and organization. Leveraging existing code effectively can be key. Using descriptive but relatively concise identifiers, short functions, good code organization. But diving into and evaluating all of that stuff in detail takes effort and a lot of skill and so many make snap judgements based on surface level processes or tool selection.