4 ms·

> and once it's passed through, it's no longer the same type. How is that different from loading a JSON into custom data structures? You run the exact same val

> and once it's passed through, it's no longer the same type. How is that different from loading a JSON into custom data structures? You run the exact same validation step, have the exact same data for input, but your result is now unusable by the entirety of your generic data functions. You'd be better off with a hash-map than a class. > If a better tool is available, why use a lesser? Because no tool is better all across the board. Otherwise we'd have the holy grail of programming languages right there. However, I'll favor productivity and the ability to reason about code over performance or some weak validation that I didn't make a typo or sent a string where a boolean was expected. Besides, I have already spent weeks trying to debug type errors in C++; its ridiculously easy to break the type system. I've also had countless cast exceptions in both Java and C#; how are types helping there? If anything they give you the illusion of correctness. > But passing around JSON objects within one's code is insane. That's not at all what you do. When you do JSON.parse the result is already using the language's data structures; there is no concept of "JSON objects". Even in C#/Java you can map these to dictionaries or use reflection to directly map these to ad-hoc structures/classes. > I completely agree, which is why I don't use XML, JSON, JavaScript, C or Java. Its rarely up to you. There aren't many endpoints supporting something other than JSON or XML. Anything running in the browser is automatically running JavaScript; anything embedded will go for C. Once the data is past the validator, its no longer user-marshalled data. Its just data. Wrapping it around ad-hoc types doesn't help your problem domain, it just adds yet another level of indirection you could easily do without. [edit] I should also add that I strongly favor YAML over JSON for two simple reasons; the format is both versioned and extensible. That fixes the problem in JSON of using string conventions for fancier types like dates. There I can load the data directly in exactly the shape I want it to.

zeveb 10y ago
> How is that different from loading a JSON into custom data structures? That's what I'm arguing for doing. I thought that you were arguing for using JSON data structures rather than custom data structures. > You run the exact same validation step, have the exact same data for input, but your result is now unusable by the entirety of your generic data functions. What do you mean by 'generic data functions'? I can do whatever I like with whatever parts of my language I wish. > Besides, I have already spent weeks trying to debug type errors in C++; its ridiculously easy to break the type system. I've also had countless cast exceptions in both Java and C#; how are types helping there? If anything they give you the illusion of correctness. They're not: C++, Java & C# are all examples of lesser tools. That's why I don't use them. > When you do JSON.parse the result is already using the language's data structures Which is what's insane. I don't want a dictionary; I want an instance. > Once the data is past the validator, its no longer user-marshalled data. Its just data. 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). Why limit yourself to whacking things with a stick to collect pinecones when you can use a starship to explore the galaxy? > Wrapping it around ad-hoc types doesn't help your problem domain, it just adds yet another level of indirection you could easily do without. Programming is all about building intelligent abstractions which enable you to reason at a higher level. I don't want to think about the third item of an array which is the value of a property name 'foo'; I want to think about interest rates, organisational rules and categories. I like YAML too; it's a decent format. Not perfect, but decent. Bit big though. I'd prefer something lighter weight like S-expressions though: just enough structure to make it easy to turn into native objects.
- jeremiep 10y ago
  > 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.
  - zeveb 10y ago

zeveb 10y ago

> How is that different from loading a JSON into custom data structures? That's what I'm arguing for doing. I thought that you were arguing for using JSON data structures rather than custom data structures. > You run the exact same validation step, have the exact same data for input, but your result is now unusable by the entirety of your generic data functions. What do you mean by 'generic data functions'? I can do whatever I like with whatever parts of my language I wish. > Besides, I have already spent weeks trying to debug type errors in C++; its ridiculously easy to break the type system. I've also had countless cast exceptions in both Java and C#; how are types helping there? If anything they give you the illusion of correctness. They're not: C++, Java & C# are all examples of lesser tools. That's why I don't use them. > When you do JSON.parse the result is already using the language's data structures Which is what's insane. I don't want a dictionary; I want an instance. > Once the data is past the validator, its no longer user-marshalled data. Its just data. 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). Why limit yourself to whacking things with a stick to collect pinecones when you can use a starship to explore the galaxy? > Wrapping it around ad-hoc types doesn't help your problem domain, it just adds yet another level of indirection you could easily do without. Programming is all about building intelligent abstractions which enable you to reason at a higher level. I don't want to think about the third item of an array which is the value of a property name 'foo'; I want to think about interest rates, organisational rules and categories. I like YAML too; it's a decent format. Not perfect, but decent. Bit big though. I'd prefer something lighter weight like S-expressions though: just enough structure to make it easy to turn into native objects.

jeremiep 10y ago
> 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.
- zeveb 10y ago