yeah the site's clearly vibecoded and isn't opensource, but i also think this is a genuinely interesting design space and more people should be building in it. APL (https://www.dyalog.com/), BQN (https://mlochbaum.github.io/BQN/), J/Jd (https://code.jsoftware.com/wiki/Jd/Overview), Klong (https://news.ycombinator.com/item?id=10586872), Kerf (https://news.ycombinator.com/item?id=9782520), RayforceDB (https://news.ycombinator.com/item?id=45889607), k/q (https://kx.com/) glad there's a new entrant.

▲

jackdoe 5 hours ago | parent | next [-]

I vibecoded https://punkx.org/apl/learn.html [1] its good slow entry into gnu-apl, at least it got me to be able to make tictactoe, vibecoded or not, it helped me to start.

I am amazed how quickly APL changed the way I think.

Also strongly recommend watching Aaron Hsu on youtube.

There is no better time to re-learn programming, try APL, Forth, LISP, z80 machine code, UXN TAL, just try new things.

"Men are born soft and supple; dead they are stiff and hard. Plants are born tender and pliant; dead, they are brittle and dry. Thus whoever is stiff and inflexible is a disciple of death. Whoever is soft and yielding is a disciple of life. The hard and stiff will be broken. The soft and supple will prevail."

[1]: https://github.com/jackdoe/gnu-apl-wasm source of the repl and learn playground and also how to compile gnu apl to wasm (vibecoded)

▲

zX41ZdbW 5 hours ago | parent | prev | next [-]

I've recently tested BQN on ClickBench (a benchmark for OLAP databases), and the results are not great: https://benchmark.clickhouse.com/#system=+N|liH&type=-&machi...

If anyone is curious how queries in this language look, you can see it here: https://github.com/ClickHouse/ClickBench/pull/939/changes#di...

▲

dzaima 4 hours ago | parent | next [-]

FYI, your "8‿64 •bit._cast -⟜@ raw" in bqn/util.bqn results in passing to •bit._cast integers in the range 0..255, whereas it expects integers ¯128..127 (and does arbitrary platform-specific things on integers outside that for the int16→int8 narrow); removing the "-⟜@" makes it work properly, and 2.5-5x faster while at it from not going to intermediate int16 (allowing the bitcast to be O(1) by itself). (•FBytes → •file.MapBytes also probably improves things, at the cost of the obvious mmap problem of issues if the file changes, as BQNs arrays are immutable). This is also what caused the problem at https://github.com/ClickHouse/ClickBench/pull/939/changes/40... (there's been some discussion about what to do about invalid •bit._cast before, considering it's rather perf-sensitive; it's the only place in CBQN with such quiet very-wrong results on invalid inputs)

The default CBQN "make o3" on x86-64 also results in it only using SSE2 (utilizing function multiversioning is on the ever-infinite TODO list, though somewhat-low on it considering it's strictly-unnecessary in any specific situation; there's also AVX-512 usage on a branch, but mostly only AVX2 on mainline; and no arm SVE)

That all said, CBQN doesn't currently do any loop fusion, so being significantly-slower for sequences of operations over larger-than-cache arrays would kinda just be expected. BQN also just isn't particularly intended for database work anyway.

(didn't look much at the specific query impls, though "Pair" in utils.bqn is at least an overlong version of "Pair ← ⋈¨"; and some if not all of those Pairs would be better as "≍˘" to avoid nested arrays and ensuing pointer chasing; and, of course, if some of the columns are bools/int8/int16/int32, it'd be beneficial to store & load them as such instead of float64)

	▲	jloveless 4 hours ago \| parent [-]
		BQN & CBQN are absolutely wonderful pieces of code. L is mac/lin but linux is avx512 only specifically to try to deal with that problem. The compute on compressed algos helps fit more in those cache lines! https://lv1.sh/blog/compute-on-compressed/

▲

jloveless 5 hours ago | parent | prev [-]

https://github.com/l-labs/db-benchmark/tree/main/l

▲

kensai an hour ago | parent | prev | next [-]

What's the problem if a site is vibecoded? We will be seeing it more often, I recon. Let's get used to it. On the other hand, perhaps a disclaimer is in order.

	▲	itishappy 36 minutes ago \| parent \| next [-]
		It's a strong signal of unknown quality. Caveat emptor. Closed-source makes that extra difficult. We are used to this, hence why folks here point it out.
	▲	jloveless an hour ago \| parent \| prev [-]
		there's one in the footer and agree.

▲

Onavo 3 hours ago | parent | prev | next [-]

I hope OP can survive the lawsuits though, the K authors are infamously litigious.

▲

quotemstr 3 hours ago | parent | prev [-]

... DuckDB.

Columnar databases are array languages, after all.

	▲	jloveless 25 minutes ago \| parent [-]
		duckdb is great and its h2o.ai benchmark was difficult to beat!