Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A look at the J language: the fine line between genius and insanity (2012)

scottlocklin.wordpress.com

Post reply on HN
Print view View original

51–60 of 70 posts

Re: A look at the J language: the fine line between genius and insanity (2012)

#51

Post by dTal »

Verdex wrote: post #16
Cactus2018 wrote: post #13

Earlier quoted context omitted.

> Here's a video that really illustrates the power of this paradigm: https://www.youtube.com/watch?v=a9xAKttWgP4 Amazing game of life code!

The first time I watched the video my response was that he was literally doing magic or that it was some sort of joke. Over time the video has become more approachable and I have a pretty good idea of what is going on. However, if I was asked to approach game of life in APL myself then I think I would still be pretty lost.

It's a kind of sleight of hand. It purports to be showing off the power of APL; what it's really showing off is the cleverness of someone who realized that the rules of Life could be expressed as a series of array operations.

APL has a kind of mystique, but all it really is is a bunch of NumPy functions with a quirky DSL (of course, APL came first and heavily inspired NumPy). But we've quietly been doing the APL experiment in the background, by pressuring programmers to avoid pure Python in favor of NumPy functions for speed, and the results are in - you can indeed push the array paradigm very far. But not quite far enough to be general and efficient.

The jury is still out on whether the quirky DSL is worth anything. My suspicion is that having names for array operators is very valuable indeed, but dedicated symbols for them much less so, and cryptic ASCII digraphs are barking completely up the wrong tree. But if you really want the weird syntax - well, it's not exactly a difficult language to parse, and Unicode is a thing now. If the notation is worthwhile, there's no real reason why any language couldn't have APL built-in as a DSL, just like regex.

Re: A look at the J language: the fine line between genius and insanity (2012)

#52

Post by dTal »

p1esk wrote: post #43
marmaduke wrote: post #42

Earlier quoted context omitted.

I started with Lush a long time ago before being obliged to switch to MATLAB and then C. Recently I have been trying to learn Futhark which is a ML like language generating parallel code (E.g. OpenCL or CUDA) from pure functional code with nested array structures. I find this exciting because when using the GPU with a thin layer like OpenCL directly, you have to write kernels from scratch without much abstraction pos…

If your primary interest is in parallel code that runs on a GPU, and not autograd features of Pytorch/Jax, take a look at CuPy: https://cupy.dev/

That's extremely cool. Julia has something very similar, in the form of CuArrays [0].

I do wish we had some better cross-platform solutions though, instead of cementing nVidia's hegemony. There's no technical reason why GPGPU should be any more difficult on AMD hardware.

[0] https://github.com/JuliaGPU/CuArrays.jl

Re: A look at the J language: the fine line between genius and insanity (2012)

#53

Post by Jtsummers »

gmfawcett wrote: post #40
Jtsummers wrote: post #37

Earlier quoted context omitted.

I've been experimenting with flashcards that prompt me to write or solve some problem, versus the more common memorization usage. Not necessarily solving the same problem (write FizzBuzz in SomeLang) but maybe more complex (select a public web API with a JSON source, get the data, process it, and make a simple report). A way to reinforce understanding of different libraries or tools. I haven't figured out the schedul…

Good luck, I hope it works! Consider adding some flash cards with grammatical forms to mix in with your "character" cards. e.g. a monadic hook "(f g) y" is equivalent to "y f g y". And some short idiomatic phrases, e.g. "(#~ f) y" means -- approximately! -- "copy the values y_i of y wherever (f y_i) is true." You can find examples of these little phrases on the J wiki.

Thanks. It's still an experiment, and about to be restarted (was going to be learning modern C++ and some APIs for work, but direction shifted and I'm now on a Java project, which I haven't used in a long time). I'd actually like to try this for J, but work and Spanish (to speak with the in-laws) are my personal priorities right now. Perhaps in October I'll start studying J to use for this next Advent of Code. I have been getting the itch to relearn it. I learned a large chunk of it circa 2010, but haven't touched it since, then APL in 2015 or 2016. I've never used either professionally or for a major project so a lot of things have been forgotten.

I'm basing my experiment on what I learned using Anki for language learning. Much like you said, you need larger statements and to develop an understanding of them. For Spanish I have some loose writing/speaking prompts and some reading prompts (not copying the text, but a prompt to go to today's newspapers and read some articles and explain them to my wife or to read some paragraphs from a book). How well I can complete these without needing a dictionary or to ask for assistance determines how I mark the cards. It seems to work decently, they come up almost like pop quizzes in school classes since the spaced repetition system means I don't see the same prompts each day. I think it should work to have project prompts for programming languages in the same manner.

Re: A look at the J language: the fine line between genius and insanity (2012)

#54

Post by mdaniel »

RyanHamilton wrote: post #38

Some of these languages are an excellent fit for specific problems. I still think an array based language is best for sql queries rather than set based. Any time you hear something like "select the first....", you don't want a set, you want an ordered list. Plug: I wrote an open source version of q/kdb that runs on the JVM: https://github.com/timestored/jq You can give it a try online in the browser here: http://www.…

It appears you forgot some references to your home directory in the code: https://github.com/timestored/jq/blob/1f4de6def8b7c12c6d6254...

Also, Java's "File" object is -- for the most part -- by its nature cross-platform, which is why the forward-slash version right below your change already worked as expected: https://github.com/timestored/jq/commit/4b94ce214452cf2b2fb8...

