6 ms·

Introduction to the Quorum Programming Language and Evidence-Oriented Programming

60 points by edtechdev 11y ago

ealexhudson 11y ago
"Perl, despite the fact that it was a very popular programming language [..] was apparently not detectably easier to use for novices than a language that my student [..] created by essentially rolling dice and picking (ridiculous) symbols at random. That result was astonishing" This sound-bite needs no comment. I do like Perl.
- jasonjayr 11y ago
  To be fair, from a few lines down .... "Interestingly, in this new study, the same result we saw with Perl we also observed with Java, a programming language so popular it is used in the Computer Science A – AP test in high school. Ultimately, using a technique we call Token Accuracy Mapping, which is basically a way to figure out which tokens may have caused the problems, it appeared that C-style syntax was plausibly the culprit."
  - moron4hire 11y ago
    If you read on to the language page, they apparently mean tokens and not syntax. They have retained C/C++/Java style syntax, only having renamed some of the keywords and delimiters.
    - edtechdev 11y ago
      Read further down, and the C-style syntax (curly braces, etc.) was a cause for problems: "Ultimately, using a technique we call Token Accuracy Mapping, which is basically a way to figure out which tokens may have caused the problems, it appeared that C-style syntax was plausibly the culprit."
      - moron4hire 11y ago
        That's my point. They don't seem to have gone any deeper than surface syntax. They renamed "while" to "repeat", but is a while-loop-by-any-other-name even the best looping construct in the given scenario?
        jack9 11y ago
        Quorum is only about syntactical optimization. The reasoning for specific implementation is beyond the scope of the "simple" problem they are trying to study.
        nickpsecurity 11y ago
        You again. You never answered my question... https://news.ycombinator.com/item?id=10775054 https://news.ycombinator.com/item?id=10775054 ...about why you believed the items on my list didn't constitute scientific evidence. Hypothesis, analysis, verification by experimental practice, matched predictions, replication via re-application by diverse crowds, and delivering results. All sounds like scientific method to me. Many studies in academic and industry with these properties over the years. If you reject all of that, I'd like to see what your version of the scientific method is as it's different than what most fields of study are using. I still contend that my numbered list represents scientific evidence in favor of whatever those methods were applied to. In that case, there's scientific evidence for everything I recommended with varying strength.
        jack9 11y ago
        > You again. You never answered my question... I didn't read it. > The proof is in the literature I'm referencing rather than me dumping all of it in the comment box You never cited anything. Most importantly, some of the enumerated "points"? that you espoused are methodology Quorum uses. I'm sure you can help them out, if this subject is of interest to you.
        nickpsecurity 11y ago
    - nickpsecurity 11y ago
      I would've started testing BASIC and Pascal style syntax as they were specifically designed for ease of use and implementation. Would be a nice test to see how wise or arbitrary various parts were.
  - nickpsecurity 11y ago
    They'd have figured that out just looking at the history of C: http://pastebin.com/UAQaWuWG http://pastebin.com/UAQaWuWG It started with a knockoff of ALGOL60 called CPL. That's already pretty arbitrary and subject to thinking of 1960's. That basically pre-dates modern software development or involvement of laypeople. They couldn't compile it so they just eliminated features until it could compile. Result, very simplistic, was BCPL. That was slightly modified & extended into C also due to hardware constraints. So, it literally has no justification as a programming language. Almost totally a result of terrible hardware that persisted for legacy/social reasons. A little research might have saved them time and money. ;)
