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

http://www.cs.ucr.edu/~ratana/PaneRatanamahatanaMyers00.pdf

by yxlx • 10 years ago

342 170 10 years ago

cs.ucr.edu

petra2• 10 years ago

So what's the closest language/language subset that fits this ?

jeletonskelly2• 10 years ago

SQL

justinlardinois3• 10 years ago

This is definitely true, and why I had more than a few stumbles learning it after I was already an experienced programmer.

Case insensitivity in string comparisons is a good example. It makes perfect sense to a non-programmer but is not at all what a programmer would expect.

eru5• 10 years ago

You might like Functional Relational Programming. See http://lambda-the-ultimate.org/node/1446

brians• 10 years ago

Good question. Racket tries, and because it's Scheme gets a good part of the way. Mozart/Oz tries, with a different basis, and gets somewhere good.

Visual Basic also seems quite close, especially with features like Linq.

Splines2• 10 years ago

Visual Basic also seems quite close

Honest question - what is there about Visual Basic that makes you say this? I've written small programs with it and on the surface it feels close to "C# if someone changed all the keywords".

jeletonskelly2• 10 years ago

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

masterzora3• 10 years ago

It's not just about non-programmers being insufficiently precise. It's also about the different ways they express precision compared to how you have to do it for existing programming languages. For example, the paper talked about how the participants tended to talk about doing something to everything in a set in vectorised terms whereas scalar languages tend to be more common outside of scientific settings.

Kenji• 10 years ago

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's more natural?

EDIT: For those who didn'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.

neosat• 10 years ago

"Would you design mathematical notations based on the opinion of 5th graders?"

Haven't read the entire paper but...learning from something doesn't mean you need to design something 'based' on that.

The advantage of studying how people unfamiliar with a specific way to solve problems will solve that problem is actually a great technique to try to understand common patterns and approaches humans think about problem solving.

Some pattern solving strategies will be more successful than others and it is worth understanding what is common to those (especially when compared to the unsuccessful ones)

Identifying patterns in the way people solve these problems can prove to be great design insights that go into the design of problem-solving solutions for those problems.

crispyambulance• 10 years ago

The thing about programming is that you're typically doing it FOR someone other than yourself. In other words, the programmer is the "middleman" between some domain and the computer. The idea is ultimately to get rid of the middleman.

It is a mistake and somewhat arrogant to view your domain experts as "5th graders".

pcunite• 10 years ago

Yes and no. If we need outsiders it means we have become too arrogant ourselves. Need a fresh take.

c3534l3• 10 years ago

I don't see why that shouldn't be taken into account. Coming up with notation that is intuitive is an important part of the design process and like the article said, this is meant to see if you can't use children as a way of measuring intuition quantitatively.

saint_fiasco• 10 years ago

Sure. That's what we did with numerical notation. We switched to a positional decimal system that even fifth graders can understand and do operations with.

vidarh2• 10 years ago

Yes, except where what the 5th graders come up with fails to meet other important criteria.

A lot of notation is the way it is because of history and inertia, rather than because practical considerations or requirements means it needs to be that way.

If there are changes we can make to make languages more approachable without making them worse in other ways, it makes sense to opt for making them more approachable.

wrp3• 10 years ago

A lot of notation is the way it is because of history and inertia...

Less than you may think. Leibniz and other mathematicians spent years debating notational forms in mathematics before settling on what we have. See Florian Cajori's _A History of Mathematical Notations_.

masterzora3• 10 years ago

Would you design mathematical notations based on the opinion of 5th graders?

It's not their opinions. It's about how they naturally think.

And, yes, if I could change mathematical notation in a manner that made it easier to learn without introducing a more significant disadvantage, I would do it in a heartbeat.

Things are the way they are for a reason but that reason isn't necessarily that the way things are is the best.

dsjoerg• 10 years ago

This is a wonderful idea. There are few programming environments that are useful to non-programmers with the possible exception of Excel.

A study like this helps us gain inspiration and to remind ourselves how non-programmers think about programming problems.

In the words of the linked pdf: "Programming may be more difficult than necessary because it requires solutions to be expressed in ways that are not familiar or natural for beginners."

mcguire• 10 years ago

Medicine may be more difficult than necessary because it requires solutions to be expressed in ways that are not familiar or natural for beginners.

Law may be...

Physics may be...

Getting the point? Beginners may not always be the best yardstick of everything.

justinlardinois3• 10 years ago

I think you're missing the point. We don't have any control over the fact that medicine and physics are complicated because they reflect nature. Law is complicated because it's an attempt to create a set of rules that apply to all possible human scenarios.

