Not sure how this is consistent with "One private company gatekeeping access to revolutionary technology"?

q is good with bulk operations on compact arrays; these are cache-friendly and the interpreter can utilize cache-level parallelism. and with q it's convenient to go from idea -> MVP in short time. it's a high-level language with functional features so expressing algos and complex logic is natural.

but it's interpreted and optimized for array ops. so really latency-critical (e.g. high-freq trading) or highly scalar logic will be done with C++. the trade-off is convenience of development.

regarding use cases, see https://kx.com/resources/use-cases/

https://code.kx.com/q/basics/debug/#stack-frames

there are many humans who could study mathematics for a lifetime and not be able to comprehend the current best knowledge we possess. i'm one of them. maybe it takes 2 lifetimes. or many more.

a human-level AI operating at machine pace would learn much more than could ever be taught to a human. our powerful generative language capabilities wouldn't matter - it's far beyond our bandwidth. especially so for a superhuman-level AI.

Are dogs, or pigs, or whales, part of the intelligence club? They are clearly intelligent beings with problem-solving skills. We won't be teaching them basic calculus any time soon.

niklaus wirth thought similarly... in 1995![0]

i enjoy implementing array langs (k primarily) so small binaries come with the territory. really appreciated your write-up. i may try something similar for an array lang.

you might also appreciate (or detest) 'b'[1][2] - a small implementation of a "fast c compiler (called b: isomorphic to c)". it has some similarities to SectorC.

[0] https://www.computer.org/csdl/magazine/co/1995/02/r2064/13rR... [1] https://web.archive.org/web/20230117082148/https://kparc.com... [2] https://github.com/kparc/bcc (more legible)

do you think there are any lessons that can be applied to a "normal" interpreter/compiler written in standard C? i'm always interested in learning how to reduce the size of my interpreter binaries

long lists of side effects are common even for the most benign and common drugs. that's standard.

for example i could say that the common side effects of tylenol[0] tell a different story:

nausea, vomiting, anemia, rash, dyspnea, abnormal breath sounds, pulmonary edema, hypoxia, pleural effusion, stridor, wheezing, coughing, peripheral edema, hypertension, hypotension, tachycardia, chest pain, muscle spasms, insomnia

[0] https://www.drugs.com/sfx/tylenol-side-effects.html

it's entirely relevant. we should know if we are building conscious beings, especially at scale (which seems like a likely future). that poses all sorts of ethical questions which ought to reach far beyond the confines of a lecture hall's walls.

it has a well-written manual and is a great jumping off point. the source is written in ~1000 lines of js. so you can look at how each primitive is implemented.

there is a k-enthusiast element.io server[1] where you can ask any question you like. folks are friendly!

EDIT: another commenter shared most of this info. oops :-) i'll add as well ngn-k browser repl[2] which has some docs and a fuller feature-set than oK. this is probably the most-used open source k right now. the author is active in the above element server, and still patches bugs and makes updates.

[0] https://github.com/JohnEarnest/ok

[1] https://matrix.to/#/#aplfarm-k:matrix.org

[2] https://ngn.codeberg.page/k/#

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

- 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.

it's worth mentioning that he has said that he believes MIRI has failed to meaningfully make progress with alignment (beyond finding some dead ends).

eliezer has long been concerned about AI and the risks it poses to humanity. and for just as long people have called him crazy and made hand-waving arguments for why we shouldn't be concerned.

now we're in the midst of an AI arms race and we don't have any good idea how this tech works. it progresses at a truly astonishing rate, where it's become sport to find instances of people saying "AI will never be capable of X" and showing them the latest AI doing X with ease.

i think his concern is real and justified. you might disagree, but i don't understand why think he's milking recent developments.