7 ms·

Can you provide an example where static typing slows you down compared to dynamic typing? I've been using static typing for decades and the only problem I can

by DenisM 8y ago

Can you provide an example where static typing slows you down compared to dynamic typing? I've been using static typing for decades and the only problem I can imagine is having to add an object property definition instead of just using it. And I can't imagine this extra operation being a significant drag. Is it for you?

shabbyrobe 8y ago
It could just be that the devs on a team don't know how to use those tools yet. Having to learn how to use TypeScript effectively while establishing the patterns that underpin a new project would definitely slow you down. Maybe that's a cost you can bear early on, but maybe it isn't.
franciscop 8y ago
For example, having a compiling system. That is a drag for everyone, but especially for newcomers and people getting started. Edit: can you really not imagine any situation where typescript slows down some team in some situations? :)
- tom_ 8y ago
  These people reap the greatest benefit, because they are least familiar with the codebase and get the most out of having the computer check their changes make sense.
  - franciscop 8y ago
    Totally agreed. I'm not saying that they would not get benefits! I'm just saying there's also a cost and that might be the difference from someone continuing learning or giving up.
    - tom_ 8y ago
      I was assuming professional programmers with at least some experience - the article is about the toolchain in use by Airbnb.
  - cellularmitosis 8y ago
    I’m not sure. A newbie experiencing a truly interactive REPL-style environment might be way faster than being stuck in an edit-compile-debug loop.
- root_axis 8y ago
  There is a cost to breaking up your logic into various modules/packages on the file system when you could simply write all your code in one gigantic file and not worry about any of that. Just because it saves time doesn't mean it's the best choice.
  - franciscop 8y ago
    Is there any situation where it'd be better to keep all your JS to a single file?
    - hombre_fatal 8y ago
      Premature extraction can solidify premature abstractions and create pressure against reabstraction. The creator of Elm has a talk that mentions this: https://www.youtube.com/watch?v=XpDsk374LDE https://www.youtube.com/watch?v=XpDsk374LDE
- james_s_tayler 8y ago
  Depends on compile/deploy times really. 5 minutes per cycle is painful. 30 seconds not so much. You often just compile the part you need and that can be very fast. Depends on the language too. I've found .NET turnaround times faster than Java for example.
geowwy 8y ago
This is my question as well. I think about types even when I don't explicitly declare them. "Function x will return a list of a" "Function y will return an instance of b or null" "Function z will return an instance of c or throw an error" How much time am I losing by putting that information in the function declaration? I doubt it's more than the time I lose when a function returns or throws something it wasn't supposed to.
- Guthur 8y ago
  You do this because that's how you have trained yourself to think about code. It's a little self centered too assume this for everyone else.
  - int_19h 8y ago
    Thinking about data contracts for inputs and outputs is pretty basic stuff. If you don't do that, how do you know what your code actually does?
    - carlmr 8y ago
      They don't, but they're fast and fail often.
    - regularfry 8y ago
      There's a gap between things it might make sense to consider as data contracts, and things that can be expressed in practical type systems in common use. One example: a function which, when given a single element, returns a single transform of that element. When passed a list of elements, returns a map of that transform over the list. You can argue as to whether that's a good idea or not, but I've seen JS functions that make sense in context which do that. This might just be my lack of type system expressivity knowledge, but how would one annotate the type of that function? I get that you could use a union type on the param and the return value, but not how you link the two.
      - hombre_fatal 8y ago
