
Blurring the Line Between User and Programmer - stevekrouse
https://futureofcoding.org/episodes/042
======
ohduran
Imagine we build the ideal programming language that both technical and non-
technical humans alike can understand. What does it look like?

I'm thinking about Excel spreadsheets. Let me elaborate: a non-technical guy
creates a monstrosity: one of those spreadsheets that "works", and tasks the
programmer with maintaining it. At every level, the non-technical understands
what's going on, because he is familiar with most formulas (that's the beauty
of Excel IMO). He just wants the programmer to focus on making sure that
everything works "just fine".

Forget for a moment about what "just fine" means. Let's say they can go back
and forth until they can convey what they mean to each other.

My point is that the very first sentence of the post is not correct.

> “The world’s been divided into people who can make software, and the people
> who use software all day, and basically we think that that paradigm is not a
> good one. It feels kind of broken,”

A non-technical person CAN indeed make software... he just can't make
maintainable software, and eventually his incompetence backfires.

If I'm correct, then Corda and other tools aimed at "making the laymen build
software" are solving the wrong problem. The spreadsheet, and before that a
piece of paper, just solved that problem. What the laymen need are the mental
tools that a programmer uses to "speak" about software, in the sense that what
a human can see on the screen isn't the whole picture of what technical people
mean by "software".

Hope I made myself understood. Can anyone assist? Am I wrong?

~~~
friendlybus
I agree with you, it's a basic problem for any skill. Anybody can draw, but
drawing fine art requires the knowledge of the structure and tools used to
draw it.

I suspect trying to build a programming language to stop having to think like
a trained programmer, is a doomed project.

~~~
pbhjpbhj
But, I can well imagine an art assisting program that I can feed my doodle to
that can return a photographic (or other artistic) rendering of a person in
that pose, even such that I can rotate the image, alter the pose, perhaps even
animate it.

I still perhaps wouldn't understand why I should have chosen other poses, or
why the lighting doesn't work, or why my material choice for the clothing
fabrics hampers the expression I was seeking ... but it seems like an artist
could come and touch up those elements.

Surely a similar level of thing could be done for programs (eventually)?

