Hacker News Reader

Comment by rurban | Hacker News Reader

While many applaud this notation superior to JSON let's face the criticsm:

It's slower than JSON, less readable than JSON and YAML, and more insecure than JSON.

To get this feature set, use YAML 2.0. YAML supports classes and references already, and is more readable then STON.

Slower: Having to support references, STON needs to store every object in a hash. JSON doesn't need to. JSON is at least 10x faster.

Readable: JSON and YAML have much less syntax, and are more pleasant to the eye.

Insecure: Changing classes in serialization protocols without any protection is the most common exploit vector. Esp. supporting user-classes, not only builtins. YAML at least supports builtin-classes only via tags.

View on HN

> Slower: ...every object in a hash...10x faster.

Did you measure the 10x faster?

Anyway, the dictionary is only needed on serialization, and then you only need an identity dictionary, which tends to be quite fast as it is only hashing the pointers. Deserialization only needs an array, with negligible overhead.

Furthermore, with JSON you tend to decode/encode via temporary dictionary representations anyway, which is many times more expensive when you're starting from an object representation. Going to an object representation also often materializes a full array/dictionary rep. because that's what the JSON specifies. You only figure out objects afterward.

So in my estimation, this has the potential of being significantly faster than typical JSON en-/de-coders.

[Background: I worked on XML parsing for a while, and having the tag preceding the contents was invaluable in creating efficient parsers that do not require a generic intermediate representation. Such generic intermediate representations typically do eat around 10x performance. See https://github.com/mpw/Objective-XML/tree/master

Although the first time I noticed about the effects of generic intermediate representations was parsing Display Postscript's Binary Object Sequences generated from a PS->PDF distiller written in Postscript to graphical objects]

Yes, otherwise I wouldn't come up with such numbers. I maintain several such serializers with various feature sets.

Yes, only serialization would be slow.

Yes, going directly to objects would be faster also. YAML or native serializers do that.

But your estimation is flawed. Fastest are still special pre-compiled serializers, such as protobuf, or better variants thereof which can mmap directly native objects.

then binary serializers such as messagepack or the insecure bson because of compression.

then json because of simplicity and limited recursion.

then the dynamic monsters, which support references and objects.

I would disagree that JSON is more readable than STON, if only for that fact that all keys have to be quoted in JSON, but I agree with the rest of your comment.

I was referring to the # pound syntax for fields. fields can be used with a . or - prefix much more pleasingly to the eyes. An untrained eye would take the # for comments.

    TestDomainObject {
      #created : DateAndTime [ '2012-02-14T16:40:15+01:00' ],
      #modified : DateAndTime [ '2012-02-14T16:40:18+01:00' ],
      #integer : 39581,
      #float : 73.84789359463944,
      #description : 'This is a test',
      #color : #green,
      #tags : [
        #two,
        #beta,
        #medium
      ],
      #bytes : ByteArray [ 'afabfdf61d030f43eb67960c0ae9f39f' ],
      #boolean : false
    }

Your untrained eye took the # for comments, but I'm not sure that generalized to anyone's. Plenty of languages use # for other things: Smalltalk uses them for symbols, Clojure uses them for reader macros, OCaml uses them for method calls, Haskell can use them as an arbitrary operator, Lua uses them for length, C and C++ use them for compiler directives. See https://en.wikipedia.org/wiki/Number_sign#In_computing for a list.

Admittedly, Python, Bash, Perl, and Ruby use # for comments, so you do have a point, especially since Python is such a common teaching language.

No, the point is the clutter. A pound # is the most intrusive ascii character, with about 85% black. Older languages were critised to use $ with about 55% black as prefix. It's like writing in ALL-CAPS.

This is a very valid critique in terms of graphic design.

(For anyone confused by the mention of graphic design: it's all about communicating information through visuals.)

Oh, I thought they were hashtags, I was gonna see if they were trending on twitter.

"An untrained eye would take the # for comments"

\begin{pedantry}

I'd argue that an untrained eye would take the # for ordinary syntax noise, since such an eye would have no notion of a "comment". A trained eye might be confused by that, but only if it was trained against an environment that uses # for comments.

\end{pedantry}

Since this looks like another human readable encoding shootout, I humbly offer luxem [0] which allows unquoted keys. Simpler than JSON, much simpler than JSON5, and probably as powerful as STON.

[0] https://github.com/rendaw/luxem

Reply on news.ycombinator.com