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

The Q Language

code.kx.com

Post reply on HN
Print view View original

41–50 of 161 posts

Re: The Q Language

#41

Post by oskarth »

ktamura wrote: post #22
jonathanapp wrote: post #5

Notes from my KX/kdb experience: 1.) The in-memory DB .exe was around 500 KB. Imagine that. 2.) The Q language syntax, while consistent, is fairly arcane and throwback to decades past. 3.) The documentation and driver support is abysmal. 4.) It's supposedly extremely fast, but I can't help but wonder if this is a lot of successful PR and hype (like hedge fund bosses insisting on Oracle because it's the only db that '…

I used to use KX/kdb/Q/K daily for several years. I wrote a full implementation of reinforcement learning (15 lines), a lightweight MVC framework (to show reports and tables in an internal webapp) and even a Q syntax checker (abusing table as a data structure to hold parse trees). Good or bad, for the longest time, Q was my "go-to" programming language. Based on that experience... 1) Yes, but that's not huge by moder…

Would be really interesting to read a write up on your experience. What do you program in now? How do you look at other PLs now? What do you miss and what are you happy "just works"? What do you think other PLs (especially languages like Lisp, which are very high in terseness) can learn from Q?

Re: The Q Language

#42

Post by beagle3 »

oskarth wrote: post #36
beagle3 wrote: post #33

Earlier quoted context omitted.

Libmill/Libdill (go coroutines) are not on the AMPQ->ZeroMQ->Crossroads->Nanomsg (socket abstraction) path ; in fact, they have essentially nothing in common except sustrik.

I wish you'd actually read the article before shooting your mouth off with a Well Actually. FTA: > Next one: nanomsg. An alternative to ZeroMQ. In comments: > How would you split nanomsg, then? > [...] 2. coroutine library, e.g. libtask, libmill [...] Not to mention that this is obvious if you understand what the core of each thing is in terms of capabilities. If you are gonna be the "technically..." guy, at least do…

As an actual user of ZeroMQ, nanomsg and dabbler of libdill, I assure you I know what I am talking about. Libdill/libmill is NOT on the same arch. It could be used to implement the next generation of zeromq/nanomsg, but it does not, in fact, provide any functionality that these provide today - it would be an internal implementation detail if sustrik followed through on that comment. But it would not be a nanomsg rewrite, likely something completely new - nanomsg has been rewritten, several times in several ways, by Garret D'amore who has taken over. D'amore explicitly rejected using e.g. libuv (mentioned in that comment) as a basis for a nanomsg rewrite. There's an "uncertainty" principle at work here - separating of concerns generates dependencies which in the grand scheme of things are not necessarily good.

In fact, one of D'amore's rewrites used native OS threads in lieu of a co-routine library, which worked perfectly well on FreeBSD and Solaris, and abysmally on all other OSses. The main reason to use a coroutine library in a messaging library is actually that the underlying OS threads implementations scale so badly on most modern systems.

Re: The Q Language

#44

Post by alexeiz »

modeless wrote: post #34

The KDB code is terse to an unhealthy extreme. Check this gem: // remove more clutter #define O printf #define R return #define Z static #define P(x,y) {if(x)R(y);} #define U(x) P(!(x),0) #define SW switch #define CS(n,x) case n:x;break; https://github.com/KxSystems/kdb/blob/master/c/c/k.h#L96 Or this wall of code: https://github.com/KxSystems/kdb/blob/master/c/c.cs

It's so terse, it's gotta be fast!

Re: The Q Language

#45

Post by kolme »

modeless wrote: post #34

The KDB code is terse to an unhealthy extreme. Check this gem: // remove more clutter #define O printf #define R return #define Z static #define P(x,y) {if(x)R(y);} #define U(x) P(!(x),0) #define SW switch #define CS(n,x) case n:x;break; https://github.com/KxSystems/kdb/blob/master/c/c/k.h#L96 Or this wall of code: https://github.com/KxSystems/kdb/blob/master/c/c.cs

Welp, you were not kidding: https://github.com/KxSystems/kdb/blob/master/c/c/curl.c

This code is basically obfuscated by hand. Absolutely unapproachable. Only the original author(s) can understand it.

Judging by other comments, it seems to work well. So they seem to be good programmers producing working code. It's just not intelligible by other human beings, which is a pretty bad thing, but not the only factor in software quality/health.

The Vim code base is at some parts straight batshit insane, but it's one of the most polished programs I've ever used.

All that being said, I would find infuriating to work with such code. Nope!

Re: The Q Language

#46

Post by geocar »

modeless wrote: post #34

