Also, there's the trace facility, for people who want to understand the parsing process.
http://www.jsoftware.com/help/release/trace.htm I suppose it might help to have had some prior exposure to shift reduce parsers ( https://en.wikipedia.org/wiki/Shift-reduce_parser ). But it seems useful to me. Just try not to use names. (You can use names, but you need to understand J's locale facility - for example using fully qualified locale references - with the current implementation of trace.) The dissect facility really does a better job, though, for dealing with understanding how data gets processed in tacit verbs. (The trace facility will only show the process of building that verb - trace shows the execution of that verb as a single step because of how parsing and execution work). Thanks, -- Raul On Mon, Nov 20, 2017 at 4:55 AM, Henry Rich <[email protected]> wrote: > New users who are trying to make sense of lines of J code might benefit from > the tool: > > http://code.jsoftware.com/wiki/Vocabulary/Dissect > > Henry Rich > > On 11/19/2017 7:06 PM, Daniel Lyons wrote: >> >> Andrew, >> >> I've been seriously trying to learn J for the last 6 weeks or so. I am a >> professional programmer, about 13 years in industry, with extensive >> experience in many languages. And I am learning J because I am interested in >> thinking different thoughts. There are a number of ways that programming >> culture could have gone. APL and J represent a different path. Maybe things >> that seem like chronic conditions in the main culture (huge reams of code, >> programming as performance art, faddishness, etc.) may just be symptoms of >> ingrained thoughts unexamined too long. >> >> Six weeks in, I could still give up. It certainly takes more effort to >> learn J. But I kind of consider that a feature. It really is different from >> other things. And I am questioning the basis behind a lot of your comments. >> I got a lot out of this video from the Dyalog conference: >> https://www.youtube.com/watch?v=9xCJ3BCIudI >> <https://www.youtube.com/watch?v=9xCJ3BCIudI> the crux of it being, >> readability is probably the most ill-defined concept in programming. When we >> say Python is readable, we really mean it is familiar. We have the sense >> that we could understand it. But I am not going to understand a complex >> financial, statistical, or scientific calculation in Python or J. The >> trouble I will have understanding what the code is doing doesn't have much >> really to do with the language, though as I'm new to J it will take longer. >> >> To me, J represents thinking about computation at the chemical level >> rather than at the quark level. Yes, there are a lot more elements in the >> periodic table than there are types of quark. But, on the other hand, if you >> have actual things to do, the chemistry might be more applicable than the >> subatomic physics. As a professional programmer, I feel like I spend a lot >> of my time rehashing the same things with small variations. So the emphasis >> on brevity isn't for the sake of laughs here. It's to elevate your thinking >> to a more abstract level. If I'm going to spend another 20–30 years >> programming, spending one year really learning a powerful tool like J >> doesn't seem like a bad investment. It would be weird to take knives away >> from chefs because kids cut themselves when they're beginning. Now to some >> of your specific points. >> >>> On Nov 19, 2017, at 12:15 PM, Andrew Dabrowski <[email protected]> >>> wrote: >>> 3. The heart of the language seems to be in tacit definitions, and >>> explicit ones seem to be just a necessary but ugly kludge >> >> On the other hand, I see a fair amount of non-tacit definitions in source >> code in the addons. I think maybe we bring this to our learning of J because >> we feel like this is the shining core of J, but I'm not sure that's really >> the case. I have made a habit of checking my definitions with 13 : but if >> the result is bigger or has too many [: caps, I keep the explicit form. I >> don't so far have the sense that people are policing the use of explicits. >> >> The only way to get better at reading code is reading more code. You'd be >> surprised how few people actually try it though, preferring only to read >> their own. I get the sense that the APL/J folks do a lot more trading of >> little snippets, and thus, more actual code reading than people who do Java, >> for some whatever reason. >> >>> 4. Therefore the language can really only be used comfortably in domains >>> where functions of arity higher than 2 are rare. >> >> Well, Haskell functions actually only have an arity of 1. If you need more >> than one argument, behind the scenes it desugars a 2-arity function to a >> function returning a function of one argument, and so on. So far, this >> hasn't been a huge problem for me; one of the manuals has some language >> about this. I think the J mentality is "control f data" so many cases where >> you would need a bunch of arguments, you either don't because of adverbs or >> you don't because you can bundle up a bunch of control data into a larger >> package with boxes. But that's my beginner's interpretation of what's going >> on here. Lots of languages have seemingly impossible limitations like this >> yet are able to get real work done. >> >>> 5. The mania for terseness is clearly at clinical levels. The family of >>> circle functions o. is something that seems like a good idea in the shower >>> or the middle of night, but no one would be foolish enough to actually >>> implement it. Except Ken Iverson. >> >> I assume that if you do a lot of trig, it eventually comes in handy to use >> the function numbers to simplify acquiring sine and cosine of a lot of >> things at once, or something. It seems overly clever to me too, but overly >> clever things that survive several decades are probably actually onto >> something, even if it isn't obvious after first contact. ;) >> >>> 6. In the age of unicode, why /not/ use the special symbols from APL? We >>> could use the J expressions to type them, but wouldn't the APL symbols look >>> and read better? As it is J might be said to have the worst of both worlds. >> >> I have given this some thought myself, and I spent a little time learning >> APL as well. My first thought is to agree with you, but in fact most of the >> APL operators are a bit more about convenience in 1960 than mathematical >> purity. There's no particularly obvious mathematical reason for base and >> decode to be T shapes. APL operators have a pleasing regularity because >> inverses are often literally inverted and whatnot, but the actual shapes >> they have are more about how many shapes you could fit on a typeball and be >> distinct after overstriking. So you get kind of a taste of Chinese with >> radicals that are added to different shapes. Well, J has that too, with >> periods usually changing a fundamental operator in a common way and colons >> doing something less common. >> >> I have found using the APL385 unicode font improves readability with J >> somewhat because most fonts try so hard to make punctuation sort of >> invisible. I imagine it just gets easier with time and we're starting out. >> >> I think you could actually go further than APL. In the book _A Programming >> Language_, Iverson describes several notations, including his inner product >> notation, that are not the way APL the language implemented them, probably >> because it's not super-feasible in a linear setting. APL looks cool at first >> blush, but I'm not convinced it's better. J actually improved on APL (IMO) >> by removing the indexing notation so that everything consistently is verbs >> and adverbs, and it actually winds up with a simpler and more consistent >> syntax. >> >>> 10. Maybe beginners aren't the point? Is J really just the Shriners of >>> programming? A bunch of crabby geezers riding around on scooters? I might >>> in fact want to join that, but I did kind of get the impression that you >>> were selling J as a serious programming language. >> >> >> I'm not sure it's necessary for every language to take beginners so >> seriously. After all, you will spend most of your time with a language as an >> intermediate or expert user, and basically every modern language worries a >> lot about beginners. As an expert programmer (at least in some languages) I >> find it kind of alluring that there are a few languages that are intended >> for experts and have left the sharp tools exposed. It has made me want to be >> better at mathematics, even more than Haskell did. I think if you look at >> what's happened in the NodeJS ecosystem, you can see what you get if you >> take a beginners-at-all-costs attitude. Maybe instead of trying to meet >> people where they start at the bottom, we should inspire them to climb up. >> > > > --- > This email has been checked for viruses by AVG. > http://www.avg.com > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
