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

61–70 of 210 posts

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

#61

Post by larzang »

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…

Weekly, sometimes daily, I run into a situation where flow is straight up wrong in baffling ways, or needlessly developer-hostile, and I end up having to help my junior team members write worse (or at least more verbose) code to compensate.

It's still a million times better than JS without TS/flow.

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

#62

Post by davedx »

nathan_f77 wrote: post #25

The author talks about Immutable.js, but doesn't mention Records, which have been a real godsend in my application. I use Immutable.Record with types [1] (using Flow), and I feel very confident with this setup. You are forced to set default values for every key, and the code will crash if you try to set a key that hasn't been defined. It's really great to have typed Records (often nested), and I expose the getters as…

Records is also how elm deals with JSON serialization IIRC.

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

#63

Post by ghosthamlet »

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...

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

#64

Post by scns »

scns wrote: post #56
nathan_f77 wrote: post #25

The author talks about Immutable.js, but doesn't mention Records, which have been a real godsend in my application. I use Immutable.Record with types [1] (using Flow), and I feel very confident with this setup. You are forced to set default values for every key, and the code will crash if you try to set a key that hasn't been defined. It's really great to have typed Records (often nested), and I expose the getters as…

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...

regarding records specifically:

https://medium.com/@javierwchavarri/performance-of-records-i...

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

#65

Post by dbattaglia »

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.

Imagine some language with the following type and functions:

  type Person { name: String }
  function parsePerson(json: String): Person { ... }
  function usePerson(person: Person) { ... }
The compiler will guarantee that usePerson will always get the correct shape of data for it's person variable. The only function you need to worry about is parsePerson, which will generally throw a runtime error if the incoming JSON does not conform to the expected shape. And in most web frameworks, the JSON to type parsing is done for you so once the framework hands you data in the type you are asking for you can expect it to be correct.

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

#68

Post by Kaveren »

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...

Additionally, you don't even need to use language implementations that compile to JavaScript. WebAssembly is progressing and is quite arguably ready for production use.

I really like Rust personally and think it's a good option for web applications, but there's many options that are becoming available.

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

#69

Post by Aqueous »

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 endpoint, and ask them why their endpoint is returning a 200 OK response with data that doesn't live up to its spec. This is a bug in their system, not yours.

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

#70

Post by ritchiey »

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.

Post reply on HN