News for hackers. Stuff that matters.
Re:K (2005) by jnordwick on Wednesday January 15, 2020 @09:40PM (#22061226)
Performance, KDB+, simplicity.

I've heard it said that J is for people with brains too big for K. J can be difficult with its hooks, forks, trains, and other complex function application constructs.

Job prospects too. K is heavily used in the financial sector (even YC has postings for K jobs in its monthly listings) and pays extremely well for what is basically a database developer.

Re:K (2005) by kick on Wednesday January 15, 2020 @11:50PM (#22061760)
To expand on this a little:

J was what Iverson did after APL. ('arcfide has called it a "stopgap," but I don't think that's right: it does a lot of things better than even Dyalog does.) In that way, it's a bit more pure of an experience [compared to Dyalog APL], and in a way brings the notation a lot further, as long as you can ignore the ASCIIfication of it.

k was made explicitly as a stripped-down version of (primitive-)APL. This has many trade-offs. It does make performance optimizations a lot easier (which is partially why practically every non-toy k implementation is faster than Dyalog, which is fast in its own right, even if J is usually faster). It's also mildly easier to keep in one's head in most cases.

It's a lot more mainstream in comparison to J, both because of the performance optimizations and because it's a lot less of a leap from Lisp to k than it is from Lisp to J. If I remember correctly, Arthur is a bit more of a normal person on this: he prefers/preferred writing Lisp to APL, and k is definitely a lot easier to compare to conventional languages than J or APL.

J was designed as a way to spread notation to the masses, k was designed as a way to get incredibly small amounts of code to do very big things. Both are good at both, I think, though to varying degrees.

k, though, appeals to a core aspect of the programmer by design: small. And it's small in a way that can't be called code golfing, either, which is like cocaine to your average programmer. It's primitive, very shiny, and its bite-sizedness appeals to your average cascade of attention-deficit (mostly grown-up now) teenagers that make up these sort of spaces. It's basically bait, and in a really good way.

Another reason is because J doesn't have all of the cool little snippets that k people love posting; there's no "ray-tracer in 7 lines of J" text dump despite something similar being possible, just because of the community that's formed around k. In k you have a bunch of people like Stevan Apter who just live for cool programming languages. They devour that stuff and try and make the coolest things they can to show everyone.

Re:K (2005) by tosh on Thursday January 16, 2020 @02:39PM (#22068064)
Thanks for this comment kick.

I wish I had a contextualized summary like this a few months ago when I first started to look into APL/j/k/q. Had a similar feeling when I first looked into Lisp and stumbled through the overwhelming amount of implementations and nuggets of information spread around the web & mailing list archives. Comments like yours really help (kinda like when you're lost in an RPG and after wandering around for a while & feeling lost you bump into this NPC who has the information you need to get further).

bookmarked

Re:K (2005) by kick on Friday January 17, 2020 @08:28PM (#22081511)
Always happy to talk about this stuff!

Have you read any of the essays/papers/anecdotes on jsoftware.com yet? They expand a lot on the history of APL, and it's pretty fascinating.

A fun quote that highlights how many years ahead APL and the companies built around APL were/are even decades later:

Working at IPSA, with its far-flung offices and its Mailbox, it was possible to “know” a person for years without ever meeting the person. Well into my IPSA career, I asked Lib Gibson, “Is Leslie Goldsmith a guy or a girl?”

https://www.jsoftware.com/papers/APLQA.htm

(IPSA was I.P. Sharp Associates, which long before that ran a huge amount of the APL in the world, remotely. Kind of like a primitive cloud, though then called time-sharing.)

Re:K (2005) by jnordwick on Thursday January 16, 2020 @02:37AM (#22062389)
The ray tracer in 7 lines of k:

http://nsl.com/k/ray/ray.k

The whole site http://nsl.com have some amazing code samples.

nsl stands for No Stinkin Loops - a reference to apl/k's implicit looping constructs.

(I miss using K)

Re:K (2005) by kick on Thursday January 16, 2020 @03:01AM (#22062499)
That's not Arthur's version, which is also really cool! nsl.com/k/ray/raya.k
Re:K (2005) by jim-jim-jim on Wednesday January 15, 2020 @09:57PM (#22061305)
Thanks for the info. I think J's implicit combinators have made me a better tacit programmer, but over reliance on them can make things frustratingly ambiguous.

The monadic/dyadic overloading in all these langs doesn't always help either. I recall somebody here recently writing a K implementation where there was explicit syntax for the uh... adicity(?) of operators, but I forgot to bookmark it. Anybody know what I'm talking about?

Re:K (2005) by uryga on Wednesday January 15, 2020 @10:26PM (#22061433)
k (well, some version of it) has something along those lines:

> [the] `:` in `|:` is used to force the verb `|` to be interpreted as a monad, as by default ambiguities are resolved in favour of dyads.

http://www.math.bas.bg/bantchev/place/k.html

Re:K (2005) by tosh on Thursday January 16, 2020 @02:46PM (#22068128)
https://t3x.org/klong/

> Klong is an array language, like K, but without the ambiguity. If you know K or APL, you may be disappointed by Klong. If you don't know any array languages, it might explode your brain. Use at your own risk!

?

Re:K (2005) by jnordwick on Wednesday January 15, 2020 @10:47PM (#22061522)
> adicity(?) of operators

You will often hear it referred to as the valence of the operator or function from APL people (don't forget niladic too).

Other CS people will call it the arity.