> I thought that you were arguing for using JSON data structures rather than custom data structures. I very rarely go for custom data structures :) I won't des

> I thought that you were arguing for using JSON data structures rather than custom data structures. I very rarely go for custom data structures :) I won't destroy data by giving it an ad-hoc type, and unless I'm working in a statically typed language I won't have a "JSONValue" type to deal with in the first place; I'll get the same value from JSON.parse as if I wrote "const defaultCfg = {host: 80};". But now I can do something like "const cfg = merge(defaultCfg, validateConfig(JSON.parse(cfgFile)));" where validateConfig takes a hash map and returns a hash map (or something behaving like a hash map). [edit] by destroy I mean you lose the ability to work on unknown data, which is a requirement to build robust distributed systems. When you marshall into a custom type and lose 3 fields, the endpoint is not going to be happy. > What do you mean by 'generic data functions'? Functions like map, filter, reduce, take, drop, zip, split, join, get, nth, head, tail, and hundreds more operating on scalars, sequences and mappings. > Which is what's insane. I don't want a dictionary; I want an instance. A dictionary is an instance. Your custom class with getters/setters is nothing more than an ad-hoc dictionary. The only time I'll go for a struct is when I get performance constraints and need to pack/align data and have continuous memory to batch operations and not trash the cache. I don't want a custom type where I have to write boilerplate around for every single operation when I have hundreds available ready to be composed. > And we discovered decades ago that it's useful to talk about categories of data (types) and about data that carries along with it behaviour (classes). Data by definition has no behaviour, its plain information. You're talking about state and there I agree, I want my state close to its behaviour because they're tightly related. But I don't want the _declarations_ of state and behaviour to be coupled either. Haskell and Clojure both solve this problem nicely with type classes and protocols respectively. You can make your types behave like sequences and mappings, but that's just extra boilerplate when talking about data and not state. > Programming is all about building intelligent abstractions which enable you to reason at a higher level. I agree, but you only need a handful of abstractions, most of the time what you're doing by wrapping data in a type is an indirection not an abstraction. S-exprs by themselves are just data, they're the very same as JSON (not versioned, not extensible). YAML supports tags making it easy to plug your custom types directly into its reader.