Live data from Hacker News

The Q Language

code.kx.com

151–160 of 161 posts

Re: The Q Language

#151

Earlier quoted context omitted.

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.

.... and the J implementation is inspired by the "A" miniature APL interpreter written by Arthur Whitney who later went to create K. See http://code.jsoftware.com/wiki/Essays/Incunabulum for more (and google "J incunabulum" if you want to see other people's commentaries)

Re: The Q Language

#152
post #117

Earlier quoted context omitted.

I have worked in C (twenty-five years), C++, Python, Perl (twenty years), JavaScript, Common Lisp (for ten years), OCaml, forth, postscript, and also q/Kdb. I think a lot can be done to improve teaching q/Kdb. The current “best practice” is to change you until it makes sense but this takes time- anywhere from 6 months to a couple years based on your other experiences. And you still have to want to “get it”. I want th…

Hi Geo, Thank you for the time to respond. I understand that speed is very important and I'm happy that Q takes it seriously. I was never questioning that part. I also understand the beauty of functional programming paradigms (working with maps and applys), I wrote many lines in Mathematica without "for" loops. I also understood many code snippets written by developers working only with Q (I guess they are experts).…

I'm happy to, and by all means reach out -- instructions to find my email are on my profile page and I'm on github, etc.

I'm not speaking tongue-in-cheek when I say the short variable names and terseness are a feature. I wrote briefly on this subject previously[1], but there's something difficult to get across here because I have been changed.

Learning how to read very dense code changed the way I think about programs, and it has completely eliminated several classes of mistakes that I used to make.

I can see repetition where I never noticed it before. I require far less abstraction to get the business problem solved. And yes, my programs are faster.

It's also put me across the table- really, might as well be an ocean: q/Kdb is fast because it is written in this way. If you try to write another language/interpreter that isn't all bunched up on one line, that has friendly error messages and long variable names, it won't be as fast. From here it is plain and obvious why, and yet I struggle to show you over there.

[1]: https://news.ycombinator.com/item?id=8476113

> The evaluation order is not clear to me. I understand this expression {x+2*y} scan 2 3 5 7

Single-character operators, and functions in the dot-q namespace (like scan, which is really called .q.scan) take an "argument" on the left-hand side. Everything else doesn't.

> It would be great if a tool could convert this expression to

parse[2] can do this, and it was really useful to me when learning q.

[2]: http://code.kx.com/q/ref/parsetrees/#parse

Re: The Q Language

#153

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.

