al_form2000

Except ftp is alive.

Yes, that's in the specs. But what I meant is that there is nothing intrinsic to the format demanding unordered behavior.

Granted, it came from there, but that was back in the days of map=eval(json) and they're gone. There is nothing in json the format (as opposed to json the language construct) to impose the unordered behavior.(Or, for that matters, the 'no comments' bit).

Agree. Except that the sheer number of questions about this spell "missed use case" - to my eyes at least. Sort of like the "How do I push a local branch to remote?" question in GITland.

That's a way. A way that, IMHO, vastly diminishes its expressive power on the reader's side, which I do not consider a very good thing. Most solutions to the issue are of this nature.

Consider serialized JSON already has a natural ordering, which is thrown away for some reason (probably parsing convenience).

Uh, "no good reason" in this case means "I unchecked the box and nothing bad happened right away" which amounts to shallow analysis, to put it gently.

"Why would you care what order we were sending the name value pairs for this?" The article makes it sound like it's somehow IBM's fault. However, questions about preserving order in hashes/associative arrays/maps/whatchamacallit span at least thirty years. Some applications of the format even demand it (e.g. ansible uses YAML - a superset of JSON - or even straight JSON for it playbooks; emitting them out of order is not an option).

Every time the issue surfaces it elicits a large amount of eye rolling among the cognoscenti. However, I'm a firm believer in the idea that recurring demands from the user base need to be addressed, rather then mocked. The coding community appears to me notably tone deaf on this.

'Course anybody can use <insert suitable technique> to send a JSON map in the desired order, except the parser on the other hand will blissfully disregard it. Or you can devise any ordered solution on both ends, which will leave you outside of the accepted standard and open you up to the situation described in the article (where the requirement may well have been frivolous).

I can remember very few - if any - instances of somebody implying that the standard should somehow make room for this kind of scenarios. The standard reply was "use a different format" or "change the requirement". (Somehow remembers me of people asking what can one do to have whitespace-preserving XML, and at least one amusing story about that)

Somewhere there is retribution awaiting our species for this. Think of it, maybe this reset procedure is part of it.

'There is no doubt that AI may one day become much more intelligent than humans' Really?

The title giveth, the body takes away. Articles like these have been making the rounds for maybe 6 ears now, and I cannot see how this brings even a moderately non-stale perspective to the fray .I checked the date, it's from today. Must be a slow week at SciAm.

Tl;dr: The world and the web suck; Tim Berner-Lee was a clueless Pollyanna; We're gonna solve everything with DECENTRALISATION that will come to pass by (makes vague hand gestures, draws ballon shaped objects).

What a bunch of useless drivel.

And just to be cute, this uses 2 pipes and is shorter (but I would not write it this way).

    #!/usr/bin/perl -w
    use strict;
    use English;
    use autodie;
    
    sub f { open(my $h,"/bin/ls $_[0]|") ; print "--\n",(<$h>),"--\n";}
    
    open(my $o,">/tmp/out.txt") ; select $o ; f("/tmp") ;
    open($o,"| wc -l ")         ; select $o ; f("/tmp") ;

I tried not to make it too golfish, but dispensed with niceties such as error detection and somesuch (which aren't there in the bash version - still autodie will catch most snafus). I also joined a few lines to make it closer to what's happening in the shell version. No doubt experienced golfers could make it tighter/shorter, but methinks that's not the point of the exercise.

    #!/usr/bin/perl -w
    use strict;
    use English;    
    use autodie;
    
    $OFS=$ORS="\n";

    sub f { my $h ; opendir($h,$_[0]) ; print "--",(readdir($h)),"--"; closedir($h);}

    my $out;

    open($out,">/tmp/out.txt") ; select $out ; f("/tmp");close($out);
    open($out,"| wc -l ")      ; select $out ; f("/tmp"); close($out);

    select STDOUT;

Would I use perl/python to write this kind of stuff? 'course not. Why would I go through the opendir rigmarole, if all I really need is 'ls'. But there are zillions of (non application) tasks where bash's syntax gets very quickly unwieldy (think filenames with blanks, quoting quotes, composing pipes programmatically, having several filehandles open at once...) while perl shines. And you can still throw the occasional

@ary=split("\n",`ls`);

around if you feel so inclined.

Just another attempt of the (liberal, regrettably) media to morph the story in something that is not.

The incident name (by consensus) is not "Female activist is exposed to techies' hate" but "Grandstanding blogger doxxes fellow developer, falls on own sword." Shifting focus and sweeping inconvenient facts under the rug is not going to make them go away.

http://t.co/Be9d7ISHlu