Study of non-programmers' solutions to programming problems [pdf]

Top three takeaways for me: event-based logic, sets instead of loops, and using past tense instead of state. Events and linq-like queries are popular enough, that last one is interesting.<p>Especially in an environment where you mostly interact with objects via events, I think querying an object&#x27;s past sounds pretty doable. Naively we could hold on to all events ever and query for one that matches what we&#x27;re talking about. Less stupidly, these past tenses are usually in forms like &quot;if this happened recently&quot; or &quot;if this happened ever&quot; which a compiler could rewrite into a variable that the relevant event sets.<p>So, the compiler sees &quot;if Pacman ate a power pellet within the last ten seconds&quot; in whatever syntax it accepts. It goes to Pacman&#x27;s &quot;eat power pellet&quot; function and appends code to set Pacman&#x27;s last-power-pellet-eaten variable, which it has to introduce. The original conditional gets rewritten in terms of timestamp comparison.

My perspective, as someone who came relatively later to programming as a career, is that the skill of &quot;thinking like a programmer&quot; isn&#x27;t too hard to acquire once you&#x27;ve taken a few college CS classes and started to simply program a lot.<p>Rather, what I&#x27;m constantly amazed at (and maybe its because I&#x27;m working in stereotypical enterprisey environments?) is how complex, convoluted, long and hard to follow a lot of code is. So much code goes into what to a non programmer or novice would seem like a fairly simple task. And so much code is really horribly written and designed and implemented. Its very much true what your professors say about how you&#x27;ll spend more time reading code than writing it. Anyways, I&#x27;m sure my perspective as both a junior dev and a late career switcher is somewhat biased, but there you have it.

As someone with a definite and well-established viewpoint on CS education, I sort of expected to hate this paper... but I didn&#x27;t. I thought it made some excellent points, and I very much liked the idea that people not trained as programmers might be able to point us toward new paradigms.<p>At this point in the development of programming languages, the problem is not really that we can&#x27;t build languages that do what you want; by and large, for unambiguous specifications (and yes, that is a big qualifier), we can.<p>At this point, then, the conversation shifts from &quot;how can I meet the machine&#x27;s needs?&quot; to &quot;how can the machine meet my (programming) needs?&quot; Another analogy: we&#x27;re no longer just stone-age people looking for a rock that doesn&#x27;t shatter when we hit things with it; we&#x27;re can shape our rocks now, and we&#x27;re trying to figure out what shape allows us to hit things hard without cutting our hands.<p>Go, functional and declarative programming! Oops, I gave it away. Sorry.

I feel that at its core programming is about taking a conceptual idea (e.g. pac-man moving around a maze) and determining the unambiguous logic that describes it. The language used to express that description has a significant effect on the end result, but it&#x27;s the ability to develop the logic in the first place that really separates &quot;programmers&quot; from &quot;non-programmers&quot;.<p>&quot;Non-programmer&quot; isn&#x27;t meant as a slight. This style of problem solving works great a significant portion of the time. Natural languages can describe a solution to a lot of problems very concisely because a) there&#x27;s a lot of implicit context that clears up many of the potential ambiguities, and b) you&#x27;re typically present and available to handle any unexpected situations that may arise. For many problems, the best solution is one that can be specified quickly, will work 90% of the time, and can be easily adjusted for most of the other 10% of the time. Natural languages and fuzzier thinking work great for this.<p>But this approach doesn&#x27;t work well for problems where the solution is either too complex too be easily described using natural language, or situations where data sizes or time constraints make it unfeasible for you to be available to handle unexpected situations. In this case the solution requires all of the logic to be precise, unambiguous, and developed up front. It&#x27;s a different way of thinking than what has typically been asked of humanity, and natural languages are pretty poor at expressing that logic.<p>I think the paper has some good points, but I&#x27;m not sure how much you can really draw from it other than verification that natural-style problem solving doesn&#x27;t work well for the type of problems that are typically solved by programming. If you asked a bunch of experienced programmers to write programs that will tell you how to &quot;go to the store and buy me some milk&quot;, you&#x27;d probably get similar results about how the programs didn&#x27;t handle the many different unexpected situations that might occur in such a simple task.

This is a wonderful idea. There are few programming environments that are useful to non-programmers with the possible exception of Excel.<p>A study like this helps us gain inspiration and to remind ourselves how non-programmers think about programming problems.<p>In the words of the linked pdf: &quot;Programming may be more difficult than necessary because it requires solutions to be expressed in ways that are not familiar or natural for beginners.&quot;

