Conway's Game of Life in Q: life:{3=a-x*4=a:2(sum -1 0 1 rotate\:,’/)/x}
By comparison in APL: life←{↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵}
life←{≢⍸⍵}⌺3 3∊¨3+0,¨⊢
The Q Language
81–90 of 161 posts
Re: The Q Language
#82Earlier quoted context omitted.
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…
The difference between "#define Z static" and Japanese is that Japanese is an effective method of communicating between 125 million people.
k/q is an effective method of writing useful code. if you are not used to it and can't appreciate it, doesn't mean that nobody can.
Re: The Q Language
#83Earlier quoted context omitted.
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.
> Longer identifiers don't make C programs larger. They make the source code larger. That makes it harder to read.
I can't understand your comment; can you make greater use of one-letter words?
Re: The Q Language
#84what makes kdb so special and why isn't there an open/libre alternative?
J language is also an open source APL-derivative and offers similar features.
Also important to note is that J is the final language from the inventor of APL (Ken Iverson) who also got the Turing award for APL. J has some advancements from vanilla APL & doesn't require a special keyboard or symbols. Some of these new features were added to Dyalog APL (modern APL with good support). Roger Hui is a well known figure in the APL community. He helped write J and works for Dyalog APL now.
Re: The Q Language
#85Notes 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 '…
Any other downsides? Management has been convinced and we're apparently switching to it at work soon but there is so little information and most of that is marketing, so it's hard to get an idea of what we're walking into.
price
Re: The Q Language
#86Earlier quoted context omitted.
Basically, this really wants to be using a custom preprocessor for a cleaner notation.
That would be a good step, but I don't think a preprocessor alone is enough to make this a good idea. You want good compiler error messages, static analysis tools, debuggers, code editors. You want a whole language.
what a gap. an abyss. inventor, and users of kdb explicitly and deliberately DO NOT WANT these things (static analysis tools, debuggers, code editors). nor they need it. language is so simple, there is no need for static analysis or code editors. (they compromised on error messages somewhat recently, though; now error messages are two words instead of one)
personally, i disagree with them on debugger. would be nice to have one.
Re: The Q Language
#87Earlier quoted context omitted.
Basically, this really wants to be using a custom preprocessor for a cleaner notation.
That would be a good step, but I don't think a preprocessor alone is enough to make this a good idea. You want good compiler error messages, static analysis tools, debuggers, code editors. You want a whole language.
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 C macros are generating, but with some other preprocessor which polishes the notation a little bit.
Even if those analysis tools and debuggers were developed for Q, they likely wouldn't apply to this code.
Re: The Q Language
#88Earlier quoted context omitted.
That would be a good step, but I don't think a preprocessor alone is enough to make this a good idea. You want good compiler error messages, static analysis tools, debuggers, code editors. You want a whole language.
what a gap. an abyss. inventor, and users of kdb explicitly and deliberately DO NOT WANT these things (static analysis tools, debuggers, code editors). nor they need it. language is so simple, there is no need for static analysis or code editors. (they compromised on error messages somewhat recently, though; now error messages are two words instead of one) personally, i disagree with them on debugger. would be nice t…
[deleted]
Re: The Q Language
#89I mostly love K/Q, and recently rearranged my career to do more of it. There are some things to be aware of, though:
* If your code doesn't spend most of its time in primitive verbs operating on large vectors, it's gonna be more or less as slow as any other interpreted language. Q and kdb+ can be fast and beautiful if you can arrange your problem in the right way, but it's not magic.
* The internals are locked away. If you don't like the way something fundamental works, tough. I've known some folks to go to heroic lengths with debuggers and hacked up shared objects to get Q to do what they want. You could also get Kx to add the stuff you need (they're pretty reasonable and responsive). But, you can't really take it apart and put it back together again like you can with, say, Lua, Ruby, or Python.
* Relating to the above point, one of the weaknesses of the language is that there are a lot of useful (even necessary) features packed into weird corners. There's little room for abstractions beyond the basics, so you get stuff like CSV parsing controlled by the structure of lists passed to a function called "0:". It's getting better documented lately, but it's still not pretty.
* Various annoyances (no real module system, no lexical scoping, etc...)
In many of those cases, I'm not even sure what could be done without compromising some other aspect of the language. Most of the time (at least for me), it's really a joy to use.