5 ms·

My application data structures ARE the JSON structures (or the YAML ones, they both map to generic data types in any language). That's the beauty of it. If you

My application data structures ARE the JSON structures (or the YAML ones, they both map to generic data types in any language). That's the beauty of it. If you have distinct application structures that means you're reinventing ad-hoc scalars, sequences and mappings for the sake of encapsulation. You gain absolutely nothing yet you now have mountains of rigid code to maintain and you can't use generic data functions anymore - more ad-hoc stuff to write! Even working in statically typed languages you can get away with HashMap<String, Object> or IDictionary<string, object> and call it a day. Very few things require the performance of custom types and its a complete myth that types makes you safer - you have so much more code that bugs are more likely to crawl in.

zeveb 10y ago
> If you have distinct application structures that means you're reinventing ad-hoc scalars, sequences and mappings for the sake of encapsulation. You gain absolutely nothing yet you now have mountains of rigid code to maintain and you can't use generic data functions anymore - more ad-hoc stuff to write! No, it means that one has types. What does '{"length": 3}' mean? 3 items? 3 inches? 3 kilometres? For that matter, is '{"length": "abc"}' incorrect? > Very few things require the performance of custom types and its a complete myth that types makes you safer - you have so much more code that bugs are more likely to crawl in. Having caught many, many bugs from strong types, I feel comfortable saying that you're incorrect here. Yes, there are even more sources of bugs than just type errors. There are also more bugs than memory-management errors. But just as manual management of memory very rarely makes sense, manual management of types very rarely makes sense. If you don't have a solid sanitisation/marshalling/untainting/whatever-you-call-it layer, you're going to have security and other correctness errors.
- jeremiep 10y ago
  > No, it means that one has types. {length: 3} has a very specific type. Shoving that into a struct Foo { double length; } doesn't make it any safer. A simple validator and properly naming fields to mention units makes you safer than types. > For that matter, is '{"length": "abc"}' incorrect? That's a non-issue with even the simplest of validators. > Having caught many, many bugs from strong types, I feel comfortable saying that you're incorrect here. Yet you still need a test suite to handle the huge holes left by the type-system. These tests will catch all bugs the strong types would along the way. Unless you're having a Hindley-Milner type system, chances are you're working in C++, Java or C# and bugs caught by these type-systems are very superficial. > If you don't have a solid sanitisation/marshalling/untainting/whatever-you-call-it layer, you're going to have security and other correctness errors. Totally agree, but you don't need types or XML for that. Having worked as much with statically typed languages and dynamic ones, I'll chose the later any day unless I have very strict performance/memory requirements which is not happening for 99.9% of projects. Types might catch the easy and superficial bugs, but my ability to reason prevents the hard ones. Having orders of magnitude less code to think about is exactly what I want to achieve it.
  - zeveb 10y ago
    > > For that matter, is '{"length": "abc"}' incorrect? > That's a non-issue with even the simplest of validators. That's the point: the user-marshalled data must pass through the validator, and once it's passed through, it's no longer the same type. Perl figured this out with its taint mode 20 years ago. We shouldn't be still exposing ourselves to these sorts of bugs. > Unless you're having a Hindley-Milner type system, chances are you're working in C++, Java or C# and bugs caught by these type-systems are very superficial. If a better tool is available, why use a lesser? > Totally agree, but you don't need types or XML for that. I'm not arguing for XML. XML is almost as horrendous an embarrassment for the profession of software development as is JavaScript. If someone is looking for a data-interchange format and settles on XML, something is deeply wrong with either him or his situation. XML's just terrible. But passing around JSON objects within one's code is insane. JSON is a (decent) data-transfer format, an completely unsuitable for computation. > Types might catch the easy and superficial bugs, but my ability to reason prevents the hard ones. Having orders of magnitude less code to think about is exactly what I want to achieve it. I completely agree, which is why I don't use XML, JSON, JavaScript, C or Java. It's why I use a marshalling layer: I only have to think about user-marshalled data in that layer; I get to only think about my problem set everywhere else.
    - jeremiep 10y ago
      > 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

> If you have distinct application structures that means you're reinventing ad-hoc scalars, sequences and mappings for the sake of encapsulation. You gain absolutely nothing yet you now have mountains of rigid code to maintain and you can't use generic data functions anymore - more ad-hoc stuff to write! No, it means that one has types. What does '{"length": 3}' mean? 3 items? 3 inches? 3 kilometres? For that matter, is '{"length": "abc"}' incorrect? > Very few things require the performance of custom types and its a complete myth that types makes you safer - you have so much more code that bugs are more likely to crawl in. Having caught many, many bugs from strong types, I feel comfortable saying that you're incorrect here. Yes, there are even more sources of bugs than just type errors. There are also more bugs than memory-management errors. But just as manual management of memory very rarely makes sense, manual management of types very rarely makes sense. If you don't have a solid sanitisation/marshalling/untainting/whatever-you-call-it layer, you're going to have security and other correctness errors.

jeremiep 10y ago
> No, it means that one has types. {length: 3} has a very specific type. Shoving that into a struct Foo { double length; } doesn't make it any safer. A simple validator and properly naming fields to mention units makes you safer than types. > For that matter, is '{"length": "abc"}' incorrect? That's a non-issue with even the simplest of validators. > Having caught many, many bugs from strong types, I feel comfortable saying that you're incorrect here. Yet you still need a test suite to handle the huge holes left by the type-system. These tests will catch all bugs the strong types would along the way. Unless you're having a Hindley-Milner type system, chances are you're working in C++, Java or C# and bugs caught by these type-systems are very superficial. > If you don't have a solid sanitisation/marshalling/untainting/whatever-you-call-it layer, you're going to have security and other correctness errors. Totally agree, but you don't need types or XML for that. Having worked as much with statically typed languages and dynamic ones, I'll chose the later any day unless I have very strict performance/memory requirements which is not happening for 99.9% of projects. Types might catch the easy and superficial bugs, but my ability to reason prevents the hard ones. Having orders of magnitude less code to think about is exactly what I want to achieve it.
- zeveb 10y ago
  > > For that matter, is '{"length": "abc"}' incorrect? > That's a non-issue with even the simplest of validators. That's the point: the user-marshalled data must pass through the validator, and once it's passed through, it's no longer the same type. Perl figured this out with its taint mode 20 years ago. We shouldn't be still exposing ourselves to these sorts of bugs. > Unless you're having a Hindley-Milner type system, chances are you're working in C++, Java or C# and bugs caught by these type-systems are very superficial. If a better tool is available, why use a lesser? > Totally agree, but you don't need types or XML for that. I'm not arguing for XML. XML is almost as horrendous an embarrassment for the profession of software development as is JavaScript. If someone is looking for a data-interchange format and settles on XML, something is deeply wrong with either him or his situation. XML's just terrible. But passing around JSON objects within one's code is insane. JSON is a (decent) data-transfer format, an completely unsuitable for computation. > Types might catch the easy and superficial bugs, but my ability to reason prevents the hard ones. Having orders of magnitude less code to think about is exactly what I want to achieve it. I completely agree, which is why I don't use XML, JSON, JavaScript, C or Java. It's why I use a marshalling layer: I only have to think about user-marshalled data in that layer; I get to only think about my problem set everywhere else.
  - jeremiep 10y ago
    > 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.