4 ms·

I couldn't get the why of the project from the Github page alone. Rich Hickey's post introducing it a year ago is clearer: http://blog.cognitect.com/blog/2014/

by lars512 11y ago

I couldn't get the why of the project from the Github page alone. Rich Hickey's post introducing it a year ago is clearer: http://blog.cognitect.com/blog/2014/7/22/transit http://blog.cognitect.com/blog/2014/7/22/transit JSON has become the go-to schemaless format between languages, despite being verbose and having problems with typing. Transit aims to be a general-purpose successor to JSON here. Stronger typing allows the optional use of a more compact binary format (using MessagePack). Otherwise it too uses JSON on the wire. Anyone who knows more, please correct me.

gioele 11y ago
> JSON has become the go-to schemaless format between languages, despite being verbose and having problems with typing. Transit aims to be a general-purpose successor to JSON here. XML has become the go-to schemaless format between languages, despite being verbose and having problems with typing. JSON aims to be a general-purpose successor to XML here.
- zcdziura 11y ago
  History repeats itself, after all.
- brianberns 11y ago
  Yes, except that XML has a schema (XSD).
  - nmeofthestate 11y ago
    Ahem. http://json-schema.org/ http://json-schema.org/
    - orless 11y ago
      Quoting http://json-schema.org/latest/json-schema-core.html http://json-schema.org/latest/json-schema-core.html: "This Internet-Draft will expire on August 3, 2013."
      - orless 11y ago
        ... which, by the way, does not mean that JSON Schema is bad or unusable. I actually quite like it, it has certaint elegance. Just not really standard.
  - tel 11y ago
    That's an exterior thing. It's perfectly reasonable to talk about XML the schemaless markup language.
- vocaro 11y ago
  XML is not schemaless. It was designed to be extensible through schemas. It's in the name, after all: eXtensible Markup Language. XML also doesn't suffer the problems of a limited set of pre-defined types that JSON has. Its type system is extensible through schemas.
  - dragonwriter 11y ago
    > XML is not schemaless. Yes, it is, though there are a variety of schema schemes that can be used with XML. > It was designed to be extensible through schemas. It was designed to be extensible through custom tags (in fact, all tags are custom tags); it can be optionally be restricted through the use of schemas, not extended. > XML also doesn't suffer the problems of a limited set of pre-defined types that JSON has. Yes, it does, with an even smaller number of types. (Strings, with a couple different representations.) > Its type system is extensible through schemas. No, it isn't. Its structure can be constrained through schemas (XML Schema, Relax NG, etc.), which can provide a means of modeling a different type system on top of the data structure supported by XML, but that isn't really "extending" XMLs type system any more than using a Haskell compiler to generate x86 machine code is "extending" the type system of x86 machine code; its just providing a completely separate type system on a different layer. Also, no matter how you view this, its not a distinction between XML and JSON, since you can do the same thing with JSON, and just as there are a variety of different schema standards that do this for XML, there are a variety that do the same thing for JSON.
jimktrains2 11y ago
> maps (with arbitrary scalar keys, not just strings) Floating point keys just seem like a terrible idea.
- dragonwriter 11y ago
  > Floating point keys just seem like a terrible idea. I don't see why floating point (with a defined precision) keys are any worse fundamentally than any finite-domain scalar keys. The applications for which they are useful may be limited, and they may be the wrong choice for some uses, but that's true of anything.
  - jimktrains2 11y ago
    > floating point (with a defined precision) If it's fixed-precision it's not floating point, it's basically an integer we interpret with a decimal point somewhere when we display it. If you didn't mean fixed-precision, then I'm not sure how actual floating points could sanely act as a hash key.
    - tel 11y ago
      Even with a defined precision they're weird in that they "ought to" be modeling the reals and therefore lack computable equality. Which makes it hard to write a well-defined hash.
    - dragonwriter 11y ago
      > If it's fixed-precision it's not floating point I'm not referring to fixed point, but fixed-size representation. > If you didn't mean fixed-precision, then I'm not sure how actual floating points could sanely act as a hash key. I don't see what the problem is. Certainly, there's problems if you do certain floating point calculations and blindly look for the result as a key in a mapping, but that's not a problem with floats as keys, its a problem with that particular usage pattern.
      - jimktrains2 11y ago
