3 answered the objection about misspelled variable names.
source | link

Need the programer in compiled, strictly-typed need to write less code since he/she doesn't have to constantly check for correct types ( instance of operator ) since the compiler catches those things ( the same applying to misspelled variable names or uninitiated variables ) ?

I write almost exclusively in dynamically typed languages, and I almost never have to check for correct types. First, the program will throw a type or no method error if I use the wrong type somewhere, and second, I tend to use the types I intend to use where I intend to use them.

An edit on that first point based on a comment below: yes, the program will throw that error "at runtime". But since I run portions of the program easily as often as I would compile in a statically typed language (possibly more often), this isn't particularly relevant. "Runtime" doesn't mean "production", it means "when I run my unit tests". When I run my unit tests, if I am calling a method that doesn't exist on a type, I'll get a no method error.

While it is true that people make mistakes and sometimes write code that divides a char by an array, this is less common than you would think. Most code is fairly type safe by design... if it weren't mostly type consistent, it wouldn't work and wouldn't pass its unit tests.

Similarly, in my experience, unit testing doesn't need to be any more thorough in say, Ruby than it does in Java... I use unit testing to test the behavior of methods and classes, not for type checking. The type checking is implicit... type mismatches throw errors that indicate errors in my code that should be solved by better code, not by adding type checks.

A further edit based on another comment -- no, my unit testing does not have to be more extensive and I do not have to write more code to make sure I didn't misspell a variable name inside a nested conditional.

If I needed a variable to change values based on some logic branch and it doesn't because I accidentally declared a new variable, I'll catch that while unit testing behavior, not unit testing variable names and type checking. I would write the same unit test in a static-explicit language, and while I might get a compile error instead of a failed test the end result is the same: I'll see the mistake and fix the code when I run the unit test that is checking that I get the right behavior, not that I'm using the right types and variables.

If I am writing code where that kind of mistake could slip through my unit tests, my problem is not that I'm using a dynamic-implicit language, it's that I'm writing bad code with untracked side-effects. Using a static-explicit language isn't going to help me there, it's just going to give me a false sense of security about my bad code.

Need the programer in compiled, strictly-typed need to write less code since he/she doesn't have to constantly check for correct types ( instance of operator ) since the compiler catches those things ( the same applying to misspelled variable names or uninitiated variables ) ?

I write almost exclusively in dynamically typed languages, and I almost never have to check for correct types. First, the program will throw a type or no method error if I use the wrong type somewhere, and second, I tend to use the types I intend to use where I intend to use them.

An edit on that first point based on a comment below: yes, the program will throw that error "at runtime". But since I run portions of the program easily as often as I would compile in a statically typed language (possibly more often), this isn't particularly relevant. "Runtime" doesn't mean "production", it means "when I run my unit tests". When I run my unit tests, if I am calling a method that doesn't exist on a type, I'll get a no method error.

While it is true that people make mistakes and sometimes write code that divides a char by an array, this is less common than you would think. Most code is fairly type safe by design... if it weren't mostly type consistent, it wouldn't work and wouldn't pass its unit tests.

Similarly, in my experience, unit testing doesn't need to be any more thorough in say, Ruby than it does in Java... I use unit testing to test the behavior of methods and classes, not for type checking. The type checking is implicit... type mismatches throw errors that indicate errors in my code that should be solved by better code, not by adding type checks.

Need the programer in compiled, strictly-typed need to write less code since he/she doesn't have to constantly check for correct types ( instance of operator ) since the compiler catches those things ( the same applying to misspelled variable names or uninitiated variables ) ?

I write almost exclusively in dynamically typed languages, and I almost never have to check for correct types. First, the program will throw a type or no method error if I use the wrong type somewhere, and second, I tend to use the types I intend to use where I intend to use them.

An edit on that first point based on a comment below: yes, the program will throw that error "at runtime". But since I run portions of the program easily as often as I would compile in a statically typed language (possibly more often), this isn't particularly relevant. "Runtime" doesn't mean "production", it means "when I run my unit tests". When I run my unit tests, if I am calling a method that doesn't exist on a type, I'll get a no method error.

While it is true that people make mistakes and sometimes write code that divides a char by an array, this is less common than you would think. Most code is fairly type safe by design... if it weren't mostly type consistent, it wouldn't work and wouldn't pass its unit tests.

Similarly, in my experience, unit testing doesn't need to be any more thorough in say, Ruby than it does in Java... I use unit testing to test the behavior of methods and classes, not for type checking. The type checking is implicit... type mismatches throw errors that indicate errors in my code that should be solved by better code, not by adding type checks.

