Hacker News new | ask | show | jobs
by beagle3 4665 days ago
I can understand the sentiment, and the only thing I can say is:

There's a learning curve; it's steep, but it is well worth it - much like Math notation (give me "x^n" any day over "repeat multiplying x by itself n times") or Music notation, once you're used to it, any notation that is less concise seems arbitrarily and needlessly verbose.

(That's actually a reason not to learn K / APL: When you actually grok it, it's hard to take modern software engineering seriously. A reason to grok them is that -- for some problems -- you're going to become much more productive).

1 comments

Well, after writing my comment, I went online looking for some quick introduction to the language. I'll admit that there are certainly very interesting facets to that language.

What I can say however is that there's a difference between conciseness in writing and productivity in reading.

For instance,

    (!R)@&{&/x!/:2_!x}'!R
It's very concise but very hard to grasp quickly. The equivalent, in even 10 lines of code, might be way easier /and/ faster to read and understand.

That being said, I really like the functional aspect of it where most of common operations on list were shortened. (I.e. map, reduce, etc.)

Personally, I think the Arc language strikes a really fine balance of verbose versus concise. It's just unfortunate that there's not a more active community and that it lacks the battery to be productive with it.

My understanding of the idea behind most APL style languages is that it's an expert language, in that you need to take the time to invest in it just like a musician would musical notation.

Once you've done that, the theory is that it is actually quicker and easier to grasp than reading "verbose" lines of code.

That said, I've never taken the time to invest in an APL style language, so I can't speak to whether it is actually true or not.

Makes sense. If you spend enough time it can become second nature, like musical sheets. Still, I find that musical notations is way more limited, so it makes sense to have it concise. But let say people were naming some parts of the songs, and referring to it, and you had to jump and "get into the mind" of the person who wrote it.. than maybe it'd be a different story and more verbosity would be better.
APL/J/K code is really like mathematics, something that most programmers aren’t exposed to in the slightest. If you don’t grok it immediately, then you can actually just sit down and equationally work out the author’s exact thinking, in precise terms—and you level up as a side effect, so you don’t need to work out the same patterns every time you see them. That’s nigh impossible in C++!

Take it from someone who has seen both sides: the concision is a good, good thing.