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

Origins of J

github.com

Post reply on HN
Print view View original

51–60 of 76 posts

Re: Origins of J

#51

Post by anonu »

hackernoteng wrote: post #11

Arthur Whitney is a mad genius. We were an early customer of KX systems and I programmed with KDB for a few years. Arthur Whitney once sat at my desk and helped me debug my code. Very nice guy. Super smart and hilariously knowledgeable about the low level performance of chips, caches, etc. Ask him how many nanoseconds it takes to divide an array of doubles by an array of ints, and he knows. He just knows.

I love kdb but First Derivatives should take it the MongoDb route... Open source it, make it widely available. Build a community around it. Build a package manager. Could be way bigger than it is... But maybe they're happy with their existing business model. I just don't see how you build a moat. Over time new tech will start to takeover as the key innovator is no longer there.

Re: Origins of J

#52

Post by 082349872349872 »

bbwbsb wrote: post #47
tangentstorm wrote: post #40

Nice to see this getting some attention again. I hope some people venture out to learn about the actual J language: https://code.jsoftware.com/wiki/Guides/GettingStarted For what it's worth, I've also studied this code a bit. This repo has an annotated and (somewhat) reformatted version of the code: https://github.com/tangentstorm/j-incunabulum

Since we are on the topic, I've thought about APLs a decent amount so here are some other resources/notes. I'm not an expert on this topic - I don't work with or research the language or anything. These probably are not good getting-started resources. There is a VM model for APL languages[1] which can make optimizations comparable to those made by CLP(FD). If you read about CLP(FD) implementations[2], you'll see oper…

> applies a function to an argument repeatedly until the output stops changing

In other words: instead of worrying about which n to use for "loop n times", it just always loops (effectively) an infinite number of times...

Re: Origins of J

#53

Post by moonchild »

Koshkin wrote: post #50
crabbone wrote: post #43

Earlier quoted context omitted.

I like J. Especially because it has a saner way to write it (it doesn't have to look like as if you accidentally forgot a null terminator in C strings, all the traditionally short identifiers have a long and understandable form). I feel like it's very regrettable that the superficial aspect of J (the very hard to read syntax) is standing in the way of some very nice ideas. To comment on mathematical notation. Before…

I, on the other hand, am dreaming of being able to use mathematical notation in my code. Sort of like what Fortran has helped with, only on a much larger scale.

You would have liked fortress.

Re: Origins of J

#54

Post by kelas »

moonchild wrote: post #38
max_ wrote: post #31

Earlier quoted context omitted.

How do we pick up that writing style.

learn apl (k and j count)

true. only k is faster, easier to learn, and does the trick :)

that said, i hold the view that mastering programming in an ultra-high level language such as APL or k does not absolve a computer programmer from learning lingua franca of our trade, which is due to k&r, will stay around for a very long time, and is called C.

people who don’t know c are ok, only they are not involved in computer programming. their field is known as software development. feel the difference.

i once attempted to convey my own understanding of this divide in a chapter titled “no stinking loops”, which is a nod to Apter’s mandatory nsl.com:

https://github.com/kparc/kcc#no-stinking-loops

Re: Origins of J

#55

Post by mlochbaum »

bbwbsb wrote: post #47
tangentstorm wrote: post #40

Nice to see this getting some attention again. I hope some people venture out to learn about the actual J language: https://code.jsoftware.com/wiki/Guides/GettingStarted For what it's worth, I've also studied this code a bit. This repo has an annotated and (somewhat) reformatted version of the code: https://github.com/tangentstorm/j-incunabulum

Since we are on the topic, I've thought about APLs a decent amount so here are some other resources/notes. I'm not an expert on this topic - I don't work with or research the language or anything. These probably are not good getting-started resources. There is a VM model for APL languages[1] which can make optimizations comparable to those made by CLP(FD). If you read about CLP(FD) implementations[2], you'll see oper…

Here are my two cents on array compilation. I think a lot of the research goes in the direction of immediately fixing types and breaking array operations into scalar components because it's easy to compile, but this ignores some advantages of dynamic typing and immutable arrays. When you can implement most operations with SIMD, a smaller type always means faster code, so dynamic types with overflow checking can be very powerful on code that deals with a lot of small integers.

https://mlochbaum.github.io/BQN/implementation/compile/intro...

I'm somewhat skeptical of the virtual optimizations on indices, "beating" and similar. They sound nice because you get to eliminate some operations completely! But if you end up with non-contiguous indices then you'll pay for it later when you can't do vector loads. Slicing seems fine and is implemented in J and BQN. Virtual subarrays, reverse, and so on could be okay, I don't know. I'm pretty sure virtual transpose is a bad idea and wrote about it here:

https://mlochbaum.github.io/BQN/implementation/primitive/tra...

Re: Origins of J

#56

Post by moonchild »

kelas wrote: post #54
moonchild wrote: post #38

Earlier quoted context omitted.

learn apl (k and j count)

