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

71–80 of 210 posts

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

#71

Post by hoodunit »

maglite77 wrote: post #60

Many of these concerns seem to not be limited to Javascript at all - especially once you're sending/receiving data between systems. In Python for example, when receiving JSON/XML payloads you have the same defensive parsing layer at the point of entry, but humans can still mess that up and monkey patch a class that breaks assumptions elsewhere without warning. Did I miss something in the larger argument?

No, that is exactly correct. The brunt of the argument applies to most popular languages- Java, Python, Ruby, and what have you- although the specifics vary.

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

#72

Post by mlthoughts2018 »

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…

But the gRPC purist who wrote that endpoint while mandating that unit testing private methods is philosophically worse than genocide and using a slackbot to append “don’t write tests for the compiler” to every pull request got a huge payout to leave the company last year before sexual harassment complaints could move forward.

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

#73

Post by hoodunit »

Tade0 wrote: post #10

But in JavaScript, the fear is always with you. That's why we have both tests and code reviews. Aside from that I'm surprised the author didn't mention checking constructors. It's arguably the most dependable way of checking if something is of a certain type. But I agree that it's a shame that TS/Flow lose their ability to check types whenever partial application or currying is involved - it's not like it's impossibl…

TS/Flow don't quite lose types "whenever" partial application or currying is involved, it's a bit more subtle than that and in many cases it works fine. But especially when using generics with currying you often have to rewrite in more verbose ways (or structure the functions in a particular way) to make the types check through.

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

#74

Post by user5994461 »

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.

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

#75

Post by dfgdghdf »

Kiro wrote: post #33
pka wrote: post #27

Earlier quoted context omitted.

You try to parse the received data into a predefined data type, if this fails you are forced by the type system to handle the failure scenario, if it parses correctly you now have a 100% valid data structure you can work with in the rest of your codebase, no defensive checks necessary.

How does that work? I thought static typing was only checked when compiling.

You write code at the entry point that might fail. Perhaps it returns either structured data or an error. From that point on, you can work only with structured data and the type-system will help you. You might be able to generate a parser from a schema.

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

#76

Post by AlexCoventry »

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…

That's usually a sign that you need to define your own types for the objects in question. I had to do this for immutable.js records, because the default types on its methods are basically lies.

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

#78

Post by davedx »

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…

This is an unrealistic strategy.

Often the systems you're connecting to aren't maintained by people in the same office or company as you.

Every back end and front end system I've worked on as long as I can remember has had dependencies on third party API's. Getting bugs fixed in those APIs could sometimes take months ("change requests"), if at all.

Finding a good balance for how your system gracefully degrades is a bit of an art form.

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

#79

Post by mdgrech23 »

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.
Post reply on HN