5 ms·

Not sure I've ever heard anyone say static typing removes the need for testing. Types are self-documenting. Onboarding new devs in a large static codebase will

Not sure I've ever heard anyone say static typing removes the need for testing. Types are self-documenting. Onboarding new devs in a large static codebase will be 10x easier than a dynamic one. Coding is actually faster in statically typed projects - autocomplete works every single time and you never have to dig into another source file to see what objects/methods you have. And, most modern type systems (Typescript, Swift, etc) don't have much overhead at all with their impressive type inference.

pg_bot 8y ago
I would disagree with the statement that coding is faster in statically typed projects. The ease of onboarding new devs is solely based on the code quality of the project. Well written programs are easy to understand regardless of typing. Terribly written programs are opaque regardless of typing.
- Tehnix 8y ago
  Sure, any code base can be horrible to learn, but two equally well written code bases, types can help significantly. When your new employee can be confident that changes something in one place, won't invisibly break something in another place, they are more prone to start making changes. Vimal Kumaar touches on how it has helped them get employees contributing to the code a lot quicker, after they moved to PureScript https://www.youtube.com/watch?v=HLEwYghBjo8 https://www.youtube.com/watch?v=HLEwYghBjo8 (I think around 24+ minutes in, but I recommend the whole talk).
- matchbok 8y ago
  If I have to connect a couple classes in separate files with a few objects/stuff inside of them, I'd bet good money that a statically typed language will provide a faster coding experience. Especially if you have leveraging third party libraries. Working in huge libs in JS (Sequelize comes to mind) is a horrible development experience that requires you to have the documentation open.
- eropple 8y ago
  Those Scotsmen are pretty untrue, huh? The claim is pretty facially silly at a glance besides, though. You literally don't know the fields and methods, to say nothing of what they actually give you, on a Ruby object without opening either the code or pulling up Pry and doing `ls`. Which I have done, often enough, to fail rather stunningly to miss doing so when in Kotlin or when using TypeScript. Checked that one? Good news--now you get to drill down into the next one, and the next one. I hope that isn't coming from another library, too, 'cause jumping from library to library in Ruby or Python is a chore. And even if not? God help you if you're using ActiveRecord, I hope you enjoy scanning your database migrations or describing tables just to learn method names. It is a bad scene. And don't get me wrong; I like Ruby quite a lot. But I won't make excuses for it. Personally, with the actual tooling available to modern systems, I write TypeScript much, much faster--we're talking probably twice as fast--than I do even ES6, which I otherwise quite like. And TypeScript can't even assert whether something is a whole number or not, unlike better languages. It has replaced Ruby for me on the strength of that alone.
mping 8y ago
It's a double edged sword - onboard some devs on "advanced" scala code and let me know how the 10x is working for ya. I also feel that sometimes types cause additional congitive load - you have to mentally model the types and what they do. OTOH I'm pretty sure most people can onboard a js project that's well written. I think exploratory, debug-based onboarding can be easier with poorly written static lang codebases that dynamic, but then again depends on what convetions are used. I don't care much about autocomplete unless I have to type ReallyLongClassNamesThatAreSupposedToBeMeaningful; besides coding is mostly about avoiding errors, not typing faster. In the end, whatever floats your boat but dyn langs surely have their place.
- matchbok 8y ago
  I've heard the "mentally model" argument a few times, and tbh I don't quite understand it. You have to model the object regardless, either with types or tons of extra checks to make sure that object has what you need. I've seen so much javascript code do exactly that because the methods had no idea what they were going to be given. The contract of static typing eases that load, I think.
  - mmartinson 8y ago
    Ya for sure. Without getting a debugger into the application code, it sometimes seems completely impossible to look at a piece of dynamic code you're not already familiar with and decide if it's going to work. I've found this especially tough during code reviews for new stuff that make heavy use of abstractions, even when the abstractions are good.
  - mping 8y ago
    Personally I feel that my mind is registering what each type does, kinda like building a mental dictionary. Dynlangs also have types but in terms of reading code it feels you can just skim through and skip the details. I guess there is a difference in the cognitive load of reading code and writing code.