true. only k is faster, easier to learn, and does the trick :) that said, i hold the view that mastering programming in an ultra-high level language such as APL or k does not absolve a computer programmer from learning lingua franca of our trade, which is due to k&r, will stay around for a very long time, and is called C. people who don’t know c are ok, only they are not involved in computer programming. their field…

Regarding k vs j, I will just say that ngn and I both agree that both the k and j array models are far more coherent than bqn. And that k is slow for multidimensional arrays ('mangle your data so it's fast in lists' is a poor response). And leave it at that :)

C is a historical accident. Its existence makes sense in context. Its continued usage only makes sense in context of artificial social factors. There is no reason why we cannot write all software in high-level languages except perhaps when targeting microcontrollers. (For example, there are strategies that can be employed to reduce the rate of memory errors in general-purpose code written in languages without automatic memory management, but there is not much reason to learn these strategies when pretty much the only code that really has to be written without automatic memory management is the memory management code itself, which is hardly 'general purpose'.) The extent to which it makes sense for people to understand the low-level details of the machine is a separate issue I won't express an opinion on here.

Re: Origins of J

#57

Post by moonchild »

mlochbaum wrote: post #55
bbwbsb wrote: post #47

Earlier quoted context omitted.

Since we are on the topic, I've thought about APLs a decent amount so here are some other resources/notes. I'm not an expert on this topic - I don't work with or research the language or anything. These probably are not good getting-started resources. There is a VM model for APL languages[1] which can make optimizations comparable to those made by CLP(FD). If you read about CLP(FD) implementations[2], you'll see oper…

Here are my two cents on array compilation. I think a lot of the research goes in the direction of immediately fixing types and breaking array operations into scalar components because it's easy to compile, but this ignores some advantages of dynamic typing and immutable arrays. When you can implement most operations with SIMD, a smaller type always means faster code, so dynamic types with overflow checking can be ve…

Blind virtual transpose (as seen in numpy) is a bad idea. A principled, locality-aware version would be fine and good.

Re: Origins of J

#58

Post by rpz »

bytelane wrote: post #36
kelas wrote: post #28

Earlier quoted context omitted.

> not obfuscated absolutely not. porting it to ISO C was a very fun and smooth ride, also added two adverbs atw forgot to add in 1989 (see over/scan) and a header file with some handy accesssors (atw usually does that, but he was lazy that day) > to someone fluent in that programming style what people often don’t realize is just how fast one can pick up atwc style, and how hard it is to ever go back :)

> what people often don’t realize is just how fast one can pick up atwc style, and how hard it is to ever go back :) For my own amusement I tried this a couple months ago and I 100% agree. I found my code to be more engaging to develop and understand (function names encoded into 3 chars, structure names encoded into 4 chars, primitive types are a capital letter, etc). It is like a game you play with your brain to rec…

I’m in the same boat. Outside of a professional setting atw style is the only way I write code. I find code easier to manage when I can see more of it at once. I like to use this style in JavaScript as well.

Re: Origins of J

#59

Post by lkuty »

bbwbsb wrote: post #47
tangentstorm wrote: post #40

Nice to see this getting some attention again. I hope some people venture out to learn about the actual J language: https://code.jsoftware.com/wiki/Guides/GettingStarted For what it's worth, I've also studied this code a bit. This repo has an annotated and (somewhat) reformatted version of the code: https://github.com/tangentstorm/j-incunabulum

Since we are on the topic, I've thought about APLs a decent amount so here are some other resources/notes. I'm not an expert on this topic - I don't work with or research the language or anything. These probably are not good getting-started resources. There is a VM model for APL languages[1] which can make optimizations comparable to those made by CLP(FD). If you read about CLP(FD) implementations[2], you'll see oper…

What is reference [9] ?

Re: Origins of J

#60

Post by bbwbsb »

lkuty wrote: post #59
bbwbsb wrote: post #47

Earlier quoted context omitted.

Since we are on the topic, I've thought about APLs a decent amount so here are some other resources/notes. I'm not an expert on this topic - I don't work with or research the language or anything. These probably are not good getting-started resources. There is a VM model for APL languages[1] which can make optimizations comparable to those made by CLP(FD). If you read about CLP(FD) implementations[2], you'll see oper…

What is reference [9] ?

Ah, mea culpa, it is here: https://www.jsoftware.com/books/pdf/calculus.pdf

The preface says:

The scope is broader than is usual in an introduction, embracing not only the differential and integral calculus, but also the difference calculus so useful in approximations, and the partial derivatives and the fractional calculus usually met only in advanced courses. Such breadth is achievable in small compass not only because of the adoption of informality, but also because of the executable notation employed. In particular, the array character of the notation makes possible an elementary treatment of partial derivatives in the manner used in tensor analysis. The text is paced for a reader familiar with polynomials, matrix products, linear functions, and other notions of elementary algebra; nevertheless, full definitions of such matters are also provided.

Post reply on HN