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

61–70 of 161 posts

Re: The Q Language

#61

Post by eggy »

tluyben2 wrote: post #13
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 '…

2) I like K better (fitting the ideals of APL); I feel Q was done by Arthur to please some big client as it doesn't feel like he would choose that kind of thing (that's from reading interviews, seeing the iterations and his basic code philosophy)

I like K better than Q too, but J[1] clicks with me more.

J has JDB[2] and Jd[3] for things somewhat similar to qdb with Jd being the commercial offering similar to qdb rather than JDB.

I would probably choose APL over Q if that were a choice. In J you can always make your definitions (verbs, nouns, etc...) plain words if you like the way Q reads.

  [1] jsoftware.com
  [2] http://code.jsoftware.com/wiki/JDB
  [3] http://www.jsoftware.com/jdhelp/overview.html

Re: The Q Language

#62

Post by dang »

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…

Commenting like this will get you banned on HN regardless of how much you know or how right you are. Please reread the site guidelines (linked at bottom of every HN page) and take them to heart from now on.

Re: The Q Language

#64

Post by beagle3 »

vram22 wrote: post #51
beagle3 wrote: post #31

Earlier quoted context omitted.

You can purchase a license if you want to be unaffected by future license changes. It might not be the right price for you, but it is for some. They are, in fact, courting only rich customers. Some languages are worth learning to expand your horizons. Lisp is one of them, even if you never use it, and the APL family (of which K/Q are members) is another. My C code has become faster, simpler, shorter and less buggy af…

>My C code has become faster, simpler, shorter and less buggy after I dabbled in K. Interesting. Can you explain why you think that has happened?

Several things:

1. K (and the entire APL family) eschew many of the layers upon layers of abstraction that modern software engineering uses, whether they are justified or not. It turns out, that they are mostly not justified. K gently pushes you toward thinking in a lower level of "what's really happening here?"; I'm not sure I can give a good example here - but the world looks different after taking the red pill. e.g., it is not uncommon in K to represent a tree as an two arrays, one of data, and one of parent pointers. Once you shake the "but I must abstract this!" feeling, you realize it works better.

2. K gently encourages doing work on batches of data. That is, it is idiomatic (and easier) to write functions that operate on arrays, and return arrays of processed data, then writing functions that operate on one element at a time. In turn, this means that the resulting program more often than not works in stages where each stage processes its entire input before going to the next stage (which uses the output from this stage as its input). In the "old" C/C++/C#/Java/Python world, it is idiomatic to push each element through a pipeline before going to the next one.

3. K encourages building a set of orthogonal, non trivial operations and combining them in various ways, rather then building layer upon layer of abstraction. It gives an example by giving an extremely useful basis of functions. E.g. http://nsl.com/k/t.k implements a very fast, reasonably capable in memory database with aggregation, joins, projects and more. It takes all of 14 lines, all quite short. While you can't implement it in 14 lines of C, using the same principles you can probably do that in less than a hundred. Achieve the same in idiomatic C is going to be much harder and longer.

4. Finally, K gently encourages solutions which work well with modern memory and storage hierarchies. E.g., it encourages linear scan operations that touch all elements of an array over random access ones that touch only 1/10 of the elements. Instinct and idiom in other languages will guide you towards the latter, but the former is often much faster.

Re: The Q Language

#66

Post by kazinator »

geocar wrote: post #60
modeless wrote: post #54

Earlier quoted context omitted.

I can see the argument for terseness. In fact I loathe how verbose Java is, I try to minimize LOC, and I enjoy using ?:. However, I don't think it's a good idea to use this extreme single-character, single-line style in languages not designed for it. If you really want this style, you should use APL or design your own language.

> I can see the argument for terseness The argument is that my programs are shorter and faster and more correct? > I don't think it's a good idea to use this extreme single-character, single-line style in languages not designed for it. You think if I need to write C, that I should do things that make my program larger and slower and less correct? That doesn't make any sense to me at all.

Longer identifiers don't make C programs larger. (Well, shared libraries have larger symbol tables, and unstripped executables have bigger debug info.)

Using multiple lines and indentation doesn't change executable code.

Re: The Q Language

#67

Post by fusiongyro »

eggy wrote: post #61
tluyben2 wrote: post #13

Earlier quoted context omitted.

2) I like K better (fitting the ideals of APL); I feel Q was done by Arthur to please some big client as it doesn't feel like he would choose that kind of thing (that's from reading interviews, seeing the iterations and his basic code philosophy)

I like K better than Q too, but J[1] clicks with me more. J has JDB[2] and Jd[3] for things somewhat similar to qdb with Jd being the commercial offering similar to qdb rather than JDB. I would probably choose APL over Q if that were a choice. In J you can always make your definitions (verbs, nouns, etc...) plain words if you like the way Q reads. [1] jsoftware.com [2] http://code.jsoftware.com/wiki/JDB [3] http://ww…

Have you used Dyalog APL recently? They now have a rank operator and fork/hook from J. I am learning J but haven't made up my mind about this.

Re: The Q Language

#68

Post by modeless »

tree_of_item wrote: post #56
modeless wrote: post #54

Earlier quoted context omitted.

I can see the argument for terseness. In fact I loathe how verbose Java is, I try to minimize LOC, and I enjoy using ?:. However, I don't think it's a good idea to use this extreme single-character, single-line style in languages not designed for it. If you really want this style, you should use APL or design your own language.

They are using APL. This style is used in APL/J/K/etc implementations as well as the languages themselves.

I don't think it's a good idea to import the style of a language into its implementation written in a different language; at least, not to this extent. When in Rome...

Re: The Q Language

#69

Post by modeless »

geocar wrote: post #60
modeless wrote: post #54

Earlier quoted context omitted.

I can see the argument for terseness. In fact I loathe how verbose Java is, I try to minimize LOC, and I enjoy using ?:. However, I don't think it's a good idea to use this extreme single-character, single-line style in languages not designed for it. If you really want this style, you should use APL or design your own language.

> I can see the argument for terseness The argument is that my programs are shorter and faster and more correct? > I don't think it's a good idea to use this extreme single-character, single-line style in languages not designed for it. You think if I need to write C, that I should do things that make my program larger and slower and less correct? That doesn't make any sense to me at all.

> You think if I need to write C, that I should do things that make my program larger and slower and less correct?

Yes (marginally), when those things are at odds with the tools and conventions of C, because there are serious downsides you don't list. Compiler error messages will be difficult to understand. Tools for code analysis and debugging will be less useful or even completely unusable. Most importantly, because your personal style is alien to other people you lose the ability to collaborate with other developers.

A language designed for this would mitigate most of those downsides.

Re: The Q Language

#70

Post by willtim »

beagle3 wrote: post #47
nkurz wrote: post #28

Earlier quoted context omitted.

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 fit…

In order for the Q interpreter to fit in that small size, the language has some rather severe limits. For example, function parameters, local variables and conditional branch sizes. Forcing users to structure code around these limits feels a bit archaic to me. This is what compilers are for.
Post reply on HN