They are just writing the C interpreter in a style that reassembles the target language as much as it is possible, I guess you would have to understand some K to better understand what they are up to in the C code.
It brought up memories of the original Bourne shell source code which used a plethora of CPP magic to make the code look more Algol-ish, and thus similar to its final product.
"The unusual appearance is a side effect of writing C as concisely as possible. There are great benefits to writing code in this way. Someone familiar with the style can read and comprehend the code much faster than they could with traditional code. Brevity creates a discipline that reduces bugs. Some of the benefits will not be apparent until you try it. Some of the downsides of the style are inaccessibility and a steep learning curve."
Everyone has this reaction when first exposed to this class of languages and their implementations - everyone. You're unfamiliar with the style, and you're confusing that with it being ugly/unreadable/dumb. I assure you it's anything but.
Now let's page silentbicycle and get him to explain :)
You're unfamiliar with the style, and you're confusing that with it being ugly/unreadable/dumb.
I can't speak for GP, but I promise you I've spent plenty of time reading code with single-letter identifiers. If I'm going to have to actually understand some code, I'd much prefer descriptive names.
While I personally dislike this style of c, you should know that j/k/apl style languages are focused around a very small number of operators. In this sense they are a mathematical notation (and in fact, APL was designed as a rationalized mathematical notation first, programming language later).
So the single character identifiers are not intended as something application specific, or mutable values. They are like +, *, %.
That said, I still think it's better to stick to the conventions of the implementation language when writing an interpreter, rather than attempt to contort it half way to your target language. If you want a self hosted implementation, just write a compiler.
J is like that but without the special keyboard. I haven't played around with J much, but I know that whenever I've finished a Project Euler problem and checked the forum afterwards for other solutions, the J folks have reduced my 100 line solution to one or two lines...
From what I understand, J has a lot of problems with efficient implementation because array ranks (multi-dimensional arrays) influence how operations are carried out (http://jsoftware.com/help/learning/07.htm), and the ranks are not known in advance. [ranks also have horribly complicated semantics: http://www.jsoftware.com/papers/rank1.htm]
K doesn't have this problem because it only has vectors.
Given that this language predates the founding of Google by almost a decade I think we can forgive them for not thinking about how "googlable" the name is.
J the programming language is the first and third hit on Google.
I never get this criticism anyway, just add some context ("programming", "language", "snippets", "libs" or whatever) and just about anything will be easy to find. Surely beats those ugly unique names that people come up with, give me Go over Clojure any day.
1 and 2 letter names cause trouble in other areas than pure Google search, mainly in search on specific web sites and forums.
For example searching for "Clojure" on Amazon is likely to find every book related to using Clojure. Searching for "Go" will come up with a lot of junk and searching for "Go programming" would not find any book with say "Go Development" or "Go Recipes". This leads to multiple searches with no guarantee you aren't missing a lot more.
How about trying to find a comparison of say Java and Go in a programming/technology forum, better hope that the forum supports 1 or 2 character searches and the threads have sensible labelling.
I have never failed to have fun when I hacked anything at all in J (or in Q/KDB+).
But I have also never done any hacking in J except in the context of little bits of code for personal amusement.
Once interesting observation - despite not really knowing J well (or Clojure or Common Lisp, other languages I hack around in on a limited basis), I somehow spend more time thinking about what I want to accomplish rather than how to do it . . .
I used Q (the 'friendly' version of K) heavily in my previous job. It was in a high frequency team at an investment bank. All of our tick data was stored in kdb databases. I was in research at the time. You could load the data into whatever your research environment was (R or Matlab for most people) but it was much faster to boot up a Q session and work with everything in-memory, 'closer to the metal'. To that end I wrote
* An order-book builder (which takes quote data and builds it into a data structure suitable for doing research). As I remember, it was one call to 'scan' with a very complicated scanning function.
* An event analysis tool, to let you ask questions like "what's the average response of this asset when event X happens". Used for anything from testing your trading strategies (how does this asset perform when I put a trade on) to news impact (how does this asset react around US employment data).
* Lots and lots of plotting functions. Q actually has some really nice in-built visualization tools (as long as you only want to visualize time series...)
And a bunch of other stuff I've now forgotten about. It's a fun language. I miss it a bit now I do all my work in Matlab.
I know that many finance firms use KDB+ and Q to manage stock tick data - this is where I first saw KDB+ in action, oddly enough I was pulling some non-tick data from a KDB+ system for a data warehouse project.
I think that J is one of those languages that would really shine in allowing a hacker with a large amount of domain specific knowledge to do wonderful work with small amounts of code. So, if you are a stats hacker interested in applied modeling, maybe you could use J to very concisely build your models. Probably bioinformatics would work as well, I can see how fastq data would be easier to deal with if you just chunked it into a KDB+ backend.
There are lots of folks on HN who seem interested in J or KDB+ (see the Kona open source project) who might have better answers than this . . .
It's just mathematical notation. Why is that insane?
What is computing at its most basic level but maths?
If you can handle working with symbols, more power to you. If you can't, move on. It's like calling mathematicians insane because you cannot understand the symbols they use.
I'm never sure if the conditioning of programmers toward certain styles has been good or bad for computing overall. It's troubling when this conditioning causes us to reject what is obviously excellent and useful work. (_if_ we learn how to make use of it)
"The problem is the price is not right for me at this stage."
Well, I'm pretty sure Whitney's enlightened path to k went through LISP, so maybe the author will get there one day. And LUSH seems a pretty nice choice of LISP's to work with - extendable, but not too big out of the box.
> The C source code for this is intensely beautiful, and very concise. Go look at it!
Which links to https://github.com/kevinlawler/kona
This has to be a joke - just pick a random file and tell me what is beautiful about that. LoseThos looks saner than this code.