Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fear, trust and JavaScript: When types and functional programming fail

reaktor.com

Post reply on HN
Print view View original

121–130 of 210 posts

Re: Fear, trust and JavaScript: When types and functional programming fail

#121

Post by magicalhippo »

Aqueous wrote: post #81
mdgrech23 wrote: post #79

Earlier quoted context omitted.

Not sure what hopeful imaginary world you live in.

One where a program that reports that it is successful (200 OK) but was not, in fact, successful, has a bug in it and should be fixed. Whether or not it gets fixed is another issue entirely. If it doesn't get fixed, switch endpoints or switch jobs.

> If it doesn't get fixed, switch endpoints or switch jobs.

At work a large part of my job is writing integrations with other systems our customers have. As an example, just recently an integration failed due to malformed XML. This was an XML file our program receives from another system our customer has bought, based on their spec.

The error was that while the XML header said the encoding was UTF-8, the actual data was Windows-1252 encoded...

The other system had bi-yearly releases, so any fix was months away, assuming their developers even understood what the issue was... And getting our customer to switch system is out of the question, at least short-term. Meanwhile our customer wanted the integration working ASAP.

So, I'd rather code a check, make our customer happy and keep my otherwise quite nice job, than quit and leave our customer stranded.

Re: Fear, trust and JavaScript: When types and functional programming fail

#122

Post by maxhallinan »

duckfruit wrote: post #84
maxhallinan wrote: post #22

> in various cases the types are wrong and the compiler doesn’t care It's disturbing how often I encounter this in TypeScript. Or its inverse: the types are correct and the compiler is wrong. Or a third common problem: the types for a library are incorrect. The unsoundness of TypeScript is not merely theoretical. The compiler is frequently just wrong. For that reason, I am mystified by the amount of enthusiasm for Ty…

Speaking for myself, the key selling point for Typescript (and Flow) is its pragmatism. While it might not have the soundness of a Bucklescript or Purescript, it does what its alternatives have chiefly failed to do for me: Allow me to see immediate incremental benefits without having to refactor an entire codebase. While the alternatives might be in some ways a better start a greenfield project in, the ability to gra…

You make a good point. I don't mean that TypeScript yields no benefit. But if I can't trust the compiler 99.99% of the time, then I find that I'm double-checking my work _and_ the compiler's work. It's not clear to me that the benefit outweighs this uncertainty. When you say that your system is "sounder", you don't really know whether that's true if the type system is unreliable.

Re: Fear, trust and JavaScript: When types and functional programming fail

#123

Post by arcticbull »

stephenr wrote: post #24
arcticbull wrote: post #16

Earlier quoted context omitted.

The runtime is unhelpful unless your tests include 100% code coverage.

Huh? If the runtime can guarantee your function receives an instance of a particular class, that's a lot of boiler plate you don't need to write yourself to assert the same thing.

Typechecking at the runtime level means that you have to write tests that traverse every single code path to make sure your code works the way you expect. You can just do this at compile time with static typing. Saves you a lot of boiler plate tests you don't need to write yourself to assert the same thing.

Re: Fear, trust and JavaScript: When types and functional programming fail

#124

Post by KirinDave »

ender7 wrote: post #91

