@ngn you have no simd in your wasm. did you try to preserve it?

can you really not use k operators in q? you have to use the words? :(

^ nvm you can, just have to wrap it in brackets for some stupid reason

@rak1507 or enter k-mode "\"

oh wow, that's brilliant, thanks

(or. k) )

before I was just doing k)

I wish you could use k stuff in q though :( idk why you can't, seems like a strange and unfortunate choice

not sure what you are trying to do, but you could write q in a k script

wont be great, but.. you could

I'm just playing with q and bc I don't know all the words yet I keep getting frustrated I can't just use the familiar symbols :P

deltas?! wtf is that, -': much more readable

well.. im taking the other side of that argument

but i can see your point if you have done a massive amount of k

personally, i believe english is more accessible to most people and therefore, somewhat easier / less of a cognitive load

not really done a massive amount, just enough that I'm more familiar with the k symbols than the q words

obviously.. after enough time, i suppose you also internalize +\ and +/

though, sums / sum is, imo, still better...

yeah, fair enough, I agree, but I think you lose out on some of the beauty of array languages where you have to be explicit

@juanez now there I disagree, because although there is a pattern, having the explicit binary operation and the reduction/scan is very nice

and it generalises, +/ */ etc

true, but you have prd (product) etc... as well.. which, imo - if you are fluent in english- conveys the meaning quite well

if you know what +\ does, it's immediately obvious how to do *\, but to work out prd/prds, you have to look it up in documentation! a whole 10 seconds of your precious life wasted!

my biggest issue with k/q is the overloads though...

would have been nice(r) without them

yeah, can be a little excessive at times

and this day and age, i dont think you need an extended keyboard...

a nice IDE with a sort of 'intellisense' could def encode.. say... "sum" into some greek character.. Sigma?

maybe, but then again by having sigma/pi for sum/product for example, you lose the niceness of having the explicit reduction

oh well. i think that train has sailed

i dont know if i think the implemenation detail is important

I prefer +/ and */ to ∑ and Π

in q btw, sum/sums is replaced by a more efficient c-implementation

Sigma/pi would probably appeal to mathematicians (?)

@juanez I really like the way array langs make reductions explicit

@juanez maybe

idk.. it's a little bit like printing out a for-loop to me

not sure i really care about the impl... unless ofc it has a bug ;)

I can see where you're coming from, but having a handful of symbols that can be used to construct what would be a lot more words to me is a lot nicer because then you can see the reuse of ideas

oh, im not against / fold \ scan as such at all

though, i dont think it's helpful that \ / are , depending on the arguments doing things quite differently...

just (imo) makes things very difficult to parse

fair enough

I understand why Q is the way it is, but I don't like it nearly as much as K

in principle it's sort of a batteries-included K but in practice I'm not extremely impressed with the included batteries, so to speak, or the surrounding ecosystem. Still very brutalist.

it's a shame that it seems that it's the most commercially viable array lang while being imo one of the least interesting

it has basically everything interesting about K, it's just sort of muddled and hidden

I mean, you still get great stuff like K's projection semantics

yeah, it's just frustrating that some of the k features aren't available or are harder/uglier to use

I hear you

having done some work with Q of late I finally had a reason to read q for mortals and I was kind of amazed at how needlessly confusing it makes the language. I mean, the preface spends time defining peano arithmetic for apparently no reason just as a flex or something: code.kx.com/q4m3/0_Overview

if anyone finds themselves using Q, nick psaris' book is massively better than the official docs

thanks I'll keep that in mind

I'd much rather do >#'=x than desc count each group x but maybe the words are easier for you if you're new to it...

I'm not convinced the words are inherently better but the advantage they do have is that there's a nearly unlimited supply of short words to use; this makes it easy to continue to grow the language. the downside to this, of course, is that there is no counterbalancing force to keep the language from growing hair...

there aren't more short words than short permutations of the symbols, most of which (unless the word is something complicated, like md5) can do the same thing

I feel like by making everything into words you lose some of the nicest aspects about array languages where you can see how small elements build up into more complicated things

agreed

there's a self-evident elegance to the selection of verbs and adverbs in k (for the most part, as seen in the handful of primitives that foam around and change in each dialect) radiating from how many useful combinations tile space

yep, and also using words and then having $[] syntax for conditions is a strange choice

I feel like there's some triangle between ASCII only | builtin coverage | elegance/simplicity/consistency

oK has never had if/do/while. k5 didn't have them, and I thought it was more elegant that way even when k6 reintroduced them

@JohnE while I've never found them a great option there are some ugly imperative things that benefit from them (versus doing some contortions with the monadic overloads of / or \, which were probably one of the least intuitive things at the beginning for me)

yeah, trying to deal with error handling and retry logic can get very difficult if you're braiding everything together in the adverbs-only style