J as she is spoke

[pozorvlak]

I've been learning the programming language J recently, and in the course of my studies came across this example program by Ewart Shaw, to draw an ASCII-graphics Mandelbrot set:
{&'#.' @ (2:<|) @ ((+*:)^:400 0:) (18 %~ i:_20) j.~/ 28 %~ _59+i.75 It embodies so many J features and techniques that I'm going to analyse it here as

Comments

[meltroid]

"if all interesting programs are short, it doesn't matter how hard it is to write and maintain long ones"

Yes... but...

Just because a working program is short doesn't mean it's necessarily quick and easy to write. Especially if every time I want to fix a bug I go back to the drawing board and write a new program from scratch, thereby almost certainly introducing *new* bugs.

Sorry, I'm not convinced. This sort of language reminds me of being a mathematician studying compsci at Uni. The computer lecturers seemed desperate to be taken seriously as rigorous and formal mathematicians yet in doing so made things increasingly impractical.

I still have nightmares about WaFL (Warwick Functional Language).

[meltroid]

PS: That wasn't intended as a dig at you! Just at certain lecturers I remember.

[pozorvlak]

Sure, and "if all interesting programs are short" was really intended as a talking point, or a counterpoint to the prevailing wisdom that gave us Java et al. I think the hardcore APLers' boast that they'd just rewrite the program from scratch if they couldn't understand it was just intended to annoy the Algol/Pascal folks: iterative development using the interactive interpreter seems to be very much a part of the APL/J culture.

Two things, though. First, I think it's often (more than 50% of the time, at least) better to think harder and write a shorter program (within reason, and without golfing), because (second) bug count increases faster than program length on average.

We had a bit more of a discussion of this here. A more cautious way of stating the APL Lesson might be "A language that sucks for big programs can still be a net win if the space of problems it can solve with short (and ideally noddy) programs is big enough and important enough". I used to think that this was a good description of Perl, before I learned Perl better

[meltroid]

I certainly agree it's worth studying these things - just not worth using them :-)

Obviously I don't favour huge, monolithic systems made from spaghetti code - I've tried maintaining enough of them! Rather I prefer modular programming with small units which perform specific functions and communicate clearly with each other. OO is one paradigm for this, there are others.

A lot of academics seem to forget that ultimately the job of a programming language is to support the programmer. That might involve imposing restrictions such as strong typing and namespaces but not being difficult to understand and maintain.