5 ms·

Introduction to J Programming Language (2004)

45 points by skazka16 11y ago

bshimmin 11y ago
They should totally do a "J For Dummies" book.
- yiyus 11y ago
  It would have only one page that said: "This is not for you".
tempodox 11y ago
Nice to see an article that explains a bit about J's background. And definite sympathy points for the language supporting complex numbers. But I'm still wondering what the language's “high performance” is based upon. I'm an assembler hog and any language that doesn't compile to native code is just a toy to me. Yet the article only mentions an interpreter. I think, by now there must be something better than an interpreted write-only language.
- agumonkey 11y ago
  IIRC the interpreter is thin as hell. Almost no syntax or interpretation overhead. Also the semantics of J makes it very mechanical sympathetic. Some kind of macros based wrappers to express loops. ps: I'm not sure it was J .. maybe K. And I can't find the C source anymore. Haa... pps: check this http://lambda-the-ultimate.org/node/5075 http://lambda-the-ultimate.org/node/5075 they discuss performance.
  - wenderen 11y ago
    J source (GPL 3): http://www.jsoftware.com/source.htm http://www.jsoftware.com/source.htm
  - mamcx 11y ago
    I post that! I'm learning to build interpreters for a toy relational language (in F#). So a fast intepreter appeal to me. I look at http://keiapl.org/rhui/remember.htm#incunabulum http://keiapl.org/rhui/remember.htm#incunabulum but a)I don't know C b)Don't know J so wonder if exist a easy-to-understand interpreter of J somewhere? The ones I look (in the link above) are very dense. Full of code-golf.
    - agumonkey 11y ago
      This is the kind of code I remember. I think someone tried to de-obfuscate it in an article.
      - mamcx 11y ago
        I have try to find it with not luck. Any idea in how search for it?
      - JadeNB 11y ago
        Is it possible that you are referring to http://sblom.github.io/openj-core/ioj.htm http://sblom.github.io/openj-core/ioj.htm ? I found it linked at http://lambda-the-ultimate.org/node/5075#comment-82793 http://lambda-the-ultimate.org/node/5075#comment-82793 .
- deleted 11y ago
  [deleted]
- murbard2 11y ago
  The code and the interpreter together are both so terse that they fit in the cache. That buys you a lot of speed.
- ksherlock 11y ago
  Let's say I create a new, interpreted language. It's called fgrep and it only has a couple instructions for searching text. But I spend 5 years optimizing those functions. Now, if you need recursively search through a directory full of text files, would you use fgrep or would you write your own "high performance" search utility with a hard-coded (none of that slow run-time interpreting!) list of files and needle?
- beagle3 11y ago
  > I'm an assembler hog and any language that doesn't compile to native code is just a toy to me. First, what exactly is native code? Is it the PythonVM/JVM byte code? The x86 code it is JITted into? The microcode that interprets the "native" x86 code? You probably mean the x86/ARM/whatever bytecode, but that's not a trivial definition. Practically speaking, compiling to "native code" is mostly useful given a known architecture. "rep movsb" used to be the fastest way to copy memory around; and then it was slow as mollasses; and then it was fast again. Table lookups were the fastest way to do 6-bit by 8-bit multiplications up until the 386 or 486 - and then the multiplier became faster than memory. Somewhat surprisingly, J (and APL and K) tend to focus on promoting those things that have always been true - e.g. sequential access is much faster than non sequential; branch free code is better than branching code; small code/data that fit in cache/main memory is better than larger code/data that doesn't. The computation model fits modern CPUs and GPUs very well, despite being approximately the same one since the 1950s. It's a different take on the "better algorithms beat faster implementations" - a good language that makes a good fast solution intuitive is often, in practice, better than one that can be faster with a lot of intricate work.
- JadeNB 11y ago
  LtU discusses exactly the issue of how 'interpreted' can be faster: http://lambda-the-ultimate.org/node/5075 http://lambda-the-ultimate.org/node/5075 .
