0. I'd be interested in some additional perspective on why you believe the contents are irrelevant. (thanks!)
1. kona, also - but since his general gist was about architectural issues, rather than focussing on a particular implementation, I am inclined to forgive him for the slightly confused presentation. 2. J is indeed single threaded, but you can run multiple J processes. And, in fact, jhs gives you a server implementation which (with a relatively small amount of work - trivial compared to the amount of work people put into serious programming efforts) can give you multiple J processes under the control of a single client. 3. Here, I think you are drawing a contrast between high volume transaction processing (such as Amazon might need for its shopping cart implementation) and analytics work (where someone tries to correlate information). I am not sure that I'd use a K/Q rdbms implementation at Amazon - I expect the hardware costs would be too high. Then again, I'm not working for Amazon so I'm not sure that I'll care a lot about this issue. [More generally: a tool being useful never means that other tools are not useful for other things.] And, as an aside, perl can be fun... (but I've not read that /. page, yet) Anyways... I feel that the point you are trying to drive at is that no one has been writing much about using J in multiprocess contexts, yet? If so, I'll just remind you that that's more a cultural observation - about what we have felt like doing and talking about - than anything else. Thanks again, -- Raul On Wed, Jul 31, 2013 at 10:22 AM, CL Jason <[email protected]> wrote: > 0. Yes, the pictures are taken of many APL/J masters, but the contents are > much irrelavent. > 1. arguments based on k/q: please check all the concrete examples against > nosql apps, if those paragraphs of k/q were removed, there are only empty > assertions > 2. up to now, J is single-threaded, k/q has some supports of > multi-threading, which is one form of concurrency/parallel programming > 3. DBMS is more than just a query interface, and supporting the subset of > SQL doesn't mean the other parts of SQL are shit. > > there is even /. advertisement: > > http://developers.slashdot.org/story/13/07/30/2348212/remember-the-computer-science-past-or-be-condemned-to-repeat-it > where > you'll even see ads for Perl... > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