Re: A look at the J language: the fine line between genius and insanity (2012)

#55

Post by eigenspace »

dTal wrote: post #52
p1esk wrote: post #43

Earlier quoted context omitted.

If your primary interest is in parallel code that runs on a GPU, and not autograd features of Pytorch/Jax, take a look at CuPy: https://cupy.dev/

That's extremely cool. Julia has something very similar, in the form of CuArrays [0]. I do wish we had some better cross-platform solutions though, instead of cementing nVidia's hegemony. There's no technical reason why GPGPU should be any more difficult on AMD hardware. [0] https://github.com/JuliaGPU/CuArrays.jl

> I do wish we had some better cross-platform solutions though, instead of cementing nVidia's hegemony. There's no technical reason why GPGPU should be any more difficult on AMD hardware.

Then look no further than GPUCompiler.jl. Tim factored out all the platform agnostic parts of CUDA.jl (successor of CuArrays.jl and CudaNative.jl) into GPUCompiler.jl and that is now being used by the AMDGPU.jl package. It works today!

Re: A look at the J language: the fine line between genius and insanity (2012)

#56

Post by the_optimist »

scottlocklin wrote: post #4

The TSDB is now called 'jd'[0] FWIIW. Funny, I've been using J on and off since then and I'm still not sure if it's genius or insane. It, along with the other APLs, is definitely its own thing, just as much as Lisp is (my previous favorite weird language was Yann LeCun and Leon Bottou's "Lush,"[1] which I continue to think is an amazing design). Once you get a little bit proficient at it, you finally realize what an…

Monument has had great experiences with J. It is fast, runs everywhere, and it is great for data handling and algorithmic dev.

Monument runs on an extended version of J that is implicitly parallel, which enables devs to focus on math rather than optimizing C code.

Re: A look at the J language: the fine line between genius and insanity (2012)

#57

Post by haolez »

My intuition for array-based languages is that you can use the "obscure" code, which heavily uses the standard vocabulary, for the low-level details of the business logic, but that you would still maintain a set of high-level verbs (DSL?) to describe in more clear terms what the hell the code is doing.

However, the few real world projects that I've seen in these languages won't use any kind of DSLs and the argument usually is "for array-based language programmers, this is actually very clear and concise". I need to improve my J to verify that :)

Re: A look at the J language: the fine line between genius and insanity (2012)

#58

Post by dTal »

eigenspace wrote: post #55
dTal wrote: post #52

Earlier quoted context omitted.

That's extremely cool. Julia has something very similar, in the form of CuArrays [0]. I do wish we had some better cross-platform solutions though, instead of cementing nVidia's hegemony. There's no technical reason why GPGPU should be any more difficult on AMD hardware. [0] https://github.com/JuliaGPU/CuArrays.jl

> I do wish we had some better cross-platform solutions though, instead of cementing nVidia's hegemony. There's no technical reason why GPGPU should be any more difficult on AMD hardware. Then look no further than GPUCompiler.jl. Tim factored out all the platform agnostic parts of CUDA.jl (successor of CuArrays.jl and CudaNative.jl) into GPUCompiler.jl and that is now being used by the AMDGPU.jl package. It works tod…

Thanks! I had hit some of those pages before, but their ontology isn't immediately obvious, so thanks for the clarification. In particular I've definitely looked at AMDGPU.jl recently, but as the page says: "not all features (and especially performance) are up to par with CUDA.jl" - hence my impression of AMD being a second-class citizen. Still, it's great that we have anything at all, and I'm extremely grateful for the hard work of those in the Julia community. It's a remarkable achievement.

Re: A look at the J language: the fine line between genius and insanity (2012)

#59

Post by lmm »

dTal wrote: post #51
Verdex wrote: post #16

Earlier quoted context omitted.

The first time I watched the video my response was that he was literally doing magic or that it was some sort of joke. Over time the video has become more approachable and I have a pretty good idea of what is going on. However, if I was asked to approach game of life in APL myself then I think I would still be pretty lost.

It's a kind of sleight of hand. It purports to be showing off the power of APL; what it's really showing off is the cleverness of someone who realized that the rules of Life could be expressed as a series of array operations. APL has a kind of mystique, but all it really is is a bunch of NumPy functions with a quirky DSL (of course, APL came first and heavily inspired NumPy). But we've quietly been doing the APL expe…

Rank polymorphism is genuinely important and useful and a lot of languages are missing it.

Cryptic symbols, I agree, less so. If your language doesn't arbitrarily restrict identifiers then you can just define the APL operators as functions and write code that looks like APL - I tried doing this in Scala once, and it worked ok. But it's hard enough to convince people to take the time to learn what "map" or "filter" or "<* " does, never mind anything further in that direction.

Re: A look at the J language: the fine line between genius and insanity (2012)

#60

Post by smabie »

If someone is interested in array languages, I would start with learning q, then k, J, and finally APL. q and k are much more conventional and less complicated than J/APL. They also tend to be more practical, and less mathematical. They also don't have multi-dimensional arrays, so the code tends to be both less general and less confusing. Once you've gotten familiar with them, J and APL won't seem as weird.

Moreover, it's entirely possible to write regular procedural code in q and k, so it's easier to transition to the array language mindset.

Post reply on HN