TS solves problems I don’t have, and promotes a style I don’t want. I don’t want thousands of global symbols in hundreds of files in my project. At least TS has the decency to infer types in some cases, or at least put the type clutter after an identifier instead of before it, but it’s usually only superfluous clutter to me personally.
I realize that many people like TS. I just hope they understand why some of us are less enthusiastic.
I think you mean currying, right? It's been supported at close to the same level as Haskell for 3+ years[1].
> TS solves problems I don’t have
To me, it solves: 1) devs getting lazy on a team, 2) catching my mistakes before runtime, 3) correctly using library APIs, and 4) refactoring.
All of these might be low-value to you, though. I think #4 is the biggest time-saver because it enables automated refactoring (through the IDE) that isn't possible with plain JS.
> I don’t want thousands of global symbols in hundreds of files in my project.
I'm curious what you mean by this. Are you saying that TypeScript creates global symbols that weren't there before?
You can configure TypeScript so that it doesn't have any symbols from outside your project at all. For example, you can set it to import the types found in Node or on the web, or you can just skip them.
1. https://www.freecodecamp.org/news/typescript-curry-ramda-typ...
I also use an in-house library to explicitly apply arguments to return a a new function, which allows you to produce 0 arity or variadic functions.
I’m glad somebody has a work around for using Ramda in TS, but it looks every bit as “fun” as generics in Java, which I think have wasted more of my time than they have ever saved.
Do you mean like curried functions?
Like you, I think the truth is between the extremes. My original post was just pointing out that the extreme of type-hate is not uncommon here. The opposite appears to be true as well.
It's not really helpful to use a label like "type-haters" or "type-hate". I mean, it's helpful in the sense that it shows how tribalistic the arguments are (just replace "$X-haters" with enough Xs and you'll get the idea). But other ways of talking are more helpful.
On a related note: don't you think it's interesting how personal it feels? To some extent that's because the people who don't care that much select themselves out of the conversation to begin with. But I think it's fascinating even after pricing that in.
> don't you think it's interesting how personal it feels?
I take your point and will avoid it in the future. I used it precisely because, as you say, people are very emotional about it and take it personally. I meant to imply that these were not necessarily good-faith arguers having a rational discussion, but rather participants in a flamewar. This general thread seems to be a mix of both reason and flame.
As for why it's personal, I don't know exactly and do find it interesting. Part of it is likely that people have invested a lot of time into one stack or another, and that becomes an emotional issue. If I spent 10 years becoming a PHP expert, I'll be more upset if someone says PHP is garbage. It suggests my skills or prospects are poor.
After that, I think people are saying things like, "People who use TypeScript are stupid/lazy/etc.", or "People who don't use TypeScript are stupid/ignorant/etc.". Then the emotion may come from the conflict itself, not from the actual position someone is holding.
This argument will never be resolved because it's dominated by psychological factors. Once you've adapted to environment A, A's costs (e.g. hoops the compiler makes you jump through / time spent tracking down type errors) become habitual and you don't notice them anymore. Meanwhile the costs of unfamiliar environment B are extremely highlighted in your attention. Similarly, if you like and identify with A, its benefits will be top-of-mind for you, while if you don't like B (and nobody likes B), you'll discount its benefits.
It gets worse. Sometimes benefits are costs until you make it through a learning curve. An example is parentheses in Lisp. They stick out like a sore thumb until one day they don't. Later you realize that they were a liberating force all along, and you now have anti-gravity powers you never dreamt of. (<-- This is an example of how people talk when they are adapted to an environment whose costs they no longer count and whose benefits are top-of-mind for them.) We can't even agree on what the costs and benefits are, let alone how to measure them.
It's no wonder that people feel so strongly about this dispute. When you don't count the costs of your preferred environment, and only count the benefits, it gets obvious pretty quickly that other people are idiots. For some reason the idiots feel the opposite and perversely insist on it.
It gets worse. Imagine that you're a decent, fairminded sort and so, magnanimously as is your wont, you decide to give the idiots a fair shake—you know, just to verify that you're being fair and whatnot. You fire up whatever it is (Clojure? OCaml? needless to say, you make a charitable choice) and start programming for a while. What happens? All the costs of unfamiliarity hit you in the face. Not one of the benefits that has lived at the top of your mind for years is anywhere to be seen. This thing doesn't even catch trivial type errors at compile time! / I can't even execute this bit of code in a REPL! This is a painful experience. It can even be an enraging one, for example if you are forced for some extraneous reason to work on a system you didn't create using tools you don't like. Most people who go through that experience once have their views solidified for life. Meanwhile someone else had the opposite experience.
Given how passionately people feel about this and the certainty in forum threads about it, it's curious (or maybe to be expected) that the question of published evidence comes up so rarely. HN user luu did the definitive survey on this: https://danluu.com/empirical-pl/. The short version is that such studies as there are don't address the core question and/or find insignificant effects and/or their designs tip obviously to one side or the other (and I do mean obviously, like comparing Peter Norvig's code to that of random undergrads).
Bias dominates every other factor, put together, times at least 10. As long as that's true, we can't say anything rational without genuinely accounting for bias. Do we actually know how to do that? The studies don't seem able to. These debates certainly don't, nor do they try. Maybe the interesting phenomenon here is actually the bias itself. Maybe it's not that we like an environment because we're more productive in it, but that we're more productive because we like it. Maybe we should get better at liking things.
The debate about this tends to remain stuck at a low level because once you've been around the block enough times you realize that it hurts to bang your head against a wall so you stop. Thus the vocal population undergoes a perpetual exodus of the experienced, but makes up for it with a fresh supply of enthusiasts, reminding one of the adage, "I arrive at the office late, but make up for it by leaving early."