Imagine we build the ideal programming language that both technical and non-technical humans alike can understand. What does it look like?<p>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".<p>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.<p>My point is that the very first sentence of the post is not correct.<p>> “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,”<p>A non-technical person CAN indeed make software... he just can't make maintainable software, and eventually his incompetence backfires.<p>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".<p>Hope I made myself understood. Can anyone assist? Am I wrong?
Tool itself is at <a href="https://coda.io" rel="nofollow">https://coda.io</a>, seems similar to but more powerful than Notion, (<a href="https://notion.so" rel="nofollow">https://notion.so</a>) which I have used, with pricing to match.<p>Tangentially, it's good of Panic to link to the above at <a href="https://www.panic.com/coda/" rel="nofollow">https://www.panic.com/coda/</a> - or perhaps they were just getting fed up with dealing with people in the wrong place!
I have not looked into Coda yet, but have a few observations on the user / programmer divide.<p>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.<p>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.<p>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).<p>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.
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, ...<p>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.
I'm not terribly excited with the idea of making spreadsheet style programs easier, but I suppose it can't hurt, either.<p>Personally, I think programming languages becoming closer to spoken languages would be more useful. I first learned of that concept from this Reddit thread:<p><a href="https://www.reddit.com/r/linux/comments/da718w/i_think_the_foss_movement_should_want_to_maximize/" rel="nofollow">https://www.reddit.com/r/linux/comments/da718w/i_think_the_f...</a><p>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.<p>I also came across this interesting article from Wolfram:<p><a href="https://blog.wolfram.com/2010/11/16/programming-with-natural-language-is-actually-going-to-work/" rel="nofollow">https://blog.wolfram.com/2010/11/16/programming-with-natural...</a><p>which goes into natural-language programming and how they will (hopefully) become dominant in the future.
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.<p>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.<p>Much of the development in computer languages and toolsets in the last 50 years have helped us make sense of ever-increasingly complex programs.<p>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 <i>hope</i> that no references have broken.<p>I humbly submit this is a problem that a team like the Coda team should be solving.
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.<p>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.<p>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!<p>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.<p>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.<p>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.
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.
According to my own distinction, <i>Blurring the Line Between User and Programmer</i> is unpossible:<p>A user is someone who asks why a software is <i>not</i> working (and even in the 21st century this is still far more common than it should be).<p>A programmer is someone who asks <i>why and how</i> a software is working. Eventually this also includes failure modes, so the user's question above will not stay unanswered forever.
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?