Understanding J

The j language is a terse APL derivative programming language that uses language like concepts.

noun

verb

adjective

adverb

etc.

There are also several programming styles. Parameterized functions, tacit functions, state machines, and many many ways of overloading verbs to get them to do what you want without having to use the full vocabulary of the language.

Tacit functions being my favorite style that I latched on to like a tick on a deer after I'd written my first couple of tacit functions.

Tacit functions are all about changing the meaning of verbs based on a chaining order that determines whether a verb is monadic(one parameter passed on the left or right) or dyadic(left and right parameters) and whether one or both of those parameters are the result of the previous verb or verbs or the original or outer parameters or a combination of the two. Basically a repeating set of 2, a hook, or 3, a fork, verbs in a chain with one verb being the original behavior. More on that here http://www.jsoftware.com/help/learning/contents.htm

So, any who, my big breakthrough moment was when I looked at an example adverb definition and it struck me that my love of terse and tacit function definitions was keeping me from being as productive as I could be in j and thereby keeping me from learning more through experience than I can through pouring through the manuals for the perfect way to cut a character off of a tacit expression.

After my big breakthrough I dug in with gusto and quickly and easily rewrote some j code I'd written  a couple of years ago when I was first learning j. The lesson I have learned is that sometimes you have to use a few more characters to get things done in j. That is just the way it is most of the time.

That being said I still look forward to the next time I have an insight that let's me shave a few characters off of an expression but I will no longer try to force it. I am still a little bit leary of using explicit functions unless it is in order to learn how to write adverbs in j.

J and Python Tips

J

$: self reference for recursion etc.

Have to experiment with it

Python

Use seq[:1] and seq[-1:] first and last instead of seq[0] and seq[-1] to avoid index out of range exception for empty sequences

Generally, for all index n use seq[n:n+1] instead of seq[n] to avoid exceptions without having to add extra logic checks

>>> [][3:4]

[]

j

What a difference a month of using an APL language variant, A Programming Language. I learned a bit more about ipython and the %%script cell command when I started playing with j in a ipython notebook. It seems like I can get by a problem at a time writing scripts in j and running  them and organizing them in an ipython notebook. I have been able to one up ipython by working in j-console and using Droidedit on my Android and Textpad on my iPad Mini.
Developing on my phone in J using the j-console app for Android has changed my mind about going much further down the path of an expanded language learning and improvement experiment. I've decided to stick to perfecting my j skills for the foreseeable future. J's super optimized algorithms and terse formulaic functional programming is exactly what I was looking for in a programing language.
I came to this realization after I reimplemented the first few problems from projecteuler.net in j.
For more check out the history of APL

Edit. oops, forgot to finish this post. I am now a half year into my j language learnings and have finished the first 17 problems in order at http://projecteuler.net

Go checkout j for yourself. The primer is the fastest way to get competent in j. http://jsoftware.com

Here is a search and replace I put together after talking about examining the efficiency and correctness/completenes/wordiness of the search and replace in the standard library for j. Next step profile this against the standard library verb and actually read through the code and add any missing features.

rep.ijs

NB. rep file contains srep verb

NB. original working concept

; 'xyz'&, each (#'abc')&}. each(('abc' E. 'abcdefabcghi') <;. 1 'abcdefabcghi')

NB. srep verb

srep =: 4 : '; (> {:x)&, each (#>{.x)&}. each ((>{.x) E. y) <;. 1 y'

smoutput 'example usage (''abc'';''xyz'') srep ''abc123abc456'''

smoutput ('abc';'xyz') srep 'abc123abc456'

Your Fancy Language is Burdensome and Dangerous

I found this quote about the PL/I language in Wikipedia to be very poignant today. The quote's sentiment and the PL/I language are from the 1960's.

PL/I is considered by some to be a turning point where it was found that large languages with a lot of complexity that allow programmers to do almost anything (such as coerce types with no semantic relationship to one another) are burdensome and dangerous rather than "more powerful."

It echoes my low opinion of most of the toy languages that seem to be escapees from a Compiler 101 college course masquerading as the cure for the inability of some people to program. I find it to be very relevant to the object oriented mass hysteria and popularity of the latest scripting languages of the moment.

My opinion of C++ with the STL and templates and generic algorithms and iterators and iostreams is lower than my original opinion of C++ before it became standardized. What problem does all that junk solve. More to the point, what problem did object oriented programming ever solve beyond speed to delivery?

Object oriented programming is a morass and a tar pit. It's the all promise and no delivery. It eats up 90% of your programming time forcing you to write witty little programming ditties when you should be writing elegant, concise solutions that aren't 90% object oriented overhead.

Object oriented code hides not only the method invocation but also confuses the issue as to which method is actually called. Multiple inheritance in C++ and other languages demonstrated that the only part of multiple inheritance worth saving in other new object oriented implementations was the interface definition which is basically a template which is basically a macro. It saves you the onerous task of cutting and pasting. In C it's called a macro and it's frowned upon because it obfuscates what the final code does and looks like.

In summary. First write code quickly using only 10% of your programming time. Second scratch head and guesstimate what your code actually does and what are it's unintended consequences. Third hope there aren't any bugs that make your invisible untraceable code do something you didn't intend and use more resources then are necessary to do it.

I'm not saying I don't appreciate Python, Ruby, Perl, C++, Java, and the like. I'm just saying it's not that hard to write the little bit of code it takes to implement most software projects. Especially since the main benefit of most new languages is their extensive built in libraries. Not that you couldn't do the same thing in C by including the proper headers and linking in the proper libraries.

To be brutally honest I think in assembler so even C seems a bit like unnecessary overhead and a bunch of macros hiding the actual code.

I've been reading up on a couple of APL like programming languages J and K but after reading some of the original code for the original J implementation all I see it a bunch of nested for loops creating everything on the stack and avoiding calls to the C standard library to allocate memory.

Now I like APL and I hope to write my own version of it one day because it solves a real programming problem through it's expressiveness. The problem it solves is how to communicate complex and simple vector and matrix operations programmatically to a computer without having to jam a for loop into your equation. The analogy would be the poor man's version tacked on to most of the recent programming languages with list comprehensions and regular expressions. Which are not the same thing.

There are some nice examples of K and J at Wikipedia. I'm not recommending checking out APL as anything other than an educational exercise. I could kick myself for not learning it sooner as it shows how a well thought out programming language was written way back in time that blows the doors off all the fancy flavor of the year languages which waste our time by forcing us programmers to learn an unending stream of new syntax with exceptions that can't even express programming logic as simply and concisely as the A language, APL(A Programming Language) could more than half a century before.