Live data from Hacker News

YAML: probably not so great after all (2017)

arp242.net

401–410 of 412 posts

Re: YAML: probably not so great after all (2017)

#401
post #246

Earlier quoted context omitted.

Interestingly, the Lua programming language actually evolved from configuration files: https://www.lua.org/history.html (and is still officially deemed useful for writing them)

That was also one of the rationales behind TCL's design. John Ousterhout explained in one of his early TCL papers that, as a "Tool Command Language" like the shell but unlike Lisp, arguments were treated as quoted literals by default (presuming that to be the common case), so you don't have to put quotes around most strings, and you have to use punctuation like ${}[] to evaluate expressions. TCL's syntax is optimized…

In our Tcl based application server (many eons ago), we followed exactly that approach.

All configuration files were Tcl data structures that were sourced on server start.

Re: YAML: probably not so great after all (2017)

#402
post #96
post #74

Earlier quoted context omitted.

JSON5 supports comments, and is only slightly more complex than JSON. https://json5.org/

The barrier here would be whether there's support in enough implementations to feel safe using it in the wild, which I'm guessing will take a while at the very least.

The popularity of transpilers might help overcome that barrier. IDE's and task runners can watch for file modifications and run a simple program to convert to the old format.

But I'm curious what you mean by "in the wild"? If you're using (producing) it, something needs to consume it, and you would probably have control over both in whatever project you were using it for.

Re: YAML: probably not so great after all (2017)

#403
post #380

Earlier quoted context omitted.

Do you need a time zone for dates?

Consider if I'm storing a user's (local) birthday on my server: {..., "birthday": "2018-03-25"} If my server is located in New York City, and the user is in Sydney, then my server isn't going to wish them happy birthday in time. So maybe we could do: {..., "birthday": "2018-03-25", "location": "Sydney/AU"} But at this point we might as well use a standardized time format (UTC) with a timezone offset. Maybe I'm thinki…

ISO 8601 has you covered:

   Year:
      YYYY (eg 1997)
   Year and month:
      YYYY-MM (eg 1997-07)
   Complete date:
      YYYY-MM-DD (eg 1997-07-16)
   Complete date plus hours and minutes:
      YYYY-MM-DDThh:mmTZD (eg 1997-07-16T19:20+01:00)
   Complete date plus hours, minutes and seconds:
      YYYY-MM-DDThh:mm:ssTZD (eg 1997-07-16T19:20:30+01:00)
   Complete date plus hours, minutes, seconds and a decimal fraction of a second
      YYYY-MM-DDThh:mm:ss.sTZD (eg 1997-07-16T19:20:30.45+01:00)
  where:

     YYYY = four-digit year
     MM   = two-digit month (01=January, etc.)
     DD   = two-digit day of month (01 through 31)
     hh   = two digits of hour (00 through 23) (am/pm NOT allowed)
     mm   = two digits of minute (00 through 59)
     ss   = two digits of second (00 through 59)
     s    = one or more digits representing a decimal fraction of a second
     TZD  = time zone designator (Z or +hh:mm or -hh:mm)

Re: YAML: probably not so great after all (2017)

#404
post #180

Years ago I had to support a tool that used YAML as a configuration language, and a transport between different applications. Holy. Hell. First of all, don't ever try to edit a YAML file by hand. You will introduce whitespace or other characters that will break the file, and you will not know until you run it and it breaks something. The reason you will not know? Not all YAML parsers are the same. Some will interpret…

Well your last sentence is the whole point: What is a sensible configuration language? For example what would have been decent for Ansible?

Chef just uses Ruby.

Re: YAML: probably not so great after all (2017)

#405
post #305

Earlier quoted context omitted.

JSON5 is also a great alternative: https://json5.org/ Supports comments, trailing commas, single quotes, multi-line strings, and more number formats.

I really wished json5 would support optional commas as well. If you have a new line, no comma needed. So you can do [ 1 2 3 ] New lines used by humans, computers should do a good job as well.

Well you could use CSON, which uses CoffeeScript notation that allows for constructs such as:

required: [

  'firstName'

  'lastName'
]

which is the same as:

{

  "required": [

    "firstName",

    "lastName"

  ]
}

in JSON :)

Re: YAML: probably not so great after all (2017)

#406
post #2

We've spent like 10 years trying to fill in gaps left when we all decided to hate XML. JSON is great as a lightweight DIF between trusted partners. If you care about maintenance and safety, XML with XSD is rock solid.

I don't know, XML is awfully verbose and the schemas are even more verbose. I've lost track of how many "XML" configuration files that looked like this: ApplicationName WhizBang ... So that they could pass schema validation and still have some hope of extensibility.

I would definitely use RelaxNG for specifying schemas instead of XSD - it's simpler both to read and write in every case I've tried, and the resulting schema is smaller as well, often by a lot.

  
    
      
        
          
        
        
          
        
      
    
  
http://www.relaxng.org/tutorial-20011203.html

Plus there's a non-XML "compressed" version as well:

  element addressBook {
    element card {
      element name { text },
      element email { text }
    }+
  }
But I agree that XML like you posted is nasty, it's no harder to write

  WhizBang
instead if you need generic parameters, or

  WhizBang
if not.

Re: YAML: probably not so great after all (2017)

#407
post #384

Earlier quoted context omitted.

YAML tags work this way. E.g., 2002-04-28 is a date (because it looks like one) but !!str 2002-04-28 is a string.

I had never heard of tags before. Thanks! So, would this work? ports: https: enabled: yes !!int port: 443 Then if someone is copy/pasting and tries to use "blah" as the value, the !!int tag would cause the yaml parser to throw an error. Right?

No, because tags specify a type for the value, not the key, so you could use

  ports:
    https:
      port: !!str 443
to parse the same as

  {
    "ports": {
      "https": {
        "port": "443"
      }
    }
  }
in JSON

Re: YAML: probably not so great after all (2017)

#409
post #379

Our shop are heavy users of YAML, and we've sort of backed our way into a restricted subset of YAML. Some of them are config files, but others function closer to DSLs. I have not yet taken a look at strictyaml, but after years of use the spec definitely needs YAML, The Good Parts Treatment. One thing the author did not mention was how slow the out of box the Python YAML parser can be. This can be sped up with a call…

I suspect the speed issues are more a result of implementation details than of being in Python. Last year, I created a config language for my own use that supports some syntax very similar to YAML. My pure Python library can load simple dict/list/string data 10x as fast as PyYAML, and nearly within 1.5x the speed of libyaml ( https://bespon.org/#benchmarks ). That's while building an AST with source information to al…

I did a few rudimentary benchmarking tests on in house real world data sets and strictyaml was approx 10X slower than PyYAML's yaml.load (w/ out calling out to libyaml) and yaml.safe_load.

I used the basic strictyaml.load function, without any schemas.

README page said speed is not a current priority, and that appears to be true.

https://github.com/crdoconnor/strictyaml#strictyaml

Re: YAML: probably not so great after all (2017)

#410
post #384

Earlier quoted context omitted.

I had never heard of tags before. Thanks! So, would this work? ports: https: enabled: yes !!int port: 443 Then if someone is copy/pasting and tries to use "blah" as the value, the !!int tag would cause the yaml parser to throw an error. Right?

No, because tags specify a type for the value, not the key, so you could use ports: https: port: !!str 443 to parse the same as { "ports": { "https": { "port": "443" } } } in JSON

Ah, I had my syntax wrong. Thanks!
Post reply on HN