7 ms·

The main argument for dynamic typing is speed in prototyping but I find that's opposite for me. I'm much more comfortable rapid prototyping and ripping stuff a

The main argument for dynamic typing is speed in prototyping but I find that's opposite for me. I'm much more comfortable rapid prototyping and ripping stuff apart when I have a strongly static typed environment telling me what I just broke. Doing radical refactoring often involves just making those changes and then fixing all the IDE or compiler errors until it runs again.

tabbott 5y ago
I would argue that the really big benefit of dynamic typing is that it enables a really nice interactive interpreter shell experience. I think it's also important from a prototyping standpoint that Python's static typing model does a lot of inference -- you don't have to add an explicit type annotation on every single variable.
- nyberg 5y ago
  This is possible with statically typed languages with Haskell being one of the examples where it's encouraged to use the REPL to work towards a solution and/or qucikly test ideas without having to write unit tests or full program tests. Ocaml and friends fall within this category too and none require extensive type annotation due to type inference. I feel that too much focus is on static languages like C/C++ where types become a chore and judging it on that rather than looking at the plenty of languages with type inference brought by ML-style languages.
  - BeFlatXIII 5y ago
    > languages like C/C++ where types become a chore It's been a long while since I used those languages, but I remember the chore part wasn't so much of typing Int or String and more so having to care if it's an Int, Short, or Long or if the float is single or double precision. I believe that those micro-optimizations are no longer popular, but manually thinking low-level is not something I enjoy.
- loup-vaillant 5y ago
  > I would argue that the really big benefit of dynamic typing is that it enables a really nice interactive interpreter shell experience. I use the Python REPL quite often, and have non trivial experience with Lua’s. But the best experience I’ve ever got was with OCaml: I type the expression, or function definition, without giving type annotations, and I get the type of the result in the response. You wouldn’t believe the number of bugs I caught just by looking at the type. Before I even start testing the function. And that’s when I don’t have an outright type error, which a dynamic language wouldn’t have caught — not before I start testing anyway.
ttymck 5y ago
I agree with your point on prototyping. I've never been more productive than when I have the (Scala) compiler acting as a second set of eyes, essentially looking over my shoulder, checking my business logic.
Enginerrrd 5y ago
Dynamic typing was great before I knew anything about programming. I'm talking like, at a middle school level. Fewer "Silly" errors. After university, the opposite became true. No difficult to diagnose undefined behavior because of ambiguity in typing.
agumonkey 5y ago
I used to have loads of fun abusing Eclipse real time type checker, imagining software live with typed interfaces. The IDE was my logical buddy, and every idea's possibility was rapidly shown with it. And I need to massage things a bit, I go faster because I know what's missing. The only time I liked eclipse/java :)
munk-a 5y ago
When I'm prototyping I tend to go inside out in a layered fashion - some days I am really feeling the data layer - other days I like to work closer to the fringes. To this end type hinting serves as a quick and dirty code contract before all my pieces are in place. I can splat out a bunch of low level definitions that I know I'm going to need and then come back the next day to add in struts - remembering my choices easily as I go. I know this isn't the approach of choice for most folks but hey - I'm working with ADHD so I've got to make some allowances for some neurodiversity.
orwin 5y ago
The biggest reason why i like type hints is because it force me to reflect on the datatype i want to use before implementing my code. Last week, i could've done either a dataframe, a list of list, a list of tuple, a dict of tuples, a dict of lists (this was a bad idea that did not survive more than 2s in my head) or a list of dict. I started coding with a dataframe in mind (i guess i wanted to show off my numpy/pandas skills to my devops colleagues), but adding type hints to my prototypes shut down the idea pretty quick: lot of complexity for nothing.
tetha 5y ago
Hm, growing somewhat experienced, I find myself adapating an old quote more and more: Sufficiently advanced static typing is indistinguishable from dynamic typing. Now, I know, it's not true. It's entirely possible to build weird things in python that are provably impossible to typecheck statically. But modern language servers and their type inference capabilities in rust, terraform, or even straight up python are very impressive.
- plmpsu 5y ago
  I don't understand your argument. Could you please explain it?
  - tetha 5y ago
    Type systems simply have matured a lot. It's not too long ago that you either had very clumsy type systems - C, Java. These type systems were more of a chore than anything else. Especially the generic transition in java was just tedious, you had to type cast a lot of stuff, and the compiler would still yell at you, and things would still crash. Or you had very powerful and advanced type systems - Haskell and C++ with templates for example. However, these type systems were just impenetrable. C++ template errors before clang error messages are something. They are certainly an error message. But fixing those without a close delta what happened? Pfsh. Nah. In those days, dynamic typing was great. You could shed the chore of stupid types, and avoid the really arcane work of making really strong types work. However, type systems have matured. Today, you can slap a few type annotations on a python function and a modern type inference engine can give you type prediction, accurate tab-completion and errro detection. In something like rust, you define a couple of types in important locations and everything else is inferred. This in turn gives you the benefit of both: You care about types in a few key locations, but everything else is as simple as a dynamically typed language. And that's when statically typed languages can end up looking almost - or entirely - like a dynamically typed language. Except with less error potential.
    - musicale 5y ago
      > a modern type inference engine can give you type prediction, accurate tab-completion and errro detection (emphasis mine) "errros" are my nemesis in languages which automatically create a new symbol with every typo!
