As someone who loves J (though I'm far from mastering it), I certainly wouldn't want to work with it either. J (and APL) really shines when you're playing with it in interactive mode, gradually building sentences and looking at the output at every step. In my case, I've been using it to experiment in algorithmic composition, and I find it forces me to think in interesting and potentially powerful ways.

But, as you say, browsing through a large codebase in J would be not be a fun experience. The only way to handle it for me would be to comment it heavily and keep each line as short as possible (which is indeed what maintainable J files tend to look like). So I reserve it for experimentation - and I'm finding it very adapted for the purpose.

What you say is true for most languages, however, it's different for J. The sigils you see are the whole language - there are only around 20 sigils, which are the core functions of the language. You only need to learn and remember them, you can then work your way through any kind of J code. It may go slowly at the beginning, but as you get used to the most often occurring ways of composing them you get faster.

In other words: you can't really say anything about how it feels to work with J without working with it for some time. This may be true to some extent with other languages, but J is unique/different enough to make this point especially true.

I worked with J for some time (in my free time) and I pretty much had to learn it from scratch 3 or 4 times. And if I had to use J right now I'd had to learn again because I literally forgot everything. The syntax, the words, the verb trains... everything is downright absurd.

I really wanted to like it so I could program in my phone, but it's just too absurd to work for me.

The basic idea I got from experienced programmers was: you don't code like that in the real world. Real-life code should look a lot more like code in other languages, with no tacit programming and a lot of redefining of one-char words into actual words to improve readability. Then... why would I code in J at all? And why am I not taught to code like that in J's help?

From http://www.jsoftware.com/help/jforc/culture_shock.htm#_Toc19... , a great book about J:

> I've looked at some J code. Every other character is a period or a colon. I've got spots before my eyes. How can anybody read this stuff?

> You'll get used to it. J has a great many primitives, and it's important to keep the names short so that you can fit a lot of computation on one line; so the names are either single characters, like >, or a character with a period or colon appended (>. and >:). The period/colon is just part of the name. Single letters with period/colon, like i., are also used for primitives. If you want to assign your own names to the primitives, you are allowed to, but pretty soon you'll want to go back to the shorter names to save space and typing.

There are a billion things against a sigil only language: it's near impossible to give you a helpful IDE (in a word-like language you can use autocomplete but how do you give ideas whether the user should use @ or ^ at a given point?), it's near impossible to search for code examples and such (the other day I was looking for code in any language at all that uses /PZ/u as a regular expression without success), you need to think twice before using any of the standard shell utilities on them and so on.

> it's near impossible to give you a helpful IDE (in a word-like language you can use autocomplete

What autocomplete you need in J? For verbs and conjunctions which are at most 2 letters long?

> how do you give ideas whether the user should use @ or ^ at a given point?

In the same way as IDE helps you to choose . or exp() ? They are completely different concepts, how can you mix them?

> it's near impossible to search for code examples and such

I think it's a common problem for complex code examples, in any language. You may, though, search for comments.

From http://www.jsoftware.com/help/jforc/foreword.htm#_Toc1917342... :

> C is a computer language; it lets you control the things the computer does. J is a language of computation: it lets you describe what needs to be done without getting bogged down in details

I think it's a great help. J doesn't just reduces typing; it also reduces the amount of things one needs to keep in the head to solve the problem.

When I implemented the GNU APL mode for Emacs, I tried to make it as much as an IDE as possible. I modelled it on SLIME, and it has a live connection to your runtime, and provides things like jump-to-definition and completion based on the functions available in the runtime.

I even coerced SES (the Emacs spreadsheet) to act as an editor for large arrays.

I would argue that I have suceeded at least partially, such that I can say that it's definitely possible to implement an IDE for APL.

A popular saying in APL world: an APL programmer solves a problem in 5 minutes, then spends the rest of the hour to polish the solution to perfection.

I doubt you'll need a lot of maintenance for short (and thought-out) solutions.