From Rosetta Code
This programming language may be used to instruct a computer to perform a task.
Official website
Execution method: Interpreted
Type safety: Safe
Type strength: Strong (but regular)
Type checking: Dynamic
Lang tag(s): j
See Also:
Listed below are all of the tasks on Rosetta Code which have been solved using J.

The J language

A frequent reaction when one first encounters a J program is often something along the lines of "that's cheating". The thought here is that the problem could not possibly be that simple, so — instead — the issue must be that J was specifically designed to tackle that problem.

The flip side of this issue is that J is a dialect of APL — a language whose development started in the 1950s and which was implemented in the early 1960s. And, originally, APL was designed as a language to describe computer architecture. The implementation as a programming language was motivated by its original successes in documenting computer hardware and instructions, and the relative simplicity of its concepts.

See also for some reflection on some of the linguistic character of J.


J is a notational programming language designed for interactive use.

It is an array language; data is universally structured as rectangular arrays.

It is a functional language; creation and composition of functions is emphasized.

Object-module and imperative techniques are supported, but not required.

The J programming language was designed and developed by wp:Ken Iverson and Roger Hui. It is a closely related successor to APL, also by Iverson which itself was a successor to the notation Ken Iverson used to teach his classes about computers in the 1950s.

The notation draws heavily from concepts of Abstract algebra and Tensor calculus, simplified for describing computer architecture and design to a pragmatic business audience. (The ideas themselves are simple, but for some reason the topics scare most teachers.)

Reading J

J is meant to be read with the aid of a computer. J sentences are single lines and trying variations and simplifications of an expression is common practice. The first step in understanding any J sentence is to understand the data you started with and the data which resulted. When learning how a J sentence works, you can also try simpler sentences with the same data or perhaps related data. When trying to understand contexts that use large data structures, it can often be wise to investigate small, representative samples until you understand how the code works.

Unless you attend an institution which has made a J interpreter available to you through your web browser (or preinstalled on your machine), if you want to see how J works you should probably install a copy of J -- or you can try one of the "try me" links, below. If you want to understand how to experiment with alternative expressions you should probably also be studying some of its documentation.

For example, the phrase (+/ % #) finds the average of a list of numbers.

   (+/ % #) 1 2 3

To understand how this works, you might try working with simpler sentences and their variations.

   +/ 1 2 3
   +/4 5 6
   # 1 2 3
   # 2 3 4
   6 % 3
   15 % 3
   (+/ % #) 4 5 6

By themselves, these experiments mean nothing, but if you know that +/ was finding the sum of a list and # was finding the length of a list and that % was dividing the two quantities (and looks almost like one of the old school division symbols) then these experiments might help confirm that you have understood things properly.

Some perspective

If you wish to use J you will also have to learn a few grammatical rules (J's parser has 9 reduction rules and "shift" and "accept" - the above examples use four of those rules). J verbs have two definitions - a single argument "monadic" definition and a two argument "dyadic" definition. These terms are borrowed from music and are distinct from Haskell's use of the word "monad". The dyadic definitions are in some sense related to LISP's "cons cell" but are implemented as grammar rather than data structure, and are a pervasive part of the language.

Another pervasive feature of the language is rank.

The language represents capabilities of hardware. For example, if language did not have an internal stack, a word's definition could not be used during the execution of that word. All current J implementations support recursion, but in some sense this is a convenience, and it's reasonable to imagine J implementations which do not (perhaps in a "compile to silicon" implementation).


Perhaps also worth noting is that when thinking about J programs, it can be convenient to think of an instance of an array as a type. This is in some ways different from the usual treatment of type (where all potential values in a syntactic context are treated as a type but the types are typically far more constrained than "an array").

J's type hierarchy supports arrays of arbitrary size and dimension, and array contents may be numeric, character or boxed. Thus, for example, we might work with an array of boxes, each box containing a one dimensional array of characters -- or, informally: strings.

In addition to arrays, J's type hierarchy includes procedural types: verbs, adverbs, and conjunctions. These roughly correspond to functions (J's verbs) and metafunctions (J's adverbs and conjunctions) of other languages.

As a simple example: 2 is an array (with zero dimensions), 3 is an array, and < is a verb. The expression (2<3) compares 2 and 3 and returns a truth value indicating that 2 is less than 3. But the expression (<3) returns a box which contains the array 3. While the details here are a bit different, the general concepts should be familiar to users of other programming languages. (For example, in C, 2&3 performs a bitwise and between the two numbers, and &y returns a pointer to the value referred to by y.)

J would be considered dynamically typed because of the generality of its arrays. But its type based syntax would lead some to consider it to be statically typed (though the simplicity of its syntax might invite criticism from people who prefer more complexity).

J on RosettaCode

Discussion of the goals of the J community on RC and general guidelines for presenting J solutions takes place at House Style.

Jedi on RosettaCode

Try me

Want to try one of those cryptic J lines you see peppered through RC? Try pasting it into this browser-based implementation of J. Here's a short video intro, for people who would prefer some guidance.

If you want to be a bit more interactive, and get some guidance from J gurus, you can join the actual J IRC channel on Freenode, #jsoftware. Buubot and several other J eval bots run there. If you don't have an IRC client you can try freenode's web interface (or just give it a quick spin). More details about the J IRC community is available.

If any of that piques your interest, and you want to explore a little more, you can download J and join the J forums.

If you have problems executing any of the J code here on Rosetta, please make a note of it either on the task page itself, on the talk page, or on the appropriate J forum, whichever is best. It might be that there's a version dependency that needs to be documented, or you might have found an actual bug.



See also: the "unimplemented tasks" task page for a mechanism for finding rosettacode tasks and draft tasks which have not been implemented in J (or any other language, for that matter).


This category has the following 3 subcategories, out of 3 total.


Pages in category "J"

The following 200 pages are in this category, out of 1,413 total.

(previous page) (next page)


(previous page) (next page)