3 ms·
This is the thing that is drawing me in. The fact that others really need babysitting. I've never had huge problems with writing programs php or JS. Now everyo
by lugg 8y ago
This is the thing that is drawing me in. The fact that others really need babysitting.
I've never had huge problems with writing programs php or JS. Now everyone is freaking out about typescript and PHP type hints and all I'm doing is sitting here scratching my head asking but why? What does it do for you?
It looks like people were doing a lot of dirty state mutation and a lot of optional parameters that sometimes had mixed types because "then you can use it with an ID, an email, or a user object you silly billy".
Both of those things create a god awful hell. The second example may sound easy to use but then you have now way to reason about code, you can no longer clearly compose pieces and variable names become less descriptive. Types provide you with a simple pair of hand cuffs that prevent this issue. But they come at a cost.
My issue is that people with shitty habits should probably just change their shitty habbits. Changing from a dynamic language that lets you take a lot of safe shortcuts to a static language because you abused those shortcuts is really the wrong way to go.
Moving to something like clojure looks like a much cleaner solution to the problem.
Still handcuffs, but at least youre forcing the right thing (pushing the state mutation to the edge, leaving the business logic clear and rational without all the type safety bloat.
- chessturk 8y agoThis is exactly my feeling about Typescript. As a Go! developer, I'm fully for strong types, even to the point of restriction, but only if they are enforced. I'm currently maintaining a massive spaghetti code TypeScript nightmare that escape-hatches with @ts-ignore and `any` about every other line. I'm not sure why they even chose to give up all of the imperative, dynamic power of JS and then not even adhere to the pre-processor's own rules. I think there's an argument for imperative and functional approaches, but I also think trying to change an imperative language into a functional one is a bad idea, and trying to shoe-horn in type safety into a language that doesn't have it is just foolish. I feel like languages come with trade-offs inherent in their design (Go! trades DRY for type safety, JS trades data validation/type safety for convenience), and if you don't like the trade-offs of the language for your project, then you are probably using the wrong tool for the job. However, when it comes to JS, you usually don't have a choice (unless you go with Dart or WebASM, which I admittedly know very little about). I suppose TS could have a place (I particularly understand libraries that attempt to improve their data contract using it), but then I wish it didn't provide such wide variety of ways to escape or ignore it's restrictions. I feel like they are fake guard rails and provide a false sense of security.
- lugg 8y agoAgree wholeheartedly, I have no issue with typescript or typesafe languages. I actually enjoy them a lot for other reasons, being able to guarantee type is a nice feeling. But it doesn't guarantee correctness. And I think that is the problem. Developers see lack of type safety as a lack of correctness. Hell, I don't even blame them, a lot of code I deal with is impossible to reason about because of so many bad habbits code review is supposed to catch. My issue with TS is that people are using it to solve a problem that it does this actually solve: the developers reluctance to code clean.