moron4hire 11y ago
This is a negative review. I don't generally like bagging on peoples' projects, but this is an important subject and I feel it has been significantly failed. Their hearts are in the right place, but I think they've failed by even their own metrics. I was very curious to read this topic because I firmly believe we need to do much, much more work to make the full range of computing more accessible for people with disabilities. It's not just about equity--though that should be reason enough--but that systems designed for systemic handicap are also useful for situational handicap. I work from home and have a brand new, baby boy. I'm going to want to hold him a lot, but I currently need two hands and two eyes on my computer. Also, with the work I do in Virtual Reality, it becomes very clear, very quickly, that our UI metaphors are informed by and designed for 2D systems, and do not adapt well to 3D systems. The current market of VR being primitive also presents problems in that User Input schemes have largely been either overlooked or exclusively focused on gaming applications. So I've been keeping my eye out for a more ergonomic programming language. I imagine a very high level language that makes functional tasks easy when I want FP, object oriented tasks easy when I want OOP, but perhaps doesn't go out of its way to try to marry the two. With this article on Quorum, they talk up a big game about using studies on live subjects to figure out more ergonomic programming languages. I found myself nodding along the entire way and was very excited to see what they had built. And then was quite deflated to see that what they had delivered is essentially a small corner of Java or C++ with no more changes than having all the keywords renamed. It seems they start with the assumption that OOP is the most natural, correct paradigm for all cases, and then only go so far as to test whether or not different variations of keywords are easier to understand as spoken language. I get renaming "for" to "repeat". I don't get how you're helping anyone with multiple inheritance, or boxed primitives for use in contajners, or Arrays that are really Lists, but also a separate List class. With the direction they've gone, it does not impress that the people involved understand programming language theory beyond keyword replacement. With zero apparent effort put into constructs and semantics, it just seems like a dead-end of bodged-together shell scripts. Also, the example code in the documentation would be wholly inadequate for a beginner. It is definitely written for an experienced programmer to learn how to map concepts in other languages to Quorum. The first example on each page does generally demonstrate the most basic usage, but subsequent examples don't actually demonstrate what they say they will demonstrate. In some cases they demonstrate how not to achieve what has been described, but then don't describe how to achieve it. And in at least one case, two entries in a compare-and-contrast example were identical. In a few examples, I'm not sure the example will even run.
kerryritter 11y ago
Ahh, cool to see this on the front page. I did some work for Quorum. Dr Stefik is a great guy and Quorum is pretty interesting.
- renox 11y ago
  Maybe but I find VERY strange that he write about studies with beginners and Perl or Java: I doubt very much that making Perl easy to learn by beginners was a priority, and Java isn't a VHLL.. Now if he was making studies like this against Python, Logo (not BASIC: it's too old) then this could be interesting.
scotty79 11y ago
If I were designing language for the blind I wouldn't end the nested block with "end" but rather "end action withdraw" "end class BankAccount" ... this could be auto-suggested for non-blind, it could help them too.
nickpsecurity 11y ago
I like the experimental approach. I'm also glad they realize a lot of these decisions were made by people with trade-offs that aren't obvious years down the line. So, it has to be done carefully. I agree with moron4hire that this is a very shallow take at it where it's basically just syntax. Prior studies on programming languages, particularly for quality or composition, showed certain features had strong benefits compared to other languages without them. I started on a list of examples proven by evidence in academic studies or field use: https://news.ycombinator.com/item?id=10734477 https://news.ycombinator.com/item?id=10734477 I'd like to see them start with what's been proven. Syntax was my lowest worry as COBOL and BASIC were used successfully by laypeople because they looked like pseudocode. So, just start with a BASIC then modify by how people solve the problem. Most issues in software defects and maintenance have nothing to do with syntax. It's an improper expression or manipulation of data, control, or interfaces. The techniques above address those. So, I challenge anyone wanting to explore evidence-oriented paradigm (aka do science) and improve SW development to start on those techniques. Pull up all the scientific literature that puts them to the test against conventional alternatives. Look at the logic behind solutions & the results in terms of numbers. Re-run the studies using Quorum-style methods along w/ attention to reducing any biases. Use test data (eg applications) that embed realistic errors or integration problems that can show or refute the above's value in facilitating robust development. Once a technique is proven, start working on various approaches of doing it in both syntax and analytical model (i.e. effectiveness). Do it for all of them and we'll have better tooling that increases effectiveness instead of just pretty syntax. That's my take on it. Good luck on that round of research.
- naasking 11y ago
  > So, just start with a BASIC then modify by how people solve the problem. The problem with this approach is that it only scales to small problems, and provides no guidance beyond trial and error for scaling to more complicated problems. Solving complicated problems requires different kinds of abstractions, and optimizing how people use existing constructs is simply finding local maxima, not finding a global maxima.
  - nickpsecurity 11y ago