The argument that we have to take people who are unfamiliar with the work and look at how they approach it is alienating me. Would you design mathematical notations based on the opinion of 5th graders? Would you build a skyscraper based on how 5th graders feel about it because it&#x27;s more natural?<p>EDIT: For those who didn&#x27;t read the article, I say 5th grader here because a large part of the study is actually about them. Not because I arrogantly compare people from other fields to children.

When was this written? They quote an article from 1985 saying that programming languages has not been designed with human interaction in mind. I think quite a lot has happened since then.<p>I also think the conclusion that people prefer sets over loops is biased because the problem domain is a database table where it is more natural to work with sets.<p>In any case i find the study interesting to compare with how people write software requirements and not to how languages are designed. Requirements are often written in natural language form and are often written by product managers that are non-programmers. I found the answers to be extremely similar to user stories seen in requirements, in particular the use of end user perspective when describing how pac man should move.

Of course non-programmers aren&#x27;t used to being extremely precise with their grammar to express solutions to logic problems. We have the capability of getting the &quot;gist&quot; of what someone is trying to express that machines current don&#x27;t. Expressing those thoughts to a machine requires precise syntax and well formed flow control. I honestly don&#x27;t find much in this paper that&#x27;s very surprising, but I think the participants did pretty well given that they aren&#x27;t expected to be extremely precise on a day-to-day basis.

