[ale] Ubuntu 18.04 release notes

[Alex Carver]

On 2018-04-27 23:59, Steve Litt wrote:

> OK, but how about this:
> 
> {"array1":{"A","B","C","D"},"struct1":{"param1":val,"param2":val},
> "struct2":{"param3":val,"param4":val}"list":{{"list_item_id":id,
> "list_item_name":"foo","list_item_param":param},{"list_item_id":id,
> "list_item_name":"foo","list_item_param":param},
> {"list_item_id":id,"list_item_name":"foo","list_item_param":param}}}
> 
> Every format/language I know of that's not indentation aware has end
> tags, which are ultimately readable by machines, but not so much by
> humans. Which is why humans usually lay out their
> indentation-independent code with strict indentation rules. There's a
> name for getting rid of the spacing in C: *Obfuscated* C. You ever try
> working on a large web page where they got rid of newlines to save a
> few bytes? Whatamess!
> 
> Ever seen C code worked on by 4 different coders?
> 
> int square(i){
>    return(i*i)
> }
> 
> int cube(i)
>    {
>    return(i*i*i)
>    }
> 
> int quad(i)
> {
>    return(i*i*i*i)
> }
> 
> int quint(i)
>    {
>    return(i*i*i*i)
> }
> 
> 
> int
>    sept(i)
>       {
>    return(i*i*i*i*i*i)
> }
> 
> The preceding are only the tip of the iceberg. There are
> plenty more indentation standards. Programmers go to war over this
> stuff.
> 
> And what happens when a maintenance programmer misunderstands some
> careless indentation, and adapts his end tags to that bogus
> understanding?
> 
> The fact is, most humans need indentation context to quickly understand
> a program or format. Since the indentation context is necessary, why
> not make it part of the format, so we're all on the same page, and,
> hooray, get rid of the end tags?
> 
> Don't get me wrong, indentation dependency doesn't work for everything.
> HTML and XML without end tags would be a horror movie. But where it
> works, I think indentation dependency is often an improvement.
> 
> This is just one of the reasons I like Python so much.

You missed my point, though.  If I have to create a configuration file
using a parsed format then it's technically easier to use a format that
is agnostic to white space because of the use of start/end markers/tags,
etc.  So writing out JSON the way I did is conceptually easier to read
in a configuration file than the equivalent YAML simply because I don't
have to care what the white space looks like and where they fall.
Technically I don't even know if the example I wrote was going to be
parsed as valid YAML.  It looks like a configuration file I had to try
and write but didn't work and also looks like one the software generated
but wouldn't work either.

The discussion started with the idea of using YAML for configuration
files and it just seems ill suited for that application given how picky
it is about exact formatting with lines and spaces.