This study, and the person you're replying to, aren't saying that all programming languages are unnecessarily complicated and should be changed. They're just saying that they're inaccessible to beginners. The authors of the study note that they're designing a programming language for beginners, so these things are useful for them to know.

fiatjaf2• 10 years ago

Did YOU get the point? Maybe Medicine and Physics and Law shouldn't be so complicated also?

nerdwaller• 10 years ago

It's interesting because many characteristics carry over to other areas. For example, we didn't have a wine opener at a hotel with my wife's brother (a youth pastor). Before I got back to the room he got started on it and used a knife to effectively drill out the cork, the obvious cost here is that you've turned the cork into sawdust. The wine was pretty terrible so i had him filter it through a coffee filter. It was still terrible, but as i walked to the room i thought about a few approaches and their associated costs, he busy did the first thing that came to mind. I found the "non engineering approach" very interesting. If course every solution has costs, his was sawdust filled wine. Mine was having to push a cork out of the way to pour.

brashrat• 10 years ago

pro-tip: I've seen demonstrated, if you repeatedly whack the bottom of a bottle of wine with the heel of your shoe (or, in a similar manner, smack the bottom of a bottle of wine against a tree trunk) the cork will slowly emerge on its own.

It occurs to me if you get it wrong, glass shards from the bottle could emerge before submerging into your flesh, so perform this trick at your own risk.

sah2ed• 10 years ago

Pro-tip: slowly twisting the cork out of the bottle (as if it were a screw) would eventually cause it to pop out. No need for a wine opener.

I do this anytime I don't have a wine opener handy.

jakelarkin2• 10 years ago

TL;DR

non-programmers tended to define/use

- declarative event-based rules over imperative flow

- set manipulations instead of 1by1 iterative changes

- list collections instead of arrays. ability to sort implicit

- rule-based exclusions for control flow instead of complex conditionals with NOTs

- object-oriented state but no inheritance

- abstract past/future tense to describe information changing over time instead of defining state-variables

other issues

- not well specified mathematical operations

- AND used as logical OR e.g. "90 and above"

- life-like motion/action assumed instead of defined; e.g. not defining x,y location and frame-by-frame delta

pierrec• 10 years ago

In the paper, they dismiss the example of "if you score 90 and above" as incorrect use of "and" (or too vague to turn into any formal logic).

However, looking at your summary, it suddenly sticks out that this issue could actually be connected with the tendency to use set manipulation. "If you score 90 and above", and I suspect many other seemingly abusive uses of "and", can turn out to be perfectly valid if you consider them as (infinite) set manipulations. However, I'm not sure which of the two explanations is closer to the actual cognitive processes behind such a phrase. Seems to me that humans are naturally comfortable with many set manipulations, while current computers require fairly elaborate abstractions in order to deal with them as sets, especially infinite. This might be one of the gnarly parts of human -> machine translation.

dkbrk• 10 years ago

To elaborate on this point, "if you score 90 and above" could be parsed in two different ways:

  1. "if [you score 90] and [you score above 90]"
  2. "if you score in [{90} 'and' {x: x > 90}]"

[1] is unsatisfiable. [2] is still ambiguous, as it's unclear in natural language whether 'and' is a set union or intersection.

In mathematical terminology, 'and' in this countext would mean set intersection, but I don't think it's necessarily "incorrect" to have this mean set union in natural language.

To elaborate, take: C = A union B. Here are two propositions about C:

  I. forall c in C. (c in A) OR (c in B)
  II. (forall a in A. a in C) AND (forall b in B. b in C)

These propositions are not equivalent. [I] actually implies C is a subset of (A union B), and [II] implies that it's a superset. Note that set builder notation for C, {c: (c in A) OR (c in B)} is structurally very similar to [I].

I think [II] is the interpretation of 'and' that is intended through the natural language use. It's essentially a form of set construction: I am constructing a set; it contains 90, and it contains the numbers above 90. As a set construction it also adds an implicit constraint that the new set can't contain anything not in the operands, so that resolves the superset ambiguity (it would be patently absurd in natural language to claim that 55 could be in the set "90 and above").

MichaelBurge• 10 years ago

I think about it as:

"90 and above" is the smallest set X satisfying both:

* 90 is in X

AND

* Above(90) is a subset of X

Another description of this set is:

An element x is in the set "90 and above" if x is 90 OR if x is in Above(90).

AND/OR are dual to each other, and it's just a matter of perspective on whether you're building up the set(OR) or constraining the set(AND).

jakelarkin2• 10 years ago

