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

101–110 of 161 posts

Re: The Q Language

#101

Post by feelin_googley »

oskarth wrote: post #27
feelin_googley wrote: post #24

This is only software I have ever seen that actually got smaller over time. Not only that, it is the only software I have ever seen that used a GUI and then ditched it in a subsequent version. Few programs are so aligned with my own software sensibilities. Only complaint is that they used to have a FreeBSD port and now only have Linux and macOS but no BSD. Unfortunately Linux compat in BSD is being perceived by some…

> This is only software I have ever seen that actually got smaller over time. I agree, this is admirable! Even if it is under different names (which I think is a far better approach), Sustrik does this too: http://250bpm.com/blog:50 He went from AMPQ (not his own creation) -> ZeroMQ -> nanomsg -> Libmill (essentially Go in C/UNIX style) Also, OpenBSD comes to mind (LibreSSL for example).

Enjoyed the blog post from Sustrik. I also found Hintjens' work in line with my own sensibilities, e.g., his libero code generator. That is perhaps a good example of "finished" software.

Whenever I have suggested on HN that there is such a thing as "finished" software that is free of serious bugs, I get some resistance. There is a consistent knee-jerk reaction citing the same tired, old meme, "All software has bugs", and "Software is never finished."

Sustrik's post proves I am not the only one perplexed by this strange belief that no software is ever finished.

IMO, it is not a question of being infallibile or being available to fix bugs. The point is that there are programs that are not continuously growing in size and complexity. They are not "dead". They are "finished".

As for OpenBSD, certainly some programs I would consider "finished" but overall the size of the kernel and base distribution are in fact growing. Not only new drivers, but new programs and new libraries continue to be added. More code means more probability for bugs and vulnerabilties.

Anyway, less code, more terse syntax means it can be easier to find problems. Not everyone will agree with this of course. But I agree with Whitney and others. Less code makes it easier for me.

Re: The Q Language

#102

Post by RodgerTheGreat »

LfLxfxxLxfxx wrote: post #81
beachy wrote: post #65

Earlier quoted context omitted.

By comparison in APL: life←{↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵}

life←{≢⍸⍵}⌺3 3∊¨3+0,¨⊢ https://youtu.be/3FjYly2G_QI?t=565

I think I've nearly convinced Arthur to include an equivalent to "stencil" in k7. Fingers crossed!

Re: The Q Language

#103

Post by hoosieree »

beagle3 wrote: post #64
vram22 wrote: post #51

Earlier quoted context omitted.

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

This is my experience as well, especially with respect to the "layer upon layer of abstraction". Abstraction isn't bad, but it's notoriously hard to do well.

Re: The Q Language

#104

Post by feelin_googley »

throwaway7645 wrote: post #100
feelin_googley wrote: post #97

Earlier quoted context omitted.

The former. With earlier versions, e.g. k2.8, there is a `show command to trigger a pop-up window that reminds me of Tcl/Tk, containing the values in editable fields. The interpreter is terminal friendly and works without the GUI but it has no formatted output of tables in ASCII like in k4. x11 libraries are a dependency.

Interesting. Did anybody miss the GUI? Sounds strange that it was removed.

I believe the GUI idea is still alive, but today it can be web-based. See 1010data.com.

Re: The Q Language

#105

Post by RodgerTheGreat »

feelin_googley wrote: post #104
throwaway7645 wrote: post #100

Earlier quoted context omitted.

Interesting. Did anybody miss the GUI? Sounds strange that it was removed.

I believe the GUI idea is still alive, but today it can be web-based. See 1010data.com.

1010data's web UI isn't actually based on the K2-era GUI framework; it is architected as a reasonably conventional web application that happens to use K3 as a server-side language. The 1010data query language offers facilities for making data-driven UIs for interactive reports and the like, but any semantic similarity to the K2 GUI system is probably coincidental.

Re: The Q Language

#106

Post by kazinator »

modeless wrote: post #94
kazinator wrote: post #87

Earlier quoted context omitted.

They have a whole language there, didn't you notice? Namely, this Q thing that the submission is about. What we're looking at here is some of its C implementation internals. They are using short identifiers and the C preprocessor to help with terseness. The justification is that this is "like APL". But there is enough C cruft there that it's not really like APL. A possibility would be to generate whatever code those…

The point is that using Q style in C is not a good way to make a C program, regardless of whether said C program is the implementation of Q or not.

The point (mine, that is) is that I basically agree that it's not a good way to code in C, but perhaps the style could work better as a notation that transliterates to C.

Re: The Q Language

#107

Post by avmich »

oskarth wrote: post #41
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…

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?

I would compare Q (and other APL-related languages) to Vim editor. There you have some carefully chosen operations which are easy to perform. They don't take much efforts. They are also easy to compose in useful ways - because the corresponding properties support that. Since the basis of editing operations is fairly large, you have many operations; but when you know many of them, you can work powerful edits.

Lisp on the other hand is more like Emacs - naturally. Here we have a small, carefully chosen orthogonal basis of abstract operations - not domain-specific, but "theoretically-foundational" small basis. Then you have a library of macros on top of that, and ability, of course, to extend.

In other words, basis for APL is "classical" math, made executable and expanded with mechanisms required to put in one line programming constructs (logic, control flow, ordering...). It's harder to expand, but you don't often need that. Lisp is a specific branch of math, lambda calculus, which is provably enough to solve arbitrary programming problem. The "inner core" of Lisp is also hard to expand, but what you expand for your task is "the usage" of the language, which is made to be straightforwardly expandable.

To me it's hard to say what is better.

Re: The Q Language

#108

Post by throwaway21234 »

beagle3 wrote: post #30
pyvpx wrote: post #17

what makes kdb so special and why isn't there an open/libre alternative?

But there are: k variants: kona (C, interpreter): https://github.com/kevinlawler/kona klong (C, interpreter): http://t3x.org/klong/ kuc (C++, JITted): http://althenia.net/kuc oK (JS, interpreter): https://github.com/JohnEarnest/ok (see also iKe by John Earnest) cousins: J (C, interpreter) http://jsoftware.com/ A+ (C, interpreter, unmaintained): http://www.aplusdev.org/index.html Gnu APL (C, interpreter): https://www.…

Another cousin:

Nial (C, GPL interpreter): https://github.com/danlm/QNial7

The author of Nial, Mike Jenkins, has recently released v7 of Nial. Nial is akin to Q in that many of the operators are keywords rather than symbols. Its computational model is slightly different due to its roots in Trenchard More's array theory.

Re: The Q Language

#110

Post by fusiongyro »

throwaway7645 wrote: post #76
fusiongyro wrote: post #67

Earlier quoted context omitted.

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.

Dyalog appears to be more popular with conferences and more products, but it costs $1k ish for a commercial license and nobody else can run your code without a license and server licenses aren't cheap. It also pretty much needs a special keyboard and a key mapping. J is free for pretty much everything and uses standard characters (although I really like the APL characters). I think they're both nice.

Dyalog comes with a keyboard layout (on a Mac it just replaces the alt keys). It's quite easy to use. GNU APL's Emacs mode does the same thing, although mapped to super rather than alt (meta, in Emacs) by default.

I'm aware of the licensing costs, I'm more curious about whether Dyalog is obtaining popularity versus J, and if so, why. Of course, three new people going to the Dyalog conference would be a 10% increase in popularity, it looks like… so maybe this far out on the long tail it doesn't matter.

Post reply on HN