steve_adams_86 5y ago
> when I have a strongly static typed environment telling me what I just broke. Yes, I'm a total scatterbrain. Types let me remind myself later that I did in fact forget what I'm doing and what I did. It lets past-me protect future-me.
Barrin92 5y ago
the main argument for dynamic typing in particular in the context of object oriented programming is decoupling. It is always the receiving object's responsibility to handle whatever they get. if you write dynamic OO languages with a static mentality in mind, i.e. you try to enforce some sort of global type expectation before the program runs, then obviously static languages are better, because you're trying to write static code. Benefiting from dynamic languages means ditching that mindset altogether.
tshaddox 5y ago
I think the only reason dynamic typing can speed up prototyping is that it allows you to make certain type errors that you may never encounter at runtime while prototyping.
tiew9Vii 5y ago
It depends on the language but I find I'm also far more productive with strong types. When I use a dynamic language I get no errors in dev, I need to run/invoke the program to see if it works. It may appear to work fine as I haven't executed a specific code path hence dynamic languages have extremely high test coverage. With dynamic languages I am delaying my feedback loop, I may get some visual output quicker but that doesn't mean my program is correct. With a strongly typed language and utilizing types you use the compiler to guide you. The compiler says hey, this isn't correct, fix it, you go fix the error and recompile and repeat. I've used Elm before and it's the only time I had a complex Javascript UI just compile and work first time. It's like a wow, did that just happen. With Typescript it's not quite to the level of Elm but find my experience working with React etc far more productive. Typescript says hey, that's wrong, I expect ... you gave ..., you work through the errors and when it runs generally there's less silly mistakes than when I just use Javascript. I'm learning Rust, the compiler error messages have greatly helped. When you compile it says hey, you tried to do ..., maybe you want ... instead. Not to sure what the suggestion is I try it and 9 times out of 10 it works, compiles, program runs. With types you generally get better IDE auto complete support etc. Now i'm using Python for my day job. My experience has been painful, discovering what arguments functions take, passing in wrong values, needing to run slow test suites, finding errors at runtime. Yes you can use type hints and I do but I find them far less reliable. I guess I'm not a very good programmer so learnt to lean on a compiler to do the hard work for me, and if you have good type support you can lean on types more to get the compiler to help you more. In Haskell I can write complex logic by writing out the types and ADT's. I've written whole programs with tests to verify the logic without writing a program. I find this incredible efficient for prototyping ideas, just write the types, the functions signitures etc etc. Once that is done you implement the functions, hit compile then boom, your shocked it just worked first time running.
mbrodersen 5y ago
Agree. I usually think types first and quickly sketch the whole application without writing any code. So,when I start writing code it just works end-to-end.

