This was written by 'RodgerTheGreat, whose comments and submissions on this site are a treasure trove.
Thanks for the tip. Looks like they also have a webcomic: http://beyondloom.com/
Stages of denial in encountering K
181–190 of 432 posts
Re: Stages of denial in encountering K
#182Earlier quoted context omitted.
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.
You've got me wondering about the utility of a genuinely write-only language. As a thought experiment, would there be benefit to letting functions only be written once? No-one could come along and break code by changing a function. If you wanted to fix a bug in a function you would have to write a new copy and explicitly update callers to use the new version. A lot of maintenance overhead? Possibly, but tooling would…
This reminds me of this https://thedailywtf.com/articles/the-inner-json-effect
Re: Stages of denial in encountering K
#183I went through a similar transformation when I finally understood LiSP. I knew Python and had programmed in it for several years but it was breaking into Scheme that changed my approach. I wonder if learning new paradigms always changes how you use other languages.
Re: Stages of denial in encountering K
#184Earlier quoted context omitted.
It's not commonly taught in college. They're probably simpler than your typical for loop.
I’d be quite disappointed in your degree if you were never asked to take a course that was centered around a functional language.
"Write an interpreter for a functional-like language of your choosing with XYZ requirements". In Haskell. As a 1st year uni project. I was just getting over Fortran. And prove it! "Can I do it in Turing please?" "No. Haskell." I still curse that exercise to this day, but it enlightened thinking.
A CS or Maths course should certainly involve some functional language element.
For someone reading thinking of CS at university, whether there's a requirement or option in such would be a good question to ask (you're interviewing them as much as they're interviewing you).
Re: Stages of denial in encountering K
#185If you want to sell me a language
do:
- Explain what particular use cases the language is optimized for
- Show its advantages compared to the alternatives
- Tell me honestly what tasks it is not suited for
do not:
- Use blantant strawmen to make the alternatives look worse.
- Tell me I am an idiot
Re: Stages of denial in encountering K
#186A 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.
It has recently been discovered that human speech has a constant bitrate of 39 bit/second[1]. People speak faster in some languages but convey less information per word, and the converse holds true in languages where people speak slower. In a 'code golf' language where you reduce a 1 million line program to 1000 lines, the 1000 line program is going to be just as hard to read. More concise syntax doesn't help as the…
Claim A: Human speech has a constant bitrate.
Claim B: The intelligibility of a computer program is proportional to its complexity of the problem it solves, not to the number of characters in its source code.
First off, I don't see how B follows from A.
Secondly, even if there does seem to be some similarity, one of the reasons any comparison breaks down is that human languages are evolutionarily adapted to our cognitive capacities, whereas programming languages are designed, for the most part without a very rigorous understanding of how they interact with our cognitive capacities (this is an active area of research, but not very advanced, I think.)
Finally, I reject claim B. The intelligibility of a computer program is heavily affected by how clearly the underlying concepts that define a solution to the given problem are mapped into the structures available in the given programming language, and that is obviously heavily affected by the choice of programming language. And I believe that in general more concise languages are more concise precisely because they make available more and more straight-forward mappings from problem-space to language-structure space. So more concise languages make it possible to write more easily comprehensible programs once you are over the barrier of holding all the mappings they make available in your head.
Re: Stages of denial in encountering K
#187Look, I don't hate K. It's probably a pretty good language for the task it seems to have been designed for, which appears to be numerical computing. Being able to fit an entire code on a screen is an interesting concept; while I'm not completely convinced it should be a goal in and of itself it's certainly something I can't rule out as a possible productivity booster. However, I still find it problematic, and it's no…
I love small languages (lisps, forths, apls) and think that there is much to learn from them, but you need an open mind. You need to start from zero and totally forget your ALGOL-mindset while you are learning the new paradigm.
It's like learning Chinese. Everyone learns it in China, and everyone there will tell you that it's perfectly readable and you don't need to be extraordinarily intelligent to speak it. But if you expect to figure it out based on your knowledge of English, it will be terribly frustrating. This does not mean that German or Dutch (which share roots with English) are better languages, or even easier to learn. Do not expect your Chinese teacher to give you a different answer from "these weird symbols are just what we do; deal with it".
This article is quite good. Clearly the author understand your reservations and he is saying: give it a try and it will click. The learning material might be better, but it's there (start with Iverson and work from that). It's much easier than learning Chinese!
Re: Stages of denial in encountering K
#188Earlier quoted context omitted.
Which part do you not understand? In any case, raya.k is quite splendid. Did you check that one out? It's very clean and quite simple. (I linked to it right below that one.)
literally any of it. I don't know perl but I can read and modify well written perl scripts in a pinch with maybe a little googling. I know several major languages and this program looks like noise to me. is it standard to give functions terrible names? and to not pull out constants to make things understandable? i'm unclear what semi-colons, colons and commas do here or why the lines are so long.
> I know several major languages and this program looks like noise to me.
That's because it is. As pointed out repeatedly, one of the main goals of the program is to minimize the program size, in terms of bytes.
Thus the source code is essentially compressed code and, as we know, compression makes thing more random hence more noise-like.
Re: Stages of denial in encountering K
#189From Arthur: design goal: speed write fast, run fast, modify fast. minimize product of vocabulary and program size. https://a.kx.com/a/k/readme.txt comprehensive programming environments (programming, files, comms, procs, ...) are depressingly complex. commonlisp, c/lib/syscalls, java, winapi are all in the 1000's of entry points. many with multiple complex parameters. with k we try to do more with less in order to w…
The readme examples remind me of Perl code. Example: print !~($/=$")+2*map 1..$s{$_%$'}++,
this reminds me of http://catb.org/jargon/html/T/TECO.html
Re: Stages of denial in encountering K
#190If you want to sell me a language do: - Explain what particular use cases the language is optimized for - Show its advantages compared to the alternatives - Tell me honestly what tasks it is not suited for do not: - Use blantant strawmen to make the alternatives look worse. - Tell me I am an idiot
Ultimately, you’re the one responsible for your opinions about the language, not the author.