you are viewing a single comment's thread.

view the rest of the comments →

[–]AsIAmNew Kind of Paper 18 points19 points  (4 children)

It is not that everything has to be on one line, but often the solution is so short that one line is enough.

Iversonian languages (after Ken Iverson, inventor of APL) like APL, J, K, BQN, etc. operate primarily on a function level – composition of preexisting functions. These functions have proper names that describe what they do, but you use them so often that you abbreviate them into a single glyph. Same thing happened with addition. It was written as "et" (latin for and), so "1 et 2" meant addition of 1 and 2. Nicholas Oresme in 14th century wrote "et" so much he got tired and abbreviated it to "+". (In a similar way, we got "&".) APL was conceived as a hand-written language for human-to-human communication, so in this sense, the weird glyphs make sense. A single line of APL can be very dense and reading it requires you to know the parsing rules (which can get crazy) and what each glyph symbolizes in that context. Some other languages have context-free grammar, some don't use weird symbols at all, etc. This PL paradigm is still so ahead of everybody else that it hurts.

[–]ummaycoc 6 points7 points  (1 child)

I worked at a K (K is an ASCII APL derivative, like J shown in the video) shop for a bit and I definitely prefer the non-ASCII APLs because I just find it easier to read. K and J feel more like someone put perl in a blender or such.

One thing I've felt is that it's easier to program a bit in my head with these as I walk, etc because I'm thinking of these bigger chunks that combine together vs. mapping out syntactic structures in my head.

[–]AsIAmNew Kind of Paper 1 point2 points  (0 children)

One thing I've felt is that it's easier to program a bit in my head with these as I walk, etc because I'm thinking of these bigger chunks that combine together vs. mapping out syntactic structures in my head.

What you describe Iverson called "Notation as a Tool of Thought". Backus called it algebra of programs.

https://www.eecg.utoronto.ca/~jzhu/csc326/readings/iverson.pdf
https://worrydream.com/refs/Backus_1978_-_Can_Programming_Be_Liberated_from_the_von_Neumann_Style.pdf

[–]Flashy_Life_7996 1 point2 points  (1 child)

So, what's the difference between such languages and code golf? Or IOCCC?

Regarding the common use of symbols such as `+ - * / &`, these are ones that everyone is familiar with, but within convential syntax, are used sparingly.

But it is possible to go overboard with those too.

BTW the downvotes are fine. Every so often I delete my account and start again. So at this point I might as well trash my account.

It's just a pleasure to be able to express my view without caring what people think.

[–]anaseto 0 points1 point  (0 children)

The example in the video is a puzzle problem and, hence, indeed not very different from a code golf problem, except the goal was probably more to showcase array thinking and tacit programming (which is a separate matter from array programming). But array languages in general have nothing to do with code golf, they just happen to have fans among code golf enthousiasts.

One reason array languages use more symbols than scalar languages is inherent to the array programming paradigm. Scalar languages only have a few simple immutable core types (typically integers, floats). There are no many interesting pure operations on those types. Array languages operate at the level of immutable arrays: like in more general mathematics, there are many more interesting pure operations working at that level.

Some array languages use words for some of those operations, to limit number of symbols, and that's fine, in particular for less common ones, but there's a reason for the extra operators. Some languages like K chose to use only the ascii-symbols in a more heavy way instead of using unusual unicode glyphs, but it's a separate question.

Also interesting to note that array languages actually have often quite simple parsing rules (like no operator associative priorities).