- markmark 8y ago
  When using a dynamic language you need to know what properties are on an object right? So you can work with them, access them, whatever. So just write it down so everyone else knows too. There, that was easy.

pg_bot 8y ago

I would disagree with the statement that coding is faster in statically typed projects. The ease of onboarding new devs is solely based on the code quality of the project. Well written programs are easy to understand regardless of typing. Terribly written programs are opaque regardless of typing.

Tehnix 8y ago
Sure, any code base can be horrible to learn, but two equally well written code bases, types can help significantly. When your new employee can be confident that changes something in one place, won't invisibly break something in another place, they are more prone to start making changes. Vimal Kumaar touches on how it has helped them get employees contributing to the code a lot quicker, after they moved to PureScript https://www.youtube.com/watch?v=HLEwYghBjo8 https://www.youtube.com/watch?v=HLEwYghBjo8 (I think around 24+ minutes in, but I recommend the whole talk).
matchbok 8y ago
If I have to connect a couple classes in separate files with a few objects/stuff inside of them, I'd bet good money that a statically typed language will provide a faster coding experience. Especially if you have leveraging third party libraries. Working in huge libs in JS (Sequelize comes to mind) is a horrible development experience that requires you to have the documentation open.
eropple 8y ago
Those Scotsmen are pretty untrue, huh? The claim is pretty facially silly at a glance besides, though. You literally don't know the fields and methods, to say nothing of what they actually give you, on a Ruby object without opening either the code or pulling up Pry and doing `ls`. Which I have done, often enough, to fail rather stunningly to miss doing so when in Kotlin or when using TypeScript. Checked that one? Good news--now you get to drill down into the next one, and the next one. I hope that isn't coming from another library, too, 'cause jumping from library to library in Ruby or Python is a chore. And even if not? God help you if you're using ActiveRecord, I hope you enjoy scanning your database migrations or describing tables just to learn method names. It is a bad scene. And don't get me wrong; I like Ruby quite a lot. But I won't make excuses for it. Personally, with the actual tooling available to modern systems, I write TypeScript much, much faster--we're talking probably twice as fast--than I do even ES6, which I otherwise quite like. And TypeScript can't even assert whether something is a whole number or not, unlike better languages. It has replaced Ruby for me on the strength of that alone.

mping 8y ago

It's a double edged sword - onboard some devs on "advanced" scala code and let me know how the 10x is working for ya. I also feel that sometimes types cause additional congitive load - you have to mentally model the types and what they do. OTOH I'm pretty sure most people can onboard a js project that's well written. I think exploratory, debug-based onboarding can be easier with poorly written static lang codebases that dynamic, but then again depends on what convetions are used. I don't care much about autocomplete unless I have to type ReallyLongClassNamesThatAreSupposedToBeMeaningful; besides coding is mostly about avoiding errors, not typing faster. In the end, whatever floats your boat but dyn langs surely have their place.

matchbok 8y ago
I've heard the "mentally model" argument a few times, and tbh I don't quite understand it. You have to model the object regardless, either with types or tons of extra checks to make sure that object has what you need. I've seen so much javascript code do exactly that because the methods had no idea what they were going to be given. The contract of static typing eases that load, I think.
- mmartinson 8y ago
  Ya for sure. Without getting a debugger into the application code, it sometimes seems completely impossible to look at a piece of dynamic code you're not already familiar with and decide if it's going to work. I've found this especially tough during code reviews for new stuff that make heavy use of abstractions, even when the abstractions are good.
- mping 8y ago
  Personally I feel that my mind is registering what each type does, kinda like building a mental dictionary. Dynlangs also have types but in terms of reading code it feels you can just skim through and skip the details. I guess there is a difference in the cognitive load of reading code and writing code.
markmark 8y ago
When using a dynamic language you need to know what properties are on an object right? So you can work with them, access them, whatever. So just write it down so everyone else knows too. There, that was easy.