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

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

#111

Post by always_good » Sat, Oct 27, 2018, 5:00 PM UTC

nycdotnet wrote: post #59

sbr464 wrote: post #54

I think shortcuts like the following are fundamentally flawed, at least when dealing with user input. If (user && user.name) { ... While it sucks to have to even check for user etc, not checking that it’s truthy, then an object, then checking that the name is the correct type also during runtime, will cause bugs over time. This type of developer provided shorthand validation is pretty much the cause of all hacks/data…

Will be nice when JS gets the Elvis operator and you’ll be able to do ‘if (typeof user?.name === “string”)’ which will have the added value of type narrowing/interaction with ‘never’ if name is expected to be something else.

I'd say the elvis operator would make things worse, especially wrt the parent post.

The problem isn't that `user && user.username` style validation is verbose, but that it's very error-prone. Making it less verbose just means you'll more likely use it before you reach for a better validation strategy, like a declarative validation library.

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

#112

Post by scilro » Sat, Oct 27, 2018, 5:03 PM UTC

Aqueous wrote: post #95

mlthoughts2018 wrote: post #72

Earlier quoted context omitted.

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.

I understand why it’s being downvoted, but I too find it very funny.

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

#113

Post by Scarbutt » Sat, Oct 27, 2018, 5:09 PM UTC

tybit wrote: post #58

scns wrote: post #56

Earlier quoted context omitted.

With Bucklescript/Reason you get typesafety, immutability, performance and small codesize: >Now we compare the runtime performance: BuckleScript Immutable Map: 1186ms Facebook Immutable Map: 3415ms We also compare code Size: BuckleScript (Prod mode): 899 Bytes Facebook Immutable: 55.3K Bytes source: https://github.com/BuckleScript/bucklescript/wiki/Why-buckle...

I’m still amazed by how much faster transpiling from Reason is compared to TypeScript or JavaScript is via Babel.

Thank Bucklescript.

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

#114

Post by mdgrech23 » Sat, Oct 27, 2018, 5:14 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…

100% agree with this. If you're using redux the boilerplate of Typescript is huge. To do that all that work and still have the compiler miss problems at the state level deemed Typescript pointless to me.

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

#115

Post by staticassertion » Sat, Oct 27, 2018, 5:22 PM UTC

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.

Uhhhhh, this is not realistic? If I have to quit my job or switch services every time those services have a bug I'm going to be switching jobs every other week.

Anyways, I think the author is actually looking for something along the lines of gRPC, where your constraints are far stricter and easier to enforce. Option types don't even really make sense for what they're after from what I could tell.

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

#116

Post by maxhallinan » Sat, Oct 27, 2018, 5:27 PM UTC

tom_ wrote: post #106

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…

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.

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

#117

Post by erikpukinskis » Sat, Oct 27, 2018, 5:29 PM UTC

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 experience in a tech even beyond what the company they are interviewing is using. That’s your best position to get hired.

It’s easy to write JavaScript you can trust. Heck, you can write a trustworthy web server in Visual Basic. Trustworthy code just isn’t worth much to 99% of the players involved.

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

#118

Post by nabla9 » Sat, Oct 27, 2018, 5:30 PM UTC

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?

The larger argument is that you can't have the "language level trust" until you push __everything__ trough the same comppiler/transpiler/validation pipeline and can trust that everything has gone trough it and it has not been modified by other means.

Using Javascript as a platform where you mix code generated trough different conventions and tools is a halfway solution. Javascript treated as the unmodifiable binary from the compiler creates same level of trust as using other languages.

Technically:

* In C++ somebody can use different header for the class and break the class abstraction.

* In Haskell some library might go trough the FFI into the runtime and assign values to data in non-functional way and break the functional abstraction.

* In Python and Java there are ways to access data in ways that circumvent the compiler or the language semantics.

The difference is how strong the convention against doing so is and does breaking the abstraction have any benefits.

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

#119

Post by ken » Sat, Oct 27, 2018, 5:31 PM UTC

ghosthamlet wrote: post #63

Javascript is maybe the language made or suitable for simple app, If you will make a big complex app, There is a simple way to fix this: use more strong languages Compile to Javascript like Elm/PureScript/BuckleScript/ScalaJs/Nim/ClojureScript(with core.specs) and so on[1]. [1] https://github.com/jashkenas/coffeescript/wiki/List-of-langu...

Yes, that's exactly what the conclusion to the article says.

As someone who has (almost entirely) given up writing plain JS, my skimming of this article is "2500 words about issues with JS mutability, then: just use ClojureScript".

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

#120

Post by maxhallinan » Sat, Oct 27, 2018, 5:35 PM UTC

l_t wrote: post #99

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

Thanks for the tip! I'm gonna try this on Monday.

To be clear: I'm not complaining about these third party types. I really appreciate that people took the time to write and share these. My gratefulness is definitely not contingent on perfection. I fully expect human work to be imperfect. Type systems exist to guard against this imperfection. A type system in which type annotations are maintained separately from the implementations, and are routinely debugged is highly suspect.