I'm a non-programmer in a new work environment where I'm feeling like I want
to modify all the programs and add some functionality. In particular I've a
lex-parse process I'd like to automate, relatively easy to describe sufficient
to do it (with time I'll probably do it myself in PHP/python). But, doing that
"doodle it" routine for such a simplistic app would be really useful.

~~~
friendlybus
>but it seems like an artist could come and touch up those elements.

I don't think you can have artists or programmers 'touch up' a generated model
post-facto without making compromises on the valuable bit of the project.
Programmers will always be needed to understand the program inside and out, so
it can be tweaked and controlled. Artists will always be needed to define the
piece from top to bottom, so it can be controlled.

Either that or lots of hair being ripped out trying to control why the top lip
on the 3d model keeps moving up and down when technically there's no muscle in
your top lip, and it makes the one scene your big dramatic moment look janky
as hell so you have to spend nights trying to figure out why the ML program
made that, and it turns out nobody knows except the guy who made it and he's
off in the bahamas helping take care of his sick wife so you have to scour the
tech support community for hours...

Or that perfect line you drew across the face of a landscape painting is now
pushed off to one side from running it through an art-style-transfer ML
program and that destabilizes all the hidden geometry you were relying on to
make the piece feel alive and now you have to know why the program did that,
if you want to change it.

>Surely a similar level of thing could be done for programs (eventually)?

Yeah I think so. It's coming quite rapidly. Two minute papers is a scary
youtube channel.

Any generative painting, cg model or computer program is going to fill the
"kinda good enough" category and change the job of the trained professional to
be controlling all the assumptions built into the generative program. You will
make a super-powered tool, which is awesome, but alas human
knowledge/skill/brains remains different to computers.

~~~
TheOtherHobbes
It's very hard to do high-quality generative art/music/poetry/anything without
a complete model of human cultural associations, perceptions, and metaphorical
frameworks for conceptualisation.

As you say, most generative work is empty because it's just form. Human
creators manipulate form to communicate content. There's a message, and art is
judged as much on the sophistication of the message as on the form it's
carried in.

Form without content can be an interesting technical experiment, but it's
culturally massless and kind of boring. Not to mention _wrong_ in a
destabilising way - like someone speaking random syllables that make
occasional sense, but don't form a coherent message.

So the most successful generative work cheats by automating processes of
cultural reference - like style transfer - or by adding levels of formal
complexity that would be very difficult to handle by hand, but can at least
produce something that seems a little original and surprising.

The less successful work doesn't even get that far.

Automated software generation is going to have similar problems. You have to
parse intent, and then balance it against practicality. Getting that right is
so hard humans really struggle with it, so I can't see machines being better
at it any time soon.

~~~
ScottBurson
> Form without content can be an interesting technical experiment, but it's
> culturally massless and kind of boring. Not to mention wrong in a
> destabilising way - like someone speaking random syllables that make
> occasional sense, but don't form a coherent message.

Couldn't read that without being reminded of this:
[https://en.wikipedia.org/wiki/Prisencolinensinainciusol](https://en.wikipedia.org/wiki/Prisencolinensinainciusol)

As the composer says, "I thought that I would write a song which would only
have as its theme the inability to communicate. And to do this, I had to write
a song where the lyrics didn't mean anything." If you haven't heard it, pull
it up on YouTube — it's quite an experience.

------
OJFord
Tool itself is at [https://coda.io](https://coda.io), seems similar to but
more powerful than Notion, ([https://notion.so](https://notion.so)) which I
have used, with pricing to match.

Tangentially, it's good of Panic to link to the above at
[https://www.panic.com/coda/](https://www.panic.com/coda/) \- or perhaps they
were just getting fed up with dealing with people in the wrong place!

~~~
AlphaWeaver
I'm a little bit obsessed with keeping up with solutions in this space, and
I've been watching both Coda and Notion for a while.

Coda actually just released their v2.0 a few days ago which has brought some
much needed bugfixes and stability improvements. I've had some time to discuss
larger strategy with their team, and I can tell they're working really hard to
"strike the right balance" between easy to use / discoverability and
capability.

I definitely like their product, and am following them going forward. If
you're at all interested in this space, you should check out Coda just for the
sake of seeing where we are (as a field) in solving this problem.

~~~
OJFord
> I can tell they're working really hard to "strike the right balance" between
> easy to use / discoverability and capability.

That's exactly it, I was saying to a colleague earlier that I wish* there were
an open-source self-hostable option, but the closest I've found - Trilium
Notes - is way further over to 'capability' than 'easy to use /
discoverability', to use your spectrum. (I was a bit harsher, describing it as
a spectrum from good UX to programmable.)

*(mainly because exports aren't that useful - Notion exports some but not all data, and then you've got to sanitise (or get lucky) the CSVs it does export for the new tool)

------
Discombulator
I have not looked into Coda yet, but have a few observations on the user /
programmer divide.

To me, spreadsheets are just another programming paradigm. I have seen
business users build impressive things using Excel (excluding here VBA). I'd
even say that in terms of raw productivity (i.e., just in terms of business
problems solved over time, without any consideration for maintainability etc),
the spreadsheet paradigm is vastly superior to the regular textual programming
paradigm – as long as the problem is simple enough. And most of normal
business is dead simple.

As soon as the process or problem hits a certain complexity, the Excel
solution becomes painful to use, understand and change. I believe this is in
part specifically fault of the tool - while Microsoft has been doing a great
job in terms of power user features (Power Query, PowerPivot), they have
apparently not been willing to extend the spreadsheet paradigm itself to meet
the requirements we demand from business software, which is a pity and missed
opportunity.

Secondly, what I have also observed is that most users, even users building
complex workbooks, are not willing to make the jump to textual programming
(e.g., VBA). I think programming in general requires a high level of
frustration tolerance that most people are not willing to bring up except when
they really have to (e.g., to use Excel, which is basically unavoidable in 99%
of businesses).

To summarize, there is still room to come up with a system that makes building
simple things as simple as Excel, while being flexible enough that it scales
to meet production software requirements.

------
mmphosis
I like going the other way where as a "Programmer" I don't need to program so
many things. Most "things" can be declared: text, html, lists, trees, tables,
databases, ...

For example in XFCE, I can add an "Applications Menu" to the menubar (panel)
and use a custom menu file with a list (or tree) of programs to run. The
icons, labels and how to run the programs are declared in .desktop files -- no
"programming" required.

------
WickedFlick
I'm not terribly excited with the idea of making spreadsheet style programs
easier, but I suppose it can't hurt, either.

Personally, I think programming languages becoming closer to spoken languages
would be more useful. I first learned of that concept from this Reddit thread:

[https://www.reddit.com/r/linux/comments/da718w/i_think_the_f...](https://www.reddit.com/r/linux/comments/da718w/i_think_the_foss_movement_should_want_to_maximize/)

There, the author of the thread talks about the benefits of Inform 7, a
programming language specifically designed for creating interactive fiction
games. It's an incredibly impressive bit of work, and is the most promising
path toward getting regular folk into programming.

I also came across this interesting article from Wolfram:

[https://blog.wolfram.com/2010/11/16/programming-with-
natural...](https://blog.wolfram.com/2010/11/16/programming-with-natural-
language-is-actually-going-to-work/)

which goes into natural-language programming and how they will (hopefully)
become dominant in the future.

~~~
pintxo
Do you have an idea on how to solve the fuzziness and ambiguity problems in
spoken language?

This IMHO is the largest problem with spoken language, no parentheses, lots of
synonyms/homonyms etc.

------
jbattle
We've all seen incredible things built in spreadsheets. Spreadsheets are
plenty powerful. I haven't met a clever+motivated person yet that couldn't
build something incredible in a spreadsheet.

What I think is missing is a way to help the author (and other team members)
make sense of the artifact as it gets more complex.

Much of the development in computer languages and toolsets in the last 50
years have helped us make sense of ever-increasingly complex programs.

With spreadsheets for example, you are basically forced to find a cell that
seems to have data you like. Then you have to back-track formula references +
check for macros/scripts and _hope_ that no references have broken.

I humbly submit this is a problem that a team like the Coda team should be
solving.

~~~
infogulch
Excel needs exactly one thing to blow open the doors on productive
programming: a new "function" data type. Since it's just a data type, you put
it in a cell just like any other data type. Have some way to call it, like
`A1(arg1, arg2)` or something. Now you can leverage the full capabilities of
Excel to manage it, name it (named ranges), etc just like other data.

A more sane expression syntax might be nice too, but isn't necessary to make
Excel more productive for abstract programming.

~~~
jagged-chisel
Sounds like you want to move VBA into the cell. I issue no opinion on doing
that, just offering an observation.

~~~
infogulch
Actually you make a great point (thank you!), but honestly I wouldn't want it
to have anything to do with VBA.

For a feature like this to be successful imo it needs zero sandbox concerns; a
user should never be prompted to downgrade to a lower security configuration,
it has to be built in and available by default in every sheet. I don't see VBA
ever being safe enough to enable by default everywhere. VBA is just an escape-
hatch to a 'real' programming environment; my claim is that excel sheets &
formulas alone could _be_ a 'real' programming environment in its own right,
no escape hatches necessary. All just by adding one feature to the existing
formula language. The reason why excel is so popular today is its simple and
understandable expression language and a unified spatially-oriented layout for
code and data. Just shoehorning VBA into a cell loses all of the
understandability of the simple excel formula and brings with it all the
baggage of the old way of needing to manage source code. I think we can do
better than that for normal everyday excel documents and normal users.

~~~
xscott
I completely agree and have been thinking the same thing for a while now.
Another reason you need the function language to be really integrated with the
rest of the spread sheet (unlike VBA) is so that global variables are also
visible in the dependency tree and topological sort. For instance, imagine a
cell containing the following lambda function:

    
    
        function (x, y) { return A1*x + y; }
    

It's clear that if the user changes the value in the A1 cell, any other cell
which calls this function should be updated to reflect the new result. In
addition to the arguments to the function (x and y), A1 is also an implicit
parameter.

------
chewxy
Sometimes I wonder if the people of the 1960s (i.e the people who came up with
lisp, multics, unix) had the right idea: to use a computer you should program
it.There are many programs, each does a different thing, you program your
final product by composing programs. Users of the final product are the
programmers.

I found myself being frustrated recently at Lifx smart lights. I had wanted to
put a slider widget on my home screen of my phone. There is no way to do that.
The only way is for me to write my own program. I started work on it, then had
to wade through ridiculous amounts of documentation on the lifx api site,
android docs. I still haven't finished it.

Consider on the other hand, if android were a massive lisp environment where
every API is available in the global scope - think emacs - how easy would it
be to program the things you want!

Now I use Lifx as an example and I appear to be bashing them. I am not. At
least Lifx publishes their API for consumption. Another time I tried to pipe
an app that generates white noise for sleep to another program (TL;DR I was
too cheap to buy a Sonos), but alas no publicly accessible API. I had to
hijack the BT stream to do something remotely useful to it.

You may think the solution is to get people to publish accessible APIs. I
think that's a band aid solution. The core issue is somehow programs have
become less composable over time. Far from the original ideals. Programs
become standalone products.

I think we as an industry made a wrong decision turning programs into
products. We should have kept programs as programs - make them super
composable, and then let the end user design their own products that fit them
best.

~~~
scroot
> Sometimes I wonder if the people of the 1960s (i.e the people who came up
> with lisp, multics, unix) had the right idea: to use a computer you should
> program it.

It's the right attitude to take, but let's try to provide some definitions.
What does it mean "to program"? Certainly we have contemporary ideas of what
it all involves. But at the end of the day it's hard to come up with a more
encompassing definition than "telling a computer what to do (and possibly what
to do later)." This means that by merely "using" a computer (ie through a GUI
or whatever -- manipulating it somehow) one is, by this definition, doing some
kind of programming.

With that definition in mind, we now see that the systems we have provided
users are completely hamstrung. We have given them limited environments and
languages (languages here being mostly of a visual/UI variety) to work with.

What's worse is that we have goo examples from even recent history about how
alternatives can work: Visicalc, Hypercard, Smalltalk, etc.

Insofar as these conversations rely on discussing "programming languages" \--
a loaded term, and only part of the picture really -- rather than whole
"computing environments," then we tread further down a losing path for
everyone.

~~~
marcosdumay
> What does it mean "to program"?

Whatever definition you end up with, it must have equal representation of data
and code.

Current GUIs are have the same problems as the 50's analog computers that
required somebody inside them plugging cables all day long.

------
golover721
What id love to see more is blurring the line between user and designer. Too
often software gets in the way of the user and simple tweaking to an interface
etc. can make a world of difference. Unfortunately this is usually either not
possible or involves a user navigating endless configuration options or worse
configuration files. Maybe that’s not a big deal to us in the software
industry but it is a huge problem for your average user.

~~~
AnIdiotOnTheNet
I agree. There's no reason we can't have this, we've had tools like Delphi and
VB for a long time now. Why can't I just choose widgets from a palette and
make my own Outlook interface?

Maybe it could even be taken a step further and turn it into a UNIX pipeline
composition equivalent in GUI form. Trying to imagine what a system could look
like, I see a kind of tiling window manager in which you can place arbitrary
widgets (list views, sliders, text entry, etc) and hook together their inputs
and outputs, maybe with a little scripting glue.

------
tempodox
According to my own distinction, _Blurring the Line Between User and
Programmer_ is unpossible:

A user is someone who asks why a software is _not_ working (and even in the
21st century this is still far more common than it should be).

A programmer is someone who asks _why and how_ a software is working.
Eventually this also includes failure modes, so the user's question above will
not stay unanswered forever.

~~~
mcherm
> Blurring the Line Between User and Programmer is unpossible

And why on earth do you believe that this difference in mindset cannot be
taught?

~~~
scroot
This is (sort of) one of the sticking points people like Kay and especially
Papert made. Because all computing is interactive, it is always an ongoing
part of a more general "learning process." There are many types of learners
and ways that they can internalize otherwise complex systems/concepts. It is
the job of the computing environment to be flexible enough to take advantage
of each person's particular method for learning how to properly (and
powerfully) manipulate it.

Lots of talk about spreadsheets in here, and rightly so. See also Hypercard.
These systems are (were) incredibly popular, and regular people were able to
do things with them that they could not in other media. It's largely because
the systems they represented were well designed -- not because people had some
particular competency in "abstract thought" or "systems thinking." We are all
human and, for the most part, we all do that stuff one way or another.

------
mfer
This reminds me a lot of Word. You can embed a spreadsheet and you can add
code to the document (I even remember using VBScript back in the day). What's
old is new again?

------
zupa-hu
Not directly related, but The Whole Code Catalog seems to be a really
interesting collection.

~~~
zupa-hu
To avoid confusion, it's from the same author:
[https://futureofcoding.org/catalog/](https://futureofcoding.org/catalog/)

