[deleted]
Fear, trust and JavaScript: When types and functional programming fail
21–30 of 210 posts
Re: Fear, trust and JavaScript: When types and functional programming fail
#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 TypeScript that I encounter online.
Re: Fear, trust and JavaScript: When types and functional programming fail
#23> In a dynamic language like JavaScript, it can be hard to know what the shape of your data is. You don't need static typing to program defensively. Static typing instead ensures a certain defensive position, but as a developer you can choose to program in such a way even in a dynamic language. That being said it is foolish to make a blanket assumption that data is doomed to confusion. The state and shape of data is…
It's nothing to do with "a dose of common sense" so much as it is the reality of dealing with humans. Humans make mistakes. Static typing is automated checks to make sure you didn't. When doctors start using checklists their patients do better [1]. Static typing is checklists for programmers. In theory weak dynamic typing works great. In practice humans suck. Hence checklists. [1] https://www.newyorker.com/magazine/2…
How would static typing help you if it's two different applications like the post you reply to is talking about?
Re: Fear, trust and JavaScript: When types and functional programming fail
#24> In a dynamic language like JavaScript, it can be hard to know what the shape of your data is. Being dynamic doesn't preclude variables from being type checked by the runtime. Reading this just sounds like "javascript has no built in support for type checking, so lets pretend it's not possible" All the time people spent making weird unreadable 'fat functions', but you still can't define the types of arguments you wa…
The runtime is unhelpful unless your tests include 100% code coverage.
Huh?
If the runtime can guarantee your function receives an instance of a particular class, that's a lot of boiler plate you don't need to write yourself to assert the same thing.
Re: Fear, trust and JavaScript: When types and functional programming fail
#25The 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 regular properties so that I don't have to call "get()" all the time. I agree that it's not perfect, but it's miles ahead of anything I've worked with in the past (at least in terms of JavaScript.)
JSON schemas are awesome, and I like the idea of validating types at runtime on the front-end. I already have a JSON schema that defines my API (I use Swagger), so I could even go one step further and auto-generate my typed Records directly from the schema. I'll get immediate feedback about any type errors in my JS codebase as soon as I make changes to the API. I generate my Swagger API specification automatically from some RSpec tests (using rswag [2]), and I also run Flow during CI, so this would result in a broken build. I could also make this work with the data I'm inlining in the HTML to hydrate the Redux store.
Random aside: I also have a one set of data that just gets dumped into a jsonb database column, so the schema for this specific data is only being defined by the front-end code. In my backend I'm always careful to provide a default value, but it's not really critical data. Anyway, I just realized that I should be defining this jsonb column as an actual model, but instead of ActiveRecord, I could use ActiveModel and a plain Ruby class. That's a neat idea. It would give me a schema and validations on the backend, while still having the flexibility and performance of storing everything in a single json column.
[1] https://gist.github.com/glenjamin/75a96b45f4bb5c6ac221815d28...
Re: Fear, trust and JavaScript: When types and functional programming fail
#26Countless fear avoidance trick #465: use browser form semantics for ui state and leverage mutation observers and proxies to delegate the rest.
nice article
Re: Fear, trust and JavaScript: When types and functional programming fail
#27Earlier quoted context omitted.
It's nothing to do with "a dose of common sense" so much as it is the reality of dealing with humans. Humans make mistakes. Static typing is automated checks to make sure you didn't. When doctors start using checklists their patients do better [1]. Static typing is checklists for programmers. In theory weak dynamic typing works great. In practice humans suck. Hence checklists. [1] https://www.newyorker.com/magazine/2…
How would static typing help you if it's two different applications like the post you reply to is talking about?
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.
Re: Fear, trust and JavaScript: When types and functional programming fail
#28Earlier quoted context omitted.
It's nothing to do with "a dose of common sense" so much as it is the reality of dealing with humans. Humans make mistakes. Static typing is automated checks to make sure you didn't. When doctors start using checklists their patients do better [1]. Static typing is checklists for programmers. In theory weak dynamic typing works great. In practice humans suck. Hence checklists. [1] https://www.newyorker.com/magazine/2…
How would static typing help you if it's two different applications like the post you reply to is talking about?
You can insert whatever level of validation you need at the untyped interface between the two... just as you would with dynamically typed languages.
Re: Fear, trust and JavaScript: When types and functional programming fail
#29The 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…
Probably the reason is that reasonable Flow types for Records aren't in the mainline 3.0 release, and 4.0 (with good static typing support) has been in RC hell for about a year and a half.
Re: Fear, trust and JavaScript: When types and functional programming fail
#30Earlier quoted context omitted.
It's nothing to do with "a dose of common sense" so much as it is the reality of dealing with humans. Humans make mistakes. Static typing is automated checks to make sure you didn't. When doctors start using checklists their patients do better [1]. Static typing is checklists for programmers. In theory weak dynamic typing works great. In practice humans suck. Hence checklists. [1] https://www.newyorker.com/magazine/2…
This completely ignores my comment in its entirety. Do people make mistakes: yes. Does software ever have defects: yes. Typically, people making mistakes in software is called a software defect. It is absolutely critical in a discussion like this to understand that defects in software are not necessarily defects in data. This conversation is about data, and checks for processing data are already present in various fo…
> For example when was the last time you complained about weak type systems when working with JSON, XML, or SQL tables?
Well, I don't know about the person you're replying to, but I certainly complain about these all the time.
Interestingly and counter to your point, I think, XML grew a "type system" of sorts with XML Schema (which is widely used IME, esp. where interfacing with external services as in SOA), and SQL actually has a reasonably strong type system for most implementations albeit dynamically checked at query planning time. (SQLite seems to be the outlier here.)
JSON is actually the outlier here, but even with JSON there's been attempts at a sort-of type system with JSON Schema. Why? Well, because beyond a certain size the "just chuck some data somewhere in there" ceases to be workable when you want stable and maintainable interfaces between software components.
Ultimately type systems are invented and used for almost entirely pragmatic reasons.