A look at the J language: the fine line between genius and insanity | Hacker News Reader

A look at the J language: the fine line between genius and insanity

scottlocklin.wordpress.com

89 pointsmhd35 comments

FTA:

> 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.

It's concise, at least.

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.

Kona is actually an implementation of k (not sure if he's planning to support q, which is k's successor), a cousin of J.

K was originally written by http://en.wikipedia.org/wiki/Arthur_Whitney_(computer_scient..., and having seen some of his C code, this looks like a very similar style. Take a look here: http://www.nsl.com/papers/origins.htm

edit: included link to a better source example

FTA: > "Reading his source will make you a better person, even if you don’t understand what is going on."

LOL. Sure, go ahead and stare at all these classes and files with single letter (and single number) names. It will make you a better PERSON.

There's a discussion on that — https://github.com/kevinlawler/kona/wiki/Coding-Guidelines

"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."

This has to be a joke

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.

On a related note, have a look at the one page prototype interpreter by Arthur Whitney that later became J, a true work of art:

http://www.jsoftware.com/jwiki/Essays/Incunabulum

Like art is also isn't terribly practical.

That page of code is a known classic that gave rise to two brilliant language implementations (J and K). It is highly practical. It's just unfamiliar.

Ah, I love (at least the idea) of the APL languages. My go-to programming syntax mindbender is this video of programming Conway's Game of Life in APL:

http://www.youtube.com/watch?v=a9xAKttWgP4

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...

Dear language creators

Stop creating non-googlable language names

R already is trouble enough, at least C is more known but still confusing

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.

Yeah. Google, on the other hand, has absolutely no excuse at all for using such an ungooglable mess of a name as "Go". It is embarrassing.

When people have to call it "Golang" just to differentiate it from the verb, then you know something is wrong.

http://www.google.com/search?sourceid=navclient&gfns=1&#...

Not entirely sure I understand the problem here.

Not entirely sure I understand what happens here.

It's an I'm Feeling Lucky query, accompanied by a bit of snark.

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.

The problem is when you're referencing the language in other contexts or worse search engines

Example: searching for a package on aptitude or yum

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.

A relevant question on the Quantitative Finance StackExchange as to whether J/JDB can be used as an effective replacement for Q/KDB+ can be read here: http://quant.stackexchange.com/questions/1870/can-the-j-lang...

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.

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 found the codemonk series on J very entertaining as well: http://drj11.wordpress.com/category/j/

Does anyone on the board use J / K daily? What for?

I do not use J daily but would like to.

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 . . .

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.

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.

Thanks for the nice intro to j. I've bookmarked it, and have put it on my list of things to explore.

Edit: Downloaded J and took a tour. It does look very compelling and I'm pretty sure I'll be back for more.

Great article! Thanks.

oh cool, j

i'd rather code in brainfuck than this

Reply on news.ycombinator.com