News for hackers. Stuff that matters.
Re:How porting to TypeScript solved our API woes by dang on Wednesday April 08, 2020 @05:25PM (#22817336)
That of course is not the argument at all. The argument is that the cost of working with static types exceeds the benefits. Finding type errors is obviously a benefit, while not finding them (or finding them only at runtime) is a cost. The question is what other costs and benefits there are, and how to compare them. Nobody agrees on that, nor ever will.

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."

Re:How porting to TypeScript solved our API woes by Roboprog on Wednesday April 08, 2020 @06:14PM (#22817792)
Great comment. I am part of the minority that is dreading being forced to use Typescript some day, at least until they come up with a solution to annotate partial function application and the like.

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.

Re:How porting to TypeScript solved our API woes by smt88 on Wednesday April 08, 2020 @09:28PM (#22818995)
> annotate partial function application

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...

Re:How porting to TypeScript solved our API woes by Roboprog on Friday April 10, 2020 @06:08PM (#22837813)
Yes, implicit currying where supplying the final arg actually calls the underlying function is one kind of partial function application. Ramda is one thing I use.

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.

Re:How porting to TypeScript solved our API woes by pgrizzay on Wednesday April 08, 2020 @06:32PM (#22817914)
> Partial function application

Do you mean like curried functions?

Re:How porting to TypeScript solved our API woes by willberman on Wednesday April 08, 2020 @07:39PM (#22818363)
It is essentially correct that the discussion on typing occurs at the least nuanced level of discourse. I've been at fault doing this myself. The distinction between different sorts of type systems and the relative conservation of the different analyses required to produce well typed programs is rarely brought up. I have a general saying that you shouldn't listen to people unless they can explain a point of view in terms of its tradeoffs. Very few real problems have absolutist solutions. I'm currently working my way through Types and Programming Languages and hope to one day present a more technical and thought out explanations of the tradeoffs present amongst untyped and the various levels of typed systems.
Re:How porting to TypeScript solved our API woes by smt88 on Thursday April 09, 2020 @01:03AM (#22819922)
This person (among others) is arguing exactly what I said that extreme type-haters will argue: https://news.ycombinator.com/item?id=22819671

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.

Re:How porting to TypeScript solved our API woes by dang on Thursday April 09, 2020 @02:40AM (#22820350)
I'm not sure I do think the truth is between the extremes, but if I came across that way I did a good enough job of it for the purposes of writing that comment!

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.

Re:How porting to TypeScript solved our API woes by smt88 on Thursday April 09, 2020 @03:16PM (#22826145)
> It's not really helpful to use a label like "type-haters" or "type-hate"

> 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.