Hacker News Reader

Comment by theamk | Hacker News Reader

That's a weird argument... passion is not always connected to efficiency/practicality/usefulness, in fact I feel that in a lot of cases it's the opposite.

As a great example, look at old computers: they are pretty popular (there is one link on HN front page right now about N64!) and people are super passionate about it, and yet you would not recommend "everyone to play at least one Nintendo 64 game".

For non-computer examples, somehow a number of my friends are extremely passionate about super hot (as in spicy) sauces. They bring a new bottle for every meal, and they can talk about the kinds of peppers for hours. It's interesting to hear, but I would not want to try them myself, nor would I recommend this to everyone.

View on HN

>spicy

can't resist ...

de gustibus ...

https://en.m.wikipedia.org/wiki/De_gustibus_non_est_disputan...

oops, double pun there ;)

I'm sure people who are into retrocomputing or spicy food or any other topic could tell you why they prefer that to something more mainstream. Whether or not you would agree, you could recognise that they had different opinions. The issue I had with your comment was writing off k as simply an inferior version of numpy etc rather than trying to consider why people like it, and what it may even do better than the mainstream alternatives.

well, the very first message in the thread said:

> Learning array languages makes you a better programmer in any other language. The way you think changes. We are taught to approach a problem procedurally. Actually the for loop is your enemy.

I happen to strongly agree with most of this: learning array-based "operations", writing the code where "the for loop is your enemy" is a very valuable experience, and if will make you a better programmer in any language. Everyone should try writing some code like this.

The problem is K is a mix of three things: array-based operations, point-free style / tacit programming, and extreme brevity via punctuation abuse and lack of types. And not all of them are equally useful.

It's like trying to introduce someone to Chinese cuisine and giving them the spiciest Hunan dish there is. Unless the person already happened to love spicy food, the chances they will just write-off the entire cuisine.

I bet there people today who associate "array programming" with obscure character soup of APL/J/K and ignore it because of that. Who knows, maybe if they knew that numpy/octave offers the same thing in more palatable package, there would be more arrays and less "for" loops in the world.

The original comment said learning "array languages". There's some debate about what that means, but generally it means APL/J/K/etc not numpy/matlab/etc.

As far as I can tell (correct me if I'm wrong) you haven't learned an array language, yet you're telling someone who has (and anyone else who reads your message) not to bother.

To use your food analogy, this is like saying "Don't try real Chinese food in a restaurant, just cook some rice at home. Same thing."

It's not the same thing. The flavour is completely different.

What would you see as the big benefit of array languages over simply array-based programming in other languages? Or in other words, what sorts of things will I learn from trying out J or APL, that I wouldn't learn by playing around with Numpy or Pandas?

In addition to what rak1507 said, knowing what parts you’re composing gives you a more intimate feel for how the pieces fit together. Knowing that you’re building on top of a handful of functions you probably already have some intuition for is quite different from using a library function and simply trusting that the authors have done their due diligence.

It's hard to think of concrete benefits on the spot when the biggest benefit is the somewhat nebulous "feel" of the language. But generally: array languages typically make use of composition of primitives rather than larger, more complicated built in functions. For example in k, there is no 'sort' primitive. Instead of sort, you have grade (<). In APL this is ⍋. In numpy this is np.argsort

This means to sort an array you do x@<x, where @ is apply (indexing - for more info on k's indexing read https://beyondloom.com/blog/slicedice.html)

At first this is a bit counterintuitive. But then you realise, x@<x is sort. y@<x is sort by. <<x is 'rank'. There are all these 'recipes' that are based on <, and some of them you may not discover using numpy, as there would be another function that did it for you. You don't typically solve things by composing simple elements, as that would be far too verbose, instead using complicated built in functions, often with many parameters to describe the desired behaviour.

I'm sure other people will have other opinions on what the benefits are, but that was just one example off the top of my head.

I've read books on APL, J, and K and have played around a bit with all of them for some toy problems. I've also used Python's Numpy & Pandas at work.

The APL/J/K and Python + Library philosophies for programming are super different and if this doesn't make sense to you, I'd recommend downloading Dyalog (it's free to play around with) and go through some tutorials and see if you still feel the same way.

Yes it's all programming like how rice and french fries are both food. They're both awesome too. With Python you have a general purpose language that lets you build up a matrix in a manner you're used to. You've then got an object you call methods on to delete columns or update an entry or whatever. With APL, you've got what is like a hyper optimized DSL for doing that. I'm a lot more proficient with the Python option and it's both popular and free, so it's probably the only option I'll ever have to use at work. Using the APL/J/K options are a ton of fun and I think I could get hyper efficient with them as well given the time. Using the APL is so alien compared to what I'm used to though. The idioms (e.g. ohh you want to do that...just use an outer product which is these two characters combined) are just so different than how I'd typically think about solving the problem (e.g. I'd use a nested couple of for loops or whatever). It really does change the way you think.

Off topic: I work with a lot of extremely large sparse matrices though (like 40,000 x 40,000 with most being 0s), so I'm not sure if APL is as optimized here and as a result it's also easier to stick to Python.

Reply on news.ycombinator.com