nikolay 11y ago
I love the syntax!

60 points by edtechdev 11y ago

"Perl, despite the fact that it was a very popular programming language [..] was apparently not detectably easier to use for novices than a language that my student [..] created by essentially rolling dice and picking (ridiculous) symbols at random. That result was astonishing" This sound-bite needs no comment. I do like Perl.

jasonjayr 11y ago
To be fair, from a few lines down .... "Interestingly, in this new study, the same result we saw with Perl we also observed with Java, a programming language so popular it is used in the Computer Science A – AP test in high school. Ultimately, using a technique we call Token Accuracy Mapping, which is basically a way to figure out which tokens may have caused the problems, it appeared that C-style syntax was plausibly the culprit."
- moron4hire 11y ago
  If you read on to the language page, they apparently mean tokens and not syntax. They have retained C/C++/Java style syntax, only having renamed some of the keywords and delimiters.
  - edtechdev 11y ago
    Read further down, and the C-style syntax (curly braces, etc.) was a cause for problems: "Ultimately, using a technique we call Token Accuracy Mapping, which is basically a way to figure out which tokens may have caused the problems, it appeared that C-style syntax was plausibly the culprit."
    - moron4hire 11y ago
      That's my point. They don't seem to have gone any deeper than surface syntax. They renamed "while" to "repeat", but is a while-loop-by-any-other-name even the best looping construct in the given scenario?
      - jack9 11y ago
        Quorum is only about syntactical optimization. The reasoning for specific implementation is beyond the scope of the "simple" problem they are trying to study.
        nickpsecurity 11y ago
        You again. You never answered my question... https://news.ycombinator.com/item?id=10775054 https://news.ycombinator.com/item?id=10775054 ...about why you believed the items on my list didn't constitute scientific evidence. Hypothesis, analysis, verification by experimental practice, matched predictions, replication via re-application by diverse crowds, and delivering results. All sounds like scientific method to me. Many studies in academic and industry with these properties over the years. If you reject all of that, I'd like to see what your version of the scientific method is as it's different than what most fields of study are using. I still contend that my numbered list represents scientific evidence in favor of whatever those methods were applied to. In that case, there's scientific evidence for everything I recommended with varying strength.
        jack9 11y ago
        > You again. You never answered my question... I didn't read it. > The proof is in the literature I'm referencing rather than me dumping all of it in the comment box You never cited anything. Most importantly, some of the enumerated "points"? that you espoused are methodology Quorum uses. I'm sure you can help them out, if this subject is of interest to you.
        nickpsecurity 11y ago
  - nickpsecurity 11y ago
    I would've started testing BASIC and Pascal style syntax as they were specifically designed for ease of use and implementation. Would be a nice test to see how wise or arbitrary various parts were.
- nickpsecurity 11y ago
  They'd have figured that out just looking at the history of C: http://pastebin.com/UAQaWuWG http://pastebin.com/UAQaWuWG It started with a knockoff of ALGOL60 called CPL. That's already pretty arbitrary and subject to thinking of 1960's. That basically pre-dates modern software development or involvement of laypeople. They couldn't compile it so they just eliminated features until it could compile. Result, very simplistic, was BCPL. That was slightly modified & extended into C also due to hardware constraints. So, it literally has no justification as a programming language. Almost totally a result of terrible hardware that persisted for legacy/social reasons. A little research might have saved them time and money. ;)

moron4hire 11y ago

