To me this isn't really about finding bugs. When the codebase start to grow and you need to find the impact of a change, there are IDE that will be able to find all the impacted code. Sure missing some impacts can be a bug. But just having the complete list is quite valuable. In some simple cases, the IDE will do the change everywhere like if I want to change a class or method name. If I miss some change, most often I'll find the bug early at compile time.
The sooner a problem is found, the lesser the cost.
But this is not only just that. The additional information provided in type provide context and documentation. They are used both by IDE to provide code completion and other nice features but also by developpers to understand what some object/type is able to do or not. This is quite valuable.
A big project with many people will benefit most from static typing as long as the toolling leverage the additional information and more than compensate for the added verbosity.
A small code base by one developper or very few that know by heart the code base what it does and what they want to achieve will be able to take shortcuts with a dynamically typed language and be more productive that way.
Yeah, I agree with all the points you bring up. Although, how often does a small, one person codebase dramatically increase to a large, multi-person project? ;)
I would say most successful projects in a company will eventually become something large. You'll want more features, the people working on it will change over time and so on.
Sure you can be in "one shot" mode where you create a website for client that will not change, maybe even for a short event and then you can trash it. But most often if it work well, if it is valuable you'll want to build on it and it will eventually become huge.
Most of the applications and libraries used by people around the world are actually big or huge. Your operating system, your beloved IDE, your photo sharing program, even just a network library...
But for one successfull application there hundred of failure. If you are alone and can go faster with a dynamic language and can fail faster, that's great. Once there a significant income/budget for the project as people recognize it's value you can always change technology. A bit like twitter that gone from ruby on rails to java and scala.
Note that Smalltalk had good tools and it was dynamically typed, in many types of applications you can write the application while the REPL is on to get lots of information on your project. A lot of IDEs even without using the type annotations used type inference as well, which worked very well with default arguments.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
To me this isn't really about finding bugs. When the codebase start to grow and you need to find the impact of a change, there are IDE that will be able to find all the impacted code. Sure missing some impacts can be a bug. But just having the complete list is quite valuable. In some simple cases, the IDE will do the change everywhere like if I want to change a class or method name. If I miss some change, most often I'll find the bug early at compile time.
The sooner a problem is found, the lesser the cost.
But this is not only just that. The additional information provided in type provide context and documentation. They are used both by IDE to provide code completion and other nice features but also by developpers to understand what some object/type is able to do or not. This is quite valuable.
A big project with many people will benefit most from static typing as long as the toolling leverage the additional information and more than compensate for the added verbosity.
A small code base by one developper or very few that know by heart the code base what it does and what they want to achieve will be able to take shortcuts with a dynamically typed language and be more productive that way.
Yeah, I agree with all the points you bring up. Although, how often does a small, one person codebase dramatically increase to a large, multi-person project? ;)
I would say most successful projects in a company will eventually become something large. You'll want more features, the people working on it will change over time and so on.
Sure you can be in "one shot" mode where you create a website for client that will not change, maybe even for a short event and then you can trash it. But most often if it work well, if it is valuable you'll want to build on it and it will eventually become huge.
Most of the applications and libraries used by people around the world are actually big or huge. Your operating system, your beloved IDE, your photo sharing program, even just a network library...
But for one successfull application there hundred of failure. If you are alone and can go faster with a dynamic language and can fail faster, that's great. Once there a significant income/budget for the project as people recognize it's value you can always change technology. A bit like twitter that gone from ruby on rails to java and scala.
Note that Smalltalk had good tools and it was dynamically typed, in many types of applications you can write the application while the REPL is on to get lots of information on your project. A lot of IDEs even without using the type annotations used type inference as well, which worked very well with default arguments.