Bayle Shanks's website: proj-oot-old-150618-ootSpreadsheetNotes2

some spreadsheet pros and cons:

pros: " Spreadsheets have a largely nonsymbolic representation of programs. The only symbolic representation used is the simple expression language, which people can easily learn as consists only of constants and function application. Of course, every spreadsheet program has some ad hoc language for defining new formula, but that’s outside the usual spreadsheet model and gets used very rarely. We can think of the spreadsheet as a limited kind of application-building toolkit. It supports a form of interactivity, in that we may select a location for editing, and updates occur in response to these edits (conceptually no different than any other application, be it Photoshop or Twitter). There’s no separate step of ‘running’ the program and we’re encouraged to consider the UI as just a way of viewing a program, rather than a separate artifact produced by a program. See viewing a program as a UI. The user can easily construct functions that manipulate sequences in an inductive fashion, considering only concrete inputs. For instance, the cell A2 takes the value = A1 * A3 + B$7, and the user drags to extend the definition to build a whole sequence. Of course, a programmer has no trouble generalizing this sort of thing and just writing a step function that uses symbolic inputs, but it requires less learning to do things the spreadsheet way. Lastly, and this might seem dumb, but a 2D grid as a template is actually a surprisingly nice starting point for a lot of computing tasks and layouts. In terms of approachability, it is much easier to modify an existing template than it is to start with a blank canvas and create entirely new content. A blank canvas requires that the user have a vision of what they want to create, which they execute on by understanding the means of abstraction and means of combination. In comparison, the ‘modify a template’ mode of spreadsheets lets the user get away with just reacting to what’s on the screen. Bret Victor talks about some of this in Learnable Programming. I won’t argue here that one modality is inherently better than the other, but part of the appeal of spreadsheets is they do support the ‘create by reacting’ modality better than traditional programming. "

cons: " They are entirely first-order. There is basically no support for abstraction (though all spreadsheet programs have some ad hoc language for defining new formula), and certainly no ability to define higher-order functions. Without the ability to define new abstractions, it’s impossible to manage complexity. The way people reuse spreadsheets is largely by copying, pasting, and modifying. Naturally, spreadsheet apps have some grown ad hoc ways of linking between spreadsheets, but this is all a very very poor substitute for a real programming language. The forms of interactivity spreadsheets do support is too limited. Why can’t I render a numeric cell as a slider that I can move back and forth to see things update instantly, for instance? And even when some form of interactivity is supported, it’s usually in some ad hoc, unguessable way, rather than something unified and obvious. The 2D grid which seems like a helpful starting point actually becomes quite annoying for more complex spreadsheets. I’m just declaring a collection of variables, why the heck do I have to worry about where they are positioned? Why the heck am I refering to values by position rather than by some meaningful name?? Also, the use of a grid often leads to lots of futzing around to deal with unwanted interaction between row heights and and column widths for logically unrelated parts of the layout. " -- http://pchiusano.github.io/2015-03-17/unison-update5.html

the cons each suggest an obvious ways to improve spreadsheets (i would expect most spreadsheets already do these, though?):

have a way to make 'libraries' and 'imports' and 'function calls'
have a way to change the 'UI mode' for each cell
have a way to create aliases, a mapping between names and cells

as pchiusano notes elsewhere, having typed cells is important too. And as others have suggested, having a way to do unit tests is important too.

also,

" David Barbour • 2 months ago

A useful variation on spreadsheets would be to make every cell a lens on some external value. A conventional spreadsheet is then modeled as a lens over unit. But if a spreadsheet becomes an editable view of external data, they become far more composable, a basis for shared UI (via pubsub on the external data), etc..

" -- http://pchiusano.github.io/2015-03-17/unison-update5.html#comment-1922324205

in response to the Unison language/IDE/platform: " Ok, so I spent about an hour casually reading the posts, watching the demo videos and glancing at the code. I agree with your premise and I like a lot of the implementation so far. It's great to see more innovation and research in this area alongside Light Table, Eve (which seems to be going in a similar direction with spreadsheets), NoFlo? and others.

...

Adding this as an optional layer to an existing editor might help work out some of the ergonomics. Performance issues aside, building on top of Atom might be a good choice since it's mostly web based like the current UI in the demos. Similarly, a custom kernel or cell type in ipython might get the ideas into daily use. " -- https://news.ycombinator.com/item?id=9514335

https://jupyter.org/

in reply to Unison:

jakub_h 22 hours ago

The things you're describing are EERILY similar to some stuff I've been conceptualizing and thinking about recently, as inspired by the VPRI people's work/OMeta/Shen. I'd just remark that...

"The program is a UI, and UI interaction is programming. Unison panels take the idea of spreadsheets, which blur the distinction between UI interaction and programming, to its logical conclusion."

...this blurring between programming and interaction (which I've also thought of) probably offers a potentially viable path to much more powerful voice control of devices, since programming APIs serving as user interfaces can now also (besides graphical UI) implicitly define strict grammars for structured voice input. That's the one thing I thought of that I didn't see mentioned there.

white-flame 21 hours ago

One term I didn't see on the page, but you should look into examples of if you already haven't, is "structure editor". That's the notion of a source code editor which doesn't allow free-form text editing, but creation of well-formed language semantics.

melloclello 20 hours ago

Also, "tree editor".

" The program is a UI, and UI interaction is programming. Unison panels take the idea of spreadsheets, which blur the distinction between UI interaction and programming, to its logical conclusion. We don’t write a program to produce a UI as output, we write a program which is viewed as a UI. Interaction with the UI is, quite literally, programming, though the user doesn’t have to be aware of it. This model means we can solve problems of validation, autocomplete, and exquisitely context sensitive help once, in the Unison editor, and solve them in a principled way using the lens of programming languages and type systems, rather than recreating this functionality in ad hoc ways for each and every UI we write. " -- http://unisonweb.org/2015-05-07/about.html

---