This is a negative review. I don't generally like bagging on peoples' projects, but this is an important subject and I feel it has been significantly failed. Their hearts are in the right place, but I think they've failed by even their own metrics. I was very curious to read this topic because I firmly believe we need to do much, much more work to make the full range of computing more accessible for people with disabilities. It's not just about equity--though that should be reason enough--but that systems designed for systemic handicap are also useful for situational handicap. I work from home and have a brand new, baby boy. I'm going to want to hold him a lot, but I currently need two hands and two eyes on my computer. Also, with the work I do in Virtual Reality, it becomes very clear, very quickly, that our UI metaphors are informed by and designed for 2D systems, and do not adapt well to 3D systems. The current market of VR being primitive also presents problems in that User Input schemes have largely been either overlooked or exclusively focused on gaming applications. So I've been keeping my eye out for a more ergonomic programming language. I imagine a very high level language that makes functional tasks easy when I want FP, object oriented tasks easy when I want OOP, but perhaps doesn't go out of its way to try to marry the two. With this article on Quorum, they talk up a big game about using studies on live subjects to figure out more ergonomic programming languages. I found myself nodding along the entire way and was very excited to see what they had built. And then was quite deflated to see that what they had delivered is essentially a small corner of Java or C++ with no more changes than having all the keywords renamed. It seems they start with the assumption that OOP is the most natural, correct paradigm for all cases, and then only go so far as to test whether or not different variations of keywords are easier to understand as spoken language. I get renaming "for" to "repeat". I don't get how you're helping anyone with multiple inheritance, or boxed primitives for use in contajners, or Arrays that are really Lists, but also a separate List class. With the direction they've gone, it does not impress that the people involved understand programming language theory beyond keyword replacement. With zero apparent effort put into constructs and semantics, it just seems like a dead-end of bodged-together shell scripts. Also, the example code in the documentation would be wholly inadequate for a beginner. It is definitely written for an experienced programmer to learn how to map concepts in other languages to Quorum. The first example on each page does generally demonstrate the most basic usage, but subsequent examples don't actually demonstrate what they say they will demonstrate. In some cases they demonstrate how not to achieve what has been described, but then don't describe how to achieve it. And in at least one case, two entries in a compare-and-contrast example were identical. In a few examples, I'm not sure the example will even run.

kerryritter 11y ago

Ahh, cool to see this on the front page. I did some work for Quorum. Dr Stefik is a great guy and Quorum is pretty interesting.

renox 11y ago
Maybe but I find VERY strange that he write about studies with beginners and Perl or Java: I doubt very much that making Perl easy to learn by beginners was a priority, and Java isn't a VHLL.. Now if he was making studies like this against Python, Logo (not BASIC: it's too old) then this could be interesting.

scotty79 11y ago

If I were designing language for the blind I wouldn't end the nested block with "end" but rather "end action withdraw" "end class BankAccount" ... this could be auto-suggested for non-blind, it could help them too.

nickpsecurity 11y ago

I like the experimental approach. I'm also glad they realize a lot of these decisions were made by people with trade-offs that aren't obvious years down the line. So, it has to be done carefully. I agree with moron4hire that this is a very shallow take at it where it's basically just syntax. Prior studies on programming languages, particularly for quality or composition, showed certain features had strong benefits compared to other languages without them. I started on a list of examples proven by evidence in academic studies or field use: https://news.ycombinator.com/item?id=10734477 https://news.ycombinator.com/item?id=10734477 I'd like to see them start with what's been proven. Syntax was my lowest worry as COBOL and BASIC were used successfully by laypeople because they looked like pseudocode. So, just start with a BASIC then modify by how people solve the problem. Most issues in software defects and maintenance have nothing to do with syntax. It's an improper expression or manipulation of data, control, or interfaces. The techniques above address those. So, I challenge anyone wanting to explore evidence-oriented paradigm (aka do science) and improve SW development to start on those techniques. Pull up all the scientific literature that puts them to the test against conventional alternatives. Look at the logic behind solutions & the results in terms of numbers. Re-run the studies using Quorum-style methods along w/ attention to reducing any biases. Use test data (eg applications) that embed realistic errors or integration problems that can show or refute the above's value in facilitating robust development. Once a technique is proven, start working on various approaches of doing it in both syntax and analytical model (i.e. effectiveness). Do it for all of them and we'll have better tooling that increases effectiveness instead of just pretty syntax. That's my take on it. Good luck on that round of research.

naasking 11y ago
> So, just start with a BASIC then modify by how people solve the problem. The problem with this approach is that it only scales to small problems, and provides no guidance beyond trial and error for scaling to more complicated problems. Solving complicated problems requires different kinds of abstractions, and optimizing how people use existing constructs is simply finding local maxima, not finding a global maxima.
- nickpsecurity 11y ago

nikolay 11y ago

I love the syntax!