[HN Gopher] Show HN: Xfer, a data-transfer language
       ___________________________________________________________________
        
       Show HN: Xfer, a data-transfer language
        
       Xfer is an experimental language I've been defining for a little
       while. It's intended to be a strictly-typed alternative to Json
       that offers a few other features, like comments, nested elements,
       placeholder substitution, and metadata. It's in VERY early days, so
       I'd love to hear your suggestions and feedback.
        
       Author : paulmooreparks
       Score  : 8 points
       Date   : 2024-11-12 11:05 UTC (1 days ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | Terretta wrote:
       | I love that you are noodling in the open, and getting feedback /
       | impressions early -- that's the recipe for doing something new,
       | better!
       | 
       | Now, unfiltered first thoughts...
       | 
       | Have you used SOAP RPC and is it clear why the industry (outside
       | of banking and financial services that depend on correctness!)
       | largely shifted to JSONic REST?
       | 
       | At first exposure to this, the delimiters _feel_ like line noise,
       | as if SOAP and a lineprinter got together and said,  "How could
       | this offer less utility while being more opaque?"
       | 
       | There's a cognitive tax on something being unlike other things,
       | which is why so many substitutions end up adopting
       | handlebars/mustache type syntax, or so many things look like
       | INI/TOML/YAML/etc.
       | 
       | Have you looked at JSON5, XML + XSLT, JSONNET and the like? What
       | about JSON Schema and similar? ( https://json-
       | schema.org/understanding-json-schema/reference/... )
       | 
       | Not saying any of those are be-all end-all, they are not. But it
       | would be super helpful to have a "Why not X" page on your README
       | that shows you've considered SOTA across the landscape, and why
       | that doesn't work for you. See, for example:
       | https://hitchdev.com/hitchstory/why-not/
        
       | MisterKent wrote:
       | Personally, I don't see a huge upsell over JSON for interop.
       | Typing is great, but largely mitigated by things like typescript,
       | graphql generators etc etc. edit: and json schema
       | 
       | The biggest issue I see with JSON today is the inability to self
       | reference values. Data duplication overhead is high, and
       | deserializing doesn't work as expected if you want two objects to
       | be reference equal.
       | 
       | Also, nitpick: that syntax would be a grind to write manually vs
       | JSON.
        
       | James_K wrote:
       | There is no need to have a digraph surrounding every element of
       | data. Beyond being ugly, the digraphs make the file almost
       | impossible to edit for anyone not already familiar with them.
       | They require a large number of random symbols to be memorised.
       | The strict typing is also not really a benefit. You can define
       | the desired types of elements in a schema before reading data
       | (and will need to do that anyway for validation purposes). Having
       | the types also transcribed in the file means that writing out the
       | file and changing the types of data would be much harder. As an
       | example, when you force a file to specify if integers are 32-bits
       | or 64, you make it less general (it will only work with parser
       | that match that number of bits) and require extra data to do
       | that. A double loss over just writing the integer out. Even if
       | you are dedicated to strict typing, it makes more sense to do it
       | with something along the lines of C literals (12f, 100l, etc.)
       | because people are already used to that. This has the added
       | benefit that the letter you put after the number is also the
       | first letter of the type you want it to be, which is easier to
       | remember than ^ for double and * for decimal. It's also not
       | needed to put the identifier on both the opening and closing
       | angle brackets. The most obvious notation would be something akin
       | to what you might see in an assembly file, eg I32.900 for 900 as
       | a 32-bit integer.
       | 
       | JSON clearly wins this comparison because people can look at the
       | JSON and guess what it means. People aren't going to go for a
       | more complicated format that makes less sense. I personally
       | prefer Clojure's EDN when it comes to data formats just because
       | it looks nicer and removes redundant syntax. I don't think
       | there's much to be improved upon from there.
        
         | knowitnone wrote:
         | Agree, I'd rather see JSON extended to something dumb like this
         | { "name": "Alice" :\s, "age": 30 :\d, "isMember": true :\b,
         | "scores": [85, 90, 78.5] :\a, "profile": { "email":
         | "alice@example.com" :\s, "joinedDate": "2023-01-15T12:00:00"
         | :\t } }
        
       | ghjfrdghibt wrote:
       | I'm reminded of XML where all the information is store in
       | attributes.
        
       ___________________________________________________________________
       (page generated 2024-11-13 23:01 UTC)