brandonbloom 11y ago
Another important feature is stream-oriented caching of values. Essentially some range of opcodes in the stream language are reserved for referring to a cache of recently seen values. It's a "dynamic" encoding feature that's super beneficial for common payloads, like JSON API responses with lots of similar keys. This is something a protobuf/thrift-like should steal, as it can often be more efficient than vanilla field-number + value encoding.

by lars512 11y ago

gioele 11y ago

> JSON has become the go-to schemaless format between languages, despite being verbose and having problems with typing. Transit aims to be a general-purpose successor to JSON here. XML has become the go-to schemaless format between languages, despite being verbose and having problems with typing. JSON aims to be a general-purpose successor to XML here.

zcdziura 11y ago
History repeats itself, after all.
brianberns 11y ago
Yes, except that XML has a schema (XSD).
- nmeofthestate 11y ago
  Ahem. http://json-schema.org/ http://json-schema.org/
  - orless 11y ago
    Quoting http://json-schema.org/latest/json-schema-core.html http://json-schema.org/latest/json-schema-core.html: "This Internet-Draft will expire on August 3, 2013."
    - orless 11y ago
      ... which, by the way, does not mean that JSON Schema is bad or unusable. I actually quite like it, it has certaint elegance. Just not really standard.
- tel 11y ago
  That's an exterior thing. It's perfectly reasonable to talk about XML the schemaless markup language.
vocaro 11y ago
XML is not schemaless. It was designed to be extensible through schemas. It's in the name, after all: eXtensible Markup Language. XML also doesn't suffer the problems of a limited set of pre-defined types that JSON has. Its type system is extensible through schemas.
- dragonwriter 11y ago
  > XML is not schemaless. Yes, it is, though there are a variety of schema schemes that can be used with XML. > It was designed to be extensible through schemas. It was designed to be extensible through custom tags (in fact, all tags are custom tags); it can be optionally be restricted through the use of schemas, not extended. > XML also doesn't suffer the problems of a limited set of pre-defined types that JSON has. Yes, it does, with an even smaller number of types. (Strings, with a couple different representations.) > Its type system is extensible through schemas. No, it isn't. Its structure can be constrained through schemas (XML Schema, Relax NG, etc.), which can provide a means of modeling a different type system on top of the data structure supported by XML, but that isn't really "extending" XMLs type system any more than using a Haskell compiler to generate x86 machine code is "extending" the type system of x86 machine code; its just providing a completely separate type system on a different layer. Also, no matter how you view this, its not a distinction between XML and JSON, since you can do the same thing with JSON, and just as there are a variety of different schema standards that do this for XML, there are a variety that do the same thing for JSON.

jimktrains2 11y ago

> maps (with arbitrary scalar keys, not just strings) Floating point keys just seem like a terrible idea.

dragonwriter 11y ago
> Floating point keys just seem like a terrible idea. I don't see why floating point (with a defined precision) keys are any worse fundamentally than any finite-domain scalar keys. The applications for which they are useful may be limited, and they may be the wrong choice for some uses, but that's true of anything.
- jimktrains2 11y ago
  > floating point (with a defined precision) If it's fixed-precision it's not floating point, it's basically an integer we interpret with a decimal point somewhere when we display it. If you didn't mean fixed-precision, then I'm not sure how actual floating points could sanely act as a hash key.
  - tel 11y ago
    Even with a defined precision they're weird in that they "ought to" be modeling the reals and therefore lack computable equality. Which makes it hard to write a well-defined hash.
  - dragonwriter 11y ago
    > If it's fixed-precision it's not floating point I'm not referring to fixed point, but fixed-size representation. > If you didn't mean fixed-precision, then I'm not sure how actual floating points could sanely act as a hash key. I don't see what the problem is. Certainly, there's problems if you do certain floating point calculations and blindly look for the result as a key in a mapping, but that's not a problem with floats as keys, its a problem with that particular usage pattern.
    - jimktrains2 11y ago

brandonbloom 11y ago

Another important feature is stream-oriented caching of values. Essentially some range of opcodes in the stream language are reserved for referring to a cache of recently seen values. It's a "dynamic" encoding feature that's super beneficial for common payloads, like JSON API responses with lots of similar keys. This is something a protobuf/thrift-like should steal, as it can often be more efficient than vanilla field-number + value encoding.