Hacker News Reader

Comment by mwexler | Hacker News Reader

Funny, that phrase can also describe k itself... It's a mindset, or cult, depending on who you chat with about it. Very powerful, and somewhat obtuse, which often go together.

Fwir, Kdb+ is written in k which is sorta APL, and then there's q for writing kdb+ programs which is easierish. But still an adventure.

View on HN

kdb+ is written in C, but q is (largely) written in k. One of the first things kdb+ does on startup is load the file `q.k`, which is a k file which defines the q language. The interpreter then switches from interpreting k to interpreting q.

Interestingly enough you can fairly easily program your own language (written in q/k) on top of that, and set the interpreter to evaluate that language by default. Kx offers a Python integration layer called EmbedPy which (among other things) exposes a Python evaluator as the "p" language in kdb+.

People always compare J, K and APL as if they were almost identical apart from the character set, but that's far from the truth.

https://aplwiki.com/wiki/Array_model#:~:text=In%20APL%20it%2....

APL and J are different between themselves (I started with APL but jumped into J) like FORTRAN and C are... What is your point?

But do they implement the same programming paradigm, or is there any fundamental differences

For example, C# and Java implement the same paradigm , they are different, many argue which provide a better set of feature, but I would not call the differences fundamental

C#, F#, implement completely different paradigms

F# and Clojure, same paradigm, but have fundamental differences, F# being static and come from the ML family , Clojure dynamic and come from the Lisp family

So APL to J, is more like what to what, C# to Java, or F# to Clojure ??

APL and J are similar but for a pretty fundamental difference: APL has nested array theory while J is flat array theory. In practice, this does not make them that different to the user, except APL's model is arguably more elegant since it's "turtles all the way down" (J array elements are not array themselves).

K on the other hand, is really different! K doesn't have true multidimensional arrays, but lists of vectors. So it's ideal for its use case: finance (1d/2d numeric tables).

I see now your point. And as you say it does not make a lot of difference to the user. I have never used K.

It's more like C# to Java. Setting aside the different character sets used, a lot of code written in one can be translated almost directly to the other. Whereas F# and Clojure, while using many similar idioms, have fundamentally different approaches to types which significantly alters your program structure and design approach.

Both J and APL work on the same type of things (principally, arrays and nested arrays) with functions being applied over the arrays or across multiple arrays. And both languages encourage a point-free or tacit style of programming (though J, from my limited experience with both, seems to push this a bit further sometimes). For a functional paradigm example it's probably more like the difference between SML and Ocaml, or between two similar lisps like Common Lisp and Emacs Lisp. There are clear differences in focus in the two language designs, but much more in common (again, setting aside the choice of characters, you can find an equivalent for most APL symbols in J and vice versa without needing to create too many new definitions).

That is what I was meaning, to me C and FORTRAN are mostly "the same" except at a surface level, and FORTRAN has multidimensional arrays and regions (a slight abstraction that can help the compiler, in particular, for automatic parallelization of loops)

Reply on news.ycombinator.com