brudgers 11y ago
Ken Iverson's introductory text is Math for the Layman. It suggests that "learning J" is a bit like "learning math" and that proficiency should probably be measured more in terms of how one applies J to particular problems rather than general knowledge of syntax and recall of library functions as is common when talking about computer languages. http://www.cs.trinity.edu/About/The_Courses/cs301/math-for-the-layman/ http://www.cs.trinity.edu/About/The_Courses/cs301/math-for-t... Or to put it another way, a person can know J in the same sort of way a 7th grader knows math...or a 3rd grader or a Master's candidate. J is an exploratory language and will meet a person where they are. It is useful whether the person is only capable of basic arithmetic or convex hulls.
- kaosjester 11y ago
  I went to Trinity and Howland attempted to teach us J there. The entire thing went terribly. I agree with Iverson's assessment: learning J is a lot like learning math in that mathematicians often use weird and cryptic syntactic forms that are only tangentially related to other, similar forms. Unlike APL, this problem occurs in absurd detail in J. APL, at least, has strictly different symbols. J, on the other hand, uses strangely and opaquely-overloaded syntax. By way of example, consider the following: A programmer may expect < to perform less-than. In J it does, when used as a dyad. Used monadically, it acts as a boxing operator (similar to Scheme's box). That's strange, but livable. The problem, though, is in J, <. means 'lesser of' (min), and <: means 'less than or equal'. Again, this is a potentially livable arrangement. Except that . means determinant (or dot product, depending on monadic or dyadic appearance) and : means either 'explicit' or 'monadic/dyadic', a sort of combinator that accepts a monadic and dyadic operator and yields a new one. That is, in Scheme, dyadic usage of : is akin to a case-lambda that checks if it uses one or two arguments. If I present to you the program <., what does it do? Well, it certainly does something different from < ., which does something different from < :, which does something different from <:, which does something different from < . :, which again differs from <. :, and so on. This is exacerbated by operations such as 'table', written /, which bleed into other places. For example, </ inserts box, while <:/ inserts a decrement! And < :/ boxes up the result of an 'explicit' being 'inserted', whatever that means. And this syntactic problem plagues the entire vocabulary of the language: http://www.jsoftware.com/help/dictionary/vocabul.htm http://www.jsoftware.com/help/dictionary/vocabul.htm A clear optimization would be to just give these things their real names, use text, and write S-expressions. At least then the programs would be readable! The largest problem, however, is that for being a functional language, J does little if anything to convey the important idea that have been developed in functional programming: recursion. It simply isn't how things 'are done' in J. So we have a language with bad syntax, good semantics, and a horrible problem from an educational perspective. It has some nice additions above and beyond other APLs, but after that it falls flat. I'd urge anyone who has read this far to learn APL instead of J; it will at least be readable by other APL programmers. (I didn't mean to go on a rant, but I suffered through Howland's class on J at Trinity, and it wasn't until I had a professor show me Scheme in ~3 hours that I saw why functional programming was truly worthwhile.)
panjaro 11y ago
So eventually there will be programming language for every letter ? j, k , l, m , n......
- dalke 11y ago
  According to http://en.wikipedia.org/wiki/List_of_programming_languages http://en.wikipedia.org/wiki/List_of_programming_languages we're missing A, H, I, M, N, O, P, and U-Z, so half the alphabet. However, this list is incomplete. H - http://dcoj.wmh3.com/cscos/h/ http://dcoj.wmh3.com/cscos/h/ M is sometimes used to refer to MUMPS (see http://en.wikipedia.org/wiki/MUMPS http://en.wikipedia.org/wiki/MUMPS and http://www.mumps.org/ http://www.mumps.org/ ). It was also a language at Microsoft, http://www.theregister.co.uk/2008/10/10/dial_m_for_microsoft http://www.theregister.co.uk/2008/10/10/dial_m_for_microsoft . N - http://link.springer.com/chapter/10.1007%2F978-3-642-76153-9_10 http://link.springer.com/chapter/10.1007%2F978-3-642-76153-9... Z - https://github.com/chrisdone/z https://github.com/chrisdone/z In other words, the answer to your question is either "yes" or "that's already happened."
  - beagle3 11y ago
    J actually descended from A, Arthur Whitney (of K and Q fame). The famous origin of J[0] was called A at the time it was created, and Whitney developed it into an APL; A version with GUI was called A+ and was later GPLed[1] [0] http://www.jsoftware.com/jwiki/Essays/Incunabulum http://www.jsoftware.com/jwiki/Essays/Incunabulum [1] http://aplusdev.org http://aplusdev.org
