32 bit version of KDB+ is now free for commercial use

interesting.

My thoughts on this area have changed a bunch, I think when I was young I was a lot more about cleverness and conciseness.

Now that I'm older and I've worked on a large variety of software systems, I am starting to believe that readability of code is one of the most important values. After all, you read the code a lot more than you write it.

I can say definitively that: - i have often regretted using single letter variables (outside of loop 'i') - I have very regretted using non-descriptive names - I have never regretted using longer variable/method names

Now a days in an IDE environment, longer names doesn't even convey a typing penalty. Yeah yeah I know Java, but it's a safe language, and in a world where I want to deliver working, correct, bug free code, safety is more important than single letter expressiveness.

After all, I don't think people hold up APL as good code.

> My thoughts on this area have changed a bunch, I think when I was young I was a lot more about cleverness and conciseness.

I'm almost the other way around. I always valued elegance, which often manifests itself in conciseness (but most conciseness is NOT an example of elegance). Followed by readability, which usually manifests itself in verbosity (though most verbosity is NOT actually readable). And when decision time came, I'd prefer verbose inelegant code to non-verbose concise code.

But then, I spent some time using K. And I realized I need 100-1000 times less lines to achieve the same thing, AND it usually works about as fast (despite an interpreter), AND I have less bugs AND those bugs tend to be of one kind (off-by-one) and easy to find.

e.g., look at this example by Stevan Apter: http://nsl.com/k/t.k - 14 short lines implement an efficient (fast and memory compact) memory database than includes joins, selects, inserts, deletes, aggregates, grouping and sorting.

To the uninitiated, it looks like code golf, but this is actually very readable K if you know K. The definition order:where:{[t;f;o]{x y z x}/[_n;o;t f]} gives two names ("order" and "where") to an idiomatic K expression that takes a table "t", and paired lists "f" (of field names) and "o" (of re-index functions that can be used to filter or sort), and returns the resulting table after reindexing, one by one, applying those functions to their relevant fields. A sorting function would be "desc:>:" (that is, ">:" hereforth also named "desc") which returns a sorting permutation for its argument. A filtering function would be "&3>" (prnounced "where 3 is larger than" and can be written "where 3>" in the Q dialect).

Now, this conciseness does NOT come from golfing. It comes from eschewing the now obligatory object oriented programming, sticking with "down to the metal" data types, and rather than trying to find the minimal base of operations and endless compositions (like most languages do), use a wide base of operations and a precisely chosen set of compositions.

It is true that reading/writing a K line takes 10-50 times as long as reading a C line. But I've been unable to consider modern software engineering anything but ludicrous when a different set of primitives (and experience) can get you the same results for 1/100 or 1/1000 of the size of the executable specification, and everyone puts a SEP field on it.