| > It's the essence of the thing in this case, and isn't a shallow criticism. Listen: I don't think you're qualified to speak to the essence of a thing that you don't understand, and I think you know that. I am telling you this is not very difficult and it is very useful, and I think you're angry at yourself for not "getting it". You are so smart you know ten programming languages, so you assume there's something wrong with "it" because to think there's something wrong with you is unthinkable. Relax. There's nothing wrong with you either. You can learn this, but you aren't going to be able to skim it; the knowledge you have gained learning ten other languages is not going to help you very much. What is going on is stranger than you can realise at this point, so many array-people believe it is easiest if you try to forget everything you know about programming when you try to learn an array language. I don't think I agree with that, but the myth that children learn languages faster than adults is pervasive. Maybe that helps. > Geocar wrote about two pages to explain what is a trivial piece of code, and I still have no idea what it even does or how! Try reading it again! It is not complicated (nor optimal) but you are likely skimming or skipping important parts. If you can tell me where I lost you, I can probably help you find your way. You might find it easier to follow along with a k reference guide. These typically fit on a note-card and can be helpful in memorising the k operators. These are all of the operators in the above program: $[a;b;c] cond (if a then b else c)
@[a;i;f] amend i indices in a with operation f
&x where (are the 1-bits in x)
#x count (the length of x)
*x first (element of X)
x&y min/and
x~y atom-equivalent (like lisp's equalp)
f':x call f with each pair of x
A complete reference card isn't much longer and usually ships with the k interpreter. People learn in different ways, and that's ok! Help me help you learn and you will probably learn this very quickly.> Is it possible to develop an array-based language and use more "normal" syntax? "Array-based" isn't exactly the same thing as an "array" language - I think people get too hung up on the power of vector-operators (which are indeed powerful!) and miss the fact that there are so few operators which to learn. I don't expect you to understand exactly what I mean by that, but I hope that if you take the plunge to learn this properly, you'll remember that I said this and when it does make sense, it will be useful. > Array based languages are the first time I've seen a high-level language that is less readable than the machine code that they are supposed to be abstracting away! You can't read Arabic either, can you? Why do you think this is different? Try to stop thinking in terms of "readable": You can only say something is "readable" to you, or perhaps if you are a hiring manager, "to most people". I can read it perfectly fine. Worrying about how "readable" a programming language at this point speaks only to how easy it is for you to acquire the ability to learn it, not how valuable it will be when you actually learn it. |