Analysis: non-programmers don't naturally code to the Von Neumann machine architecture. They instead declaratively define higher-level rules and operations with a naive grammar strongly influenced by human language and experience.

euske• 10 years ago

I don't think "programmer" and "non-programmer" is a binary distinction. Most programmers don't think when iterating an array, but even experienced programmers sometimes take a non-programmer like approach when they see an unfamiliar problem.

In other words, if we could make a programming language that's more approachable to non-programmers, we might benefit everyone.

daveguy• 10 years ago

I thought the most interesting one was the use of then as a temporal construct. First this, then this, then that. That's the common use in literature, but that sense of then is implied by statement sequence or function composition in programming. When you are programming the use of then as conditional consequence is so natural you don't think of it as different to the way most people (66%) use it.

smcl• 10 years ago

This is something I'm having trouble explaining to Business Analysts - they tend to think and define systems declaratively whereas when we receive a set of requirements we prefer to work from an imperative set of instructions. I've not succeeded in conveying this successfully (they either think devs are just being difficult/lazy or they just fail to grasp what we need) - anyone else suffered this? If so have you got any tips as to how it could be better conveyed?

kyllo• 10 years ago

They are telling you what to build, you should be deciding how to build it. A business analyst who writes requirements as imperative pseudo code is doing most of your thinking for you.

sp332• 10 years ago

Maybe you could use a more declarative language? Or build a domain-specific language yourself?

capote4• 10 years ago

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 'beginner')

How is it different from making structural engineering more accessible to non-structural engineers, dentistry more accessible to non-dentists, etc?

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/natural talent?

andkenneth• 10 years ago

I work as a teaching assistant in a compsci 101 lab - I found this paper to be incredibly eye opening, and will hopefully help me link the intuitive thoughts people have with the specific language features they should be using. We just did a lab on lists and for loops, and this paper basically clarified what the issue most people were actually having, that they wanted to operate on the list in aggregate. While this paper does seem to be looking at potential changes for new languages, it's useful for more than that.

And what makes you think that these potential new language features won't make it easier for experienced programmers as well? Sure, everyone will eventually get their head around iterative loops, but should we not be using the most efficient language for our brains? At the end of the day, a non intuitive concept will have inherent overhead.

RodericDay• 10 years ago

I taught javascript to an older person once, and I think for-loops are one of those things that people who studied programming think "are not so bad", but it's absolutely senseless and insane to outsiders.

I'm thinking

    var output = [];
    for (var i=0; i<listOfThings.length; i++) {
        var thing = listOfThings[i];
        var newThing = applyAction(thing);
        output.push(newThing);
    }

vs.

    listOfThings.map(thing => applyAction(thing));

and even that is a little bit iffy.

capote4• 10 years ago

I replied to another guy, but it addresses your answer too.

pasquinelli2• 10 years ago

"Is it really necessary to make programming more accessible to non-programmers?"

no, but it might be helpful for designing programming languages. not necessarily to make programming languages that're easier for beginners to use, but because there are two immediate entities that interact through a programming language, the computer and the programmer. so learning how humans naturally tend to formulate problems and solutions could be valuable for designing that interface.

thrownaway24242• 10 years ago

Indeed, if there was something I could force the average person to learn it would not be computer programming, it would be mass balance or other elementary principles of accounting.

Input + Generation = Output + Consumption + Accumulation

It applies to so many problem domains. They should teach it in 5th grade.

Splines2• 10 years ago

I don't think this is a matter of making programming easier for people who are not interested in programming - I look at this as a study of how "normal" programming could be made to model how the human mind might think naturally.

Non-programmers often need to "program". For example, consider writing email filtering rules. The wording and flow could be improved with the learnings from this study. "Apply this label to this mail and all the ones like it, then archive all of those mails".

bordercases• 10 years ago

You would be surprised how much you can get away with by learning to work with the machine directly. The way that the human mind works without training is naturally ambiguous and chaotic. There are of course benefits to offloading some of the thinking and parsing to the compiler or interpreter whatever; that's why we have Python, because C and Assembly weren't enough.

But human beings have been inventing formal notations because they end up being the right tool for the job, most of the time, to guide thought, even if the upstart cost of using them takes some work. I suspect that being afraid of formality will gradually make you lose power over the computer, and will cause unpredictable results when it isn't crystal clear where the impedance to communication and understanding with the machine lies.

I'm all for the more declarative style of programming though, even if it doesn't resemble any particular natural language specifically (remember that papers like these still have a grand Anglo bias in their implementations – imagine the sparsity of a Chinese version of these studies, and the potential difference of the results!).

capote4• 10 years ago