A further edit based on another comment -- no, my unit testing does not have to be more extensive and I do not have to write more code to make sure I didn't misspell a variable name inside a nested conditional.

If I needed a variable to change values based on some logic branch and it doesn't because I accidentally declared a new variable, I'll catch that while unit testing behavior, not unit testing variable names and type checking. I would write the same unit test in a static-explicit language, and while I might get a compile error instead of a failed test the end result is the same: I'll see the mistake and fix the code when I run the unit test that is checking that I get the right behavior, not that I'm using the right types and variables.

If I am writing code where that kind of mistake could slip through my unit tests, my problem is not that I'm using a dynamic-implicit language, it's that I'm writing bad code with untracked side-effects. Using a static-explicit language isn't going to help me there, it's just going to give me a false sense of security about my bad code.

2 added 894 characters in body
source | link

Need the programer in compiled, strictly-typed need to write less code since he/she doesn't have to constantly check for correct types ( instance of operator ) since the compiler catches those things ( the same applying to misspelled variable names or uninitiated variables ) ?

I write almost exclusively in dynamically typed languages, and I almost never have to check for correct types. First, the program will throw a type or no method error if I use the wrong type somewhere, and second, I tend to use the types I intend to use where I intend to use them.

An edit on that first point based on a comment below: yes, the program will throw that error "at runtime". But since I run portions of the program easily as often as I would compile in a statically typed language (possibly more often), this isn't particularly relevant. "Runtime" doesn't mean "production", it means "when I run my unit tests". When I run my unit tests, if I am calling a method that doesn't exist on a type, I'll get a no method error.

While it is true that people make mistakes and sometimes write code that divides a char by an array, this is less common than you would think. Most code is fairly type safe by design... if it weren't mostly type consistent, it wouldn't work and wouldn't pass its unit tests.

Similarly, in my experience, unit testing doesn't need to be any more thorough in say, Ruby than it does in Java... I use unit testing to test the behavior of methods and classes, not for type checking. The type checking is implicit... type mismatches throw errors that indicate errors in my code that should be solved by better code, not by adding type checks.

Need the programer in compiled, strictly-typed need to write less code since he/she doesn't have to constantly check for correct types ( instance of operator ) since the compiler catches those things ( the same applying to misspelled variable names or uninitiated variables ) ?

I write almost exclusively in dynamically typed languages, and I almost never have to check for correct types. First, the program will throw a type or no method error if I use the wrong type somewhere, and second, I tend to use the types I intend to use where I intend to use them.

Similarly, in my experience, unit testing doesn't need to be any more thorough in say, Ruby than it does in Java... I use unit testing to test the behavior of methods and classes, not for type checking.

Need the programer in compiled, strictly-typed need to write less code since he/she doesn't have to constantly check for correct types ( instance of operator ) since the compiler catches those things ( the same applying to misspelled variable names or uninitiated variables ) ?

I write almost exclusively in dynamically typed languages, and I almost never have to check for correct types. First, the program will throw a type or no method error if I use the wrong type somewhere, and second, I tend to use the types I intend to use where I intend to use them.

An edit on that first point based on a comment below: yes, the program will throw that error "at runtime". But since I run portions of the program easily as often as I would compile in a statically typed language (possibly more often), this isn't particularly relevant. "Runtime" doesn't mean "production", it means "when I run my unit tests". When I run my unit tests, if I am calling a method that doesn't exist on a type, I'll get a no method error.

While it is true that people make mistakes and sometimes write code that divides a char by an array, this is less common than you would think. Most code is fairly type safe by design... if it weren't mostly type consistent, it wouldn't work and wouldn't pass its unit tests.

Similarly, in my experience, unit testing doesn't need to be any more thorough in say, Ruby than it does in Java... I use unit testing to test the behavior of methods and classes, not for type checking. The type checking is implicit... type mismatches throw errors that indicate errors in my code that should be solved by better code, not by adding type checks.

1
source | link

Need the programer in compiled, strictly-typed need to write less code since he/she doesn't have to constantly check for correct types ( instance of operator ) since the compiler catches those things ( the same applying to misspelled variable names or uninitiated variables ) ?

I write almost exclusively in dynamically typed languages, and I almost never have to check for correct types. First, the program will throw a type or no method error if I use the wrong type somewhere, and second, I tend to use the types I intend to use where I intend to use them.

Similarly, in my experience, unit testing doesn't need to be any more thorough in say, Ruby than it does in Java... I use unit testing to test the behavior of methods and classes, not for type checking.