mrep 8y ago
>Can you provide an example where static typing slows you down compared to dynamic typing? I spend an annoying amount of time trying to compare/add/multiply... different types in C++ like time, durations, dates, ints, floats in my day job. > And I can't imagine this extra operation being a significant drag. If you have an open source C++ web framework that you think is comparable in features to python django or ruby on rails, I would be very interested as I do want the performance improvements but all the ones I have looked at look like way more work to implement what I want than using django/RoR.
- int_19h 8y ago
  > I spend an annoying amount of time trying to compare/add/multiply... different types in C++ like time, durations, dates, ints, floats in my day job. Multiplying ints and floats "just works" in C (although you have to mind overflow, but that's not a type issues). Other examples don't make a lot of sense. E.g. why would you need to multiply time by duration, or compare one with the other? They're different quantities, reflected as such in the type system. That it won't let you do something like that is the whole point - it would be a bug if it did (and if not, then the data types were chosen wrongly). OTOH, adding a duration to a date is semantically meaningful - which is why std::chrono has operator+ overloaded for various combinations of time_point and duration.
  - mrep 8y ago
    > and if not, the data types were chosen wrongly That is kind of my point. When I use C++ in my day job, there are highly optimized libraries/classes which makes sense considering the amount of work that needs to be done. However, if I am just trying to do some quick data analysis and the data set is small, I just want to do some quick math on some basic data and not have to write code to convert between every single type under the sun. With dynamic types, I can quickly convert data between dictionaries, sets, lists and what not and run it extremely quickly. That is much quicker than trying to compile and run code to transform data into the results I am trying to create.
    - cjs_2 8y ago
skohan 8y ago
Exactly. In fact, I find dynamic types to be much slower to work with in the long-run. For example, with a statically typed language, just one look at the method signature is sufficient to know exactly what it has to be passed. In the worst example of dynamic typing, in Javascript I don't even know how many arguments have to be passed. I probably have to look at the API documentation, and hope the author gave details about what the function is expecting. And compile-time errors are much cheaper than runtime errors.
SomeHacker44 8y ago
Depends on the problem. As a user if both Haskell and various LISPs since 1990, I would say I personally am as productive in both strongly typed and dynamically typed languages, assuming I have a match between my problem and my platform, and avoid overengineering my types (heh). I am also equally productive in what I consider weakly typed languages (hello, Java), when I can avoid boilerplate hell. Bottom line is I think the productivity of the developer is more a function of the familiarity with the language, platform, tooling and problem (and proposed solution) than how strongly typed the language is. I do find that having a REPL improves productivity in essentially all cases.
jondubois 8y ago
- Slow debug cycle due to increased compile time. If using TDD, it takes longer to run tests. The delays adds up - Especially on large projects and especially if you're not used to having a build step during development. - Sporadic source mapping issues/bugs which makes it hard to fix things (I had an issue with Mocha tests last week where it was always telling me that the issue was on line 1). I've worked with TypeScript on multiple projects across different companies but every single time, there has been source mapping or configuration issues of some kind. - Type definitions from DefinitelyTyped are often out of date or have missing properties/methods. It means that I can't use the latest version of a library. - Third party libraries are difficult to integrate into my project's code due to conflicts in type names or structural philosophy (e.g. they leverage types to impose constraints which are inconsistent with my project requirements). - Doesn't guarantee type safety at runtime; e.g. If parsing an object from JSON at runtime; you still need to do type validation explicitly. The 'unknown' type helps but it's not clear that this whole flow of validating unknown data and then casting to a known type adds any value over regular schema validation done in plain JavaScript. - Whenever I write any class/method, I have to spend a considerable amount of time and energy thinking about how to impose constraints on the user of the library/module instead of assuming that the user is an intelligent person who knows what they're doing. - Compiler warnings make it hard to test code quickly using console.log(...); I'm more reliant on clunky debuggers which slows me down a lot and breaks my train of thought. - The 'rename symbol' feature supported by some IDEs is nice, but if a class or property is mentioned inside a string (e.g. in a test case definition) then it will not rename that; so I still have to do text search after doing a symbol rename and manually clean up. - It takes a lot of time think of good names for interfaces and they are renamed often as project requirements evolve. It's not always clear whether similar concepts should be different types or merged into one. It often comes down to what constraints you want to impose on users; This adds a whole layer of unnecessary mental work which could have been better spent on thinking about logic and coming up with meaningful abstractions which don't require arbitrary constraints to be imposed. - Setting up TypeScript is a pain. - Adds a lot of dependencies and complexity. It's a miracle that TypeScript works at all given how much complexity it sweeps under the carpet. Check the output JavaScript. It's ugly.
macca321 8y ago
probably when not using a JetBrains IDE

by DenisM 8y ago

shabbyrobe 8y ago

It could just be that the devs on a team don't know how to use those tools yet. Having to learn how to use TypeScript effectively while establishing the patterns that underpin a new project would definitely slow you down. Maybe that's a cost you can bear early on, but maybe it isn't.

franciscop 8y ago

For example, having a compiling system. That is a drag for everyone, but especially for newcomers and people getting started. Edit: can you really not imagine any situation where typescript slows down some team in some situations? :)

