5 ms·

> wirth was the greatest remaining apostle of simplicity, correctness, and software built for humans to understand; now only hoare and moore remain… No. There

> wirth was the greatest remaining apostle of simplicity, correctness, and software built for humans to understand; now only hoare and moore remain… No. There is another. https://en.m.wikipedia.org/wiki/Arthur_Whitney_%28computer_scientist%29 https://en.m.wikipedia.org/wiki/Arthur_Whitney_%28computer_s...

vidarh 3y ago
Some would dispute the "built for humans to understand". Whitney's work is brilliant, but it's far less accessible than Wirth's.
- bumbledraven 3y ago
  The point of Whitney's array languages is to allow your solutions to be so small that they fit in your head. Key chunks should even fit on one screen. A few years ago, Whitney reportedly started building an OS using these ideas (https://aplwiki.com/wiki/KOS https://aplwiki.com/wiki/KOS).
  - vidarh 3y ago
    I'm aware of the idea. I'm also aware that I can read and understand a whole lot of pages of code in the amount of time it takes me to decipher a few lines of K for example, and the less dense codes sticks far better in my head. I appreciate brevity, but I feel there's a fundamental disconnect between people who want to carefully read code symbol by symbol, who often seem to love languages like J or K, or at least he better able to fully appreciate them, and people like me who want to skim code and look at the shape of it (literally; I remember code best by its layout and often navigate code by appearance without reading it at all, and so dense dumps of symbols are a nightmare to me) I sometimes think it reflects a difference between people who prefer maths vs languages. I'm not suggesting one is better than the other, but I do believe the former is a smaller group than the latter. For my part I want grammar that makes for a light, casual read, not having to decipher. I want to be able to get a rough understanding with a glance, and gradually fill in details, not read things start to finish (yes, I'm impatient) A favourite example of mije is the infamous J interpreter fragment, where I'd frankly be inclined to prefer a disassembly over the source code. But I also find the ability to sketch out such compact code amazing. I think Wirths designs very much fit in the languages that are skimmable and recognisable by shape and structure category. I can remember parts of several of Wirths students PhD theses from the 1990s by the shape of procedures in their Oberon code to this day. That's not to diminish Whitney's work, and I find that disconnect in how we process code endlessly fascinating, and regularly look at languages in that family because there is absolutely a lot to learn from them, but they fit very different personalities and learning styles.
    - kragen 3y ago
      i keep hoping that one day i'll understand j or k well enough that it won't take me hours to decipher a few lines of it; but today i am less optimistic about this, because earlier tonight, i had a hard time figuring out what these array-oriented lines of code did in order to explain them to someone else textb = 'What hath the Flying Spaghetti Monster wrought?' bits = (right_shift.outer(array([ord(c) for c in textb]), arange(8))).ravel() & 1 and i wrote them myself three months ago, with reasonably descriptive variable names, in a language i know well, with a library i've been using in some form for over 20 years, and their output was displayed immediately below, in https://nbviewer.org/url/canonical.org/~kragen/sw/dev3/random-truncated-correlation.ipynb https://nbviewer.org/url/canonical.org/~kragen/sw/dev3/rando... i had every advantage you could conceivably have! but i still guessed wrong at first and had to correct myself after several seconds of examination i suspect that in j or k this would be something like (,(@textb)*.$i.8)&1 though i don't know the actual symbols. perhaps that additional brevity would have helped. but i suspect that, if anything, it would have made it worse by contrast, i suspect that i would have not had the same trouble with this bits = [(ord(c) >> i) & 1 for c in textb for i in range(8)] however, as with rpn, i suspect that j or k syntax is superior for typing when what you're immediately evaluating expressions rather than writing a program to maintain later, because the amount of finger typing is so much less. but maybe i just have a hard time with point-free style? or maybe, like you say, it's different types of people. or maybe i just haven't spent nearly enough time writing array code during those years
      - vidarh 3y ago
        I think the K would likely be both simpler and harder than your first example by reading very straightforwardly in a single direction but with operators reading like line noise. In your case, my Numpy is rusty, but I think this is the Ruby equivalent of what you were doing? textb = 'What hath the Flying Spaghetti Monster wrought?' p textb.bytes.product((0...8).to_a).map{_1>>_2}.map{_1 & 1} Or with some abominable monkey patching: class Array def outer(r) = product(r.to_a) def right_shift = map{_1>>_2} end p textb.bytes.outer(0...8).right_shift.map{_1 & 1} I think this latter is likely to be a closer match to what you'd expect in an array language in terms of being able to read in a single direction and having a richer set of operations. We could take it one step further and break the built in Array#&: class Array def &(r) = map{_1 & r} end p textb.bytes.outer(0...8).right_shift & 1 Which is to say that I don't think the operator-style line-noise nature of K is what gives it its power. Rather that it has a standard library that is fashioned around this specific set of array operations. With Ruby at least, I think you can bend it towards the same Array nature-ish. E.g. a step up from the above that at least contains the operator overloading and instead coerces into a custom class: textb = 'What hath the Flying Spaghetti Monster wrought?' class Object def k = KArray[*self.to_a] end class String def k = bytes.k end class KArray < Array def outer(r) = product(r.to_a).k def right_shift = map{_1>>_2}.k def &(r) = map{_1 & r}.k end p textb.k.outer(0...8).right_shift & 1 With some care, I think you could probably replicate a fair amount of K's "verbs" and "adverbs" (I so hate their naming) in a way that'd still be very concise but not line-noise concise.
kragen 3y ago
well, simplicity anyway, arguably (like moore) to an even higher degree than wirth

vidarh 3y ago

Some would dispute the "built for humans to understand". Whitney's work is brilliant, but it's far less accessible than Wirth's.

bumbledraven 3y ago
The point of Whitney's array languages is to allow your solutions to be so small that they fit in your head. Key chunks should even fit on one screen. A few years ago, Whitney reportedly started building an OS using these ideas (https://aplwiki.com/wiki/KOS https://aplwiki.com/wiki/KOS).
- vidarh 3y ago
  I'm aware of the idea. I'm also aware that I can read and understand a whole lot of pages of code in the amount of time it takes me to decipher a few lines of K for example, and the less dense codes sticks far better in my head. I appreciate brevity, but I feel there's a fundamental disconnect between people who want to carefully read code symbol by symbol, who often seem to love languages like J or K, or at least he better able to fully appreciate them, and people like me who want to skim code and look at the shape of it (literally; I remember code best by its layout and often navigate code by appearance without reading it at all, and so dense dumps of symbols are a nightmare to me) I sometimes think it reflects a difference between people who prefer maths vs languages. I'm not suggesting one is better than the other, but I do believe the former is a smaller group than the latter. For my part I want grammar that makes for a light, casual read, not having to decipher. I want to be able to get a rough understanding with a glance, and gradually fill in details, not read things start to finish (yes, I'm impatient) A favourite example of mije is the infamous J interpreter fragment, where I'd frankly be inclined to prefer a disassembly over the source code. But I also find the ability to sketch out such compact code amazing. I think Wirths designs very much fit in the languages that are skimmable and recognisable by shape and structure category. I can remember parts of several of Wirths students PhD theses from the 1990s by the shape of procedures in their Oberon code to this day. That's not to diminish Whitney's work, and I find that disconnect in how we process code endlessly fascinating, and regularly look at languages in that family because there is absolutely a lot to learn from them, but they fit very different personalities and learning styles.
  - kragen 3y ago
    i keep hoping that one day i'll understand j or k well enough that it won't take me hours to decipher a few lines of it; but today i am less optimistic about this, because earlier tonight, i had a hard time figuring out what these array-oriented lines of code did in order to explain them to someone else textb = 'What hath the Flying Spaghetti Monster wrought?' bits = (right_shift.outer(array([ord(c) for c in textb]), arange(8))).ravel() & 1 and i wrote them myself three months ago, with reasonably descriptive variable names, in a language i know well, with a library i've been using in some form for over 20 years, and their output was displayed immediately below, in https://nbviewer.org/url/canonical.org/~kragen/sw/dev3/random-truncated-correlation.ipynb https://nbviewer.org/url/canonical.org/~kragen/sw/dev3/rando... i had every advantage you could conceivably have! but i still guessed wrong at first and had to correct myself after several seconds of examination i suspect that in j or k this would be something like (,(@textb)*.$i.8)&1 though i don't know the actual symbols. perhaps that additional brevity would have helped. but i suspect that, if anything, it would have made it worse by contrast, i suspect that i would have not had the same trouble with this bits = [(ord(c) >> i) & 1 for c in textb for i in range(8)] however, as with rpn, i suspect that j or k syntax is superior for typing when what you're immediately evaluating expressions rather than writing a program to maintain later, because the amount of finger typing is so much less. but maybe i just have a hard time with point-free style? or maybe, like you say, it's different types of people. or maybe i just haven't spent nearly enough time writing array code during those years
    - vidarh 3y ago
      I think the K would likely be both simpler and harder than your first example by reading very straightforwardly in a single direction but with operators reading like line noise. In your case, my Numpy is rusty, but I think this is the Ruby equivalent of what you were doing? textb = 'What hath the Flying Spaghetti Monster wrought?' p textb.bytes.product((0...8).to_a).map{_1>>_2}.map{_1 & 1} Or with some abominable monkey patching: class Array def outer(r) = product(r.to_a) def right_shift = map{_1>>_2} end p textb.bytes.outer(0...8).right_shift.map{_1 & 1} I think this latter is likely to be a closer match to what you'd expect in an array language in terms of being able to read in a single direction and having a richer set of operations. We could take it one step further and break the built in Array#&: class Array def &(r) = map{_1 & r} end p textb.bytes.outer(0...8).right_shift & 1 Which is to say that I don't think the operator-style line-noise nature of K is what gives it its power. Rather that it has a standard library that is fashioned around this specific set of array operations. With Ruby at least, I think you can bend it towards the same Array nature-ish. E.g. a step up from the above that at least contains the operator overloading and instead coerces into a custom class: textb = 'What hath the Flying Spaghetti Monster wrought?' class Object def k = KArray[*self.to_a] end class String def k = bytes.k end class KArray < Array def outer(r) = product(r.to_a).k def right_shift = map{_1>>_2}.k def &(r) = map{_1 & r}.k end p textb.k.outer(0...8).right_shift & 1 With some care, I think you could probably replicate a fair amount of K's "verbs" and "adverbs" (I so hate their naming) in a way that'd still be very concise but not line-noise concise.

kragen 3y ago

well, simplicity anyway, arguably (like moore) to an even higher degree than wirth