tabbott 5y ago

I would argue that the really big benefit of dynamic typing is that it enables a really nice interactive interpreter shell experience. I think it's also important from a prototyping standpoint that Python's static typing model does a lot of inference -- you don't have to add an explicit type annotation on every single variable.

nyberg 5y ago
This is possible with statically typed languages with Haskell being one of the examples where it's encouraged to use the REPL to work towards a solution and/or qucikly test ideas without having to write unit tests or full program tests. Ocaml and friends fall within this category too and none require extensive type annotation due to type inference. I feel that too much focus is on static languages like C/C++ where types become a chore and judging it on that rather than looking at the plenty of languages with type inference brought by ML-style languages.
- BeFlatXIII 5y ago
  > languages like C/C++ where types become a chore It's been a long while since I used those languages, but I remember the chore part wasn't so much of typing Int or String and more so having to care if it's an Int, Short, or Long or if the float is single or double precision. I believe that those micro-optimizations are no longer popular, but manually thinking low-level is not something I enjoy.
loup-vaillant 5y ago
> I would argue that the really big benefit of dynamic typing is that it enables a really nice interactive interpreter shell experience. I use the Python REPL quite often, and have non trivial experience with Lua’s. But the best experience I’ve ever got was with OCaml: I type the expression, or function definition, without giving type annotations, and I get the type of the result in the response. You wouldn’t believe the number of bugs I caught just by looking at the type. Before I even start testing the function. And that’s when I don’t have an outright type error, which a dynamic language wouldn’t have caught — not before I start testing anyway.

ttymck 5y ago

I agree with your point on prototyping. I've never been more productive than when I have the (Scala) compiler acting as a second set of eyes, essentially looking over my shoulder, checking my business logic.

Enginerrrd 5y ago

Dynamic typing was great before I knew anything about programming. I'm talking like, at a middle school level. Fewer "Silly" errors. After university, the opposite became true. No difficult to diagnose undefined behavior because of ambiguity in typing.

agumonkey 5y ago

I used to have loads of fun abusing Eclipse real time type checker, imagining software live with typed interfaces. The IDE was my logical buddy, and every idea's possibility was rapidly shown with it. And I need to massage things a bit, I go faster because I know what's missing. The only time I liked eclipse/java :)

munk-a 5y ago

When I'm prototyping I tend to go inside out in a layered fashion - some days I am really feeling the data layer - other days I like to work closer to the fringes. To this end type hinting serves as a quick and dirty code contract before all my pieces are in place. I can splat out a bunch of low level definitions that I know I'm going to need and then come back the next day to add in struts - remembering my choices easily as I go. I know this isn't the approach of choice for most folks but hey - I'm working with ADHD so I've got to make some allowances for some neurodiversity.

orwin 5y ago

The biggest reason why i like type hints is because it force me to reflect on the datatype i want to use before implementing my code. Last week, i could've done either a dataframe, a list of list, a list of tuple, a dict of tuples, a dict of lists (this was a bad idea that did not survive more than 2s in my head) or a list of dict. I started coding with a dataframe in mind (i guess i wanted to show off my numpy/pandas skills to my devops colleagues), but adding type hints to my prototypes shut down the idea pretty quick: lot of complexity for nothing.

tetha 5y ago

Hm, growing somewhat experienced, I find myself adapating an old quote more and more: Sufficiently advanced static typing is indistinguishable from dynamic typing. Now, I know, it's not true. It's entirely possible to build weird things in python that are provably impossible to typecheck statically. But modern language servers and their type inference capabilities in rust, terraform, or even straight up python are very impressive.

