Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
Those are the good points to consider about TS!
Even you adding more importance to strong typing that it would had on a good and tested software -regardless of the size- I'll explain myself.
we know that in a perfect world we would probably use TDD, trust our tests at the top of out structure, commit little chunks of code, add proper documentation (not only from devs, but also the features should be documented out of the software on a structured manner) and all IT roles in the project are covered by the best individuals on the industry and so on or we can even fantasise that there's a machine that codes. If we reach this situation for any reason, strong typing would never be a need, because you understand the software you work in and knows how it works, and even when facing a human error, there will be trust-able tests that points us in the right direction.
The need of adding strong typing raises to the moon when we have junior devs, rushing bosses, bad company culture and so on.
Apart from that, for a given piece of software you can discern how big it will be, you always can connect different software made with different technologies without issues so as long as it's decoupled enough and well scoped in it's tasks it will be fine either way.
If you need (need is the keyword here) strong typing, you should be working on something that implicitly needs it for any reason or something bad is happening in your development process. Knowing the cause of this need could be a game changer for you and your teammates.
Arguing that you want it "just in case" is also fine, why not?
You can add TS then if you want mix it with JS if you need it so it will be a good.
Then if we talk about performance, statically typed languages have better performance at run-time intrinsically due to not needing to check types dynamically while executing (it checks before running). Similarly, compiled languages are faster at run time as the code has already been translated instead of needing to “interpret”/translate it on the fly.
TS compiles to JS so there is no issue here on performance, it will -hopefully- be the same than using plain JS.
Those are the good points to consider about TS!
Even you adding more importance to strong typing that it would had on a good and tested software -regardless of the size- I'll explain myself.
Nope - in fact, if you look at my profile, you'll see that I left comment before in one thread where I mentioned the importance of testing. I never said that static types are more important than testing nor that they're sufficient.
I add the importance on static typing because it's been proven over and over that static typed programming languages are better for large scale projects.
strong typing would never be a need, because you understand the software you work in and knows how it works
It would be a need even in that case because humans are not perfect - even with the properly written tests it would be possible to make bunch of mistakes and to pass data of wrong types. Static typing prevents you from making dumb mistakes in the first place.
The need of adding strong typing raises to the moon when we have junior devs, rushing bosses, bad company culture and so on.
No, the need of adding strong typing exists because it has been shown that large scale project written in dynamic typed languages are much harder to maintain. That's one of the reason why TS even came to existence - Microsoft had huge JS code bases and saw how unmaintainable they become after some time (and I'm pretty sure Microsoft engineers do write tests and documentaion).
Types allow you to describe the data and relationship between different data. This allows you to much better predict possible pitfalls (for example, to check if your switch case incorporates all posible cases like Rust does) and so on.
What you're basically saying is that all these static typed languages in the existence today came to be just because there were some cranky bosses and junior devs who couldn't program in dynamic typed lanugages, which couldn't be further from the truth.
Apart from that, for a given piece of software you can discern how big it will be, you always can connect different software made with different technologies without issues so as long as it's decoupled enough and well scoped in it's tasks it will be fine either way.
You can't easily predict how big some software will be. Also, decoupling is a hard process. I know this because I have worked on many microservice based architectures. One bad step and it's easy to make a huge number of errors.
If you need (need is the keyword here) strong typing, you should be working on something that implicitly needs it for any reason or something bad is happening in your development process. Knowing the cause of this need could be a game changer for you and your teammates.
It makes work much easier in the long run. That alone is one of the reasons why I prefer it over the dynamic typing. Sure, that doesn't mean I don't use dynamic typed languages at all - I have a game which is written in Ruby for example.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
Thanks for this kind of comments Nikola, in this discussion I'm playing the role of devil's lawyer but I know those things, I have a career since long time ago. In this platform sometimes I get frustrated because there are many people blind-following things and not even analysing what they should do. Explanations like yours, mines sometimes and other few should get more visibility.
I'll try to pick some time in few days and extract excerpts about all this post in a manner of question/concern -> answer, trying to add external sources for further information and so on for those who want to get more than a surface knowledge and understand the concepts.
In the meantime I'll try to counter some points of view to see how people argue it's opinions or experiences and let's see what can we learn about all those chunks of text! :)
I'll mention you all when this job is done
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.
Now that's what I expect to read from someone!
Those are the good points to consider about TS!
Even you adding more importance to strong typing that it would had on a good and tested software -regardless of the size- I'll explain myself.
we know that in a perfect world we would probably use TDD, trust our tests at the top of out structure, commit little chunks of code, add proper documentation (not only from devs, but also the features should be documented out of the software on a structured manner) and all IT roles in the project are covered by the best individuals on the industry and so on or we can even fantasise that there's a machine that codes. If we reach this situation for any reason, strong typing would never be a need, because you understand the software you work in and knows how it works, and even when facing a human error, there will be trust-able tests that points us in the right direction.
The need of adding strong typing raises to the moon when we have junior devs, rushing bosses, bad company culture and so on.
Apart from that, for a given piece of software you can discern how big it will be, you always can connect different software made with different technologies without issues so as long as it's decoupled enough and well scoped in it's tasks it will be fine either way.
If you need (need is the keyword here) strong typing, you should be working on something that implicitly needs it for any reason or something bad is happening in your development process. Knowing the cause of this need could be a game changer for you and your teammates.
Arguing that you want it "just in case" is also fine, why not?
You can add TS then if you want mix it with JS if you need it so it will be a good.
Then if we talk about performance, statically typed languages have better performance at run-time intrinsically due to not needing to check types dynamically while executing (it checks before running). Similarly, compiled languages are faster at run time as the code has already been translated instead of needing to “interpret”/translate it on the fly.
TS compiles to JS so there is no issue here on performance, it will -hopefully- be the same than using plain JS.
Nope - in fact, if you look at my profile, you'll see that I left comment before in one thread where I mentioned the importance of testing. I never said that static types are more important than testing nor that they're sufficient.
I add the importance on static typing because it's been proven over and over that static typed programming languages are better for large scale projects.
It would be a need even in that case because humans are not perfect - even with the properly written tests it would be possible to make bunch of mistakes and to pass data of wrong types. Static typing prevents you from making dumb mistakes in the first place.
No, the need of adding strong typing exists because it has been shown that large scale project written in dynamic typed languages are much harder to maintain. That's one of the reason why TS even came to existence - Microsoft had huge JS code bases and saw how unmaintainable they become after some time (and I'm pretty sure Microsoft engineers do write tests and documentaion).
Types allow you to describe the data and relationship between different data. This allows you to much better predict possible pitfalls (for example, to check if your switch case incorporates all posible cases like Rust does) and so on.
What you're basically saying is that all these static typed languages in the existence today came to be just because there were some cranky bosses and junior devs who couldn't program in dynamic typed lanugages, which couldn't be further from the truth.
You can't easily predict how big some software will be. Also, decoupling is a hard process. I know this because I have worked on many microservice based architectures. One bad step and it's easy to make a huge number of errors.
It makes work much easier in the long run. That alone is one of the reasons why I prefer it over the dynamic typing. Sure, that doesn't mean I don't use dynamic typed languages at all - I have a game which is written in Ruby for example.
Thanks for this kind of comments Nikola, in this discussion I'm playing the role of devil's lawyer but I know those things, I have a career since long time ago. In this platform sometimes I get frustrated because there are many people blind-following things and not even analysing what they should do. Explanations like yours, mines sometimes and other few should get more visibility.
I'll try to pick some time in few days and extract excerpts about all this post in a manner of question/concern -> answer, trying to add external sources for further information and so on for those who want to get more than a surface knowledge and understand the concepts.
In the meantime I'll try to counter some points of view to see how people argue it's opinions or experiences and let's see what can we learn about all those chunks of text! :)
I'll mention you all when this job is done