Fear, trust and JavaScript: When types and functional programming fail • Hacker News Board

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

#91

Post by ender7 » Sat, Oct 27, 2018, 3:15 PM UTC

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 which compile to JS!). Complaining that an imperative language isn't a soundly-typed functional language is tautologically true I guess, but who cares?

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

#92

Post by Aqueous » Sat, Oct 27, 2018, 3:20 PM UTC

woah wrote: post #90

Aqueous wrote: post #82

Earlier quoted context omitted.

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

You’ve clearly had a blessed and gentle career

I've worked for very large companies whose massive codebases are littered with defensive checks that have piled up over many years. Invariably, I find that this is because, when the initial wave of defensive checks inevitably broke down because they guard against something that itself changes behavior again, more defensive checks were added.

All of this could have been avoided if those companies had just created a culture, from the beginning, where you force the upstream data provider to fix its issues rather than coding around them by allowing code to fail-fast rather than gracefully.

Now companies are beginning to introduce integration and unit testing across the board and type systems (again, to ensure internal consistency for systems so that other systems can depend on them) and the cruft and defensiveness is slowly going away.

To repeat the old cliché, the best defense is a good offense :-)

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

#93

Post by mpolichette » Sat, Oct 27, 2018, 3:21 PM UTC

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…

I agree with this. I’m all for writing checks against values which may be optional, but I don’t litter my logic with checks against code that should provide the appropriate data.

If you’re getting bad data you need to address the issue higher up. Either through fixing your source or if you’re forced into some badly behaving library then you should at most write a wrapper around it and make that as isolated as possible. Then you should start making plans to deprecate that library.

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

#94

Post by mpolichette » Sat, Oct 27, 2018, 3:24 PM UTC

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…

Getting the problem fixed is about culture as much as anything else.

If there is some legacy reason something cannot be fixed and has to keep returning bad data, then yes, there is 100% a reason to have two endpoints that do the same thing... usually prefixed with /v2/ or something

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

#95

Post by Aqueous » Sat, Oct 27, 2018, 3:25 PM UTC

mlthoughts2018 wrote: post #72

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.

not sure why you're being modded down. i find this comment hilarious and it reminds me of individuals i've encountered.

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

#96

Post by Nitramp » Sat, Oct 27, 2018, 3:27 PM UTC

It's a bit hard to follow what the author wants to tell us, so I might be misrepresenting below (sorry!). I don't think the assertions that (I think) they make hold though, or are particularly useful.

The author claims "functional programming, types, JavaScript: pick two". He supports that with links to a number of libraries that have incomplete type definitions, and a few patterns that are hard to express in a static type system.

I don't think that assertion holds. Some JavaScript APIs are indeed written in a style that's very hard to give static types for, and some libraries have sub-par type definitions.

But odd JavaScript APIs != the entirety of functional programming, and sub-par type definitions are just missing features that need to be fixed. You can write perfectly fine, statically typed, functional programming idioms within the TypeScript type system (and presumably within Flow). You can even do that within the confines of Java's type system, and that's a lot weaker than TS' or Flow's.

These type systems are optional, and you can subvert them. If you use the recommended strictness flags though, it's hard to do so accidentally.

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

#97

Post by Aqueous » Sat, Oct 27, 2018, 3:28 PM UTC

davedx wrote: post #78

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 b…

Don't think it's unrealistic at all from within a single company.

The point about 3rd party libraries is taken but I also think if you are using a 3rd-party endpoint that publishes a specification that it then doesn't live up to (and takes months to fix) then it's not a reliable partner in whatever you're doing and is not living up to its own promises about the data its customers can expect. Like one of the other commenters here said, time to deprecate or write a wrapper around it that enforces the data contract.

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

#98

Post by eropple » Sat, Oct 27, 2018, 3:54 PM UTC

ItsMe000001 wrote: post #48

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…

Same here. I have been using Flow (mostly) and TS (occasionally, including counter-checking problems in Flow to see what TS does in a similar case). Overall I would not go back to the time without a type checker, however, I too am mystified by the enthusiasm. Anyone who wants to check the state of static type checking for Javascript should take some time and read through - https://github.com/Microsoft/TypeScript/issu…

> I spent more time working on the types than on the actual code.

That's interesting. I very strongly don't, when writing TypeScript (but I don't then also mess around with a second type system on top of it). Better Intellisense and fail-up-front checking means I write code much, much faster.

I didn't have to change my coding style because this is already how I wrote code; I now have the tools to actually do it well.

TypeScript is not a "complex dynamic" language unless you step outside its bounds. Which, sure, sometimes you need to; it's not perfect, and one of its advantages is being able to opt out when absolutely necessary. Then you fence off that type-unsafe code by strongly testing before you hand something back into TypeScript because you're a competent programmer who understands the limitations of your tools. But that happens so very, very rarely that optimizing for that corner case seems foolish.

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

#99

Post by l_t » Sat, Oct 27, 2018, 3:56 PM UTC

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…

The most important thing, if you haven't already, is to set the noImplicitAny and strictNullChecks compiler flags. I find that not having these flags set is a common source of Typescript type unreliability.

The flags prevent two behaviors that are a major source of type failures: defaulting some types to "any", and allowing null/undefined to be valid values for ANY type (!). Enabling these flags for an existing codebase is likely to uncover hundreds of type errors that are papered over with the default compiler settings.

W.r.t. upstream types for libraries being wrong, I find the silver lining here is that libraries will usually be happy to accept patches for their types, often with significantly less fuss than a patch to the actual code.

edit: Even with those in place, I also notice that Typescript types are not 100% trustworthy. This often comes down to unsanitized input, use of the "as" keyword, or hidden type violations. The conclusion I've come to is that it's just very hard to type Javascript code, partly because the values themselves are so prone to being mutated. So I agree that Typescript doesn't feel like the perfect solution to me. (I usually use Clojurescript these days).

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

#100

Post by qwer » Sat, Oct 27, 2018, 4:02 PM UTC

tempodox wrote: post #37

Tade0 wrote: post #18

Earlier quoted context omitted.

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.

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 values are what are necessary. Types on the other hand are neither necessary nor sufficient.