4 ms·

The biggest change for me was when I switched to strictly typed languages. It doesn't matter if it's Go or Typescript or whatever. As long as it has types it dr

The biggest change for me was when I switched to strictly typed languages. It doesn't matter if it's Go or Typescript or whatever. As long as it has types it dramatically improves maintainability and ease of scale.

amirouche 9y ago
what about measurement/profiling
- banashark 9y ago
  I think measurement/profiling in a case like this is hard. How do you measure maintainability without a large database of bugs, iteration performance, etc. I wish it were an easier thing to do, but I think as far as maintainability and codebase size scalability go, it's hard to quantify properly without metrics that are usually only tracked in enterprises. I'm trying to think about how to make this more clear in the original post.
jnbiche 9y ago
I'll echo this sentiment, although I found Go much more limiting type-wise than Typescript, Java, or other mainstream typed language. But in general, moving from PHP, Python and JS (where I started out years ago) to languages like Java, Flow-typed JS, and even Scala at work have made me realize how much dynamically-typed large projects loose in maintainability vis-a-vis statically-typed projects. Yes, excellent test coverage can help mitigate this, but static types go so much farther when used effectively.
brightball 9y ago
I've never experienced this personally, although I hear it said a lot. I generally work on server side applications with a database behind them and 90% of the work involved is taking data from the client and putting it in the database or the other way around. The database handles actual type enforcement. The requests come in as strings and they are returned to the client in string based format. Introducing types to the server side language has never done anything for me other than making sure that the types are in sync with those of the database while creating a lot of tedious overhead converting data that the application itself might not ever need to process to a particular type. The Elixir gradual typing approach has always seemed like the ideal balance to me.
- collyw 9y ago
  That's been my experience as well. Dynamic typing in a language doesn't bother me at all, but the thought of a database without dynamic types doesn't seem right.
seanwilson 9y ago
Agree with this. I've had a large JavaScript codebase where there were so many annoying edge cases mostly caused by variables being null/undefined when you didn't expect it and string/arrays values being mixed up. You could track them down eventually but there was always a feeling of unease that there was more bugs there. If you start using TypeScript with its non-null checking feature and type checking, you can catch so many of these kinds of bugs before even running the code and have high confidence you got them all.

amirouche 9y ago

what about measurement/profiling

banashark 9y ago
I think measurement/profiling in a case like this is hard. How do you measure maintainability without a large database of bugs, iteration performance, etc. I wish it were an easier thing to do, but I think as far as maintainability and codebase size scalability go, it's hard to quantify properly without metrics that are usually only tracked in enterprises. I'm trying to think about how to make this more clear in the original post.

jnbiche 9y ago

I'll echo this sentiment, although I found Go much more limiting type-wise than Typescript, Java, or other mainstream typed language. But in general, moving from PHP, Python and JS (where I started out years ago) to languages like Java, Flow-typed JS, and even Scala at work have made me realize how much dynamically-typed large projects loose in maintainability vis-a-vis statically-typed projects. Yes, excellent test coverage can help mitigate this, but static types go so much farther when used effectively.

brightball 9y ago

I've never experienced this personally, although I hear it said a lot. I generally work on server side applications with a database behind them and 90% of the work involved is taking data from the client and putting it in the database or the other way around. The database handles actual type enforcement. The requests come in as strings and they are returned to the client in string based format. Introducing types to the server side language has never done anything for me other than making sure that the types are in sync with those of the database while creating a lot of tedious overhead converting data that the application itself might not ever need to process to a particular type. The Elixir gradual typing approach has always seemed like the ideal balance to me.

collyw 9y ago
That's been my experience as well. Dynamic typing in a language doesn't bother me at all, but the thought of a database without dynamic types doesn't seem right.

seanwilson 9y ago

Agree with this. I've had a large JavaScript codebase where there were so many annoying edge cases mostly caused by variables being null/undefined when you didn't expect it and string/arrays values being mixed up. You could track them down eventually but there was always a feeling of unease that there was more bugs there. If you start using TypeScript with its non-null checking feature and type checking, you can catch so many of these kinds of bugs before even running the code and have high confidence you got them all.