<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">>Ever seen C code worked on by 4 different coders?<br>
<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">My worst was code that I believe was edited in WordPad with a non-monospaced font.  Noting lined up to the left at all<br><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Apr 28, 2018 at 3:00 AM Steve Litt via Ale <<a href="mailto:ale@ale.org">ale@ale.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 27 Apr 2018 10:00:46 -0700<br>
Alex Carver via Ale <<a href="mailto:ale@ale.org" target="_blank">ale@ale.org</a>> wrote:<br>
<br>
> On 2018-04-27 09:43, Kyle Brieden via Ale wrote:<br>
> > <a href="https://twitter.com/sadoperator/status/989895215442837504" rel="noreferrer" target="_blank">https://twitter.com/sadoperator/status/989895215442837504</a><br>
> > <br>
> > But seriously, though, I appreciate YAML for what it is, and that<br>
> > is "a human readable markup language".  It's easy to look over it<br>
> > and suss out what is what, much like JSON.  I prefer JSON to YAML,<br>
> > but they're both widely used and well implemented most of the<br>
> > time.  <br>
> <br>
> JSON is reasonably human readable and certainly does not depend on<br>
> indentation to read it.<br>
> <br>
> I can read and write this:<br>
> <br>
> {<br>
> "array1": {"A", "B", "C", "D"},<br>
> "struct1": {"param1": val, "param2": val},<br>
> "struct2": {"param3": val, "param4": val}<br>
> "list":<br>
>     {<br>
>       {"list_item_id": id, "list_item_name": "foo",<br>
> "list_item_param": param }, {"list_item_id": id, "list_item_name":<br>
> "foo", "list_item_param": param }, {"list_item_id": id,<br>
> "list_item_name": "foo", "list_item_param": param } }<br>
> }<br>
> <br>
> far easier and with less likelihood of errors <br>
<br>
OK, but how about this:<br>
<br>
{"array1":{"A","B","C","D"},"struct1":{"param1":val,"param2":val},<br>
"struct2":{"param3":val,"param4":val}"list":{{"list_item_id":id,<br>
"list_item_name":"foo","list_item_param":param},{"list_item_id":id,<br>
"list_item_name":"foo","list_item_param":param},<br>
{"list_item_id":id,"list_item_name":"foo","list_item_param":param}}}<br>
<br>
Every format/language I know of that's not indentation aware has end<br>
tags, which are ultimately readable by machines, but not so much by<br>
humans. Which is why humans usually lay out their<br>
indentation-independent code with strict indentation rules. There's a<br>
name for getting rid of the spacing in C: *Obfuscated* C. You ever try<br>
working on a large web page where they got rid of newlines to save a<br>
few bytes? Whatamess!<br>
<br>
Ever seen C code worked on by 4 different coders?<br>
<br>
int square(i){<br>
   return(i*i)<br>
}<br>
<br>
int cube(i)<br>
   {<br>
   return(i*i*i)<br>
   }<br>
<br>
int quad(i)<br>
{<br>
   return(i*i*i*i)<br>
}<br>
<br>
int quint(i)<br>
   {<br>
   return(i*i*i*i)<br>
}<br>
<br>
<br>
int<br>
   sept(i)<br>
      {<br>
   return(i*i*i*i*i*i)<br>
}<br>
<br>
The preceding are only the tip of the iceberg. There are<br>
plenty more indentation standards. Programmers go to war over this<br>
stuff.<br>
<br>
And what happens when a maintenance programmer misunderstands some<br>
careless indentation, and adapts his end tags to that bogus<br>
understanding?<br>
<br>
The fact is, most humans need indentation context to quickly understand<br>
a program or format. Since the indentation context is necessary, why<br>
not make it part of the format, so we're all on the same page, and,<br>
hooray, get rid of the end tags?<br>
<br>
Don't get me wrong, indentation dependency doesn't work for everything.<br>
HTML and XML without end tags would be a horror movie. But where it<br>
works, I think indentation dependency is often an improvement.<br>
<br>
This is just one of the reasons I like Python so much.<br>
<br>
SteveT<br>
<br>
Steve Litt <br>
April 2018 featured book: Troubleshooting Techniques<br>
     of the Successful Technologist<br>
<a href="http://www.troubleshooters.com/techniques" rel="noreferrer" target="_blank">http://www.troubleshooters.com/techniques</a><br>
_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org" target="_blank">Ale@ale.org</a><br>
<a href="https://mail.ale.org/mailman/listinfo/ale" rel="noreferrer" target="_blank">https://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Pete Hardie<br>--------<br>Better Living Through Bitmaps</div>