plmpsu 5y ago
I don't understand your argument. Could you please explain it?
- tetha 5y ago
  Type systems simply have matured a lot. It's not too long ago that you either had very clumsy type systems - C, Java. These type systems were more of a chore than anything else. Especially the generic transition in java was just tedious, you had to type cast a lot of stuff, and the compiler would still yell at you, and things would still crash. Or you had very powerful and advanced type systems - Haskell and C++ with templates for example. However, these type systems were just impenetrable. C++ template errors before clang error messages are something. They are certainly an error message. But fixing those without a close delta what happened? Pfsh. Nah. In those days, dynamic typing was great. You could shed the chore of stupid types, and avoid the really arcane work of making really strong types work. However, type systems have matured. Today, you can slap a few type annotations on a python function and a modern type inference engine can give you type prediction, accurate tab-completion and errro detection. In something like rust, you define a couple of types in important locations and everything else is inferred. This in turn gives you the benefit of both: You care about types in a few key locations, but everything else is as simple as a dynamically typed language. And that's when statically typed languages can end up looking almost - or entirely - like a dynamically typed language. Except with less error potential.
  - musicale 5y ago
    > a modern type inference engine can give you type prediction, accurate tab-completion and errro detection (emphasis mine) "errros" are my nemesis in languages which automatically create a new symbol with every typo!

steve_adams_86 5y ago

> when I have a strongly static typed environment telling me what I just broke. Yes, I'm a total scatterbrain. Types let me remind myself later that I did in fact forget what I'm doing and what I did. It lets past-me protect future-me.

Barrin92 5y ago

the main argument for dynamic typing in particular in the context of object oriented programming is decoupling. It is always the receiving object's responsibility to handle whatever they get. if you write dynamic OO languages with a static mentality in mind, i.e. you try to enforce some sort of global type expectation before the program runs, then obviously static languages are better, because you're trying to write static code. Benefiting from dynamic languages means ditching that mindset altogether.

tshaddox 5y ago

I think the only reason dynamic typing can speed up prototyping is that it allows you to make certain type errors that you may never encounter at runtime while prototyping.

tiew9Vii 5y ago

It depends on the language but I find I'm also far more productive with strong types. When I use a dynamic language I get no errors in dev, I need to run/invoke the program to see if it works. It may appear to work fine as I haven't executed a specific code path hence dynamic languages have extremely high test coverage. With dynamic languages I am delaying my feedback loop, I may get some visual output quicker but that doesn't mean my program is correct. With a strongly typed language and utilizing types you use the compiler to guide you. The compiler says hey, this isn't correct, fix it, you go fix the error and recompile and repeat. I've used Elm before and it's the only time I had a complex Javascript UI just compile and work first time. It's like a wow, did that just happen. With Typescript it's not quite to the level of Elm but find my experience working with React etc far more productive. Typescript says hey, that's wrong, I expect ... you gave ..., you work through the errors and when it runs generally there's less silly mistakes than when I just use Javascript. I'm learning Rust, the compiler error messages have greatly helped. When you compile it says hey, you tried to do ..., maybe you want ... instead. Not to sure what the suggestion is I try it and 9 times out of 10 it works, compiles, program runs. With types you generally get better IDE auto complete support etc. Now i'm using Python for my day job. My experience has been painful, discovering what arguments functions take, passing in wrong values, needing to run slow test suites, finding errors at runtime. Yes you can use type hints and I do but I find them far less reliable. I guess I'm not a very good programmer so learnt to lean on a compiler to do the hard work for me, and if you have good type support you can lean on types more to get the compiler to help you more. In Haskell I can write complex logic by writing out the types and ADT's. I've written whole programs with tests to verify the logic without writing a program. I find this incredible efficient for prototyping ideas, just write the types, the functions signitures etc etc. Once that is done you implement the functions, hit compile then boom, your shocked it just worked first time running.

mbrodersen 5y ago

Agree. I usually think types first and quickly sketch the whole application without writing any code. So,when I start writing code it just works end-to-end.