Is having to use something like a json-like schema just admitting that the language is broken? If you can’t trust or use common practices inherent to the language to do things in a typed way if needed then what is the point of a not strongly typed language?
Fear, trust and JavaScript: When types and functional programming fail
51–60 of 210 posts
Re: Fear, trust and JavaScript: When types and functional programming fail
#52Is having to use something like a json-like schema just admitting that the language is broken? If you can’t trust or use common practices inherent to the language to do things in a typed way if needed then what is the point of a not strongly typed language?
To be honest, just having a defined, literal type is not going far enough.
Is there a built in language strategy, in Rust for example, to define a complex numerical type that has common properties like min/max range, exclusive min/max, conditionally required logic etc?
Of course you can put some custom checks/logic to validate, but not sure why people instantly shame json-schema. From a validation perspective (not tooling) typescript is simplistic compared to a reusable, extended json schema.
It may be a matter of time for other js/ts tools to improve. I’ve been learning Rust and I haven’t seen a better solution currently for runtime/user input validation. (Not a c/rust expert by any means)
Re: Fear, trust and JavaScript: When types and functional programming fail
#53Is having to use something like a json-like schema just admitting that the language is broken? If you can’t trust or use common practices inherent to the language to do things in a typed way if needed then what is the point of a not strongly typed language?
To be honest, just having a defined, literal type is not going far enough. Is there a built in language strategy, in Rust for example, to define a complex numerical type that has common properties like min/max range, exclusive min/max, conditionally required logic etc? Of course you can put some custom checks/logic to validate, but not sure why people instantly shame json-schema. From a validation perspective (not to…
Currently, you do runtime checks. We’ve accepted an RFC for integer generics that will let you do compile-time checks instead, but we’re still working on an implementation.
Re: Fear, trust and JavaScript: When types and functional programming fail
#54I think shortcuts like the following are fundamentally flawed, at least when dealing with user input.
If (user && user.name) { ...
This type of developer provided shorthand validation is pretty much the cause of all hacks/data breaches currently. It’s more of an attitude or how a developer prioritizes their own wants/needs over maybe a client/end user. Like I mentioned in another comment, checking for more advanced, abusive behavior will make issues with type checking seem basic in comparison.
Re: Fear, trust and JavaScript: When types and functional programming fail
#55I 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…
Yes. That's why a good language makes this explicit in the type.
For example in Scala, this example would be that user is of type Option[User] and the name property would also be Option[String] for example.
Then to safely get the name would be:
user.flatMap(_.name)
and the resulting type would be Option[String]
Which would then carry on the info that you don't know for certain that you know the name.
Re: Fear, trust and JavaScript: When types and functional programming fail
#56The 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
BuckleScript (Prod mode): 899 Bytes
Facebook Immutable: 55.3K Bytes
https://github.com/BuckleScript/bucklescript/wiki/Why-buckle...
Re: Fear, trust and JavaScript: When types and functional programming fail
#57Earlier quoted context omitted.
To be honest, just having a defined, literal type is not going far enough. Is there a built in language strategy, in Rust for example, to define a complex numerical type that has common properties like min/max range, exclusive min/max, conditionally required logic etc? Of course you can put some custom checks/logic to validate, but not sure why people instantly shame json-schema. From a validation perspective (not to…
Currently, you do runtime checks. We’ve accepted an RFC for integer generics that will let you do compile-time checks instead, but we’re still working on an implementation.
Thanks Steve
Re: Fear, trust and JavaScript: When types and functional programming fail
#58The 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...
I’m still amazed by how much faster transpiling from Reason is compared to TypeScript or JavaScript is via Babel.
Re: Fear, trust and JavaScript: When types and functional programming fail
#59I 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.
Re: Fear, trust and JavaScript: When types and functional programming fail
#60Many 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?