6 ms·

well, web services were a complete bust too! It's interesting (as other commenters have noted) that now people implement rest interfaces and we don't seem to h

by sgt101 11y ago

well, web services were a complete bust too! It's interesting (as other commenters have noted) that now people implement rest interfaces and we don't seem to have any (other) standards for imposed (controlled) shared state. Agent standards like FIPA were supposed to enable consensual shared state by agreement, but have never really been used to do that. I guess the world really doesn't need these things yet?

tracker1 11y ago
In the end, simple, documented, defined (even if the documented/defined are simply the source you have access to) is easier to deal with than overly complicated systems that add little value, and a lot of cognitive overhead, confusion and indirection. This is why today's JSON services rule the roost so to speak. Not that there aren't attempts to create some standards... It's just that a lot of the time they don't add much value.
- rwmj 11y ago
  CORBA (and SOAP) had type safety, something which is missing from "modern" systems. JSON is an ill-defined standard - integers, for example, are almost completely undefined, and this causes real problems in real programs (eg [1]). [1] https://lists.gnu.org/archive/html/qemu-devel/2011-05/threads.html#02162 https://lists.gnu.org/archive/html/qemu-devel/2011-05/thread...
  - tracker1 11y ago
    Integers don't exist in JS/JSON... You get IEEE754 double precision floating point numbers, meaning whole numbers between -(2^53 - 1) through (2^53-1) are supported without rounding issues. If you need greater precision or fixed decimals, use a base10 string and an appropriate library in your application. I'd say the lack of strict date/locations in the spec are probably as big of an issue, but there are standards for how to handle that that have evolved as well... (geojson and ISO-8601 date-time strings).
    - rwmj 11y ago
      You've made my point with "If you need greater precision or fixed decimals, use a base10 string and an appropriate library in your application". In other words, it's not interoperable or type safe. BTW the JSON spec itself doesn't define integers at all. "Numbers are really floats" comes from Javascript and hence is just a convention for people who are using JSON from another language. The larger problem is the lack of schemas. In JSON they exist but no one uses them. CORBA forced you to have a schema (IDL). SOAP had schemas, albeit very complex ones which no one really understood.
      - tracker1 11y ago
        "JavaScript Object Notation" ... it makes perfect sense for JSON numbers to match JS numbers, which is IEEE spec.
  - sgt101 11y ago
    I find the lack of strong type assertion and checking is always alarming... I get a real sense of vertigo without type checking.
  - jacques_chester 11y ago
    > CORBA (and SOAP) had type safety, something which is missing from "modern" systems. You had the illusion of type safety. In practice, a robust distributed system needs to check all messages at each node -- ie, check types at runtime. Any distributed system is, in fact, a dynamically typed system, no matter what the headline says.

by sgt101 11y ago

tracker1 11y ago

In the end, simple, documented, defined (even if the documented/defined are simply the source you have access to) is easier to deal with than overly complicated systems that add little value, and a lot of cognitive overhead, confusion and indirection. This is why today's JSON services rule the roost so to speak. Not that there aren't attempts to create some standards... It's just that a lot of the time they don't add much value.

rwmj 11y ago
CORBA (and SOAP) had type safety, something which is missing from "modern" systems. JSON is an ill-defined standard - integers, for example, are almost completely undefined, and this causes real problems in real programs (eg [1]). [1] https://lists.gnu.org/archive/html/qemu-devel/2011-05/threads.html#02162 https://lists.gnu.org/archive/html/qemu-devel/2011-05/thread...
- tracker1 11y ago
  Integers don't exist in JS/JSON... You get IEEE754 double precision floating point numbers, meaning whole numbers between -(2^53 - 1) through (2^53-1) are supported without rounding issues. If you need greater precision or fixed decimals, use a base10 string and an appropriate library in your application. I'd say the lack of strict date/locations in the spec are probably as big of an issue, but there are standards for how to handle that that have evolved as well... (geojson and ISO-8601 date-time strings).
  - rwmj 11y ago
    You've made my point with "If you need greater precision or fixed decimals, use a base10 string and an appropriate library in your application". In other words, it's not interoperable or type safe. BTW the JSON spec itself doesn't define integers at all. "Numbers are really floats" comes from Javascript and hence is just a convention for people who are using JSON from another language. The larger problem is the lack of schemas. In JSON they exist but no one uses them. CORBA forced you to have a schema (IDL). SOAP had schemas, albeit very complex ones which no one really understood.
    - tracker1 11y ago
      "JavaScript Object Notation" ... it makes perfect sense for JSON numbers to match JS numbers, which is IEEE spec.
- sgt101 11y ago
  I find the lack of strong type assertion and checking is always alarming... I get a real sense of vertigo without type checking.
- jacques_chester 11y ago
  > CORBA (and SOAP) had type safety, something which is missing from "modern" systems. You had the illusion of type safety. In practice, a robust distributed system needs to check all messages at each node -- ie, check types at runtime. Any distributed system is, in fact, a dynamically typed system, no matter what the headline says.