Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

K: We need to talk about group

gist.github.com

Post reply on HN
Print view View original

51–60 of 102 posts

Re: K: We need to talk about group

#51

Post by Avshalom »

anyfoo wrote: post #48
Avshalom wrote: post #46

Earlier quoted context omitted.

J i guess. https://www.jsoftware.com/#/ I don't really like J but the only serious APL left is the proprietary (though free, and fun) Dyalog; K, the official product, is also proprietary and because Arthur rewrites it every couple of years all the open source clones are of different versions so there isn't much of an ecosystem.

Hmm, so why J over Dyalog APL then?

it's libre and gratis, if that's not something that bothers you (and to be sure if you're just writing code for your own edification it's not a practical problem) then i would recommend dyalog, although as a side effect of being open J has a (perhaps only slightly) larger free ecosystem and community.

the down side is that subjectively some people (myself included) find J uglier, less effective as a tool of thought and due to some syntactic features (hooks and forks, but no proper lightweight anonymous function syntax)-prone to people posting impenetrably dense code as "examples"

Re: K: We need to talk about group

#52

Post by anyfoo »

Avshalom wrote: post #51
anyfoo wrote: post #48

Earlier quoted context omitted.

Hmm, so why J over Dyalog APL then?

it's libre and gratis, if that's not something that bothers you (and to be sure if you're just writing code for your own edification it's not a practical problem) then i would recommend dyalog, although as a side effect of being open J has a (perhaps only slightly) larger free ecosystem and community. the down side is that subjectively some people (myself included) find J uglier, less effective as a tool of thought a…

I see, thanks! Looks like I might try both. The "no proper lightweight anonymous function syntax" sounds weird to me, I would have thought that's paramount for an array language? Do I misunderstand?

Re: K: We need to talk about group

#53

Post by Avshalom »

semi-extrinsic wrote: post #18
pavlov wrote: post #12

It’s awe-inspiring to see a K program where the comments are in another APL variant (I can’t pretend to know which): {d:~1=':s:^x / s‿e←1⊸»⊸(>⋈ This program implements a Pigdog Latin translator, bien sûr .

Isn't the original APL the only lang that uses actual Unicode symbols for operators?

this is a bit obscure but Trealla Prolog allows for full unicode in the source and user defined operators, which is nice.

Re: K: We need to talk about group

#54

Post by scrawl »

krick wrote: post #29
pavlov wrote: post #12

It’s awe-inspiring to see a K program where the comments are in another APL variant (I can’t pretend to know which): {d:~1=':s:^x / s‿e←1⊸»⊸(>⋈ This program implements a Pigdog Latin translator, bien sûr .

Amazingly, APL is more readable. Actually, it's even pretty intuitive. Which proves again, that restricting code to ASCII when every competent programmer (and PC-user in general) can enter almost any unicode symbols just fine is simply stupid.

i don't think it's stupid. i also find k more readable. 2 reasons why:

- k has much fewer primitives. it's easier to remember a smaller set of operations.

- k is statically parsable. APL is not. we know the program structure simply by reading the code.

this is completely subjective. because you find APL more intuitive doesn't prove anything. to each their own.

Re: K: We need to talk about group

#55

Post by chrispsn »

msla wrote: post #36

Imagine what APL could do with a Haskell-style type system and enforced referential transparency. APL programmers want to say their language is mathematical notation, well, make it mathematical notation.

In the Wordle dict example, it would have helped if a type system could tell me I was wrong when I assumed that an indexing miss would generate an empty list.

Re: K: We need to talk about group

#56

Post by jim-jim-jim »

anyfoo wrote: post #43

From the way I often use Haskell, Matlab, and even crazy shell one-lines with lots of pipes, awk, sort, and other stuff, I often have the impression that array languages are exactly what I'm looking for for certain problems. The question is... which array language should I pick? What are the reasons to pick one over the other?

I had a similar feeling, but ultimately found Haskell more maintainable. If you write it point-free with well chosen symbolic operators, it winds up being the best of both worlds.

Not that I have any firsthand experience with the matter, but I think Morgan Stanley has been switching over from K to some Haskell-like dialect as well.

Re: K: We need to talk about group

#57

Post by scrawl »

anyfoo wrote: post #43

From the way I often use Haskell, Matlab, and even crazy shell one-lines with lots of pipes, awk, sort, and other stuff, I often have the impression that array languages are exactly what I'm looking for for certain problems. The question is... which array language should I pick? What are the reasons to pick one over the other?

i love k. it's a much smaller and regular language than APL and some of its derivatives. you can look at John Earnest's oK. it's fantastically documented and a great learning resource.

i would also recommend BQN. it has an active community and it's designer Marshall Lochbaum explicitly tried to address some of the warts in APL and j. he's done a great job.

learning any of the array languages will be a tremendous learning experience if you haven't approached the paradigm before

Re: K: We need to talk about group

#58

Post by sli »

messe wrote: post #45
ksherlock wrote: post #22

Earlier quoted context omitted.

There are esoteric code golf languages that use unicode. MPW (shell, assembler) used extended characters (MacRoman, not unicode but then again, APL also predates unicode) for some operations. eg, instead of "echo yo >> file" you would "echo yo ≥ file"

Julia has support for Unicode operators. Most editor plugins for Julia allow you to enter the characters using (La)Tex syntax, so it’s quite common to see.

Unicode support doesn't really seem that uncommon, in the grand scheme. Rosetta Code's wiki has a page for languages that support Unicode variable names[0] and some of them were surprising to me (e.g. AppleScript).

Of course, supporting Unicode variable names doesn't mean a language supports Unicode anywhere, but it's a starting point for historical research at least.

[0]: https://rosettacode.org/wiki/Unicode_variable_names

Re: K: We need to talk about group

#59

Post by b112 »

jlg23 wrote: post #35
semi-extrinsic wrote: post #18

Earlier quoted context omitted.

Isn't the original APL the only lang that uses actual Unicode symbols for operators?

APL predates the first documented thoughts (not specification/implementation) of unicode by roughly 20 years.

APL predates the first documented thoughts

I used to think that Lisp was bad, with its "God coded the universe in Lisp", then I read only the first part of your sentence, and was "Woha, so APL predates thought?!"

https://www.youtube.com/watch?v=5-OjTPj7K54

Re: K: We need to talk about group

#60

Post by twoodfin »

mandevil wrote: post #30
qsort wrote: post #16

Earlier quoted context omitted.

I... just can't. I work a lot with data, so it sounds like it should be a good fit for what I do, but I find that writing the damn code in a normal language is much more productive. Maybe it's my brain that's wired wrong, but I fail to see how the entire construction is supposed to help.

A friend worked on a project in 2005 that had lots of K code in production. They had a contract with Kx Systems and Arthur Whitney in particular because, in my friend's opinion, only Whitney could really understand K code well enough to debug it. Friend's description was it took my friend two days just to comment the code into something grokkable by a normal developer, whereas AW didn't need to do that. Of course, it…

In my experience this practice isn’t obfuscation or for performance. The whole point of array processing languages is to amortize any fixed operation cost over the span of the array.

The notation-as-a-tool-of-thought camp prefers short identifiers on the principle that the more concise the expression, the easier it is to comprehend in total. This is not at all dissimilar from the general practices of mathematics.

Post reply on HN