This programming language may be used to instruct a computer to perform a task.
|Type strength:||Strong (but regular)|
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.
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 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.)
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.
<lang J> (+/ % #) 1 2 3 2</lang>
To understand how this works, you might try working with simpler sentences and their variations.
<lang J> +/ 1 2 3 6
+/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.
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
- Roger Hui: contributions, J wiki
- Tracy Harms: contributions, J wiki
- Dan Bron: contributions, J wiki
- Arie Groeneveld: contributions
- Raul Miller: contributions, J wiki
- Jose Quintana: contributions, J wiki
- Ric Sherlock: contributions, J wiki
- Avmich: contributions
- VZC: contributions
- Alex 'bathala' Rufon: contributions, J wiki
- David Lambert:contributions
- JimTheriot: contributions
- Devon McCormick: contributions
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 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.
Reports:Tasks_not_implemented_in_J (The rosettacode reports on tasks not implemented in a language were lost in the move to miraheze. Miraheze offers a number of advantages, but someone will need to rebuild a replacement for these reports before they can function on this site.)
See: 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,327 total.(previous page) (next page)
- A* search algorithm
- Abbreviations, automatic
- Abbreviations, easy
- Abbreviations, simple
- ABC problem
- ABC words
- Abelian sandpile model
- Abelian sandpile model/Identity
- Abstract type
- Abundant odd numbers
- Abundant, deficient and perfect number classifications
- Accumulator factory
- Achilles numbers
- Ackermann function
- Active object
- Add a variable to a class instance at runtime
- Additive primes
- Address of a variable
- ADFGVX cipher
- AKS test for primes
- Algebraic data types
- Align columns
- Aliquot sequence classifications
- Almkvist-Giullera formula for pi
- Almost prime
- Alternade words
- Amicable pairs
- Anagram generator
- Anagrams/Deranged anagrams
- Angle difference between two bearings
- Angles (geometric), normalization and conversion
- Animate a pendulum
- Anonymous recursion
- Append a record to the end of a text file
- Apply a callback to an array
- Apply a digital filter (direct form II transposed)
- Approximate equality
- Arbitrary-precision integers (included)
- Archimedean spiral
- Arena storage pool
- Arithmetic coding/As a generalized change of radix
- Arithmetic derivative
- Arithmetic evaluation
- Arithmetic numbers
- Arithmetic-geometric mean
- Arithmetic-geometric mean/Calculate Pi
- Array concatenation
- Array length
- Ascending primes
- ASCII art diagram converter
- Aspect oriented programming
- Assertions in design by contract
- Associative array/Creation
- Associative array/Iteration
- Associative array/Merging
- Attractive numbers
- Autogram checker
- Average loop length
- Averages/Arithmetic mean
- Averages/Mean angle
- Averages/Mean time of day
- Averages/Pythagorean means
- Averages/Root mean square
- Averages/Simple moving average
- AVL tree
- Babbage problem
- Babylonian spiral
- Bacon cipher
- Balanced brackets
- Balanced ternary
- Banker's algorithm
- Barnsley fern
- Base64 decode data
- Base64 encode data
- Bell numbers
- Benford's law
- Bernoulli numbers
- Best shuffle
- Bifid cipher
- Bilinear interpolation
- Bin given limits
- Binary coded decimal
- Binary digits
- Binary search
- Binary strings
- Bioinformatics/base count
- Bioinformatics/Sequence mutation
- Birthday problem
- Bitmap/Bresenham's line algorithm
- Bitmap/Bézier curves/Cubic
- Bitmap/Bézier curves/Quadratic
- Bitmap/Flood fill
- Bitmap/Midpoint circle algorithm
- Bitmap/Read a PPM file
- Bitmap/Write a PPM file
- Bitwise IO
- Bitwise operations
- Black box
- Boolean values
- Boustrophedon transform
- Box the compass
- Boyer-Moore string search
- Brace expansion
- Brazilian numbers
- Break OO privacy
- Brilliant numbers
- Brownian tree
- Bulls and cows
- Bulls and cows/Player
- Burrows–Wheeler transform
- Caesar cipher
- Calculating the value of e
- Calendar - for "REAL" programmers
- Calkin-Wilf sequence
- Call a foreign-language function
- Call a function
- Call a function in a shared library
- Call an object method
- Canny edge detector
- Canonicalize CIDR
- Cantor set
- Card shuffles
- Carmichael 3 strong pseudoprimes
- Cartesian product of two or more lists
- Case-sensitivity of identifiers
- Casting out nines
- Catalan numbers
- Catalan numbers/Pascal's triangle
- Catmull–Clark subdivision surface
- Change e letters to i in words
- Changeable words
- Chaos game
- Character codes
- Chebyshev coefficients
- Check Machin-like formulas
- Check output device is a terminal
- Check that file exists
- Checkpoint synchronization
- Chemical calculator
- Chernick's Carmichael numbers
- Cheryl's birthday
- Chinese remainder theorem
- Chinese zodiac
- Cholesky decomposition
- Chowla numbers
- Church numerals
- Cipolla's algorithm
- Circles of given radius through two points
- Circular primes
- Cistercian numerals
- Closest-pair problem
- Closures/Value capture
- Code Golf: Code Golf
- Color of a screen pixel
- Color quantization
- Color wheel
- Colorful numbers
- Colour bars/Display
- Colour pinstripe/Display
- Combinations and permutations
- Combinations with repetitions
- Comma quibbling
- Command-line arguments
- Commatizing numbers