I agree, the language alone isn’t a silver bullet. I’m not suggesting that it is. You still have to implement good workflow, do testing, code reviews, architecture design, and so on. All these things are language agnostic. What the language can do is reduce friction in your workflow, and nudge design in the right direction by making it easier to do the right thing. I largely see it as a quality of life improvement.
Also, I’m not saying that patterns like adapters don’t have their uses or that you might not use a similar approach in a functional language. My point was that these types of patterns tend to be more pervasive in mainstream languages.
Static typing itself is a trade off as well. It introduces mental overhead because you are restricted to a set of statements that can be expressed using a particular type system, and this can lead to code that’s written for the benefit of the type checker rather than a human reading it. Everything is a trade off in practice.
Finally, the choice of language ultimately depends on a particular team. Different people think in different ways, and have different experience. The best language is the one that majority of the team is comfortable using. Hence, I’m speaking here from my personal perspective of the way I enjoy doing development. This will necessarily vary from person to person.
Static typing itself is a trade off as well. It introduces mental overhead because you are restricted to a set of statements that can be expressed using a particular type system, and this can lead to code that’s written for the benefit of the type checker rather than a human reading it. Everything is a trade off in practice.
You mean code that’s written to the benefit of a low efficiency enterprise workflow, which is my love hate relationship with Typescript. Best out choice out of a pile of shit.
That’s not what I’m saying. I think static typing introduces a certain set of trade offs that some people prefer. You restrict the set of statements that are possible to express to ones that can be checked by the type system, and as a result you get additional compile time guarantees. For example, Lemmy devs prefer this trade off and it has nothing to do with enterprise workflows.
you are restricted to a set of statements that can be expressed using a particular type system
What I’m saying is that most good static typing systems do not practically have such limitations, you’d be very hard pressed to find them and they’d be fairly illogical. Most static typing systems that are used in enterprise do have limitations because they are garbage.
So in such shitty type systems you often have code that’s written for the benefit of the type checker rather than a human reading it. In good type systems any code that’s written for the benefit of the type checker is often an antipattern.
For example, Lemmy devs prefer this trade off and it has nothing to do with enterprise workflows.
Rust has HKT support through GATs and typeclass support thru traits. Rust has minimal code you write for the benefit of the type checker.
Typescript technically has HKT support but it’s a coincidence and the Typescript team doesn’t care about it, since the beginning Typescript was made to be Enterprise Javascript by Microsoft. Though systems like fp-ts exist they’re hard to get rolling in enterprise.
Typescript does have problems with code that’s written for the benefit of the type checker rather than a human reading it in a large part due to inefficiencies of the compiler itself. In a small part due to some corner cases that still exist because even though it’s type system while more advanced than others in it’s enterprise grade class, it’s still written in that style for that purpose so the inconsistencies it makes to support the janky workflow (plus some EMCA stuff e.g. Promise is not functionally typeable since the spec breaks set theory for convenience reasons) leads to that problem.
However in Typescript these are avoidable problems and you are able to write code without dealing with the type checker’s bullshit a good amount of the time if you follow the correct patterns – certainly better than any other “enterprise grade” static typing system.
What I’m saying is that most good static typing systems do not practically have such limitations, you’d be very hard pressed to find them and they’d be fairly illogical. Most static typing systems that are used in enterprise do have limitations because they are garbage.
Of course they do, it’s silly to claim otherwise. Some type systems are certainly more flexible than others, but each one necessarily restricts how you can express yourself. Not to mention the fact that advanced type systems introduce mental overhead of their own. The more flexible the type system is the more complex it is as a result. There was even famously a debugger for Scala type system illustrating just how absurd things can get. I’ve used plenty of typed languages including Haskell, so I understand perfectly well how modern static typing works.
Meanwhile, I’d argue that Typescript provides incredibly weak guarantees in practice, and the impact of transpiling on the workflow is not insignificant.
My experience is that immutability plays a far bigger role than static typing in practice. The best pattern for ensuring correctness and maintainability is to break things up into small components that can be reasoned about independently. Any large project can be broken up into smaller parts, and that’s by far the best approach towards ensuring correctness that I’ve seen.
Again, that’s my experience working with many different languages for over two decades now. I’m not suggesting other people can’t have their own preferences.
I agree, the language alone isn’t a silver bullet. I’m not suggesting that it is. You still have to implement good workflow, do testing, code reviews, architecture design, and so on. All these things are language agnostic. What the language can do is reduce friction in your workflow, and nudge design in the right direction by making it easier to do the right thing. I largely see it as a quality of life improvement.
Also, I’m not saying that patterns like adapters don’t have their uses or that you might not use a similar approach in a functional language. My point was that these types of patterns tend to be more pervasive in mainstream languages.
Static typing itself is a trade off as well. It introduces mental overhead because you are restricted to a set of statements that can be expressed using a particular type system, and this can lead to code that’s written for the benefit of the type checker rather than a human reading it. Everything is a trade off in practice.
Finally, the choice of language ultimately depends on a particular team. Different people think in different ways, and have different experience. The best language is the one that majority of the team is comfortable using. Hence, I’m speaking here from my personal perspective of the way I enjoy doing development. This will necessarily vary from person to person.
You mean code that’s written to the benefit of a low efficiency enterprise workflow, which is my love hate relationship with Typescript. Best out choice out of a pile of shit.
That’s not what I’m saying. I think static typing introduces a certain set of trade offs that some people prefer. You restrict the set of statements that are possible to express to ones that can be checked by the type system, and as a result you get additional compile time guarantees. For example, Lemmy devs prefer this trade off and it has nothing to do with enterprise workflows.
What I’m saying is that most good static typing systems do not practically have such limitations, you’d be very hard pressed to find them and they’d be fairly illogical. Most static typing systems that are used in enterprise do have limitations because they are garbage.
So in such shitty type systems you often have
code that’s written for the benefit of the type checker rather than a human reading it. In good type systems any code that’s written for the benefit of the type checker is often an antipattern.Rust has HKT support through GATs and typeclass support thru traits. Rust has minimal code you write for the benefit of the type checker.
Typescript technically has HKT support but it’s a coincidence and the Typescript team doesn’t care about it, since the beginning Typescript was made to be Enterprise Javascript by Microsoft. Though systems like fp-ts exist they’re hard to get rolling in enterprise.
Typescript does have problems with
code that’s written for the benefit of the type checker rather than a human reading itin a large part due to inefficiencies of the compiler itself. In a small part due to some corner cases that still exist because even though it’s type system while more advanced than others in it’s enterprise grade class, it’s still written in that style for that purpose so the inconsistencies it makes to support the janky workflow (plus some EMCA stuff e.g.Promiseis not functionally typeable since the spec breaks set theory for convenience reasons) leads to that problem.However in Typescript these are avoidable problems and you are able to write code without dealing with the type checker’s bullshit a good amount of the time if you follow the correct patterns – certainly better than any other “enterprise grade” static typing system.
Of course they do, it’s silly to claim otherwise. Some type systems are certainly more flexible than others, but each one necessarily restricts how you can express yourself. Not to mention the fact that advanced type systems introduce mental overhead of their own. The more flexible the type system is the more complex it is as a result. There was even famously a debugger for Scala type system illustrating just how absurd things can get. I’ve used plenty of typed languages including Haskell, so I understand perfectly well how modern static typing works.
Meanwhile, I’d argue that Typescript provides incredibly weak guarantees in practice, and the impact of transpiling on the workflow is not insignificant.
My experience is that immutability plays a far bigger role than static typing in practice. The best pattern for ensuring correctness and maintainability is to break things up into small components that can be reasoned about independently. Any large project can be broken up into smaller parts, and that’s by far the best approach towards ensuring correctness that I’ve seen.
Again, that’s my experience working with many different languages for over two decades now. I’m not suggesting other people can’t have their own preferences.
deleted by creator