I found your comment, though intemperate, to be illuminating. You criticize the nature of the first search result you find, but I note the second (in my browser) points the searcher to the Tcl library packages for processing JSON, whose docs provide what you ask for: simple explanations and examples on how to do it.
Now on to the other languages you mention:
> Hey tclers, try this on for size. Google for "perl json"
OK. The first result I get is a man page for a module that claims to be a bridge for two other modules, one pure perl the other perl+C. There's paragraphs and paragraphs of warnings about version incompatibilities and advice about handling corner cases, which if you're not careful about lead to data loss, because in perl Everything Is Not A String.
First two results for "ruby json" are for gems tailored to two different ruby versions. Of course ruby is famous for breaking backward compatibility even for minor releases, so make a choice and it may work out for you. Keep in mind the reports of massive security vulnerabilities when using ruby to parse JSON.
First result for "java json" is a page full of pointers to class definitions, and a link to a package whose author claims to have no time to maintain it and hasn't used it in a decade. If that makes you uncomfortable, the home page of the first link helpfully provides references to 26 separate Java JSON libraries.
First two results for "python json", like ruby, are for the unpredictably compatible versions 2 and 3. Like perl and ruby, there are many paragraphs of warning about corner cases and data loss because Everything Is Not A String.
The top paragraphs of these results I admit make things look simple, but mask significant implementation issues that tend to trap the unwary newbie or explode outright, that aren't issues at all with Tcl.
It may be that the appeal of Tcl will always be limited to a minority who prefer to discuss a little first and consider issues of compatibility, stability, scalability, maintainability and security before implementing. Like the people who run your company? 20+ years in business, presumably it's profitable.
Maybe we get different search results. When I search for 'perl json' it leads to http://search.cpan.org/~makamaka/JSON-2.90/ which is a mature and easy to use JSON client. It does talk about backwards incompatible changes from version 1.0 -- but that was back in 2007.
When I search for 'java json' I get several libraries, all of which are actively supported: www.json.org/json, gson, and Jackson.
I don't really understand your comment about significant implementation issues that aren't issues at all with Tcl. Could you give an example? What edge cases aren't covered by the standard Perl and Ruby JSON libraries?
Now on to the other languages you mention:
> Hey tclers, try this on for size. Google for "perl json"
OK. The first result I get is a man page for a module that claims to be a bridge for two other modules, one pure perl the other perl+C. There's paragraphs and paragraphs of warnings about version incompatibilities and advice about handling corner cases, which if you're not careful about lead to data loss, because in perl Everything Is Not A String.
First two results for "ruby json" are for gems tailored to two different ruby versions. Of course ruby is famous for breaking backward compatibility even for minor releases, so make a choice and it may work out for you. Keep in mind the reports of massive security vulnerabilities when using ruby to parse JSON.
First result for "java json" is a page full of pointers to class definitions, and a link to a package whose author claims to have no time to maintain it and hasn't used it in a decade. If that makes you uncomfortable, the home page of the first link helpfully provides references to 26 separate Java JSON libraries.
First two results for "python json", like ruby, are for the unpredictably compatible versions 2 and 3. Like perl and ruby, there are many paragraphs of warning about corner cases and data loss because Everything Is Not A String.
The top paragraphs of these results I admit make things look simple, but mask significant implementation issues that tend to trap the unwary newbie or explode outright, that aren't issues at all with Tcl.
It may be that the appeal of Tcl will always be limited to a minority who prefer to discuss a little first and consider issues of compatibility, stability, scalability, maintainability and security before implementing. Like the people who run your company? 20+ years in business, presumably it's profitable.