On Sun, Nov 19, 2017 at 5:32 PM, Rob Hodgkinson <[email protected]> wrote: > Enjoyed your comments Daniel, I find them insightful for someone relatively > new to the language. > > Liked your analogy about knives, chefs and kids too ! > > The general observation is to persist (Andrew) as the more you become > familiar with J the more the power dawns on you to the kinds of > possibilities. Most often such power is entwined closely with concepts > around higher level arrays and linear algebra where such language notations > really shine. I have found phrases around shortest path solution and > transitive closure to be incredibly succinctly and elegantly defined in J for > example. > > For more advanced applications in mathematics (like a J tutorial on steroids > focused on very interesting graphics applications) I would also highly > recommend Cliff Reiter’s work on Fractals published in eBook form available > here (and in print from Amazon). > > http://www.lulu.com/au/en/shop/clifford-reiter/fractals-visualization-and-j/ebook/product-17513422.html
Aw man, here I am, happily lurking all these years, and someone actually posts something prodding me into action. While I'm here, what I look for in learning a new language: * Can it be installed reasonably easily? * Can I invoke it more or less using `#!/usr/bin/env <whatever> from a plain jane xterm, and/or is the build system sane? * Is there any sort of automated testing API or library available? I use test automation as personal documentation. While the lack isn't a show stopper (I've written my own simple test harnesses), it's not encouragement. The rest can pretty much ride. I'll crawl back to my cave now. -dave > Thanks, Rob > >> On 20 Nov 2017, at 11:06 am, Daniel Lyons <[email protected]> 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. >> >> -- >> Daniel Lyons >> >> >> >> >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm -- primus inter parse ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
