It's different. But it is definitely not shit. The majority of use shouldn't write code like this. But those who can create amazing things.

Here's a working adaptation that is quite close to the original. https://github.com/tangentstorm/j-incunabulum/blob/master/mj...

A current version of the k language still has traces of it inside. And there are still people on Wall Street running mission critical systems with it. http://kx.com/q/c/c/k.h

The kona project attempts an open source implementation. And they give some rationale on the paricular coding style. https://github.com/kevinlawler/kona/wiki/Coding-Guidelines

> Do your colleagues a favor and don't write like this.

I'd second this - in any normal situation.

If you're really aspiring to form the future, strive to be extremely productive, demands that from your colleagues - that's another thing.

Sigh - industry as a whole isn't nearly on the level to use those advanced tools.

>Sigh - industry as a whole isn't nearly on the level to use those advanced tools.

Is this a parody?

Is J a language for writing personal code with personal meaning only that you can only run in your head?

There is nothing professional about this. Sounds more like a mental illness.

I once needed to develop an algorithm for a underspecified task. Something like "generate a real-looking map of the floor - with walls, windows, doors, corridors..." . Took me 40 minutes to try several variants in J. Then some 3 hours more to complete C# code. I don't know how long it would took if I'd experiment directly in C#. Probably not too long - but iterations would surely be more painful; too much boilerplate code.

In my experience, J is closer to thought process than many other languages. Really. You just have to try - and get used a little bit.

There's a reason that APL never gained a foothold and J has not been adopted by software engineers. You can program at the speed of thought in TECO as well, but the reasons for its limitations and peculiar history vanished long ago.

There are far better tools available these days for rapid prototyping; interpreted languages with REPLs and libraries for just about everything--without resorting to a write-only line-noise language and actually ending up with a usable product.

For that matter, I suppose it's possible to write understandable, maintainable TECO, APL and J with some effort if you don't value obscurity and cleverness over simplicity, correctness, maintainability and understandability.

If your business logic or product is written in line noise written by some lone J genius, your company is fucked when your guy inevitably gets hit by a bus, goes nuts, or leaves for greener pastures.

The same could be said for writing a document in Chinese, Arabic or Hebrew. They all look like "line noise" until you make an effort to learn them.

"For that matter, I suppose it's possible to write understandable, maintainable TECO, APL and J with some effort if you don't value obscurity and cleverness over simplicity, correctness, maintainability and understandability."

Yes. I do separate long functions in k onto separate lines. However, long functions in k are rare (and usually) an indication that I haven't arrived at a simple solution.

Writing in J/k/APL allows to think in chunks where the chunk is an algorithm - not all of the tiny steps in an algorithm. It is a higher level of abstraction - not unlike programming in C versus assembly language or machine code.

E.g.

The sum of a list (of any type) in k (APLis similar):

sum:+/x / read "plus over x" or "reduce x with plus"

versus (C code fragment) which computes the sum of integers only:

int sum=0: for(int i=0; i<n; ++i) { sum = sum + x[i]; }

Btw, John Von Neumann once chastised a grad student for writing an assembler. Perhaps real software engineers only write in machine code.

"If your business logic or product is written in line noise written by some lone J genius, your company is fucked when your guy inevitably gets hit by a bus, goes nuts, or leaves for greener pastures."

I think the larger issue is documentation. Undocumented code (of any kind) is a liability. When I write in k, Every line of k is documented (as text past column 80). In addition, there is header documentation that described the purpose and approach of the code in the file/module. The number of lines of code in a file is typically no more than 10 lines.

> There's a reason that APL never gained a foothold

APL was widespread in operations research in the 80s, and since the early 90s is usually found in and around finance, even though it isn't really common anymore.

Part of it is a mindset thing; People used to consider longer employment periods, both from the company's perspective and from the employee's perspective. Although APL is extremely useful when you use it properly, it is definitely not a "programmer-is-a-replaceable-cog" language that Java strives to be and the most firms now assume.

Perhaps "Notation as a Tool of Thought" - http://www.jsoftware.com/papers/tot.htm - could help you, if you want to understand why people keep writing APL and its successors? Like Mathematica, for example?..

Do you think mathematical articles are understandable and maintainable?

What if there is not a lone J genius, but a whole - small - department of people, who spend time actually thinking and talking about computations, not the ways to express it?

I've been screwing around with it in my spare time. J is quite logical and understandable. Anyone can understand it, but they have to make an effort to do so, just like they would if they were learning some other "weird" language like Lisp or Forth.