They need to "program," not program. The difference is key—people who can't write email rules just aren't "computer savvy" and that's not such a large issue with the new generations.

What seems to be happening is people trying to figure out how to make teaching programming easier—like the guy below who works as a TA. I wasn't a TA but I did help a lot of people in school with programming and other CS assignments, and I definitely noticed lots of people in the field for the wrong reason. Either because they thought they could make a lot of money or because their parents wanted them to do it—but they had no natural interest or talent and didn't understand anything. Some of them declared many times they "hate" math or science.

Why do we have to go out of our way to teach people like this computer science principles or programming? They aren't interested in it and don't think the right way. There are many other professions and schools out there, surely most people can find what they really are cut out for, right?

edtechdev• 10 years ago

Last I checked, dentists don't brush our teeth for us.

And all dentists, at one point, were non-dentists.

capote4• 10 years ago

Yeah, but nobody set out to make dentistry easy for them, or to coach them through it when clearly they have no natural ability to learn the sciences required. Some people just don't get it.

c3534l3• 10 years ago

I wouldn't know how to write something that "summarizes how I (as the computer) should move Pacman in relation to the presence or absence of other thing." I can't figure out what that's supposed to mean. Given the image shown, I would have said "if PacMan reaches a wall, the computer should not continue moving PacMan in that direction."

Also, why anthropomorphize the computer? And why are we "summarizing" 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]

The experiment seems extremely sloppy. It can't possibly show what it purports to show, there'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.

masterzora3• 10 years ago

The list of things they taught kids for the PacMan study also seemed very... well, technical.

What list? Perhaps I'm just missing it or there's another link I haven't seen but they don't seem to mention having taught the kids anything--especially anything technical--before the Pac-Man study.

c3534l3• 10 years ago

My mistake, that list was something the researchers before the task was conducted, not part of it.

caseyf7• 10 years ago

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

grapevines• 10 years ago

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

Let me take the opportunity to plug a new language which I have spent the last 5 months designing: github.com/jbodeen/ava

An ava solution -- 9 lines of code, and 1 set of parentheses -- would look like this:

  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

Maybe we need to zoom out of ancient languages into more intuitive paradigms if programming is to become easier for more people to access

freditup• 10 years ago

Could you elaborate on how this is more understandable to a novice than the typical C program? My guess is that neither is immediately understandable, and that the C program is clearer to someone experienced.

simoncion3• 10 years ago

Maybe we need to zoom out of ancient languages...

Maybe. Compare your function to the equivalent Erlang one:

  sum(L) ->
    sum(L, 0).
  sum([], Acc) ->
    Acc;
  sum([Num|Rest], Acc) ->
    sum(Rest, Acc+Num).

Assuming that it's in a module called 'math', run it like so:

  math:sum([5,4,3,2,1]).
  15

im_down_w_otp• 10 years ago

  -module(math).
  -export([sum/1]).

  sum(ListOfNumbers) ->
      sum(ListOfNumbers, 0).
  sum([Number | RestOfList], Subtotal) ->
      sum(RestOfList, Subtotal + Number);
  sum([], Total) ->
      Total.

edit: blargh... sorry @simoncion, I didn't see your reply. It apparently takes me longer than 14min to type that out on my phone without typos + proper spaces to treat it like code :-)

simoncion3• 10 years ago

sorry @simoncion...

No worries. It's astonishing how absolutely awful on-screen phone keyboards still are for doing anything more involved than writing a brief human-language message.

thrownaway24242• 10 years ago

Typical C program, eh? Yet another reason to not program in C, I guess.

sum = std::accumulate(begin, end, 0);

eru5• 10 years ago

Wow, that's pretty verbose. But I guess the long variable names are partly to blame.

jackweirdy• 10 years ago

Haskell:

let listsum = foldl (+)

tome• 10 years ago

You probably want foldl' (+) 0

wslh• 10 years ago

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.

Obviously I can'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's very difficult to came up with a solution if you are a novice.

z1mm32m4n2• 10 years ago

It feels a little bit disingenuous to say that you can use a spreadsheet's builtin "sum" function to compute a sum. It honestly sounds like an argument in favor of functional languages; here's a Haskell program that's just as simple:

Prelude> sum [1, 2, 3] 6

Hey, you could even search for a library that sums lists for you in C, then include and call that function.

eru5• 10 years ago

Yes, it's a simple first order function on some kind of collection.