This article is just a recapitulation of the old pure functional programming vs. imperative programming argument but wrapped up in new packaging. Most of these issues, such as needing to validate types at codebase boundaries, functions that have side effects, and unsound static type systems, could just as easily be leveled at most imperative languages (C++, Java). So yeah, go use a proper functional language (many of…

It's not really, though. Because even pure FP folks read this article and say, "This is just nonsense and ill-considered propaganda."

For example, the idea that you can't trust Typescript because it might call untyped code but you CAN trust Purescript is just wrong. It's not even just wrong, it's utterly misrepresentative of what actually happens in Elm and Purescript. It's misinformation.

Re: Fear, trust and JavaScript: When types and functional programming fail

#125

Post by tom_ »

maxhallinan wrote: post #116
tom_ wrote: post #106

Earlier quoted context omitted.

In what cases have you seen the compiler refuse to accept something that’s correct?

Passing props through a higher-order component using JSX's spread operator instead of the attribute syntax, e.g. `{...{...props, foo, }}` and accessing that prop in the wrapped component. I found it was possible with the attribute syntax. More examples can be found in the issues for `@types/ramda`. In some cases, the types are incorrect. In other cases, TypeScript's type inference is too weak.

From your description, that sounds like the compiler accepting something that isn't correct. I'm more interested in the case(s?) mentioned where the types are correct and the compiler won't accept the code.

I will have a quick skim through the @types/ramda issues, thanks.

Re: Fear, trust and JavaScript: When types and functional programming fail

#126

Post by KirinDave »

maxhallinan wrote: post #22

> in various cases the types are wrong and the compiler doesn’t care It's disturbing how often I encounter this in TypeScript. Or its inverse: the types are correct and the compiler is wrong. Or a third common problem: the types for a library are incorrect. The unsoundness of TypeScript is not merely theoretical. The compiler is frequently just wrong. For that reason, I am mystified by the amount of enthusiasm for Ty…

It's too bad the author chose specious and self-invalidating arguments for using Purescript and Elm as opposed to pointing out real issues with Flow and TS, isn't it?

Re: Fear, trust and JavaScript: When types and functional programming fail

#127

Post by arcticbull »

Tade0 wrote: post #18
arcticbull wrote: post #15

Earlier quoted context omitted.

I did Objective-C work for a decade under such conditions. It's never enough to have tests and code reviews. Static typing is strictly better.

I worked on a 150k LOC pure JS codebase for almost two years and my experience is different - if tests aren't enough then they're either not written well enough or there isn't enough of them.

Think of all the time you wasted writing unnecessary tests that the compiler could perform automatically on your behalf by you properly specifying your types. You'd be much more productive and confident, and have less LOC to maintain. Refactoring would be much easier too.

Re: Fear, trust and JavaScript: When types and functional programming fail

#128

Post by arcticbull »

qwer wrote: post #100
tempodox wrote: post #37

Earlier quoted context omitted.

You would never be able to write the infinite amount of tests necessary to supplant static typing, let alone run them.

Well don't lose sight of the goal. The goal is less bugs. Static typing is just for internal quality. Users don't give a rat's ass if your types are correct as long as the program works. Proof: Many wildly and massively successful programs are duck-typed. Nobody ever cared to use tests to replicate what a type system does. That's a straw man. Tests go straight for the actual goal by testing actual values. Correct val…

Internal quality is external quality haha. If your types are wrong your program is wrong, and if it just happens to work now wait until more people use it, or you refactor it, or you change the way it works. Your users are basically just fuzzing machines haha.

Your statement that "nobody ever cared to use tests to replicate what the type system does" is trivially false, have you ever tested what happens when you pass "null" into a function that probably shouldn't take null? If so, you just did. Some type systems allow you to even specify valid subranges of types, and combined with algebraic data types, it's effectively impossible to misuse.

Re: Fear, trust and JavaScript: When types and functional programming fail

#129

Post by stephenr »

arcticbull wrote: post #123
stephenr wrote: post #24

Earlier quoted context omitted.

Huh? If the runtime can guarantee your function receives an instance of a particular class, that's a lot of boiler plate you don't need to write yourself to assert the same thing.

Typechecking at the runtime level means that you have to write tests that traverse every single code path to make sure your code works the way you expect. You can just do this at compile time with static typing. Saves you a lot of boiler plate tests you don't need to write yourself to assert the same thing.

In the context of JS 'compile time' refers to.. TS?

My point was that if your TS project is used in a non-TS context (i.e. the compiled JS is called from regular JS code, not compiled TS code, you no longer have that compile step.

I also think you've misunderstood what I mean. I'm talking about native language level support for typed function arguments at the javascript level, not relying on TS to provide that.

Re: Fear, trust and JavaScript: When types and functional programming fail

#130

Post by oldboyFX »

erikpukinskis wrote: post #117

Companies and coders will always push themselves to the absolute brink, where they no longer trust the code and the system is nearly unmaintainable. Because every step towards that line has not just cash value, but exponential cash value if it’s a startup. And by constantly pushing themselves into unfamiliar territory coders develop the most impressive possible resumes. They either have relevant experience or have ex…

Could you elaborate on this a bit; do you have any interesting real life examples of this mentality?
Post reply on HN