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

81–90 of 210 posts

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

#81

Post by Aqueous »

mdgrech23 wrote: post #79
Aqueous wrote: post #69

Not sure what this author is saying here. Types have nothing to do with being able to trust other systems and everything to do with the internal formal consistency of the code that you write. It's about being consistent with yourself. If you find yourself writing defensive checks in fulfilled promise handlers because the data you get is sometimes invalid, stop. Get up from your keyboard, go to whoever owns the endpoi…

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.

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

#82

Post by Aqueous »

user5994461 wrote: post #74
Aqueous wrote: post #69

Not sure what this author is saying here. Types have nothing to do with being able to trust other systems and everything to do with the internal formal consistency of the code that you write. It's about being consistent with yourself. If you find yourself writing defensive checks in fulfilled promise handlers because the data you get is sometimes invalid, stop. Get up from your keyboard, go to whoever owns the endpoi…

If your software crashes on bad user input, that's an error in your software. By the way, there is distinction to make between library code that should exception/assert/abort on error and application code that should verify input and display an error to the user.

Correct - but in the case I described above, you (and your program) are the user.

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

#83

Post by UncleMeat »

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…

This was a deliberate design choice by Anders. It is quite difficult to make a sound type system for JS that has nice interoperability and ultimately adoption was more important.

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

#84

Post by duckfruit »

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 gradually add types to an existing codebase with developers who are just learning the language with the ability make the system sounder over time is a killer feature for me. Also, the big-company backing helps corporate slaves like me trying to sell a new technology to management.

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

#85

Post by mdgrech23 »

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.

Switching endpoints may not be option. It's probably not. Why would your company have two endpoints that do the same thing. If it's a third party service you could switch to a competitor but that's not that simple either.

Switching jobs? I mea yea you could but again that's not exactly an option for a lot of people. Particularly in the short term.

Mean while your app is stuck on a loading screen with an infinite spinner and bad reviews are flowing into the app store.

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

#87

Post by [deleted] »

Aqueous wrote: post #69

Not sure what this author is saying here. Types have nothing to do with being able to trust other systems and everything to do with the internal formal consistency of the code that you write. It's about being consistent with yourself. If you find yourself writing defensive checks in fulfilled promise handlers because the data you get is sometimes invalid, stop. Get up from your keyboard, go to whoever owns the endpoi…

[deleted]

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

#88

Post by platz »

ritchiey wrote: post #70
cetra3 wrote: post #12

I love TypeScript and use it in any new project I create. The author is right though, you need to have team discipline to avoid using the `any` type when it can be avoided, and immutability is not in scope. TypeScript is probably the closest we'll get to my personal ideal of static typing in JS, while understanding that you sometimes need an escape hatch to deal with dynamic typing as JS is a dynamic language. I thin…

You don’t need to wait for web-assembly to solve these problems. TA mentions 3 languages (Elm, Reason & Purescript) that combine sound type-checking and immutability right now. None of these bring the cognitive overhead of Rust’s borrow checker and, in the case of Reason at least, compile at lightning speed to readable (though optimised) JS.

Purescript also has a nice escape hatch as OP desires because it has a native JavaScript ffi unlike, say, elm.

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

#89

Post by Aqueous »

mdgrech23 wrote: post #85
Aqueous wrote: post #81

Earlier quoted context omitted.

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.

Switching endpoints may not be option. It's probably not. Why would your company have two endpoints that do the same thing. If it's a third party service you could switch to a competitor but that's not that simple either. Switching jobs? I mea yea you could but again that's not exactly an option for a lot of people. Particularly in the short term. Mean while your app is stuck on a loading screen with an infinite spin…

In many companies, there's also option C - fix it yourself. Any way you slice it, the bug is in the system that's reporting the wrong condition, and adding a defensive check merely papers over an issue with additional code complexity.

Sure - your program can degrade gracefully. But that should be for informational / diagnostic purposes only. It doesn't change the fact that you're using a system that is not living up to its data contract.

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

#90

Post by woah »

Aqueous wrote: post #82
user5994461 wrote: post #74

Earlier quoted context omitted.

If your software crashes on bad user input, that's an error in your software. By the way, there is distinction to make between library code that should exception/assert/abort on error and application code that should verify input and display an error to the user.

Correct - but in the case I described above, you (and your program) are the user.

You’ve clearly had a blessed and gentle career
Post reply on HN