A sum function is not very `function' at all. (It sure feels at home in functional languages, more than in imperative bit-by-bit piecemeal programming, sure.)

z1mm32m4n2• 10 years ago

I think the idea that the author was trying to express was that in a spreadsheet language, you select a data range and then choose a function to perform on that data. That's the "functional" aspect I took away from my reading of it.

wuch• 10 years ago

And in C++ you would write this as follows (with a range library it would be a one-liner):

  const auto & xs = {1, 2, 3};
  cout << accumulate(begin(xs), end(xs), 0);

todd8• 10 years ago

The problem with programming isn'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'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.

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'm sorry, but a programming language without Boolean operators is going to be worthless. Just because 5th graders haven't learned De Morgan's Laws doesn'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/longjump, call-with-continuation, threads, concurrency, interrupt handlers, atomic locking, streams, files, relational data bases, the list goes on and on.

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's not going to be used to write a web server. I just don't see how these "experiments" give us any insight into non-toy programming.

In the 1970'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's type system, Scheme'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.

The use of abstraction in programming isn't limited to programming languages. Libraries supporting matrix operations won't make sense to a 5th grader or anyone else that hasn't studied matrices. So how is a 5th grader going to describe rotation of a graphical element? They don'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?

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't studied these issues?

CJefferson• 10 years ago

Firstly, no-one is suggesting we get rid of the hard programming. But actually, I disagree with your point of view.

I do research into A.I., and often work with companies. I find problem fall into 3 categories. Approximately:

50% of problems are extremely trivial problems which we've know how to solve for at least 10 years, we just need to help the companies use the existing techniques.

15% of problems require techniques from the last 10 years or so, so require extensive up-to-date expertise but aren't interesting research.

5% of problems are interesting, hard problems which lead to interesting research problems.

30% of problems are so far beyond the state of the art they are impossible.

Helping people in that first 50% solve their problems without having to talk to us is an interesting area. At the moment they use tools like Excel and Microsoft Access. I believe there must be better tools for those problems, which aren't any more complicated. Why can't my mother easily produce (for a concrete example) create and update a schedule for her darts league, without needing me to help?

soared• 10 years ago

I took a business analytics class which taught SQL and basic machine learning. We exclusively used an excel plugin, and it was exceptionally easy to get great results. This sounds like something that would help that 50%.

Deregibus• 10 years ago

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's the ability to develop the logic in the first place that really separates "programmers" from "non-programmers".

"Non-programmer" isn'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's a lot of implicit context that clears up many of the potential ambiguities, and b) you'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.

But this approach doesn'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's a different way of thinking than what has typically been asked of humanity, and natural languages are pretty poor at expressing that logic.

I think the paper has some good points, but I'm not sure how much you can really draw from it other than verification that natural-style problem solving doesn'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 "go to the store and buy me some milk", you'd probably get similar results about how the programs didn't handle the many different unexpected situations that might occur in such a simple task.

petra2• 10 years ago

> But this approach doesn't work well for problems where the solution is either too complex too be easily described using natural language,

For such solutions, let's say in the business domain - the programmer could work with the domain experts on the general structure of the domain model - business objects, members and methods - while the domain expert will design fill the methods, maybe validation rules(with some tool), all small code sections(so it might be easier to think un-ambigously) - and than the model will be fed to an automated system like naked-objects/ISIS that will handle all the technical stuff automatically.

Than if the system detects an ambiguity, it will offer debug info(and code view) in a format that domain experts understand, and let them fix it - or ask help. And of course you could add testing and code review with programmers and domain experts(who can now read the code) to the mix.

And yes, sure this won't fit every system. But it maybe extend the power of the domain expert.

> or situations where data sizes or time constraints make it unfeasible for you to be available to handle unexpected situations.

For such situations, a search engine having access to the full code specified in an ambiguous language(not necessary natural), could help tools find/build an code containing an optimized form, and maybe offer help about how to integrate it.

njharman2• 10 years ago

It's fundamentally wrong to have non domain expert, "generic" devs. To be effective your devs need to become domain experts in whatever they are developing

TuringTest• 10 years ago

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. But this approach doesn'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.

The good thing is, both extremes are not mutually exclusive, but rather exist on a continuum. You can start with fuzzy specifications and progressively refine it by case-based reasoning and induction until you get some general, unambiguous rules. Programmers work this way when building new programs, even though they hate to admit it and like to say that the program logic emerges fully formed from the specifications (ha!), they just need to understand the problem in their heads first (no tinkering and trial-error happens in programming, right?).

I believe the next radically different family of languages will be one that embraces that fact and allows developers to better handle that progressive refinement in all steps of the process, rather than require the program to be fully formed and flawless in order to operate. In some sense, modern IDEs already work that way.

jbclements• 10 years ago

As someone with a definite and well-established viewpoint on CS education, I sort of expected to hate this paper... but I didn'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.

At this point in the development of programming languages, the problem is not really that we can't build languages that do what you want; by and large, for unambiguous specifications (and yes, that is a big qualifier), we can.

At this point, then, the conversation shifts from "how can I meet the machine's needs?" to "how can the machine meet my (programming) needs?" Another analogy: we're no longer just stone-age people looking for a rock that doesn't shatter when we hit things with it; we're can shape our rocks now, and we're trying to figure out what shape allows us to hit things hard without cutting our hands.

Go, functional and declarative programming! Oops, I gave it away. Sorry.

jtolmar• 10 years ago

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.

Especially in an environment where you mostly interact with objects via events, I think querying an object's past sounds pretty doable. Naively we could hold on to all events ever and query for one that matches what we're talking about. Less stupidly, these past tenses are usually in forms like "if this happened recently" or "if this happened ever" which a compiler could rewrite into a variable that the relevant event sets.

So, the compiler sees "if Pacman ate a power pellet within the last ten seconds" in whatever syntax it accepts. It goes to Pacman's "eat power pellet" function and appends code to set Pacman's last-power-pellet-eaten variable, which it has to introduce. The original conditional gets rewritten in terms of timestamp comparison.

lifeisstillgood• 10 years ago

This is really fascinating - our security folks are using even based history - must go talk to them again in this context

Thank you

vanderZwan2• 10 years ago

using past tense instead of state

Isn't Clojure's philosophical foundation almost exactly this? Adding the dimension of time to data structures? I vaguely recall a ConTalk by Rich Hickey from the early days about it.

zdkl• 10 years ago

You may be thinking of http://www.datomic.com/ a product by Cognitect where Rich Hickey works. However the Clojure data structures also have the time dimension in the context of the language's immutable structures but it is not something you typically concern yourself with too much.

raverbashing• 10 years ago

This is a nice tl;dr, thanks

The 3 elements make sense even as a programmer, but of course you would need to do them yourself in your program logic and might opt for something simpler

zyxley• 10 years ago

The "sets instead of loops" one makes me think of Ruby, where operations on sets are a basic part of the philosophy in a way they aren't in a bunch of languages.

Even the basic "do this 5 times" is expressed in the same way as a set comprehension:

    this_set_of_items.each do |item|
      puts "hey, look at #{item}"
    end
 
    5.times do |index|
      puts "look, a line!"
    end

de_Selby• 10 years ago

It sounds very like array programming, eg APL and it's derivatives

rileymat2• 10 years ago

I am not sure that would count as working on the set. It looks like iteration.

From the article:

a) 1___ 2___ 3___ 4___ 5___ 6___ 7___ 8___ 9___

Thinks of them as a set or subsets of entities and operates on those, or specifies them with plurals. Example: Buy all of the books that are red.

b) 1___ 2___ 3___ 4___ 5___ 6___ 7___ 8___ 9___

Uses iteration (i.e. loop) to operate them explicitly. Example: For each book, if it is red, buy it.

In your case it looks like you are operating on each item and not on the set.

ssmoot2• 10 years ago

That's just Array.forEach in JS. Or in Scala:

  (1 to 5) foreach { _ =>
    println("look, a line!")
  }

That's really nothing to do with Sets.

DanitaBaires• 10 years ago

I took it more like the way you specify certain jQuery operations such as:

    $('.card').hide();

to mean "hide all cards", or

    $('.card.green').show();

to mean "show all green cards". It's really comfortable to think about operating on the set like this and not having to worry about looping on the individual items.

conceit• 10 years ago

Bah, the past tense in a summary is just bad grammar. It is regularly correct to use the present, also called the narrative present as wikipedia will have you know.

bakhy• 10 years ago

the past-querying sounds a lot like reactive programming, doesn't it? you lay out an expression (and you would be typically using set/aggregate operations there as well) and the expression kinda just sits there quietly, accumulates events until a certain condition or threshold is reached, when it fires a signal further down the chain...

s_kilk• 10 years ago

Especially in an environment where you mostly interact with objects via events, I think querying an object's past sounds pretty doable

Sounds a bit like Event Sourcing.

I can imagine logic like:

Do action "foo" if user_account has ever been in the "deactivated" state.

njharman2• 10 years ago

Adding a variable is creating state. Defeating "past tense without state."

What you described, has ever, has recently seems like classical finite state machine.

andrewflnr3• 10 years ago

The entire point is the model presented to the programmer, not the guts. Of course it's implemented in terms of state. Computing hardware is stateful.

gambler2• 10 years ago

Using sets instead of loops is a sensible thing to do. After using LINQ or a proper functional language it's hard to go back.

Using past tense instead of explicit state handling is actually a very interesting idea that I don't see being commonly used. Wort thinking about.

But... Event-based logic is often the source of horrendous complexity and bugs due to timing and exponential complexity of dealing with various sequence permuations. This is one of those things that I firmly believe people should be conditioned to avoid at all cost by using either functional (immutability+recursion) or logic (rules+deduction) flavors of programming. This is one of those things that's really not intuitive to get started with but provides huge benefits in the long run.

michaelfeathers• 10 years ago

It's funny we make the presumption that the natural way is the best way.

sillysaurus3• 10 years ago

Programs are for humans to read. That is their sole purpose.

Too• 10 years ago

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.

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.

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.

machinelearning• 10 years ago

2001 src: http://www.cs.cmu.edu/~NatProg/publications.html

mikehollinger• 10 years ago

Essentially isn't excel "programming for non-programmers?"

ZanyProgrammer• 10 years ago

My perspective, as someone who came relatively later to programming as a career, is that the skill of "thinking like a programmer" isn't too hard to acquire once you've taken a few college CS classes and started to simply program a lot.

Rather, what I'm constantly amazed at (and maybe its because I'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'll spend more time reading code than writing it. Anyways, I'm sure my perspective as both a junior dev and a late career switcher is somewhat biased, but there you have it.

wtetzner2• 10 years ago

Well, that's the thing. Simple code is hard to write. It's easy to end up with a convoluted mess, because often the first version is just the programmer implementing their thought process as they think through the problem.

It's rare that people get the chance to go back and fix up the code once they have a better understanding of the problem.

twa9274• 10 years ago

Why do you hold the assumption that code can be made much simpler than it is?

I've done many years of programming and wrote some bigger programs from scratch by myself. Almost always the actual code is far more complicated than one would assume it should be. And it's not because it's of low quality. It happens that writing something nontrivial that works in the real world requires all the details, checks and abstractions it contains.

If you were in school recently, maybe you were lead to think that programming is an extension of math, where everything is pure, simple and provable. But it isn't - programming is much messier.

Chris_Newton4• 10 years ago

It happens that writing something nontrivial that works in the real world requires all the details, checks and abstractions it contains.

I think it helps to separate essential complexity, due to the nature of the problem you’re trying to solve, from accidental complexity, which comes from other sources. In an ideal world, you’d represent the essential complexity as clearly and flexibly as possible, and minimise the amount of accidental complexity you put on top.

That accidental complexity can come from lots of different sources: tools that aren’t a perfect fit for what you’re trying to do, a design that isn’t as clean as it could be, an unfortunate choice of data structures of algorithms… I suspect it probably is fair to say that a lot of accidental complexity that goes into real world programs could have been avoided if, for example, more appropriate tools had been used or better design decisions had been made during development.

gambler2• 10 years ago

I'm not OP, but I can answer the question as if it was addressed to me. I believe that a lot of "real life" code can be simplified because I've had way too many cases where I open some program and remove 60 to 80 percent of its code without affecting the overall logic. (This usually includes obvious duplication, needless abstraction layers and things that reimplement functionality of standard libraries.)

The difficult part usually isn't the restructuring itself, but understanding what the program is supposed to be doing in the first place. Fortunately, deleting code is one of the best ways to learn about what it's doing. You need some good tooling to do this safely, though.

ArkyBeagle• 10 years ago

It could be that the reality reflected by the code base is simply complicated. It could be that technical debt isn't measured properly or at all.

It could be a "that's your problem, buddy". That's more likely.

jsolson• 10 years ago

There are two common ways in which I've seen this happen.

In one, the code started simple and evolved in place to accommodate bugs or additional use cases. Some refactoring has happened in the past, and that added some complexity to the overall project, but still not all of the abstractions were right. Further refactoring may have been attempted, but proved too involved given the value of the task at hand and the complexity the code had already acquired. The code is now more complex further raising the bar for refactoring when the next change comes along.

In the other, substantial effort went into designing the code to be flexible. It was recognized that not all use cases could be understood at the outside, and that refactoring things mid project often fails due to time constraints. A design was arrived at best on the most complete understanding of the requirements at the time, and that naturally design had a certain amount of intrinsic complexity to it as the requirements were complex. As development progressed, it was discovered that the design was not ideal for the actual requirements of the project. Plumbing was added and layers were tacked on to work around the issue.

What I conclude from this that you're damned if you do and you're damned if you don't.

Practically, I generally prefer working with code that was arrived at by the first approach. It often has a few good abstractions in along with a bunch of methods or classes that just combine too much stuff in one place. Perhaps some things are plumbed into places they shouldn't be. This can, with time and patience, be peeled apart into something a bit more manageable. By contrast, my experience with the second strategy is that it leads to a much less manageable mess where most time is spent finding the code that actual does anything. There is much more plumbing to rip out and seeming innocuous changes have far-reaching consequences.

wlievens• 10 years ago

The mismatch between the high-level notion of programming (solving interesting problems) and the daily routine is there because in practice only a relatively small part if code deals with domain knowledge, and the rest deals with mundane technicalities (persistence, validation, security, logging, diagnostics, user interface technicalities, command routing, data translation ...). The latter part certainly has its share of interesting challenges, but most of it is boring cruft.

twa9274• 10 years ago

Mathematical proofs of correctness of even simple programs WITHOUT the mentioned technicalities are very complex (multiple times longer than the actual programs). This suggests that there is a lot of inherent complexity in the core software.

wrp3• 10 years ago

I have a similar story. After taking a not-unusual academic path from Math through Linguistics to Cognitive Science, I eventually got started in programming to support my research. I had previously avoided programming largely out of fear. When I thought of the effort it took me to produce a half page of correct mathematics, I blanched at the thought of trying to write thousands of lines of working code.

When I finally delved into Perl, Python, C, etc. and reading open source code (mostly C, mostly greenfield projects), I was flabbergasted to discover how much coding is by guess and by golly. I am genuinely unable to grasp how a person with the intelligence to master the technical details that programming requires could be so lacking in ability to elegantly conceptualize a problem domain and produce suitably organized code. I have come to wonder if it isn't a psychological inhibition. Like some people keep their desk obsessively neat but others work amid a filthy messs, not because they're too lazy to clean but because they're more comfortable that way.

Once in a while, I see a programmer demonstrating the clarity of analysis I'm accustomed to seeing in science (and even the humanities). This is the kind of programmer who will produce a shorter and clearer solution in C than the average programmer will produce in Python. It's rare, though, so I'm constantly amused/irritated by the frequently stated assumption on HN and elsewhere that programmers have superior analytical skills.

pointernil• 10 years ago

For any non-trivial (code size, complexity etc) programming-problem

there are programmers with little analytical skills but given enough time they will end up with code doing mostly the right things... unfortunately from the out side there is no way to tell to what degree the code evolved from try and error or from true analysis...

Then there are skillful and analytical programmers who over the course of the dev cycle for a problem burn out their "analytical mana" due to simple exhaustion, external pressure or both or simply because the problem grows conceptually over their 'head-room' during the work on it... backtracking and reworking already written down code is still cumbersome, always a risk and unpleasant ('trashing something already done')

Then there often is time eroding the most clean, analytical code with every little update into a mass, unless ofc energy is spent to re-analyse and rewrite.

Then there are ofc some differences between areas in which programming is used.

'how much coding is by guess and by golly'

I hear this quite often from ppl with math, physics background etc. who are often accustomed to read expositions of ideas in math papers: presenting the final versions of the formulas.

Code quite often is more equivalent to the notes a mathematician would make and use before summarizing them into the published paper.

Those Math-Whitepapers are executed in the heads of the humans so they tend to try to keep it clean and minimal and analytical sound.

Those Code-Artefacts are executed by machines which don't care at all about such things, thus as long as the humans are satisfied with the end-results the 'inner-structure' tends to erode. Code is read more often than written but it is often only read later and by other people, so ... first things first: it has to work, right? ;)

But yea, I mostly agree that many programmers slide down into a habit of very special kind of

"reactive programming" ;)

where they try to hit the target by incrementally zeroing down on a solution reacting only on the results of the previous version of the code. Due to the action - reaction structure this tends to be quite flow-inducing and satisfactory... but the results are seldom analytically pleasing or sound.

kriro• 10 years ago

Note: This was published in 2001. Here's a Scholar link of other papers citing it (none of the top ones are very recent) in case anyone wants to dig deeper:

https://scholar.google.de/scholar?cites=9767640341703630929&...

A good search term is "computational thinking" which probably needs to be combined with a couple of synonyms for "non-programmer".

wrp3• 10 years ago

There are two aspects of this study that I think nullify its value.

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't take me long to become comfortable with it.

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.

I will also point out that English-like programming languages have been promoted for decades and they haven't caught on.

erez• 10 years ago

I always tell non-programmers (and sometimes programmers interfacing with the systems I maintain):

Don'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.

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

Related Stories