Earlier quoted context omitted.
That objection seems trivial.
The whole article is trivial and trite, yet dressed up as something novel.
I don't think so. Even if that's true though, you could do better.
Stages of denial in encountering K
121–130 of 432 posts
Re: Stages of denial in encountering K
#122A million-line program isn't readable by anybody, no matter how readable the language is. If the equivalent program can be written in, say, a thousand lines in some more concise language, that's more than worth the learning curve, even if the language is strange and off-putting.
That depends. When my assumptions about the underlying problem are wrong a million line program is much easier to fix than a thousand line one. Or rather, a thousand line concise program in a quirky language will become a million line program in a quirky language when exposed to changing business requirements.
If the language allows you to simplify the program sufficiently it might be easier to just rewrite it from scratch when the requirements change. I doubt that this is the case for any language, but you know, in principle it could happen.
Re: Stages of denial in encountering K
#123Some people find entertaining from these extremely compact syntax languages. I have hard time to understand them, but such is life.
Regular expressions are a more concise way of writing string matching and extraction code, often exponentially more efficiently than without. They’re also usually more compact than spoken English can represent. For example, this proofreading regex detects possible issues in spelling:
/(?<!c)i(?=e)/
Re: Stages of denial in encountering K
#124A million-line program isn't readable by anybody, no matter how readable the language is. If the equivalent program can be written in, say, a thousand lines in some more concise language, that's more than worth the learning curve, even if the language is strange and off-putting.
[deleted]
Re: Stages of denial in encountering K
#125A million-line program isn't readable by anybody, no matter how readable the language is. If the equivalent program can be written in, say, a thousand lines in some more concise language, that's more than worth the learning curve, even if the language is strange and off-putting.
Only if it's written in a style which affords reading. K programmers seem to want to write their code in a mathematical style, but without the natural language prose which makes mathematical papers readable. In a paper by a mature mathematician, the equations only perform some of the work in expressing the idea. The rest of the work is done by prose written with an intent to be lucidly expository, to allow the notation to be terse because the high-level concepts are being expressed in a natural language.
We have this style in the programming world. It's called Literate Programming. How many K programmers write in that style?
Re: Stages of denial in encountering K
#126People are so quick to reject K and APL-style languages for superficial reasons that they never get to the deep and interesting reasons! I am mostly familiar with APL, but I think the things I appreciate and dislike are about the same in K.
One interesting philosophical difference, at least among some APL programmers, is that building abstractions should be avoided. TFA has a hint of that philosophy, in its suggestion that perhaps naming (the root of abstraction) hinders clarity. I think this is definitely worth considering, and it doesn't really have anything to do with the (supposedly) cryptic syntax.
One reason I don't like K/APL-ish vector programming is performance. I once spent some time working with others on a GPU-targeting APL compiler, and I found that some common programming patterns are quite antithetical to good performance. In particular, the use of "nested arrays" (not the same as multidimensional arrays) induces pointer structures that are difficult to do anything with. Such nested arrays are typically necessary when you want to do the equivalent of a "map" operation that does not apply to each of the scalars at the bottom, but perhaps merely the rows of a matrix. Thus, control flow and data are conflated. This is fine conceptually, but makes it difficult to generate high-performance code.
Another concern is that encoding control flow as data requires a lot of memory traffic (unless you have a Sufficiently Smart Compiler; much smarter than I have ever seen). Consider computing the Mandelbrot set, which is essentially a 'while' for each of a bunch of points. An idiomatic APL implementation will often put the while loop on the outside of the loop over the point array, which means it will be written to memory for every iteration. In other languages, it would be more idiomatic to apply the 'while' loop to each point individually, which will then be able to run entirely in registers. You can also do that in APL, but it is normally not idiomatic (and sometimes awkward) to apply complex scalar functions to array elements.
Just look at this Mandelbrot implementation from Dyalog; they do it in exactly the way I described: https://www.dyalog.com/blog/2014/08/isolated-mandelbrot-set-...
Specifically, the conceptual 'while' loop has been turned into an outer 'for' loop (this is OK because the 'while' loop is always bounded anyway):
:For cnt :In 1↓⍳256 ⍝ loop up to 255 times (the size of our color palette)
escaped←4Re: Stages of denial in encountering K
#127Earlier quoted context omitted.
This is what - I presume - is their implementation of sending an e-mail E:[u:();e:{a::?[a;x;y];J( x)+#y};cz:{$[#u;e/_`u;]};kx:{u,:,(j,j+#x; k_a);e[k]x};kb:{$[=/k;J j-1 0;];kx""};cx:{kx cc`};cv:{kx@9'`}] A:[w::_W%F;j:: k;k:0 0;J:{k::2#0|x&#a};lx:{J j+x};y::V+F 0,j;z::1'(V;w[1]$a)],E U:{(`Z,'!Z).'+x};V:0;i:0;I::`Z,(!Z)(#Z)!i;y:{I .`y};zf:{$[`kt= x;i+:1;^`W`F? x;I . x;. x]};u::F[0] !#Z;W:{U`V,,u,'0;U`W,,(-':1_u, x),'x 1…
A bit more convincing: http://www.kparc.com/edit.k Properly formatted and with comments, it almost looks readable. The insistence to use one- or two-letter identifiers that you then have to look up the meaning of in a comment makes it look pretty childish, though. "Look ma, it's still super terse even when doing something real!" Yes kid, it is when you refuse to do the one obvious thing that could actually make it re…
Single-letter identifiers are a natural thing to object to when coming from other language paradigms, i.e. nearly every programming background out there, but this is a category error. What seems ridiculous in one context can be sensible in another. The objection turns out to be parochial.
It reminds me of how people think that parentheses are a significant aspect of Lisp, when in practice they're not. The parens look grotesque at first, but once past the novice stage they fade completely into the background and impose no cognitive overhead. Because of their regularity, the parens free you to program without thinking about syntax, allowing you to think more about the problem at hand—a highly liberating experience—yet to someone who hasn't worked with the language long enough to get that experience into muscle memory, they look absurd.
Short identifiers are preferred in APL-style languages because longer ones obscure the code. As you get familiar with the idioms of the language, you can pick them out in visual chunks to grok what a program is doing. You're not reading the program operator-by-operator, but phrase-by-phrase.
That wouldn't work if the programs used longer identifiers, because then the programs would consist mostly of identifiers, making it harder to scan the phrases, making it harder to grok the code. That's why people don't do it. You can simulate that in more familiar languages:
for (ridiculously_long_name = 0; ridiculously_long_name In other words, the reason why APL-style programs adopt this style is not because the programmers are childish, but because the ergonomics of the language make it optimal. This is hard to understand, but only because mainstream languages have completely different ergonomics.
Re: Stages of denial in encountering K
#128Earlier quoted context omitted.
Boilerplate can be stripped away, though, while you can't pull meaning out of a symbol without knowing what the symbol is .
Sure you can — from repeated usage of said symbol in context. That’s how language acquisition works in toddlers. Not saying that it’s a preferred way, though.
Chomsky has an idea called "The poverty of the stimulus", where he attempts to prove his ideas about deep syntax (or whatever he calls it) by handwaving that toddlers can't possibly learn language by merely being immersed in it for a few years.
I'm not impressed with the notion as applied to toddlers, but I think it applies fairly well to learning what variables mean in a codebase. Especially one written to be terser-than-terse.
Re: Stages of denial in encountering K
#129Earlier quoted context omitted.
That depends. When my assumptions about the underlying problem are wrong a million line program is much easier to fix than a thousand line one. Or rather, a thousand line concise program in a quirky language will become a million line program in a quirky language when exposed to changing business requirements.
If the language allows you to simplify the program sufficiently it might be easier to just rewrite it from scratch when the requirements change. I doubt that this is the case for any language, but you know, in principle it could happen.
https://en.wikipedia.org/wiki/Write-only_language
>Languages that are often derided as write-only include APL, Dynamic debugging technique (DDT), Perl,[2] Forth, Text Editor and Corrector (TECO),[3] Mathematica, IGOR Pro and regular expression syntax used in various languages.
Re: Stages of denial in encountering K
#130A million-line program isn't readable by anybody, no matter how readable the language is. If the equivalent program can be written in, say, a thousand lines in some more concise language, that's more than worth the learning curve, even if the language is strange and off-putting.
Only if it's written in a style which affords reading. K programmers seem to want to write their code in a mathematical style, but without the natural language prose which makes mathematical papers readable. In a paper by a mature mathematician, the equations only perform some of the work in expressing the idea. The rest of the work is done by prose written with an intent to be lucidly expository, to allow the notati…
[deleted]