Is it really necessary to make programming more accessible to non-programmers? (this is how interpret some of the introduction about making programming easier to a &#x27;beginner&#x27;)<p>How is it different from making structural engineering more accessible to non-structural engineers, dentistry more accessible to non-dentists, etc?<p>Take my latter question not so literally—I mean to ask what is wrong with everyone having their own profession as a result of their passions&#x2F;natural talent?

I wouldn&#x27;t know how to write something that &quot;summarizes how I (as the computer) should move Pacman in relation to the presence or absence of other thing.&quot; I can&#x27;t figure out what that&#x27;s supposed to mean. Given the image shown, I would have said &quot;if PacMan reaches a wall, the computer should not continue moving PacMan in that direction.&quot;<p>Also, why anthropomorphize the computer? And why are we &quot;summarizing&quot; instead of instructing the computer? The question asked for a declarative solution and then is surprised that the children gave declarative answers. [edit: I misread what was being said in that portion of the paper and that portion of has been replaced by this bit in square brackets]<p>The experiment seems extremely sloppy. It can&#x27;t possibly show what it purports to show, there&#x27;s way too much in the design of the study that could have biased the results, the sample sizes tiny, the task unclear, and the quantitative analysis subjective.

Not exactly the same but many years ago I did a small experiment: I gave a few relatively easy logical puzzles to my family (including my grandmother who only finished elementary school) and to friends studying CS and math. In general, my family solved the puzzles faster and making very basic (but useful) representations that my friends who followed more formal thinking.<p>Obviously I can&#x27;t extrapolate or make big assumptions about this tiny experiment but I underestimate my family members capabilities. Also, it is obvious that on complex areas of study it&#x27;s very difficult to came up with a solution if you are a novice.

Note: This was published in 2001. Here&#x27;s a Scholar link of other papers citing it (none of the top ones are very recent) in case anyone wants to dig deeper:<p><a href="https:&#x2F;&#x2F;scholar.google.de&#x2F;scholar?cites=9767640341703630929&amp;as_sdt=2005&amp;sciodt=0,5" rel="nofollow">https:&#x2F;&#x2F;scholar.google.de&#x2F;scholar?cites=9767640341703630929&amp;...</a><p>A good search term is &quot;computational thinking&quot; which probably needs to be combined with a couple of synonyms for &quot;non-programmer&quot;.

Reminds me how non-programmers quickly pick up the vectorization of R and programmers keep writing loops.

It feels a little bit disingenuous to say that you can use a spreadsheet&#x27;s builtin &quot;sum&quot; function to compute a sum. It honestly sounds like an argument in favor of functional languages; here&#x27;s a Haskell program that&#x27;s just as simple:<p>Prelude&gt; sum [1, 2, 3] 6<p>Hey, you could even search for a library that sums lists for you in C, then include and call that function.

<i>For example, a typical C program to compute the sum of a list of numbers includes three kinds of parentheses and three kinds of assignment operators in five lines of code</i><p>Let me take the opportunity to plug a new language which I have spent the last 5 months designing: github.com&#x2F;jbodeen&#x2F;ava<p>An ava solution -- 9 lines of code, and 1 set of parentheses -- would look like this:<p><pre><code> let rec sum list = let are_we_at_the_end = 0 in let take_a_number_and_the_rest_of_the_list n list = add n ( sum list ) in list are_we_at_the_end take_a_number_and_the_rest_of_the_list in </code></pre> Maybe we need to <i>zoom out</i> of ancient languages into more intuitive paradigms if programming is to become easier for more people to access

There are two aspects of this study that I think nullify its value.<p>First, they take naive user reasoning as normative. Nobody remains a naive user for long. When I first started leaning to program, shifting from set-based to iteration-based reasoning about collections was a bit of a jolt, but it didn&#x27;t take me long to become comfortable with it.<p>Second, they ignore that programming is an activity requiring much more precise reasoning than typical daily life. You must learn to think differently and it is beneficial for the notation to enforce this.<p>I will also point out that English-like programming languages have been promoted for decades and they haven&#x27;t caught on.

Essentially isn&#x27;t excel &quot;programming for non-programmers?&quot;

So what&#x27;s the closest language&#x2F;language subset that fits this ?

I always tell non-programmers (and sometimes programmers interfacing with the systems I maintain):<p>Don&#x27;t tell me what I need to do, tell me what You want to do. Mostly clients seem to think they need to come up with the way to accomplish stuff, rather than express the need and let the programmer figure out how to meet that need.

The problem with programming isn&#x27;t solving simple problems. The hard part is dealing with the hard problems. An important contribution of Computer Science is the recognition that abstractions (functional, procedural, object-oriented, relational, ...) are necessary when writing software of any significance. The paper&#x27;s simple problems perhaps give insight into how a programming language for children should be designed, but for the most part its recommendations should be ignored.<p>The paper points out that non-programmers (5th graders) have trouble with NOT, AND, and OR and suggest in a separate paper that table based queries can avoid some confusion with these Boolean operators. I&#x27;m sorry, but a programming language without Boolean operators is going to be worthless. Just because 5th graders haven&#x27;t learned De Morgan&#x27;s Laws doesn&#x27;t mean that we should throw out Boolean operators. What about lambda expressions, functions as first class elements, higher dimensional arrays, recursion, complex numbers, binary and decimal internal integer representations, floating point with exponents, built in log functions, setjump&#x2F;longjump, call-with-continuation, threads, concurrency, interrupt handlers, atomic locking, streams, files, relational data bases, the list goes on and on.<p>Programming in a programming language for Kids tends to be tedious and very concrete. Scratch bored me to tears. Perhaps its a good fit for kids, but it&#x27;s not going to be used to write a web server. I just don&#x27;t see how these &quot;experiments&quot; give us any insight into non-toy programming.<p>In the 1970&#x27;s there were still plenty of professional programmers and fellow grad students that felt like programming in assembly language was the highest form of programming. It was challenging, I did my fair share, but it was also brutish and nasty. There were no powerful abstractions to facilitate ones programming. Everything was concrete and explicit and terrible. The history of programming languages has been to build a tower of increasingly powerful abstractions over the hardware below. C++ templates, Haskell&#x27;s type system, Scheme&#x27;s call-with-continuation, SQL, these are so far removed from the simple little operations being performed by the processor, but they give us the power to write the programs that we do.<p>The use of abstraction in programming isn&#x27;t limited to programming languages. Libraries supporting matrix operations won&#x27;t make sense to a 5th grader or anyone else that hasn&#x27;t studied matrices. So how is a 5th grader going to describe rotation of a graphical element? They don&#x27;t know matrix math or trigonometric functions? Should these be eliminated from programming languages? Operating systems also insulate us from the hardware through abstractions not present in the physical hardware: processes, scheduling, virtual memory, files, abstract sockets, networks, threads. What about the other tools we use like relational data bases, source code control systems like git, and bug trackers? How about pseudo-random numbers and encryption? What do 5th graders know of these?<p>Finally, some professional programmers have to understand deeper issues, programming complexity, turing incompleteness, regular expressions, context-free grammars, LR parsing, performance of algorithms, correctness arguments. All of these issues have some impact on programming. Are we really going to throw all of this out because it is confusing to 5th graders? or even adults that haven&#x27;t studied these issues?

TL;DR<p>non-programmers tended to define&#x2F;use<p>- declarative event-based rules over imperative flow<p>- set manipulations instead of 1by1 iterative changes<p>- list collections instead of arrays. ability to sort implicit<p>- rule-based exclusions for control flow instead of complex conditionals with NOTs<p>- object-oriented state but no inheritance<p>- abstract past&#x2F;future tense to describe information changing over time instead of defining state-variables<p>other issues<p>- not well specified mathematical operations<p>- AND used as logical OR e.g. &quot;90 and above&quot;<p>- life-like motion&#x2F;action assumed instead of defined; e.g. not defining x,y location and frame-by-frame delta