tom_ 8y ago
These people reap the greatest benefit, because they are least familiar with the codebase and get the most out of having the computer check their changes make sense.
- franciscop 8y ago
  Totally agreed. I'm not saying that they would not get benefits! I'm just saying there's also a cost and that might be the difference from someone continuing learning or giving up.
  - tom_ 8y ago
    I was assuming professional programmers with at least some experience - the article is about the toolchain in use by Airbnb.
- cellularmitosis 8y ago
  I’m not sure. A newbie experiencing a truly interactive REPL-style environment might be way faster than being stuck in an edit-compile-debug loop.
root_axis 8y ago
There is a cost to breaking up your logic into various modules/packages on the file system when you could simply write all your code in one gigantic file and not worry about any of that. Just because it saves time doesn't mean it's the best choice.
- franciscop 8y ago
  Is there any situation where it'd be better to keep all your JS to a single file?
  - hombre_fatal 8y ago
    Premature extraction can solidify premature abstractions and create pressure against reabstraction. The creator of Elm has a talk that mentions this: https://www.youtube.com/watch?v=XpDsk374LDE https://www.youtube.com/watch?v=XpDsk374LDE
james_s_tayler 8y ago
Depends on compile/deploy times really. 5 minutes per cycle is painful. 30 seconds not so much. You often just compile the part you need and that can be very fast. Depends on the language too. I've found .NET turnaround times faster than Java for example.

geowwy 8y ago

This is my question as well. I think about types even when I don't explicitly declare them. "Function x will return a list of a" "Function y will return an instance of b or null" "Function z will return an instance of c or throw an error" How much time am I losing by putting that information in the function declaration? I doubt it's more than the time I lose when a function returns or throws something it wasn't supposed to.

Guthur 8y ago
You do this because that's how you have trained yourself to think about code. It's a little self centered too assume this for everyone else.
- int_19h 8y ago
  Thinking about data contracts for inputs and outputs is pretty basic stuff. If you don't do that, how do you know what your code actually does?
  - carlmr 8y ago
    They don't, but they're fast and fail often.
  - regularfry 8y ago
    There's a gap between things it might make sense to consider as data contracts, and things that can be expressed in practical type systems in common use. One example: a function which, when given a single element, returns a single transform of that element. When passed a list of elements, returns a map of that transform over the list. You can argue as to whether that's a good idea or not, but I've seen JS functions that make sense in context which do that. This might just be my lack of type system expressivity knowledge, but how would one annotate the type of that function? I get that you could use a union type on the param and the return value, but not how you link the two.
    - hombre_fatal 8y ago

mrep 8y ago

>Can you provide an example where static typing slows you down compared to dynamic typing? I spend an annoying amount of time trying to compare/add/multiply... different types in C++ like time, durations, dates, ints, floats in my day job. > And I can't imagine this extra operation being a significant drag. If you have an open source C++ web framework that you think is comparable in features to python django or ruby on rails, I would be very interested as I do want the performance improvements but all the ones I have looked at look like way more work to implement what I want than using django/RoR.