pierrec 11y ago
I've been slowly learning J on and off for the past year or so (well, I wanted to learn it ever since I saw this [1]). It still feels pretty write-only to me, and I wouldn't make any large project in it, but as a brainstorming, research and experimentation tool, it's gold. This especially applies if you're working with matrices or things that can be well represented by arrays of any dimension. The jqt environment that comes with the standard package is polished, and encourages an interactive workflow where you progressively build your sentences while looking at the output. This way also greatly eases the learning curve. Another useful tool to help learning is the cheat sheet [2]. I'm not really into dead trees but I still printed it on paper because I'm not surrounded by monitors, and it really helps to have a quick reference to the very rich and concise J vocabulary. Applying unexplored verbs to problems that interest you is a fun exercise. One thing that struck me it that it's difficult to look up examples to help you as you go, in part because the one-letter name is not search engine-friendly, but more importantly because of the small size of the J corpus out there on the web. This is good because it force you to find solutions yourself, but it's bad because you never know if you're limiting yourself to a sub-optimal solution. [1]: https://news.ycombinator.com/item?id=1041500 https://news.ycombinator.com/item?id=1041500 [2]: http://www.jsoftware.com/jwiki/HenryRich?action=AttachFile&do=view&target=J602_RefCard_color_letter_current.pdf http://www.jsoftware.com/jwiki/HenryRich?action=AttachFile&d...
- RodgerTheGreat 11y ago
  I have been teaching myself K, and one useful resource for me has been http://codegolf.stackexchange.com http://codegolf.stackexchange.com. There are a handful of active users who write solutions in J, so it might be a good way to compare your solutions with those of another J programmer.
beders 11y ago
if you put s =: ({. , }. /: 12"_ o. }. - {.) @ /:~ in my code base, you are going to get smacked. Expressability of programming languages has a cognitive limit and J is flirting with it.
- Avshalom 11y ago
  if it makes you feel any better in Dyalog APL[1] I'd write that as: s←{ sp←⍵[⍋ ⍵] h t←(1↑sp) (1↓sp) h , t[⍋ 12○(t-h)] } or I can make it ugly as hell: s←{h,t[⍋ 12○(t←1↓p)-h←1↑p←⍵[⍋ ⍵]]} In Dyalog (and most APLs now) ←{...} creates function that automatically has ⍵ as it's left argument (so invoking "s points" ⍵ is points ) ⍋ give the indexes in sorted order and [ ] is how you access elements so ⍵[⍋ ⍵] is how you sort an array ↑ and ↓ are take and drop so (1↑sp) takes the head and (1↓sp) drops the head leaving the tail "h t←(1↑sp) (1↓sp)" is just multiple assignments J's verb trains are cute but kind of awful "h , t[⍋ 12○(t-h)]" sorts the tail according to the value of each elements phase (I agree the circle functions are particularly bad) and cats its back on to the head (also strictly speaking i don't need the parens around "t-h" but I like them). [1] well no actually I wouldn't because Dyalog's grade up (⍋) function doesn't work on complex numbers (though how to write a function ( gu ) that DOES is covered here http://dfns.dyalog.com/c_le.htm http://dfns.dyalog.com/c_le.htm )

