Since this is chat, I'll share that I played with kdb awhile back and
asked a question because J was outperforming it:
https://groups.google.com/forum/#!msg/personal-kdbplus/mPBxtdDYjA0/lrz68b4p2YEJ
It certainly depends on the problem and the approach taken
On Thu, Nov 5, 2015 at 3:29 PM, Devon
I have little doubt that K outperforms J in CPU speed, especially where it
specializes - data manipulation.
Maybe everyone else is a better programmer than I am but I've found the
biggest bottleneck to getting any process done usually sits between the
chair and the keyboard.
On Thu, Nov 5, 2015 a
On Thu, Nov 5, 2015 at 12:00 PM, Joe Bogner wrote:
> Not to nitpick here, but I don't think we can draw any conclusions on
> the number of characters or even the number of operations (since each
> composed of a conjunction and verb)
Oh, certainly.
4x was a ceiling. I doubt even 1x is a floor (be
On Thu, Nov 5, 2015 at 10:37 AM, Raul Miller wrote:
> One thing of note, here, is that the K "each" is a single character
> (and does less work under the covers, so is faster than J's each).
> It's also K's analog to J's "rank" (though - again, it does less and
> so is faster).
>
> So that's a fac
Most code never gets used in any specific context, and so can be
discarded if someone is willing to invest the time and understanding
of what's needed, and has a context where that effort makes sense and
user base willing to support that effort.
Thanks,
--
Raul
On Thu, Nov 5, 2015 at 11:44 AM,
>From what little I know of it, K does amazing things w/very little code.
On Thu, Nov 5, 2015 at 10:37 AM, Raul Miller wrote:
> On Thu, Nov 5, 2015 at 10:19 AM, Devon McCormick
> wrote:
> > I'm not sure why "whenever we want to work with the characters within a
> > line, we'd have to unbox it"
On Thu, Nov 5, 2015 at 10:19 AM, Devon McCormick wrote:
> I'm not sure why "whenever we want to work with the characters within a
> line, we'd have to unbox it" is considered such a drawback, especially
> given the "each" conjunction.
One thing of note, here, is that the K "each" is a single char
I'm not sure why "whenever we want to work with the characters within a
line, we'd have to unbox it" is considered such a drawback, especially
given the "each" conjunction. I frequently work with character data and
find it very useful to build my code to work on a string, then apply that
code with
On Wed, Nov 4, 2015 at 4:29 PM, Joe Bogner wrote:
> I think ragged lines in this context means delimited text (not fixed width).
>
> It sounds like the author recognizes the options:
>
> "For J the choice is not quite as clear. One way of loading the data
> would be to `box' each line and then cre
On 4 November 2015 at 07:42, Raul Miller wrote:
>
> On Tue, Nov 3, 2015 at 3:15 PM, Wendell P wrote:
> > Although at first glance K looks similar to J, it really is not an APL,
in my limited exploration of programming languages k clearly inherits some
of the remarkable features of APL. it does
I think ragged lines in this context means delimited text (not fixed width).
It sounds like the author recognizes the options:
"For J the choice is not quite as clear. One way of loading the data
would be to `box' each line and then create a vector of boxes to
represent all of the data in the fil
Interesting that he says J would cost him to use, and K is free for him to use.
My experience has been exactly the opposite.
(Also, I didn't see any specific examples involving textual ragged lines.)
Thanks,
--
Raul
On Wed, Nov 4, 2015 at 2:53 PM, Wendell P wrote:
>> I don't understand the
On Wed, Nov 4, 2015 at 2:27 PM, Wendell P wrote:
> With its more complex semantics, I doubt that J's syntax could be much
> simpler than it is, though some of the periods and colons do seem
> superfluous.
The periods and colons you are probably referring to are an ascii
approximation of diacritic
On Tue, Nov 3, 2015, at 12:20 PM, Devon McCormick wrote:
> It sounds like what you're saying is that more people (at least those
> like
> you) would be more attracted to J if there were some large, specific
> applications instead of general-purpose tools - is this accurate?
The friction between co
> I don't understand the issue with uneven lines. I haven't encountered
> that before. Can you give a more concrete example of it?
David Ness wrote are few things here and there about ragged lines. In
this essay, for example.
http://www.nesssoftware.com/home/dn/JKExperiments/fog12.html
>
On Tue, Nov 3, 2015, at 12:42 PM, Raul Miller wrote:
> On Tue, Nov 3, 2015 at 3:15 PM, Wendell P wrote:
> > Although at first glance K looks similar to J, it really is not an APL,
> > since it is based on lists rather than arrays. Most of the
> > simplifications follow from this. There is no shape
On Tue, Nov 3, 2015 at 3:15 PM, Wendell P wrote:
> Although at first glance K looks similar to J, it really is not an APL,
> since it is based on lists rather than arrays. Most of the
> simplifications follow from this. There is no shape, rank, and boxing.
> Syntax is cleaner for list operations a
Thanks. I agree with the points you made regarding K's simplicity over J. I
think there is also a fair share of complex things in K that aren't in J -
such as the barely documented namespaces of q,h,z, functional select and my
perception of overloading symbols with too many operations. Every langua
It sounds like what you're saying is that more people (at least those like
you) would be more attracted to J if there were some large, specific
applications instead of general-purpose tools - is this accurate?
On Tue, Nov 3, 2015 at 3:15 PM, Wendell P wrote:
> On Mon, Nov 2, 2015, at 05:10 PM,
On Mon, Nov 2, 2015, at 05:10 PM, Joe Bogner wrote:
> On Nov 2, 2015 2:34 PM, "Wendell P" wrote:
> > eventually decided to go with K/Q because Arthur Whitney has done an
> Hi Wendell, can you elaborate on a few of the points you made?
> 1. How do you see K as a simpler language than J?
> 2. What f
On Nov 2, 2015 2:34 PM, "Wendell P" wrote:
> I
> eventually decided to go with K/Q because Arthur Whitney has done an
> incredible job of simplifying the language while keeping and even
> expanding the facilities for data manipulation. If J had a pre-existing
> library for this, I would have used
On Mon, Nov 2, 2015, at 01:43 AM, Björn Helgason wrote:
> We have a great programming language.
> It has a potential to do a lot.
> There is a learning barrier.
> Very many potential users give up.
I think J's biggest problem is not lack of demos but lack of full-scale
apps/libs for developers to
I have in the past done some.
Have been traveling a lot and only carried a small android with me.
Not very easy to experiment with jhs on it.
I know it is possible and in some cases I know how.
Would be nice if others tried it some.
I have ideas what I would like to see.
I think it important to ge
Devon,
I'm doing some informal internal training on R and I brought up Shiny
and manipulate a few weeks back. Here's the snippet I used:
require(manipulate)
manipulate(
(function() {
label <- element_blank()
if (g.Label) { label <- geom_text(aes(label=CustomerName, hjust=0,
vjust=0, ang
On Mon, Nov 2, 2015 at 4:43 AM, Björn Helgason wrote:
> What is missing are more and better demos how to use this.
> How to create forms.
> How to interact between those two.
> It is surely doable.
I think you should put some effort into showing how these sorts of
demos should be written.
Write
Hi Gosi - you are completely correct. As an example of where we might aim,
take a look at what the R people do with "Shiny" - http://shiny.rstudio.com/
- a "web application framework" that allows you to put a web interface on
your R code without dealing w/HTML (so they say).
On Mon, Nov 2, 2015 a
We have a great programming language.
It has a potential to do a lot.
There is a learning barrier.
Very many potential users give up.
Using J and HTML looks great.
What is missing are more and better demos how to use this.
How to create forms.
How to interact between those two.
It is surely doable.
27 matches
Mail list logo
