If you are trying to run old code, you might want to execute 9!:49]1 before doing so.
That said, when comparing J and C, the issue is not parallelism. It's more cpu cache management, code structure, and development support. But feel free to write this in C: 2 %~/\ ([: -/ .* [: +./~ 1 + i.)"0 i. 12 (Obviously, there's better ways of writing it in J, also.) Finally, when talking about sql support in k/q, it's not a native part of the language, but an application (kdb+) written in the language. I do not know if kona supports kdb+ but - hypothetically speaking at least - that should not matter. If you have a license to run kdb+ you have a license to use whatever k/q was shipped with it. Alternatively, you could write your own sql implementation... (that's how these things get written in the first place, after all - someone writes them. And, kdb+ was, I believe, written by a team of one programmer). Thanks, -- Raul On Wed, Jul 31, 2013 at 9:25 PM, CL Jason <[email protected]> wrote: > Sorry for the rants. These days I'm studying old APL docs and try to code > in J, when doing that I am amazed at how different they are (not to mention > that many old J code in 2000 can't run in current J, so it's great to see > LJ has updates), and yes, it's an addiction to play with J/APL. But I'm > disgusting of those advertisements and empty assertions without relevant > and concrete examples. In fact, J is very flexible, because you may look at > it as a wrapper of C, and vice versa. If expressible in C, then > concurrency/parallelism (that is not equivalent to threading) is a free > lunch nowadays. But for SQL-like query interface, k/q is the only > accessible one. Does kona support it? > > > On Thu, Aug 1, 2013 at 12:24 AM, Raul Miller <[email protected]> > wrote: > > > Of course. > > > > I don't think anyone would say that the existence of languages like APL > (or > > any of its derivatives) means that all of the rest of achievement in the > > context of computers will go away, or should go away. > > > > Ok, maybe some would say such things, but I see no reason to express > > agreement with them. > > > > Lessons to learn from though? > > > > That, I think is the point. > > > > Thanks, > > > > -- > > Raul > > > > > > On Wed, Jul 31, 2013 at 11:30 AM, CL Jason <[email protected]> wrote: > > > > > No, not-supporting-something is not a shame, nor a glory excuse. > > > Concurrency/parallel and dbms have their own merits and are also > > > interesting. > > > > > > > > > On Wed, Jul 31, 2013 at 10:44 PM, Raul Miller <[email protected]> > > > wrote: > > > > > > > 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 > > > > > > > ---------------------------------------------------------------------- > > > For information about J forums see http://www.jsoftware.com/forums.htm > > > > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
