I've been thinking about this quote by @jonathoda that @tomasp shared at https://twitter.com/tomaspetricek/status/1188835828933496838?s=08: "Why isn't there something as easy to use as spreadsheets, but as powerful as programming?". This made me ask a different set of questions: 1) What characteristics of spreadsheets are believed to directly contribute to the success of spreadsheets as an end-user programming tool? 2) Has anyone attempted to design a non-spreadsheet-based programming tool by using these characteristics as a roadmap? Regarding question #1, I found this excellent paper at https://www.miramontes.com/writing/spreadsheet-eup/. I haven't found anything else quite like it and was wondering whether anyone here knows of more research like it (I plan to write the authors as well). Regarding question #2, I found lots of projects that explore the programmability of spreadsheet tools, but that's not what I had in mind. Thoughts?

You can program in spreadsheets just fine :)

Still, it's hard to argue with its success in adding hundreds of millions of new "programmers"

In another thread, I posted a quote from John Hanacek's thesis "As We May Sketch" which discusses this: In Don Norman’s “The Design of Everyday Things” he provides ‘principles of good design,’ which are: * Visibility. By looking, the user can tell the state of the device and the alternatives for action. * A good conceptual model. The designer provides a good conceptual model for the user, with consistency in the presentation of operations and results and a coherent, consistent system image. * Good mappings. It is possible to determine the relationships between actions and results, between controls and their effects, and between the system state and what is visible. * Feedback. The user receives full and continuous feedback about the results of actions. Traditional “typed statement” programming environments live up to none of these criteria. In traditional programming it is often very difficult to determine relationships between operations and results. The feedback is not continuous and because of syntax constraints often a program being modified is not in a state where you can see the results. Systems like spreadsheets are better, since they offer easier to choose alternatives and usually allow you to see the results with just a click, providing a nice feedback loop. Norman concludes that with spreadsheets “it felt as if you were working directly on the problem, not on a computer.”

Thanks. I'll give it a read.

There's some research from computing education around tools for bulding and developing notional machines

OK, but I'm wondering about design credit

I too was thinking precisely about this tension last week, especially the Reinhart/Rogoff kerfuffle: https://futureofcoding.slack.com/archives/CLYCGTCPL/p1572456721136600?thread_ts=1572002424.061800&cid=CLYCGTCPL Summary: our tools try too hard to meet people where they currently are, rather than to also be opinionated about where they should be. Programming in spreadsheets is possible, but spreadsheets don't seem to be very good at nudging people to think about architecture or testing. Design sense and testing feel like essential, timeless mindsets for end-user programming. You have to teach them to get comprehensive end-user programming, and you can't just paper over the cracks with better tooling. The tooling has to support education.

The question isn't about how to make spreadsheet users into better end-user programmers, or how to help spreadsheet users with testing, or how to catch spreadsheet errors, although all these are needed. The question is, what is it about spreadsheets that makes them into programming tools with the largest base of programmers, and can any of this be used to design non-spreadsheet-based programming tools for programmers that are "as easy to use as spreadsheets."

I've heard your question asked a few times, and my recent insight was that asking it in isolation can lead to misleading conclusions. People tend to either want to copy everything from spreadsheets or ignore them entirely. It may be worth asking as a first step what characteristics of spreadsheets are worth carrying over. But perhaps this feels like a response to "how to do this in Python" that says "have you considered Ruby?" Apologies, and I will see myself out 😕

@Doug Moen “*Feedback*. The user receives full and continuous feedback about the results of actions.” This is really good point. Feedback is the largest gap in what’s involved with how we currently do programming. A programmer instead has to keep a simulation in their head about what changes their code will eventually have once it’s all constructed.

One challenge with feedback for code changes: over-training on one input/example can create regressions elsewhere. So how can you get feedback on multiple inputs/scenarios at once? Has anyone come up with a better visualization for big-picture feedback than than a list of tests going green?

@Kartik Agaram "It may be worth asking as a first step what characteristics of spreadsheets are worth carrying over." Exactly. And as a second step, it may be worth designing a PL and tool based on these characteristics.

First step? Exactly what @Doug Moen said (and so glad to see someone quote Don’s book here!): 1. Visibility - just like excel shows states and formulas leading to them, so should editors. The data and it’s structure should be the priority, not the code. 2. Good model - Our editors are either text editors or UI editors, what we need is a visual Lisp - a list is a great general conceptual model, a tree is an even better one and everyone understands it. Excel has tables. Everyone gets tables. 3. Mappings - oh god IDE’s are mostly terrible in this one. Too much information everywhere and you gotta be an expert in the IDE to understand what any mapping does. Excel is not great at this one but pretty good tho, everyone understands it and you can do more if you know the options beyond basics - but don’t need to know them. 4. Feedback - Result is also a part of the process and should be treated as such. Pretty obvious what we need here from excel.

here are a few other things about excel that i don’t see talked about very often: 1. started with existing conceptual tools (double entry accounting, arithmetic, graphs and charts) and gradually extended them, rather than forcing early adopters to immediately understand a whole new abstraction before they could get anything done 2. direct editing: you don’t have to issue commands to get data entry done. you don’t have to click a link to get to a different part of a sheet. you just click on cells to edit them. if you want abstractions you learn more complex menus and commands but (given enough time and patience) you could manually do pretty much all of excel with the basics. this also makes learning easier 3. saved state: people copy scratch info to random areas of their tables ALL THE TIME and it’s an incredibly rare feature. wish i had it for the browser 4. your data is never “finished”. every spreadsheet is a breathing document. they get updated all the time and work in almost every intermediate state. it’s data transformation with structurally typed holes 5. ubiquitous metaphor. everything is a table 6. types are visual. you know that blank fields will give you different results. you can see which columns have them just off the top of my head