Comment by towelrod | Hacker News Reader

Comment by towelrod | Hacker News Reader

I frequently write tcl, and I work in a company that has been using it in production for 20+ years. I've written thousands of lines of Tcl, but I only go back to Tcl when I have to work on legacy stuff these days. I wouldn't even remotely consider writing something new in Tcl.

I really wish someone would take charge of wiki.tcl.tk and cut out all the nonsense. For example, I am currently in need of producing some JSON from one of our Tcl apps. So I search for JSON and I get this:

http://wiki.tcl.tk/13419

It starts out pretty promising -- listing a bunch of competing JSON implementations for tcl -- which is unusual for a wiki.tcl.tk page. But then it quickly devolves into the usual stream of consciousness that infects every tcl wiki page. What am I supposed to actually do?

At first we have a big list of different implementations; that makes sense, every language is kinda like that.

But before the first page is even finished, we get weird "string is double gotcha" stuff from gchung, including "you should use the following" 100 character regex! How about: you should use this module for doing this usual thing that every language in the world can do?

Then, we get JMN's thoughts about how a JSON generator is better than a JSON parser. Apparently TCV solved this himself in 2009 (but, no code referenced). Very quickly we get into "here's my version!".

I'm not complaining about all these guys contributing different solutions. But can't the community gather around one of them? It's like searching wikipedia but always landing on the "talk" page.

Hey tclers, try this on for size. Google for "perl json" and see if you get a real response that explains how to do it, or a bunch of random guys talking about how they solved it themselves. Then try "ruby json", "java json", "python json".

That is why tcl is dead.

> It's like searching wikipedia but always landing on the "talk" page.

I think the TCL wiki is old enough that it dates to the era when that was what a wiki was supposed to be. The original c2.com wiki has a lot of that flavor too. The Wikipedia idea of having main pages that serve as working drafts of "articles" and moving the discussion to separate "talk" pages caught on a few years later. Of course that doesn't preclude switching now...

Tcl suffers in this respect from the same problem that FORTH does - the language is so malleable that everyone does it their own way. For example, before tcl got it's own native OO system, there were LOTS of competing OO systems, some which were compiled extensions, others written in pure tcl. All had proponents, none were standard.

Within the tcl community, this problem is well known, it just seems no one has the time to take on the enormous, thankless, never-ending task of curating all the useful bits that have been dropped over time. A few wikignomes bravely try to improve things, but it is like moving a mountain of sand with a pair of tweezers. (or emptying a well with an eyedropper).

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 'ruby json' I get http://ruby-doc.org//stdlib-2.0/libdoc/json/rdoc/JSON.html, which is part of the standard library.

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?

If it helps, I've recently used huddle[0] to create arbitrarily-nested dictionaries and output JSON of them. It can be quite slow to do a jsondump for large dictionaries though: it sometimes takes a few minutes to output a multi-megabyte file.

And, to add to your point, it wasn't even listed on the JSON page you mentioned until the "Misc" conversation section.

[0] http://wiki.tcl.tk/21116

Thanks -- that does seem to be working ok for me. I'm going to try it out, since I'm having a hard time finding a tcllib rpm for RHEL.

Reply on news.ycombinator.com