45 points by skazka16 11y ago

bshimmin 11y ago

They should totally do a "J For Dummies" book.

yiyus 11y ago
It would have only one page that said: "This is not for you".

tempodox 11y ago

Nice to see an article that explains a bit about J's background. And definite sympathy points for the language supporting complex numbers. But I'm still wondering what the language's “high performance” is based upon. I'm an assembler hog and any language that doesn't compile to native code is just a toy to me. Yet the article only mentions an interpreter. I think, by now there must be something better than an interpreted write-only language.

agumonkey 11y ago
IIRC the interpreter is thin as hell. Almost no syntax or interpretation overhead. Also the semantics of J makes it very mechanical sympathetic. Some kind of macros based wrappers to express loops. ps: I'm not sure it was J .. maybe K. And I can't find the C source anymore. Haa... pps: check this http://lambda-the-ultimate.org/node/5075 http://lambda-the-ultimate.org/node/5075 they discuss performance.
- wenderen 11y ago
  J source (GPL 3): http://www.jsoftware.com/source.htm http://www.jsoftware.com/source.htm
- mamcx 11y ago
  I post that! I'm learning to build interpreters for a toy relational language (in F#). So a fast intepreter appeal to me. I look at http://keiapl.org/rhui/remember.htm#incunabulum http://keiapl.org/rhui/remember.htm#incunabulum but a)I don't know C b)Don't know J so wonder if exist a easy-to-understand interpreter of J somewhere? The ones I look (in the link above) are very dense. Full of code-golf.
  - agumonkey 11y ago
    This is the kind of code I remember. I think someone tried to de-obfuscate it in an article.
    - mamcx 11y ago
      I have try to find it with not luck. Any idea in how search for it?
    - JadeNB 11y ago
      Is it possible that you are referring to http://sblom.github.io/openj-core/ioj.htm http://sblom.github.io/openj-core/ioj.htm ? I found it linked at http://lambda-the-ultimate.org/node/5075#comment-82793 http://lambda-the-ultimate.org/node/5075#comment-82793 .
deleted 11y ago
[deleted]
murbard2 11y ago
The code and the interpreter together are both so terse that they fit in the cache. That buys you a lot of speed.
ksherlock 11y ago
Let's say I create a new, interpreted language. It's called fgrep and it only has a couple instructions for searching text. But I spend 5 years optimizing those functions. Now, if you need recursively search through a directory full of text files, would you use fgrep or would you write your own "high performance" search utility with a hard-coded (none of that slow run-time interpreting!) list of files and needle?
beagle3 11y ago
> I'm an assembler hog and any language that doesn't compile to native code is just a toy to me. First, what exactly is native code? Is it the PythonVM/JVM byte code? The x86 code it is JITted into? The microcode that interprets the "native" x86 code? You probably mean the x86/ARM/whatever bytecode, but that's not a trivial definition. Practically speaking, compiling to "native code" is mostly useful given a known architecture. "rep movsb" used to be the fastest way to copy memory around; and then it was slow as mollasses; and then it was fast again. Table lookups were the fastest way to do 6-bit by 8-bit multiplications up until the 386 or 486 - and then the multiplier became faster than memory. Somewhat surprisingly, J (and APL and K) tend to focus on promoting those things that have always been true - e.g. sequential access is much faster than non sequential; branch free code is better than branching code; small code/data that fit in cache/main memory is better than larger code/data that doesn't. The computation model fits modern CPUs and GPUs very well, despite being approximately the same one since the 1950s. It's a different take on the "better algorithms beat faster implementations" - a good language that makes a good fast solution intuitive is often, in practice, better than one that can be faster with a lot of intricate work.
JadeNB 11y ago
LtU discusses exactly the issue of how 'interpreted' can be faster: http://lambda-the-ultimate.org/node/5075 http://lambda-the-ultimate.org/node/5075 .

