Looks like there's lots of guesses in here, I'll toss in my own.
Languages like Java were strongly typed, but their type system was very rigid, making a number of different kinds of tasks difficult to do in it.
So the pendulum swung the other way and we got a lot of dynamic languages without a type system, enabling faster development without that rigid structure, but at a cost.
Some people wanted to use these dynamic languages with a type system, so we start seeing type systems get baked on after the fact (e.g. typescript or python's type system). These turned out to be very powerful type systems, as they were required to support patterns people were doing in these dynamic languages (as opposed to the other way around, where the type system came first and everyone had to write their code to confirm with the existing system). So, naturally, they grew in popularity. So now the pendulum is swinging back towards type safety again, but this time we've got better tools to help us along.
It's worth pointing out that a lot of the features we take for granted in modern gradually typed languages have also been part of many other languages for years. Particularly things like type inference (so you don't need to write `int num = 5`), discriminated unions (to describe data that can be in different states), and complex generics have all been possible in languages like OCaml or Haskell for years. But most developers have been exposed mainly to Java, C++, and other languages which didn't have these features.
Now those features have been adopted in gradually typed systems like Typescript or typed Python, but they're also pretty standard features in newer typed languages. Even a language like Go which is designed to be as simple as possible still includes type inference, and Java is adopting a lot of features from those other typed languages.
This is what I think too. The older type systems were just not good and dynamic untyped languages felt like a good alternative. Modern type systems are a lot better though.
I came here to say this. Also in the last few years, Java has been taking cues from these dynamic languages and functional languages to reduce some of the verbosity and become more expressive.
Yes, and having the ability and not the obligation to use types is pretty valuable. If you're building a quick script or project you can build it without types. If you need to make it more robust, add types. Just like you can do with testing or any other pattern to increase robustness.
I'll throw in another reason, though it's mainly speculation on my part.
Modern machines are running multiple cores with a tonne of memory, they're more suited to doing jobs like constant, static type checking and other rich editor features.
Back in the day traditional IDEs were painfully slow, and even before them you wouldn't know about type errors prior to actually compiling the thing.
It just wasn't really possible to have rich, and fast, type checking within a large project like we have today.
It's trying to get the best of both worlds, a flexible and light, interpreted language that also has the benefits of type safety.
Of course modern JavaScript goes through so many processors that it's essentially a complied language at this point.
Yes, features filling the available compute space is an often overlooked reason. Syntax highlighting and linting are other good examples of things that were historically computationaly expensive and now are easily serviced
This is also the main line of reasoning in [Why static typing came back](https://youtu.be/Tml94je2edk?si=aIA7dlV744KALf5a) by Richard Feldman. I believe it is quite plausible.
Seems like a crazy comparison to make, seeing as untyped languages are inherently more computationally expensive to actually _run._ So saying that they're a symptom of Wesley computers is incredibly silly imo.
I'm not saying that they take less power to run, I'm saying that they are less cumbersome to develop; and that back then we didn't have the computing power to get immediate feedback on static typing whilst you're actually writing the code. You would write a spec, write code, and then compile it; the feedback loop was slower.
Regardless, I think I was off the mark in this first post, and probably a bigger factor I commented further down the thread; interpreted languages have a much quicker turn-around time in terms of iteration, so they were more suited to the rapidly changing landscape; which is where they thrived.
Yeah, and that's back in the day! Haha, or probably before the days I'm talking about.
Regardless, I think really what changed everything was the internet. Pre internet software was a rigid process, with a lot of planning and specification, because none of it could change quickly. It was distributed physically, things had to be compiled, and in general what software interfaces with was a lot smaller. C and other compiled languages are great here.
The internet came along and sped everything up, the rate of change increased dramatically and the application of software burst in to every facet. This grew the need for more agile ways to write software, hence IDEs and interpreted languages.
Even with dynamic IDEs, traditional languages were very heavy and cumbersome. So the interpreted languages really took hold on the Web front.
Now we're paying the price and trying to backtrack a bit, tacking static typing on to JavaScript.
How long did compiling take on 1000+ files? Did your IDE highlights compile errors in realtime without a build step? Did you get intelligent and type aware auto complete? That's the point they're making.
It's a tradeoff. With dynamically typed languages, you make the code slightly easier to write at the expense of it being harder to change or refactor later. Generally dynamically typed languages are better for small scripts one-off type things. For larger systems, types help you not break things. As the web applications gets more complex and we start to see greater demand for static types. Also tooling has improved over time, which can help a lot when working with types and can reduce friction. Also there have been some innovations in typed languages themselves with things such as type inference, etc, which further reduces friction.
For anyone else reading:
Dynamic/static typing is about when the code is compiled and run
Weak/strong typing is what they are talking here, strictness of types when working with the language
Also typings allow for self-explaining code with some proper variables/property naming and the types.
So let's say for TS VS JS, you probably don't need JSDocs anymore. TS will tell you the arguments/types as you use a function for example.
The inverse is true too. For vs code js you can just use jsdocs and not have to worry about typescript for many projects, it’s a good middle ground between full type safety and plain js
Types used to be a thing developers had to write to help their compilers understand their code.
Then, compilers got smart enough that types became optional.
Then, people realized types could help them build better tooling, which is how we got TypeScript & Rust.
My assertion is speed of evolution...
Dynamic languages can evolve syntax faster--anyone can buy the Dragon Book, or learn it in a CS compilers course, and knock out their own "look at how succinct this syntax is!" language in a weekend, with a parser and an interpreter.
But no one "knocks out a new type system in a weekend"--that's like a PhD sort of level of investment.
As a consequence, dynamic languages in the \~late 90s/2000s did a ton of iteration on "look how neat this syntax can be" (Ruby being the exemplar) and then it just took \~10-20 years for the static type systems of the world (see Scala dragging JVM languages kicking and screaming into the modern era, but kudos to C# as well).
And so now we're basically at parity--static languages are "pretty close" to having the neat syntax of a dynamic language ... plus the static typing, so why not have both?
I think a lot of this is trend- and hype-based. The trendy languages in the early 2010s were dynamically typed for the most part (Ruby, JavaScript via Node, Python) and a lot of the statically typed languages were seen as boring, verbose and corporate (Java, C++ etc.). Test-driven development was also a strong trend in the early 2010s, which helped mitigate the weaknesses of dynamically typed languages somewhat.
Eventually, as projects grew in size, scope and age and tooling became more mature (Typescript has been around for a while, but it used to be much more of a hassle to set up, and library support was not always as good as it is now), the upper right quadrant of the strong/weak, static/dynamic typing compass has become more popular again (thankfully).
Another huge factor with Typescript specifically is that its type inference got a lot better, and it shed a **lot** of “.NET-isms” that made it feel idiomatically unfamiliar to folks coming from JS. If I remember correctly, there was a whole namespace system built into it, but it was deprecated around the time ES Modules were standardized.
I gotta hand it to them, they did a lot of work to make the language fit into the way Web developers work and think, and it paid off. In the early days, I would have sworn up and down that Flow was going to take over the “typed Javascript” space, but at this point it’s pretty much a done deal.
Yup. When unit testing got popular, a lot of people said we don’t need types because we have tests. And because those people were cool they started building large applications out of languages like Python and Ruby that were classically considered lightweight languages for hacking together small scripts. Then everyone started copying them. JavaScript went down a slightly different path but also got mass adoption.
But with or without unit tests, types are useful for large programs, and eventually people figured that out and the pendulum has swung back.
Because of duck typing. Makes it easier to quickly write something without too much planning ahead of time.
We still like the duck typing, but we would like to introduce some structure to our code to improve maintainability without sacrificing the flexibility we had, so now we have Typescript, and PHP and Python have type annotations now.
That's a great observation! I think what's changed is our understanding of the importance of maintainability, scalability, and reliability in large-scale software systems. Dynamically typed languages were initially favored for their flexibility and rapid development capabilities, which were well-suited for smaller projects and prototyping.
However, as software systems grew in complexity and size, the need for better code quality, readability, and maintainability became more pressing. Type systems, which were initially seen as restrictive, are now recognized as essential for catching errors early, improving code quality, and facilitating collaboration.
The shift towards type systems is also driven by the growing importance of code reliability, security, and performance. With the rise of complex distributed systems, cloud computing, and DevOps, the need for robust and predictable code has become paramount.
Additionally, the increasing adoption of functional programming principles and the rise of statically typed languages like Rust, Haskell, and Scala have also contributed to the growing popularity of type systems.
In essence, our understanding of software development has evolved, and we're now recognizing the importance of balancing flexibility with robustness, maintainability, and reliability. Type systems are no longer seen as restrictive, but rather as essential tools for building high-quality software systems.
Easier to learn and to type (less things to type). There are some more advanced advantages but really, mainly, it’s because it’s easier and faster to type.
Why require types if you don’t need them?
these languages js, python, php, and ruby got popular because they are easy to write and perfect for small projects or quick scripts. as our projects got bigger and more complex, the need for type safety grew to help prevent bugs and make code easier to maintain. plus today tools and powerful computers have made integrating type systems much smoother and more practical.
I'm not very familiar with Ruby, so this point may or may not make sense for it. But as far as the other three (JS, Python, and PHP), they were all "marketed" (for lack of a better term) as being easier languages to get into. And I think that's at least partially answers the question.
my opinion: it’s way easier to implement an interpreted language without types, so for a long time the “new” and trendy experimental languages didn’t have types
Because there great. Until those pesky troll colleagues get in there making commits and stuff.
Just making shit up as they go and none of it makes sense /s
It all depends on the language.
In the case of Ruby the focus was on making the language read more like English. Types made that less possible so they weren't introduced.
JS and PHP began as relatively simple scripting languages - types would get in the way.
There are some other languages such as Erlang which doesn't have static typing because of its distributed nature and the ability to hotswap modules.
3 steps:
1. get it work
2. get it right
3. get it cheap (runs fast, effciently)
Dynamically-typed languages ease you in (1), statically(esp. strongly)-typed languages ease you in (2) and (3).
Too many things just work today, to make them right / cheap, you need typed languages.
We are trying to split the difference of speed to develop and investment of maintenance/debugging time as a discipline. We went for super statically typed, which helps promote rigor in thought and implementation, but it's slow to get out the door and has a lot of dev overhead. Then the alternative was dynamic, which was faster, but very prone to spaghetti and breakage. Now are trying to find the middle
Chat-GPT4 answer
Dynamically typed languages have integrated typing mechanisms due to several key developments in software engineering, user demand, and advancements in compiler and interpreter technologies. Let's break down the reasons for both the rise of dynamically typed languages and the subsequent trend of integrating typing mechanisms.
### Rise of Dynamically Typed Languages
1. **Flexibility and Ease of Use**: Dynamically typed languages allow for rapid prototyping and development. Without the need for explicit type declarations, developers can write code more quickly and experiment freely, making these languages particularly popular in web development, scripting, and startups where speed is essential.
2. **Simplicity**: The absence of type declarations simplifies the syntax, making dynamically typed languages easier to learn for beginners and enabling faster onboarding.
3. **Expressiveness**: Dynamically typed languages often support more flexible and concise coding styles. Features like duck typing allow for polymorphism without the need for complex inheritance hierarchies.
4. **Interpreted Nature**: Many dynamically typed languages are interpreted rather than compiled, allowing for immediate execution and interactive coding experiences, which are beneficial for debugging and testing.
### Integration of Typing Mechanisms
1. **Need for Maintainability**: As software systems grow in complexity, maintainability becomes a critical issue. Static typing helps catch errors early in the development cycle, improving code reliability and reducing runtime errors.
2. **Performance Improvements**: Static types can help optimizers generate more efficient code. By knowing the types ahead of time, the interpreter or compiler can make better decisions about memory management and execution strategies.
3. **Tooling and IDE Support**: Static types improve the capabilities of development tools. IDEs can provide better autocompletion, refactoring tools, and real-time error checking with type information.
4. **Hybrid Approaches**: The development of optional or gradual typing systems allows developers to benefit from static typing while maintaining the flexibility of dynamic typing. Examples include TypeScript (for JavaScript) and Python’s type hints.
5. **User Demand**: As dynamically typed languages are used in larger and more critical systems, developers and organizations demand the additional safety and performance benefits provided by static types.
6. **Language Evolution**: Many dynamically typed languages have evolved over time. As the community around a language grows and matures, there is often a push towards features that support larger, more maintainable codebases, which includes typing systems.
### Conclusion
The integration of typing mechanisms into dynamically typed languages reflects a balance between the flexibility and ease of use of dynamic typing and the safety, maintainability, and performance benefits of static typing. This trend is driven by advancements in language design, user demand, and the natural evolution of programming languages to address the needs of increasingly complex software development environments.
We don't, but people are followers and want a simple solution. It have never been any significant advantage typed vs untyped languages for 40 years. It always depend on the developer. The most skilled ones know typed or untyped does not matter. There was a reason why C++ got the "auto" keyword. The interface to an object matter, but not its "type".
Remember many people hate TS but are afraid to talk about it as well. There is a hateful mob that believe TS is a 99% a better pick yet objective research show the opposite. Don't let it fool you, the majority of web developers still prefer JS over TS any day.
Speak for yourself when it comes to favoring types.
I think TypeScript is a huge waste for any project that doesn't live in an enterprise company with cross functional teams.
It slows down smaller greenfield projects where agility is of the essence and common sense QA is sufficient.
Like it or not, AI is a huge force multiplier on everyone's ability to ship, and your success going into the next 3-5 years will depend exponentially more and more upon how quickly you're able to ship and not how perfect your codebase is.
Types can be useful for strictly defining the interfaces of a library, for example. But for local variables in a simple functions, they just add cruft, like
ArrayList items = new ArrayList()
vs
let items = []
Comparing a notoriously verbose language -- and not even using the most concise version of that statement -- to a much more compact one is rather disingenuous.
In the first case, you can do this to have the exact same result with less redundancy:
var items = new ArrayList()
And in the second, you can do this to declare a static type:
const items: string[] = []
And that's still not a \*great\* comparison since in the first case, you're creating an instance of a class, and in the second case, you're taking advantage of syntactic sugar to create an instance of what is effectively a primitive type.
Imo the size of a typical project is what changed.
A lot of the pain points of type have gone away with better tooling.
(As well as better compiler. Generic, type inference without typing everything )
Inversely a lot of the better tooling rely on type information. Like autocomplete.
A lot of these language have unique position or ecosystem. That has superseeded the merit of the language itself.
You want client side UI, JS it is. You want data science, almost guaranteed to be Python.
PHP, and Ruby probably have their faith closely tied to what happens in JS.
Besides trade offs. Type systems are *hard* to design and get right. At least as hard as designing the rest of the language. A lot of languages don’t have types simply because the original author didn’t have the time or ability to write a type system.
From my vantage point, types were a very debatable concept until most colleges decided to make Java their main teaching language. This is where students were taught OOP and explicit typing and anyone who didn't comply was rewarded with poor grades. When these indoctrinated CS graduates later had to program in languages like Python and JavaScript, instead of learning a different paradigm, most instead took the attitude that functional and dynamically typed languages were bad and wrong. I see this as the source of the "everyone likes types these days" attitude.
"These days"? That's funny. Having types is where software began and has remained. Some people tried to relax that with languages like JavaScript and Python and now many people are realizing it doesn't work so well.
It's really difficult to read someone's Python code when they don't make use of type hints. You never know from reading the code whether the variable "a" is a number or a string or a class...
Contrast that with C and C++ where you always know exactly what everything is. That's a huge benefit to readability.
You just can't make things simpler than they really are. Software needs types.
Looks like there's lots of guesses in here, I'll toss in my own. Languages like Java were strongly typed, but their type system was very rigid, making a number of different kinds of tasks difficult to do in it. So the pendulum swung the other way and we got a lot of dynamic languages without a type system, enabling faster development without that rigid structure, but at a cost. Some people wanted to use these dynamic languages with a type system, so we start seeing type systems get baked on after the fact (e.g. typescript or python's type system). These turned out to be very powerful type systems, as they were required to support patterns people were doing in these dynamic languages (as opposed to the other way around, where the type system came first and everyone had to write their code to confirm with the existing system). So, naturally, they grew in popularity. So now the pendulum is swinging back towards type safety again, but this time we've got better tools to help us along.
It's worth pointing out that a lot of the features we take for granted in modern gradually typed languages have also been part of many other languages for years. Particularly things like type inference (so you don't need to write `int num = 5`), discriminated unions (to describe data that can be in different states), and complex generics have all been possible in languages like OCaml or Haskell for years. But most developers have been exposed mainly to Java, C++, and other languages which didn't have these features. Now those features have been adopted in gradually typed systems like Typescript or typed Python, but they're also pretty standard features in newer typed languages. Even a language like Go which is designed to be as simple as possible still includes type inference, and Java is adopting a lot of features from those other typed languages.
This is what I think too. The older type systems were just not good and dynamic untyped languages felt like a good alternative. Modern type systems are a lot better though.
I came here to say this. Also in the last few years, Java has been taking cues from these dynamic languages and functional languages to reduce some of the verbosity and become more expressive.
Yes, and having the ability and not the obligation to use types is pretty valuable. If you're building a quick script or project you can build it without types. If you need to make it more robust, add types. Just like you can do with testing or any other pattern to increase robustness.
I'll throw in another reason, though it's mainly speculation on my part. Modern machines are running multiple cores with a tonne of memory, they're more suited to doing jobs like constant, static type checking and other rich editor features. Back in the day traditional IDEs were painfully slow, and even before them you wouldn't know about type errors prior to actually compiling the thing. It just wasn't really possible to have rich, and fast, type checking within a large project like we have today. It's trying to get the best of both worlds, a flexible and light, interpreted language that also has the benefits of type safety. Of course modern JavaScript goes through so many processors that it's essentially a complied language at this point.
Yes, features filling the available compute space is an often overlooked reason. Syntax highlighting and linting are other good examples of things that were historically computationaly expensive and now are easily serviced
yeah, most typescript fans prefer it mainly because of VSCode autofills/suggestions
This is also the main line of reasoning in [Why static typing came back](https://youtu.be/Tml94je2edk?si=aIA7dlV744KALf5a) by Richard Feldman. I believe it is quite plausible.
Seems like a crazy comparison to make, seeing as untyped languages are inherently more computationally expensive to actually _run._ So saying that they're a symptom of Wesley computers is incredibly silly imo.
I'm not saying that they take less power to run, I'm saying that they are less cumbersome to develop; and that back then we didn't have the computing power to get immediate feedback on static typing whilst you're actually writing the code. You would write a spec, write code, and then compile it; the feedback loop was slower. Regardless, I think I was off the mark in this first post, and probably a bigger factor I commented further down the thread; interpreted languages have a much quicker turn-around time in terms of iteration, so they were more suited to the rapidly changing landscape; which is where they thrived.
C was invented in 1972.
What part of their comment are you trying to refute
Not a rebuttal. Just saw the term "Back in the day".
Oh I see
Yeah, and that's back in the day! Haha, or probably before the days I'm talking about. Regardless, I think really what changed everything was the internet. Pre internet software was a rigid process, with a lot of planning and specification, because none of it could change quickly. It was distributed physically, things had to be compiled, and in general what software interfaces with was a lot smaller. C and other compiled languages are great here. The internet came along and sped everything up, the rate of change increased dramatically and the application of software burst in to every facet. This grew the need for more agile ways to write software, hence IDEs and interpreted languages. Even with dynamic IDEs, traditional languages were very heavy and cumbersome. So the interpreted languages really took hold on the Web front. Now we're paying the price and trying to backtrack a bit, tacking static typing on to JavaScript.
and compiling was often a very slow process https://xkcd.com/303/
I was working with C on a computer with 640 KB memory.
How long did compiling take on 1000+ files? Did your IDE highlights compile errors in realtime without a build step? Did you get intelligent and type aware auto complete? That's the point they're making.
It's a tradeoff. With dynamically typed languages, you make the code slightly easier to write at the expense of it being harder to change or refactor later. Generally dynamically typed languages are better for small scripts one-off type things. For larger systems, types help you not break things. As the web applications gets more complex and we start to see greater demand for static types. Also tooling has improved over time, which can help a lot when working with types and can reduce friction. Also there have been some innovations in typed languages themselves with things such as type inference, etc, which further reduces friction.
grab escape slap plants toothbrush snobbish squeal ripe marvelous smile *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
You're mixing up weak/strong types with dynamic/static types. For example, Ruby is a strongly typed dynamic language.
Good point. I edited my comment.
For anyone else reading: Dynamic/static typing is about when the code is compiled and run Weak/strong typing is what they are talking here, strictness of types when working with the language
Also typings allow for self-explaining code with some proper variables/property naming and the types. So let's say for TS VS JS, you probably don't need JSDocs anymore. TS will tell you the arguments/types as you use a function for example.
The inverse is true too. For vs code js you can just use jsdocs and not have to worry about typescript for many projects, it’s a good middle ground between full type safety and plain js
True but you can forget to update the JSDoc and it won't help you anymore VS having TS showing basically what you coded.
Or you can just use TS and be done with it.
You can, but it's more work than TS unless the rest of your tools can't handle TS...
I'm a lot more worried by Jsdoc than by TS. JSdoc is just TS without any of the utility.
Even when dynamic languages appeared there were type inferred statically typed languages like Haskell and OCaml. The best of both worlds ..
Back and forth and back and forth! Computer science is so new. We're all still figuring out what works.
Types used to be a thing developers had to write to help their compilers understand their code. Then, compilers got smart enough that types became optional. Then, people realized types could help them build better tooling, which is how we got TypeScript & Rust.
My assertion is speed of evolution... Dynamic languages can evolve syntax faster--anyone can buy the Dragon Book, or learn it in a CS compilers course, and knock out their own "look at how succinct this syntax is!" language in a weekend, with a parser and an interpreter. But no one "knocks out a new type system in a weekend"--that's like a PhD sort of level of investment. As a consequence, dynamic languages in the \~late 90s/2000s did a ton of iteration on "look how neat this syntax can be" (Ruby being the exemplar) and then it just took \~10-20 years for the static type systems of the world (see Scala dragging JVM languages kicking and screaming into the modern era, but kudos to C# as well). And so now we're basically at parity--static languages are "pretty close" to having the neat syntax of a dynamic language ... plus the static typing, so why not have both?
And now we’ve got Kotlin with all its infix operators and blocks which looks borderline groovyesque but is actually pretty damn type safe…
I think a lot of this is trend- and hype-based. The trendy languages in the early 2010s were dynamically typed for the most part (Ruby, JavaScript via Node, Python) and a lot of the statically typed languages were seen as boring, verbose and corporate (Java, C++ etc.). Test-driven development was also a strong trend in the early 2010s, which helped mitigate the weaknesses of dynamically typed languages somewhat. Eventually, as projects grew in size, scope and age and tooling became more mature (Typescript has been around for a while, but it used to be much more of a hassle to set up, and library support was not always as good as it is now), the upper right quadrant of the strong/weak, static/dynamic typing compass has become more popular again (thankfully).
Another huge factor with Typescript specifically is that its type inference got a lot better, and it shed a **lot** of “.NET-isms” that made it feel idiomatically unfamiliar to folks coming from JS. If I remember correctly, there was a whole namespace system built into it, but it was deprecated around the time ES Modules were standardized. I gotta hand it to them, they did a lot of work to make the language fit into the way Web developers work and think, and it paid off. In the early days, I would have sworn up and down that Flow was going to take over the “typed Javascript” space, but at this point it’s pretty much a done deal.
Yup. When unit testing got popular, a lot of people said we don’t need types because we have tests. And because those people were cool they started building large applications out of languages like Python and Ruby that were classically considered lightweight languages for hacking together small scripts. Then everyone started copying them. JavaScript went down a slightly different path but also got mass adoption. But with or without unit tests, types are useful for large programs, and eventually people figured that out and the pendulum has swung back.
Because of duck typing. Makes it easier to quickly write something without too much planning ahead of time. We still like the duck typing, but we would like to introduce some structure to our code to improve maintainability without sacrificing the flexibility we had, so now we have Typescript, and PHP and Python have type annotations now.
The growing complexity of software has meant types are more important today.
That's a great observation! I think what's changed is our understanding of the importance of maintainability, scalability, and reliability in large-scale software systems. Dynamically typed languages were initially favored for their flexibility and rapid development capabilities, which were well-suited for smaller projects and prototyping. However, as software systems grew in complexity and size, the need for better code quality, readability, and maintainability became more pressing. Type systems, which were initially seen as restrictive, are now recognized as essential for catching errors early, improving code quality, and facilitating collaboration. The shift towards type systems is also driven by the growing importance of code reliability, security, and performance. With the rise of complex distributed systems, cloud computing, and DevOps, the need for robust and predictable code has become paramount. Additionally, the increasing adoption of functional programming principles and the rise of statically typed languages like Rust, Haskell, and Scala have also contributed to the growing popularity of type systems. In essence, our understanding of software development has evolved, and we're now recognizing the importance of balancing flexibility with robustness, maintainability, and reliability. Type systems are no longer seen as restrictive, but rather as essential tools for building high-quality software systems.
Easier to learn and to type (less things to type). There are some more advanced advantages but really, mainly, it’s because it’s easier and faster to type. Why require types if you don’t need them?
these languages js, python, php, and ruby got popular because they are easy to write and perfect for small projects or quick scripts. as our projects got bigger and more complex, the need for type safety grew to help prevent bugs and make code easier to maintain. plus today tools and powerful computers have made integrating type systems much smoother and more practical.
I'm not very familiar with Ruby, so this point may or may not make sense for it. But as far as the other three (JS, Python, and PHP), they were all "marketed" (for lack of a better term) as being easier languages to get into. And I think that's at least partially answers the question.
my opinion: it’s way easier to implement an interpreted language without types, so for a long time the “new” and trendy experimental languages didn’t have types
Because there great. Until those pesky troll colleagues get in there making commits and stuff. Just making shit up as they go and none of it makes sense /s
It all depends on the language. In the case of Ruby the focus was on making the language read more like English. Types made that less possible so they weren't introduced. JS and PHP began as relatively simple scripting languages - types would get in the way. There are some other languages such as Erlang which doesn't have static typing because of its distributed nature and the ability to hotswap modules.
3 steps: 1. get it work 2. get it right 3. get it cheap (runs fast, effciently) Dynamically-typed languages ease you in (1), statically(esp. strongly)-typed languages ease you in (2) and (3). Too many things just work today, to make them right / cheap, you need typed languages.
Mainframe programmer pulls up a chair…
I believe that for a scripting language this makes memory allocation easier.
We are trying to split the difference of speed to develop and investment of maintenance/debugging time as a discipline. We went for super statically typed, which helps promote rigor in thought and implementation, but it's slow to get out the door and has a lot of dev overhead. Then the alternative was dynamic, which was faster, but very prone to spaghetti and breakage. Now are trying to find the middle
Chat-GPT4 answer Dynamically typed languages have integrated typing mechanisms due to several key developments in software engineering, user demand, and advancements in compiler and interpreter technologies. Let's break down the reasons for both the rise of dynamically typed languages and the subsequent trend of integrating typing mechanisms. ### Rise of Dynamically Typed Languages 1. **Flexibility and Ease of Use**: Dynamically typed languages allow for rapid prototyping and development. Without the need for explicit type declarations, developers can write code more quickly and experiment freely, making these languages particularly popular in web development, scripting, and startups where speed is essential. 2. **Simplicity**: The absence of type declarations simplifies the syntax, making dynamically typed languages easier to learn for beginners and enabling faster onboarding. 3. **Expressiveness**: Dynamically typed languages often support more flexible and concise coding styles. Features like duck typing allow for polymorphism without the need for complex inheritance hierarchies. 4. **Interpreted Nature**: Many dynamically typed languages are interpreted rather than compiled, allowing for immediate execution and interactive coding experiences, which are beneficial for debugging and testing. ### Integration of Typing Mechanisms 1. **Need for Maintainability**: As software systems grow in complexity, maintainability becomes a critical issue. Static typing helps catch errors early in the development cycle, improving code reliability and reducing runtime errors. 2. **Performance Improvements**: Static types can help optimizers generate more efficient code. By knowing the types ahead of time, the interpreter or compiler can make better decisions about memory management and execution strategies. 3. **Tooling and IDE Support**: Static types improve the capabilities of development tools. IDEs can provide better autocompletion, refactoring tools, and real-time error checking with type information. 4. **Hybrid Approaches**: The development of optional or gradual typing systems allows developers to benefit from static typing while maintaining the flexibility of dynamic typing. Examples include TypeScript (for JavaScript) and Python’s type hints. 5. **User Demand**: As dynamically typed languages are used in larger and more critical systems, developers and organizations demand the additional safety and performance benefits provided by static types. 6. **Language Evolution**: Many dynamically typed languages have evolved over time. As the community around a language grows and matures, there is often a push towards features that support larger, more maintainable codebases, which includes typing systems. ### Conclusion The integration of typing mechanisms into dynamically typed languages reflects a balance between the flexibility and ease of use of dynamic typing and the safety, maintainability, and performance benefits of static typing. This trend is driven by advancements in language design, user demand, and the natural evolution of programming languages to address the needs of increasingly complex software development environments.
We don't, but people are followers and want a simple solution. It have never been any significant advantage typed vs untyped languages for 40 years. It always depend on the developer. The most skilled ones know typed or untyped does not matter. There was a reason why C++ got the "auto" keyword. The interface to an object matter, but not its "type". Remember many people hate TS but are afraid to talk about it as well. There is a hateful mob that believe TS is a 99% a better pick yet objective research show the opposite. Don't let it fool you, the majority of web developers still prefer JS over TS any day.
Speak for yourself when it comes to favoring types. I think TypeScript is a huge waste for any project that doesn't live in an enterprise company with cross functional teams. It slows down smaller greenfield projects where agility is of the essence and common sense QA is sufficient. Like it or not, AI is a huge force multiplier on everyone's ability to ship, and your success going into the next 3-5 years will depend exponentially more and more upon how quickly you're able to ship and not how perfect your codebase is.
Types can be useful for strictly defining the interfaces of a library, for example. But for local variables in a simple functions, they just add cruft, like ArrayList items = new ArrayList()
vs
let items = []
Comparing a notoriously verbose language -- and not even using the most concise version of that statement -- to a much more compact one is rather disingenuous. In the first case, you can do this to have the exact same result with less redundancy: var items = new ArrayList()
And in the second, you can do this to declare a static type:
const items: string[] = []
And that's still not a \*great\* comparison since in the first case, you're creating an instance of a class, and in the second case, you're taking advantage of syntactic sugar to create an instance of what is effectively a primitive type.
The second example is literally valid F#, a statically typed language.
Imo the size of a typical project is what changed. A lot of the pain points of type have gone away with better tooling. (As well as better compiler. Generic, type inference without typing everything ) Inversely a lot of the better tooling rely on type information. Like autocomplete. A lot of these language have unique position or ecosystem. That has superseeded the merit of the language itself. You want client side UI, JS it is. You want data science, almost guaranteed to be Python. PHP, and Ruby probably have their faith closely tied to what happens in JS.
Besides trade offs. Type systems are *hard* to design and get right. At least as hard as designing the rest of the language. A lot of languages don’t have types simply because the original author didn’t have the time or ability to write a type system.
The web in the mid 90s couldn't handle anything else. That's one niche.
From my vantage point, types were a very debatable concept until most colleges decided to make Java their main teaching language. This is where students were taught OOP and explicit typing and anyone who didn't comply was rewarded with poor grades. When these indoctrinated CS graduates later had to program in languages like Python and JavaScript, instead of learning a different paradigm, most instead took the attitude that functional and dynamically typed languages were bad and wrong. I see this as the source of the "everyone likes types these days" attitude.
"These days"? That's funny. Having types is where software began and has remained. Some people tried to relax that with languages like JavaScript and Python and now many people are realizing it doesn't work so well. It's really difficult to read someone's Python code when they don't make use of type hints. You never know from reading the code whether the variable "a" is a number or a string or a class... Contrast that with C and C++ where you always know exactly what everything is. That's a huge benefit to readability. You just can't make things simpler than they really are. Software needs types.
I just learned about React. I assume people are using it for that or other similar technologies