Yes, the "electric" GUI was incredibly fast and effective. The K2 GUI was basically the only GUI system I've ever used in which it is easier to write a GUI for a simple system than a batch command line. It looks basic and wouldn't have won any design awards, but it was crazy fast and crazy effective. See e.g. The S- spreadsheet (copied here in its entirety), see near the bottom of http://nsl.com/papers/spreadsheet.htm for screenshots and discussions

    S..t:".[`D;(;);{. y};S[]];S[.;`f]:9$D[]"
    S:D:.+(`a`b`c`d;4 6#,"")
Other examples: http://nsl.com/papers/puzzle15.htm , http://nsl.com/papers/calculator.htm

I suspect the reasons it was removed were:

(a) it was a lot to maintain compared to the rest of the k environment, as it needed to be implemented for all systems independently (X, Win, Mac at the time), and introduced dependencies that were about 10x larger than the base system.

(b) it wasn't actually a selling point - being simple and local GUI meant that while it was nice for the programmer users, it wasn't useful for end users, who usually had no K license of their own, and who expected everything to be web-able and importable to Excel.

(c) it wasn't extendable with more widgets. Needed a small HTML control or video player in your GUI? touch luck.

Re: The Q Language

#154

Earlier quoted context omitted.

Red pill is originally a Matrix reference...

Yes, and just like Pepe, it has been adopted by a community and no longer means what it originally means.

Pepe being somehow this banner of the alt-right is fucking weird.

Re: The Q Language

#155

Earlier quoted context omitted.

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.

.... and the J implementation is inspired by the "A" miniature APL interpreter written by Arthur Whitney who later went to create K. See http://code.jsoftware.com/wiki/Essays/Incunabulum for more (and google "J incunabulum" if you want to see other people's commentaries)

Neat, thanks!

Re: The Q Language

#156

Earlier quoted context omitted.

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!

K's approach of arrays of arrays would preclude an efficient 2d stencil operation wouldn't it?

Re: The Q Language

#157
post #139

Earlier quoted context omitted.

I also dabble in Dyalog APL. I have an inexplicable bias for the symbols, however I really like J and the commmunity. I have played with Jd with a trial license, and as said above, J is free and the source is available for scrutiny. I have played with using the J DLLs in my C code. I am always amazed at my takeaway understanding of a mathematics problem after working it out in J. It somehow gels it in my mind, and fi…

I like the APL symbols, but I think we could probably do better today, since we're not as limited by what we can come up with using overstriking.

Probably, but like Cuneiform's wedge-shaped marks, it brings an easy familiarity to a line or lines of text or code. It would be cool to make APl in Vulcan or Predator symbols!

Re: The Q Language

#158

Earlier quoted context omitted.

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.

>any semantic similarity to the K2 GUI system is probably coincidental.

Hardly coincidental! I very much had the K gui in mind when I originally architected it (and I'm not sure I'd describe it as a "reasonably conventional web application"...)

Re: The Q Language

#159
post #117

Earlier quoted context omitted.

I have worked in C (twenty-five years), C++, Python, Perl (twenty years), JavaScript, Common Lisp (for ten years), OCaml, forth, postscript, and also q/Kdb. I think a lot can be done to improve teaching q/Kdb. The current “best practice” is to change you until it makes sense but this takes time- anywhere from 6 months to a couple years based on your other experiences. And you still have to want to “get it”. I want th…

> Nim and Python and JavaScript are all basically the same thing. You learned one of them, you kindof learned them all, so adding another one feels like these things are easy to learn. Alien technology is alien though, you haven't learned any of it. How can we even talk to each other? This is an understatement. It helps explain why a person who has never programmed will pick up APL/J/K easier than someone who already…

> It helps explain why a person who has never programmed will pick up APL/J/K easier than someone who already knows Python or C.

I disagree with this.

It is probably easier to teach someone APL/J/K if they don't think they already know Python or C, but, an experienced C+K programmer will be able to teach a willing C programmer K very quickly.

Many q/Kdb guides start with simple things like addition and subtraction but with vectors, like a Python programmer really cares about the difference between:

    prd 1+til x
and:

    numpy.arange(1,1+x).prod()
and heck, that Python programmer probably thinks that looks better or "cleaner". They might argue about whether it should be two steps or an extra parenthesis, or whatever, but the relationship between capability and semantic appears roughly the same.

That's why I start with tables, IPC, and views.

It's one of those things that makes python programmers go "whoah": They quickly get kdb tables are way better with queries, that IPC is "like pickle times asyncio on steroids", and "just wow" to views.

If you do not see someone do something that you are struggling with quickly and effortlessly it will be difficult to drop your ego; If you really think "yeah but everything else is easier in python" then it is a handle to hold onto.

q/Kdb makes a lot of really hard things easy, and it gets them extremely right. That's right: Fuck speed. I like programming in q/Kdb because I'm more effective: It's a better language, with a better set of builtins and libraries.

And so on.

Re: The Q Language

#160
post #152

Earlier quoted context omitted.

Hi Geo, Thank you for the time to respond. I understand that speed is very important and I'm happy that Q takes it seriously. I was never questioning that part. I also understand the beauty of functional programming paradigms (working with maps and applys), I wrote many lines in Mathematica without "for" loops. I also understood many code snippets written by developers working only with Q (I guess they are experts).…

I'm happy to, and by all means reach out -- instructions to find my email are on my profile page and I'm on github, etc. I'm not speaking tongue-in-cheek when I say the short variable names and terseness are a feature. I wrote briefly on this subject previously[1], but there's something difficult to get across here because I have been changed. Learning how to read very dense code changed the way I think about program…

Short names and terseness are indeed features - for those who have already internalized the meaning of names and symbols. The problem is that bridging this ocean takes such a long time that for many people it's just not worth it (and for many others it doesn't _seem_ worth it).

It's doubly frustrating because it doesn't have to be that hard. With a projectional editor descriptive names, explicit evaluation order, inline expansion of functions and macros (e.g. for the C code mentioned below) could just be a button press away. And it's not like experienced coders would never benefit from such tools, either.

Post reply on HN