brudgers 11y ago

Ken Iverson's introductory text is Math for the Layman. It suggests that "learning J" is a bit like "learning math" and that proficiency should probably be measured more in terms of how one applies J to particular problems rather than general knowledge of syntax and recall of library functions as is common when talking about computer languages. http://www.cs.trinity.edu/About/The_Courses/cs301/math-for-the-layman/ http://www.cs.trinity.edu/About/The_Courses/cs301/math-for-t... Or to put it another way, a person can know J in the same sort of way a 7th grader knows math...or a 3rd grader or a Master's candidate. J is an exploratory language and will meet a person where they are. It is useful whether the person is only capable of basic arithmetic or convex hulls.

kaosjester 11y ago
I went to Trinity and Howland attempted to teach us J there. The entire thing went terribly. I agree with Iverson's assessment: learning J is a lot like learning math in that mathematicians often use weird and cryptic syntactic forms that are only tangentially related to other, similar forms. Unlike APL, this problem occurs in absurd detail in J. APL, at least, has strictly different symbols. J, on the other hand, uses strangely and opaquely-overloaded syntax. By way of example, consider the following: A programmer may expect < to perform less-than. In J it does, when used as a dyad. Used monadically, it acts as a boxing operator (similar to Scheme's box). That's strange, but livable. The problem, though, is in J, <. means 'lesser of' (min), and <: means 'less than or equal'. Again, this is a potentially livable arrangement. Except that . means determinant (or dot product, depending on monadic or dyadic appearance) and : means either 'explicit' or 'monadic/dyadic', a sort of combinator that accepts a monadic and dyadic operator and yields a new one. That is, in Scheme, dyadic usage of : is akin to a case-lambda that checks if it uses one or two arguments. If I present to you the program <., what does it do? Well, it certainly does something different from < ., which does something different from < :, which does something different from <:, which does something different from < . :, which again differs from <. :, and so on. This is exacerbated by operations such as 'table', written /, which bleed into other places. For example, </ inserts box, while <:/ inserts a decrement! And < :/ boxes up the result of an 'explicit' being 'inserted', whatever that means. And this syntactic problem plagues the entire vocabulary of the language: http://www.jsoftware.com/help/dictionary/vocabul.htm http://www.jsoftware.com/help/dictionary/vocabul.htm A clear optimization would be to just give these things their real names, use text, and write S-expressions. At least then the programs would be readable! The largest problem, however, is that for being a functional language, J does little if anything to convey the important idea that have been developed in functional programming: recursion. It simply isn't how things 'are done' in J. So we have a language with bad syntax, good semantics, and a horrible problem from an educational perspective. It has some nice additions above and beyond other APLs, but after that it falls flat. I'd urge anyone who has read this far to learn APL instead of J; it will at least be readable by other APL programmers. (I didn't mean to go on a rant, but I suffered through Howland's class on J at Trinity, and it wasn't until I had a professor show me Scheme in ~3 hours that I saw why functional programming was truly worthwhile.)

panjaro 11y ago

So eventually there will be programming language for every letter ? j, k , l, m , n......

dalke 11y ago
According to http://en.wikipedia.org/wiki/List_of_programming_languages http://en.wikipedia.org/wiki/List_of_programming_languages we're missing A, H, I, M, N, O, P, and U-Z, so half the alphabet. However, this list is incomplete. H - http://dcoj.wmh3.com/cscos/h/ http://dcoj.wmh3.com/cscos/h/ M is sometimes used to refer to MUMPS (see http://en.wikipedia.org/wiki/MUMPS http://en.wikipedia.org/wiki/MUMPS and http://www.mumps.org/ http://www.mumps.org/ ). It was also a language at Microsoft, http://www.theregister.co.uk/2008/10/10/dial_m_for_microsoft http://www.theregister.co.uk/2008/10/10/dial_m_for_microsoft . N - http://link.springer.com/chapter/10.1007%2F978-3-642-76153-9_10 http://link.springer.com/chapter/10.1007%2F978-3-642-76153-9... Z - https://github.com/chrisdone/z https://github.com/chrisdone/z In other words, the answer to your question is either "yes" or "that's already happened."
- beagle3 11y ago
  J actually descended from A, Arthur Whitney (of K and Q fame). The famous origin of J[0] was called A at the time it was created, and Whitney developed it into an APL; A version with GUI was called A+ and was later GPLed[1] [0] http://www.jsoftware.com/jwiki/Essays/Incunabulum http://www.jsoftware.com/jwiki/Essays/Incunabulum [1] http://aplusdev.org http://aplusdev.org

