4 ms·

With "dynamic typing" there is no compiler to figure out the types for you. There is only the runtime to print a stack trace (if you're lucky) and bail out. The

With "dynamic typing" there is no compiler to figure out the types for you. There is only the runtime to print a stack trace (if you're lucky) and bail out. The whole point of types is to be able to check things without running the program, because exercising every possible code path becomes increasingly untenable at scale. A side (but many would also say critical) benefit of types is that they act as a form of documentation that can never go stale (because they are enforced by the compiler). "Dynamic typing" does not offer this benefit whatsoever.

k__ 3y ago
As far as I know, JS is weakly typed and Python is strongly typed. JS will convert types under your butt if you're not careful, Python won't. Sure, static typing (when done well) is superior to that, but the title talks about strong typing.
dartos 3y ago
Many dynamically typed languages have static analyzers, but retain the flexibility of not needing to prescribe types up front (it’s impossible to know exactly what data structure you need at the start of a project) That’s the crux of why I’m not all in on static typing all the time. (Especially for networked programs that expect a wide range of different kinds of input) Having to prescribe the types I need before I actually need them goes against how I tend to build.
- sfn42 3y ago
  Sounds like you'd like C#. It does type inference with `var` and similar things, so you don't always have to specify types explicitly, but everything does have a type at compile time.
  - Smaug123 3y ago
    (C#'s type inference is so much worse than F#'s. I find it deeply painful to go back.)
- loup-vaillant 3y ago
  > Many dynamically typed languages have static analyzers, but retain the flexibility of not needing to prescribe types up front Almost all static type systems have escape hatches that let you go dynamic when you really really need it. Also, I bet that most of your use cases for dynamic typing could be solved with a simple tagged union. Most people bemoaning the lack of flexibility of static typing just don’t know about how tagged unions can easily emulate dynamic typing when we need it, such that we rarely even need to reach for the actual escape hatches. > (it’s impossible to know exactly what data structure you need at the start of a project) Thankfully data structures are even easier to change with static typing: change it, gets a ton of type errors, fix them, done. With dynamic typing you run the risk of missing a call site. > Having to prescribe the types I need before I actually need them goes against how I tend to build. There’s type inference for that. I personally take advantage of it any chance I get.
pfdietz 3y ago
Dynamic typing doesn't exclude the compiler from being able to detect some things that would cause errors at run time. It just means that these turn into compile time warnings, not compile errors. In Common Lisp, it's common practice to not accept code unless all such warnings are gone.
- chongli 3y ago
  That is static typing. You can add static types to a dynamic language, but then you introduce a compilation step. This is not an argument in favour of dynamic typing. If your language requires a compilation step anyway, then what you have is a static language with only one type: the ‘any’ type. Every argument I’ve seen in favour of dynamic typing is some variation of “I like it this way.” They’re not technical arguments because dynamic typing is a strict subset of a statically typed language, equivalent to passing a flag to turn the type checker off. Sure, not every compiler offers such a flag, but that is an argument against one particular static language (or group of languages), not an argument against static types itself.
marcosdumay 3y ago
> There is only the runtime to print a stack trace Types are not exclusively for verification, and even if you decide it is, you can do a lot more with a type error than exiting the program. That stance most people keep repeating is actually ridiculous. The most common usage of static type systems is to verify badly-written ad-hock dynamic ones that handle user errors.
kerkeslager 3y ago
> With "dynamic typing" there is no compiler to figure out the types for you. There is only the runtime to print a stack trace (if you're lucky) and bail out. This is just incorrect. Plenty, if not most, dynamically-typed languages are compiled. Indeed even the idea that there's a clean dichotomy between compiled and interpreted is an outdated idea: I'm not aware of any production-quality language implementations which run tree-walk interpreters entirely without compilation. Modern "interpreters" typically compile to bytecode but in some cases even can compile to native code, they simply do so in a just-in-time manner. These compilation steps are quite capable of applying type systems. For example, if you run a Python script, you can see the results of compilation cached in .pyc files (these will be either in the same directory as the source files, or in your __pycache__ folder, depending on your configuration). > The whole point of types is to be able to check things without running the program, because exercising every possible code path becomes increasingly untenable at scale. Is it? I would argue that the point of types is to report errors at the place where they occur, rather than doing the wrong thing silently and reporting an error elsewhere, or simply behaving incorrectly. If a tree falls in a forest and nobody hears it fall, does it really fall at all? If a bug happens on a code path, and nobody exercises that code path, is there really a bug?

k__ 3y ago

As far as I know, JS is weakly typed and Python is strongly typed. JS will convert types under your butt if you're not careful, Python won't. Sure, static typing (when done well) is superior to that, but the title talks about strong typing.

dartos 3y ago

Many dynamically typed languages have static analyzers, but retain the flexibility of not needing to prescribe types up front (it’s impossible to know exactly what data structure you need at the start of a project) That’s the crux of why I’m not all in on static typing all the time. (Especially for networked programs that expect a wide range of different kinds of input) Having to prescribe the types I need before I actually need them goes against how I tend to build.

sfn42 3y ago
Sounds like you'd like C#. It does type inference with `var` and similar things, so you don't always have to specify types explicitly, but everything does have a type at compile time.
- Smaug123 3y ago
  (C#'s type inference is so much worse than F#'s. I find it deeply painful to go back.)
loup-vaillant 3y ago
> Many dynamically typed languages have static analyzers, but retain the flexibility of not needing to prescribe types up front Almost all static type systems have escape hatches that let you go dynamic when you really really need it. Also, I bet that most of your use cases for dynamic typing could be solved with a simple tagged union. Most people bemoaning the lack of flexibility of static typing just don’t know about how tagged unions can easily emulate dynamic typing when we need it, such that we rarely even need to reach for the actual escape hatches. > (it’s impossible to know exactly what data structure you need at the start of a project) Thankfully data structures are even easier to change with static typing: change it, gets a ton of type errors, fix them, done. With dynamic typing you run the risk of missing a call site. > Having to prescribe the types I need before I actually need them goes against how I tend to build. There’s type inference for that. I personally take advantage of it any chance I get.

pfdietz 3y ago

Dynamic typing doesn't exclude the compiler from being able to detect some things that would cause errors at run time. It just means that these turn into compile time warnings, not compile errors. In Common Lisp, it's common practice to not accept code unless all such warnings are gone.

chongli 3y ago
That is static typing. You can add static types to a dynamic language, but then you introduce a compilation step. This is not an argument in favour of dynamic typing. If your language requires a compilation step anyway, then what you have is a static language with only one type: the ‘any’ type. Every argument I’ve seen in favour of dynamic typing is some variation of “I like it this way.” They’re not technical arguments because dynamic typing is a strict subset of a statically typed language, equivalent to passing a flag to turn the type checker off. Sure, not every compiler offers such a flag, but that is an argument against one particular static language (or group of languages), not an argument against static types itself.

marcosdumay 3y ago

> There is only the runtime to print a stack trace Types are not exclusively for verification, and even if you decide it is, you can do a lot more with a type error than exiting the program. That stance most people keep repeating is actually ridiculous. The most common usage of static type systems is to verify badly-written ad-hock dynamic ones that handle user errors.

kerkeslager 3y ago

> With "dynamic typing" there is no compiler to figure out the types for you. There is only the runtime to print a stack trace (if you're lucky) and bail out. This is just incorrect. Plenty, if not most, dynamically-typed languages are compiled. Indeed even the idea that there's a clean dichotomy between compiled and interpreted is an outdated idea: I'm not aware of any production-quality language implementations which run tree-walk interpreters entirely without compilation. Modern "interpreters" typically compile to bytecode but in some cases even can compile to native code, they simply do so in a just-in-time manner. These compilation steps are quite capable of applying type systems. For example, if you run a Python script, you can see the results of compilation cached in .pyc files (these will be either in the same directory as the source files, or in your __pycache__ folder, depending on your configuration). > The whole point of types is to be able to check things without running the program, because exercising every possible code path becomes increasingly untenable at scale. Is it? I would argue that the point of types is to report errors at the place where they occur, rather than doing the wrong thing silently and reporting an error elsewhere, or simply behaving incorrectly. If a tree falls in a forest and nobody hears it fall, does it really fall at all? If a bug happens on a code path, and nobody exercises that code path, is there really a bug?