There's something to be said for being able to see more code at once, too. This is something the vector language people emphasize (also Chuck Moore, IIRC). The APL/J/K style is a different way of both writing and reading code, and the standard objections ("readability", "that looks like line noise") mostly are just because of the gap between that experience and the more mainstream way of experiencing code.
Btw we once had a long HN discussion about pg's suggestion that one should measure code size in tokens rather then lexically. I remember arguing in favor but being persuaded out of it by someone who was even more radical about small codebases than I am.
I've given some talks making the case that what we are doing with Java streams, LINQ, Rx, Ruby Enumerable, point-free style in Haskell, etc is prepping us for array languages.
They are all emphasize transformation pipelines. What the array languages bring to the game is shape polymorphism and many more operators. I suspect we'll see both move into more mainstream languages over the next 5 years or so.
Having played a bit with J, and also used Haskell extensively, I'd say they aren't that close.
Probably the closest contemporary language to J is Python+Numpy+Pandas. I've gone about 1/3 of the way through Notation as a Tool of Thought (http://www.jsoftware.com/papers/tot.htm ) and translated most of it to idiomatic numpy. E.g. their first example is:
+/l5
(read this as generate an array 1,2,3,4,5, then apply + as a reducer to it.)
In numpy this is:
add.reduce(arange(1,6))
It may just be familiarity, but I do find the Python to be far more readable. (Hardly surprising since brevity is the core value of k/j/Q, but readability is the core value of python.)
The examples in the paper are in APL which uses a special, non-ascii character set to express its syntax. J uses the standard ASCII character set. Readability comes with familiarity. If you want closer to natural language for programming then see Inform [1]. I think readability in Inform hinders compos ability and adds up to some lengthy programs. Mathematicians take the time to familiarize themselves with Greek letters, and other seemingly odd symbols, so it can be understood across cultures and languages, and is succinct.
In APL, you can change indexing from 0-based to 1-based. In J it is 0-based, so the need to increment the sequence with the increment verb '>:' as follows:
+/\>:i.5
1 3 6 10 15
You could also rename or group and rename functions for readability if working with others not familiar with J:
range =: >:@(i.) NB. @ joins the two verbs increment (>:) and index (i)
range 5
1 2 3 4 5
add_reduce =: +/\ NB. rename +/ (plus apply) and \ (infix)
add_reduce range 5
1 3 6 10 15
+/ range 5 NB. This is a comment (from the Latin 'Nota Bene')
15
I am playing with Idris, and do not know Haskell much, but I still find it more like mathematics when composing functions in J as opposed to Idris/Haskell. I see Idris/Haskell as more easy to express the proofs in a style to a proofs textbook, but I see J as more representative of the actual mathematical formulas. They are short, and can be easily manipulated without so much typing.
People sometimes criticize J/K/Q/APL the way they do when they write about Forth or Lisp, but it doesn't take away from them. The Rosetta lander had a lot of mission-critical code in Forth, but there are not many who like the syntax or way of composing programs.
J's learning materials have greatly improved from when I first looked at it [2].
kdb+/q beats the pants off of Spark, and Jd is the J programming language's answer to kdb+/q.
Array processing with a language that has arrays as its fundamental unit makes sense, and that is where it is all headed. Whether it is one of the existing array languages or a hybrid is the question. All those high salaries programming in Q is not a myth, and companies don't pay for no return on salary.
FYI - The creator of Pandas, Wes Mckinney, was studying or looking over J for his next venture. The link seems to have disappeared, so perhaps it is not in development, or it is being developed in secret!;)
I like the concepts introduced in the video. But, the Q syntax hurts my eyes. I am personally, not in favor of fitting my entire program in a tweet. Readability helps!
Readability is subjective and largely colored by your experience. Verbosity or succinctness isn't the problem here; it's that the syntax and semantics of Q are unfamiliar to you. I think it's very important to take a moment to step back and consider how many choices in language design you may be casually taking for granted.
Many mainstream languages today- Java, Python, Ruby, C, PHP etc.- have very similar core semantics and syntax. Choices of keywords and type systems differ, but loads of ideas work the same, especially when you consider idiomatic everyday code- for loops, scalar variables, some superset of the algebraic rules for operator precedence you learn in math class. Whitespace in an expression tends to be irrelevant, but sometimes its absence is significant. To add a scalar to a list, you use a loop. Assignment operators flow right to left. Lists tend to be indexed from zero. How many of these choices are essential and how many are arbitrary? All of these languages are descendants of FORTRAN and ALGOL, sometimes with some ideas from the Lisp family thrown in. They share a common heritage.
Q, K, J, A+ and APL represent an entirely parallel course of evolution. Within this family there is a great deal of mutual intelligibility. I'm very familiar with K, but the Q dialect doesn't surprise me. When learned, it's familar- readable. What did source code look like to you before you learned to program?
The APL family isn't amazing because programs tend to be short; that's a side-effect of the positive properties of these languages. They teach you to write naturally parallel solutions to problems and offer a simple, consistent way to compound together and apply functions to large structures at once. Please don't say "this looks different than I'm used to" and then close your mind to what the paradigm has to offer.
I'll grant that the debugging story for K isn't as sophisticated as with many other languages. Having a REPL and preferring programs that are mostly pure functions helps, but there's room for improvement. Tooling is about the community, though- not the language. I think that making documentation, screencasts and generally encouraging the expansion of K's open-source ecosystem will, with time, close that gap.
And when the data gets bigger, there's data.table[1], which performs amazingly well at certain tasks (vectorized ops ftw!), though the syntax can get a little clunky (if you squint at it hard, it's SQL-ish). On my 2012 macbook pro, I'm able to do (some) transformations of tables containing 10s of millions of rows in only a few seconds (and sometimes faster).
It's possible to use dplyr and data.table together, as well, to good effect[2].
The problem with all varients is the incredibly minimal resources to learn them. I wish a skilled practitioner would do something larger than a blog post. Something like a pluralsight/oreilly course...
It's brilliant language, and all, but I don't buy it. Here's why:
1) languages with this high level of abstraction are very nice if your scenario maps perfectly to its usage (e.g. the wikipedia analysis given in the video). Everything is nicely vectorizable, etc. But if there is some quirk in your data, then sometimes you need to go the usual way, and the Q is of no help (no better than any other language), with the difference that now you do some very inefficient things with those "stinky" loops.
2) it's a question of taste, but I find Q syntax a bit unusual. Probably more time you need to think how to fix your simple problems with this clever one-liners than simply, well solving them...
3) legibility: for all of us working in software developement, we know how much time we waste due to illegible code. Finding bugs, etc. Here this is raised to the new level... of difficulty
4) this is a bit exaggerated, but I don't see how I could use Q in something bigger? Is Q only a scripting languages for one-off mini-batch programs? For instance R has this problem of not having any well-defined project structure, and it is hard to do many things, for instance: bigger programs are hard to maintain and debug, stream processing with R is pain in the ass. Server-side stuff is a little bit shoehorned (Shiny server is cool, but then it's just one-thread thing for serving filtered dataframes to ggplots)
It is cool niche language, but for smart simple analyses, nothing too complex, as it will abstract you from details to your loss.
I had previously built similar games using other technologies, but found developing in q to be far faster, even given the more primitive debugging capabilities.
I understand that this is a relatively small example, but building it was enough to convince me the APL/k/q approach is useful beyond its supposed niche.
Regarding 2 & 3, I assume you don't know Q or any other array language. If you do, it's not really any less readable than any other language. Finding bugs isn't particularly hard due to how friendly the languages are to REPL development and how easy it is to trace array transformations.
I do agree with 1 & 4 though—Q (and to a lesser extent, K, APL, and J) are niche languages. However, they're really, really good at their niche.
It has nothing to do with array language, R is vectorized and is slightly more legible than, say clojure, that is not array lang. It has to do with very high density, though.
Right, but I would not minimize the number of bytes in a program, but rather the number of nodes in AST: http://www.paulgraham.com/arcchallenge.html
Here's an exercise: parse your favorite APL program into an AST, and see how many nodes it has.