The KDB code is terse to an unhealthy extreme. Check this gem: // remove more clutter #define O printf #define R return #define Z static #define P(x,y) {if(x)R(y);} #define U(x) P(!(x),0) #define SW switch #define CS(n,x) case n:x;break; https://github.com/KxSystems/kdb/blob/master/c/c/k.h#L96 Or this wall of code: https://github.com/KxSystems/kdb/blob/master/c/c.cs

I'm a vocal convert.

This approach helps me find bugs and repetition in my programs which makes my code shorter and faster as a result.

Re: The Q Language

#47

Post by beagle3 »

nkurz wrote: post #28
ktamura wrote: post #22

Earlier quoted context omitted.

I used to use KX/kdb/Q/K daily for several years. I wrote a full implementation of reinforcement learning (15 lines), a lightweight MVC framework (to show reports and tables in an internal webapp) and even a Q syntax checker (abusing table as a data structure to hold parse trees). Good or bad, for the longest time, Q was my "go-to" programming language. Based on that experience... 1) Yes, but that's not huge by moder…

1) Yes, but that's not huge by modern standard. OP could have phrased it better, but I presume his point was that 500KB is extremely small by modern standards. The whole executable fits comfortably in L3, so you'll probably never have a full cache miss for instructions. On the other hand, while it's cool that it's small, I'm not sure that binary size is a good proxy for performance. Instruction cache misses are rarel…

> Instruction cache misses are rarely going to be a limiting factor.

k's performance is a combination of a lot of small things, each one independently doesn't seem to be that meaningful. And yet, the combination screams.

The main interpreter core, for example, used to be When Python switched the interpreter loop from a switch to a threaded one, for example, they got ~20% speedup[0]; I wouldn't be surprised if the fitting entirely within the I-cache (which K did and Python didn't at the time) gives another 20% speedup.

[0] https://bugs.python.org/issue4753

Re: The Q Language

#48

Post by beagle3 »

kolme wrote: post #45
modeless wrote: post #34

The KDB code is terse to an unhealthy extreme. Check this gem: // remove more clutter #define O printf #define R return #define Z static #define P(x,y) {if(x)R(y);} #define U(x) P(!(x),0) #define SW switch #define CS(n,x) case n:x;break; https://github.com/KxSystems/kdb/blob/master/c/c/k.h#L96 Or this wall of code: https://github.com/KxSystems/kdb/blob/master/c/c.cs

Welp, you were not kidding: https://github.com/KxSystems/kdb/blob/master/c/c/curl.c This code is basically obfuscated by hand. Absolutely unapproachable. Only the original author(s) can understand it. Judging by other comments, it seems to work well. So they seem to be good programmers producing working code. It's just not intelligible by other human beings, which is a pretty bad thing, but not the only factor in sof…

It takes time getting used to, yes.

And it is not for all people.

But it's just a foreign language; You could look at Japanese text[0] and make similar statements, and would be just as valid (or rather, invalid) as your statement.

You expect to be able to read it because you're used to a class of languages which are all similar enough at the surface level -- perhaps you are even familiar with more than one fundamentally different classes, say, "lispish and algolish" or "germanic and latin". But that doesn't make APLish or Japanese[0] horrible.

This is just APL using C syntax.

[0] assuming, the proverbial you does not know Japanese

Re: The Q Language

#49

Post by IshKebab »

geocar wrote: post #46
modeless wrote: post #34

The KDB code is terse to an unhealthy extreme. Check this gem: // remove more clutter #define O printf #define R return #define Z static #define P(x,y) {if(x)R(y);} #define U(x) P(!(x),0) #define SW switch #define CS(n,x) case n:x;break; https://github.com/KxSystems/kdb/blob/master/c/c/k.h#L96 Or this wall of code: https://github.com/KxSystems/kdb/blob/master/c/c.cs

I'm a vocal convert. This approach helps me find bugs and repetition in my programs which makes my code shorter and faster as a result.

You're joking right?

Re: The Q Language

#50

Post by IshKebab »

beagle3 wrote: post #48
kolme wrote: post #45

Earlier quoted context omitted.

Welp, you were not kidding: https://github.com/KxSystems/kdb/blob/master/c/c/curl.c This code is basically obfuscated by hand. Absolutely unapproachable. Only the original author(s) can understand it. Judging by other comments, it seems to work well. So they seem to be good programmers producing working code. It's just not intelligible by other human beings, which is a pretty bad thing, but not the only factor in sof…

It takes time getting used to, yes. And it is not for all people. But it's just a foreign language; You could look at Japanese text[0] and make similar statements, and would be just as valid (or rather, invalid) as your statement. You expect to be able to read it because you're used to a class of languages which are all similar enough at the surface level -- perhaps you are even familiar with more than one fundamenta…

APL isn't really readable by other humans either.

This is idiotic.

Post reply on HN