[beagle3]

It's a nice idea, but the run-length example is kind-of-misguided, even though that's how everyone would implement it on first try.

A language should push you towards a more robust/faster/simpler solution by making it the simple, elegant thing to do. In K, a run length encoder would be something like:

    {(x@&~m),'(+/m)@&~m:~':x}

Which looks like line noise, but basically encodes the following operations:

x is the input

m gets 1 where a position in x is the same as the previous position, 0 where it isn't. (apply ': "each-pair" to ~ "match")

Then take the sum of match (+/m) at where (@&) there is no match (~m).

Finally, add that to x where there is no match (x@&~m, literally, "x at where no m"), and zip it (,' meaning concat each). And the curly brances make it into a function of x.

Now, I understand most people would think that this is unreasonable. However, in K it is easier to produce a vectorized solution than an itertive one - and as an added bonus, the bugs tend to be either of the "wrong spec" or the "off by one" error, eliminating whole classes of potential bugs.

And .. the result is usually quick, thanks to vectorizing (and can go on a GPU easily).

A language that promotes item-at-a-time processing is missing a lot.

[daivd]

I do like an expressive high-level encoding like that, but 1) I just needed a silly example to show what pipes are. In practice you would probably use higher-order library functions (or components) like group for the same thing. 2) In my experience, very compressed expressions can be hard to modify in certain directions. Practical stuff like printing, logging or storing progress every X seconds, which is a small modification in a for-loop, can be a hassle.

[jacquesm]

Does K have any APL roots by chance?

edit: ignore the question, yes it does:

http://en.wikipedia.org/wiki/K_%28programming_language%29

[d0m]

As intriguing as it looks, I certainly wouldn't want to look at that kind of code all they long.

[beagle3]

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).

[d0m]

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.

[ajanuary]

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.

[d0m]

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.

[evincarofautumn]

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.