int_19h 8y ago
> I spend an annoying amount of time trying to compare/add/multiply... different types in C++ like time, durations, dates, ints, floats in my day job. Multiplying ints and floats "just works" in C (although you have to mind overflow, but that's not a type issues). Other examples don't make a lot of sense. E.g. why would you need to multiply time by duration, or compare one with the other? They're different quantities, reflected as such in the type system. That it won't let you do something like that is the whole point - it would be a bug if it did (and if not, then the data types were chosen wrongly). OTOH, adding a duration to a date is semantically meaningful - which is why std::chrono has operator+ overloaded for various combinations of time_point and duration.
- mrep 8y ago
  > and if not, the data types were chosen wrongly That is kind of my point. When I use C++ in my day job, there are highly optimized libraries/classes which makes sense considering the amount of work that needs to be done. However, if I am just trying to do some quick data analysis and the data set is small, I just want to do some quick math on some basic data and not have to write code to convert between every single type under the sun. With dynamic types, I can quickly convert data between dictionaries, sets, lists and what not and run it extremely quickly. That is much quicker than trying to compile and run code to transform data into the results I am trying to create.
  - cjs_2 8y ago

skohan 8y ago

Exactly. In fact, I find dynamic types to be much slower to work with in the long-run. For example, with a statically typed language, just one look at the method signature is sufficient to know exactly what it has to be passed. In the worst example of dynamic typing, in Javascript I don't even know how many arguments have to be passed. I probably have to look at the API documentation, and hope the author gave details about what the function is expecting. And compile-time errors are much cheaper than runtime errors.

SomeHacker44 8y ago

Depends on the problem. As a user if both Haskell and various LISPs since 1990, I would say I personally am as productive in both strongly typed and dynamically typed languages, assuming I have a match between my problem and my platform, and avoid overengineering my types (heh). I am also equally productive in what I consider weakly typed languages (hello, Java), when I can avoid boilerplate hell. Bottom line is I think the productivity of the developer is more a function of the familiarity with the language, platform, tooling and problem (and proposed solution) than how strongly typed the language is. I do find that having a REPL improves productivity in essentially all cases.

jondubois 8y ago

- Slow debug cycle due to increased compile time. If using TDD, it takes longer to run tests. The delays adds up - Especially on large projects and especially if you're not used to having a build step during development. - Sporadic source mapping issues/bugs which makes it hard to fix things (I had an issue with Mocha tests last week where it was always telling me that the issue was on line 1). I've worked with TypeScript on multiple projects across different companies but every single time, there has been source mapping or configuration issues of some kind. - Type definitions from DefinitelyTyped are often out of date or have missing properties/methods. It means that I can't use the latest version of a library. - Third party libraries are difficult to integrate into my project's code due to conflicts in type names or structural philosophy (e.g. they leverage types to impose constraints which are inconsistent with my project requirements). - Doesn't guarantee type safety at runtime; e.g. If parsing an object from JSON at runtime; you still need to do type validation explicitly. The 'unknown' type helps but it's not clear that this whole flow of validating unknown data and then casting to a known type adds any value over regular schema validation done in plain JavaScript. - Whenever I write any class/method, I have to spend a considerable amount of time and energy thinking about how to impose constraints on the user of the library/module instead of assuming that the user is an intelligent person who knows what they're doing. - Compiler warnings make it hard to test code quickly using console.log(...); I'm more reliant on clunky debuggers which slows me down a lot and breaks my train of thought. - The 'rename symbol' feature supported by some IDEs is nice, but if a class or property is mentioned inside a string (e.g. in a test case definition) then it will not rename that; so I still have to do text search after doing a symbol rename and manually clean up. - It takes a lot of time think of good names for interfaces and they are renamed often as project requirements evolve. It's not always clear whether similar concepts should be different types or merged into one. It often comes down to what constraints you want to impose on users; This adds a whole layer of unnecessary mental work which could have been better spent on thinking about logic and coming up with meaningful abstractions which don't require arbitrary constraints to be imposed. - Setting up TypeScript is a pain. - Adds a lot of dependencies and complexity. It's a miracle that TypeScript works at all given how much complexity it sweeps under the carpet. Check the output JavaScript. It's ugly.

macca321 8y ago

probably when not using a JetBrains IDE