pierrec 11y ago

I've been slowly learning J on and off for the past year or so (well, I wanted to learn it ever since I saw this [1]). It still feels pretty write-only to me, and I wouldn't make any large project in it, but as a brainstorming, research and experimentation tool, it's gold. This especially applies if you're working with matrices or things that can be well represented by arrays of any dimension. The jqt environment that comes with the standard package is polished, and encourages an interactive workflow where you progressively build your sentences while looking at the output. This way also greatly eases the learning curve. Another useful tool to help learning is the cheat sheet [2]. I'm not really into dead trees but I still printed it on paper because I'm not surrounded by monitors, and it really helps to have a quick reference to the very rich and concise J vocabulary. Applying unexplored verbs to problems that interest you is a fun exercise. One thing that struck me it that it's difficult to look up examples to help you as you go, in part because the one-letter name is not search engine-friendly, but more importantly because of the small size of the J corpus out there on the web. This is good because it force you to find solutions yourself, but it's bad because you never know if you're limiting yourself to a sub-optimal solution. [1]: https://news.ycombinator.com/item?id=1041500 https://news.ycombinator.com/item?id=1041500 [2]: http://www.jsoftware.com/jwiki/HenryRich?action=AttachFile&do=view&target=J602_RefCard_color_letter_current.pdf http://www.jsoftware.com/jwiki/HenryRich?action=AttachFile&d...

RodgerTheGreat 11y ago
I have been teaching myself K, and one useful resource for me has been http://codegolf.stackexchange.com http://codegolf.stackexchange.com. There are a handful of active users who write solutions in J, so it might be a good way to compare your solutions with those of another J programmer.

beders 11y ago

if you put s =: ({. , }. /: 12"_ o. }. - {.) @ /:~ in my code base, you are going to get smacked. Expressability of programming languages has a cognitive limit and J is flirting with it.

Avshalom 11y ago
if it makes you feel any better in Dyalog APL[1] I'd write that as: s←{ sp←⍵[⍋ ⍵] h t←(1↑sp) (1↓sp) h , t[⍋ 12○(t-h)] } or I can make it ugly as hell: s←{h,t[⍋ 12○(t←1↓p)-h←1↑p←⍵[⍋ ⍵]]} In Dyalog (and most APLs now) ←{...} creates function that automatically has ⍵ as it's left argument (so invoking "s points" ⍵ is points ) ⍋ give the indexes in sorted order and [ ] is how you access elements so ⍵[⍋ ⍵] is how you sort an array ↑ and ↓ are take and drop so (1↑sp) takes the head and (1↓sp) drops the head leaving the tail "h t←(1↑sp) (1↓sp)" is just multiple assignments J's verb trains are cute but kind of awful "h , t[⍋ 12○(t-h)]" sorts the tail according to the value of each elements phase (I agree the circle functions are particularly bad) and cats its back on to the head (also strictly speaking i don't need the parens around "t-h" but I like them). [1] well no actually I wouldn't because Dyalog's grade up (⍋) function doesn't work on complex numbers (though how to write a function ( gu ) that DOES is covered here http://dfns.dyalog.com/c_le.htm http://dfns.dyalog.com/c_le.htm )