Pros / Cons of Implicit Programming in J

Question

As a newbie to J, I often come across unspoken programs that seem pretty Byzantine compared to the more familiar explicit form.

Now, just because I find the interpretation difficult does not mean that the unspoken form is false or false. Very often, the unwritten form is much shorter than the explicit form, and therefore it is easier to visually see everything at once.

A question for experts: do these unwritten forms support a better sense of structure and perhaps repel underlying computing mechanisms? Are there any other benefits?

I hope the answer is yes, and true for some non-trivial examples ...

Answer 1

Typical programming is usually faster and more efficient , because you can tell J exactly what you want to do, instead of finding out how it goes according to your proposal. But, as someone loving the hell out of behind-the-scenes programming, I can also say that “strong” silent programming encourages you to think about things in the way of J.

To spoil the ending and answer your question: yes, silent programming can and conveys information about the structure. Technically, this emphasizes the point above all, but many of the operators that occupy a prominent place in the less trivial expressions you come across ( @: & &. ^: To name a few) have very structure-related meanings.

The canonical example of why it pays to write implicit code is special code for modular exponentiation, as well as the certainty that there are many more shortcuts, such as :

  ts =: 6!:2, 7!: 2@ ] NB. time and space 100 ts '2 (1e6&| @ ^) 8888x' 2.3356e_5 16640 100 ts '1e6 | 2 ^ 8888x' 0.00787232 8.496e6 

Another important thing that you will hear is that when J sees an explicit definition, he must analyze and analyze it every time he applies it:

  NB. use rank 0 to apply the verb a large number of times 100 ts 'i (4 : ''x + y + x * y'')"0 i=.i.100 100' NB. naive 0.0136254 404096 100 ts 'i (+ + *)"0 i=.i.100 100' NB. tacit 0.00271868 265728 NB. J is spending the time difference reinterpreting the definition each time 100 ts 'i (4 : ''x (+ + *) y'')"0 i=.i.100 100' 0.0136336 273024 

But both of these reasons make us think that J has a very clear style of problem solving . Not if ^: exists. There is no loop, there is a rank. Similarly, Ken saw the beauty in that in the calculus f + g was the pointwise sum of functions - indeed, f + g defines a function where (f + g) (x) = f (x) + g (x) - and since J already been so good at point-by-point adding of an array, why stop there?

Just like a language like Haskell, revels in the pleasure of combining higher-order functions rather than “manually”, synchronizing them to the end, just like J. Semantically, take a look at the following examples:

• h =: 3 : '(fy) + g y' - h is a function that captures its argument y , inserts it into f and g and inserts the results into the sum.
• h =: f + g - h is the sum of the functions f and g .
• (A < B) +. (A = B) (A < B) +. (A = B) - "A is less than B or equal to B".
• A (< +. =) B - "A is less than or equal to B".

This is much more algebraic. And while I talked about trains; There is much to say about the convenience of tools like ^: or &. . The lesson is clear enough: J wants it to be easy to talk about your functions algebraically. If you had to wrap all your actions in 3 :'' or 4 :'' - or, even worse, name them in a separate line! - every time you would like to apply them interestingly (for example, via / or ^: or ;. ), You will probably be very disconnected from J.

Of course, I admit that it will be difficult for you to find examples as elegant as your expressions, more complex. The typical style is just getting used to. The wokab should be familiar (if not second nature) to you, and even then you sometimes enjoy slipping code that is simply unforgivable. This can happen with any language.

Answer 2

Not an expert, but the biggest positive aspects of coding are silent for me: 1) that it makes it a little easier to write programs that write programs, and 2) it is a little easier for me to understand the J-way (which is a big part of why I like programming with J) . The explicit expression is more like procedural programming, especially if I use control words such as if. , while. or select. .

The problems are that 1) explicit code sometimes works faster than silent code, but it depends on the task and algorithm, and 2) silent code is interpreted as it is analyzed, which means that there are times when explicit code is clean because you can leave code waiting for values ​​of variables that are defined only at runtime.