From reading the article and reading the comments here it seems to me that giving "programming" power to the masses does not mean they will want to use it to actually implement their individual uses cases, especially if they are one time or rare use case. Besides all that talk of applications being deconstructed into libraries with a programmable interface on top of it is nothing but a pool of APIs with something like IFTTT on top of it.
There seem to be 2 major friction points that prevent one application to be used by another or being a part of a flow:
1) Generating an API
2) Consuming an API
If there was a way to automate API generation based on parameters then presumably a person could create an API endpoint that gets them the data they want and then use that in an IFTTT recipe.
However to use it in an IFTTT recipe the API should also have a specification generated to we can automate a program like IFTTT to look at the specification and create the API consuming code.
So from a simplistic viewpoint it would be better to think of how to create a standardized way to auto generate APIs.
Generates code from parameters (types). If parameters form a function, then code will implement it. If function final type is IO a, then implementation code will be side-effecting action.
And, having a function f for a type T, you can ask for a function g that will call f, giving you a type Q. I guess that would stand for "Consuming API".
It seems obvious that the current application paradigm does not scale.
I have over 100 different apps on my phone, and that number only keeps growing. It seems like there's a new app for everything nowadays. You'll soon (if not already) have an app for your car, your door lock, your fridge, your fan and your shoes. How is a person supposed to navigate all of these apps and get the most of it's environment when drowned in that uncalled-for diversity?
I probably have created over 1000 online accounts, and I don't see that slowing down either. The lack of communication between apps makes it very difficult for new players to receive any significant contribution from their users. Why would I invest in a platform/service that can disappear the next day and force me to start over? The semantic web seems to provide a quite elegant solution to this problem.
It seems to me that we're only going to overcome this problem once we stop designing UI by hand. Once we shift our focus away from guiding the user experience, and put the effort toward improving the semantics of the data, will the generalizations of UI emerge and unify all experiences under one language.
>How is a person supposed to navigate all of these apps and get the most of it's environment when drowned in that uncalled-for diversity?
We could assign each app a name, and design a universal app launcher that, given a name, would navigate to that app, launch it, and execute it a safe sandbox for the user. As a bonus, now any app in this universal app launcher could link to other apps, so that apps could launch other apps as necessary. That way, the complexity of keeping track of apps isn't up to the user, but instead each app presents links that allow the user to navigate to other apps as necessary to get their work done. Since apps would be connected to each other in a mesh, or web, and this launcher would allow the user to browse all of these apps, we could call this universal launcher a web browser ;)
EDIT: More seriously, this is exactly the problem that URLs (Uniform Resource Locators) are supposed to solve.
I agree wholeheartedly with the premise presented in this essay. And I hope that sometime in the future we collectively all realize the benefits and figure out the implementation.
Being nit picky but:
> I still can't get Gmail to do even simple tasks like schedule an email to be sent later or batch up all incoming emails containing a certain phrase into a weekly digest!
That's interesting because I completely disagree with the premise of the essay. The simple fact is, we've tried repeatedly to make programming environments that were accessible to non-programmers. Cobol. SQL. LabView. Visual Basic. The end result of every single one of those efforts has been exactly the same: a tool that the intended users do not use, and one that the programmers they hire hate to use.
There is a fair amount of accidental complexity with programming, but there is even more inherent complexity. Thinking about problems using strict formal logic is hard. It's not something that everyone has the time, patience or inclination to do. I am 100% in Bob's camp in that argument; I think it's utterly and completely unrealistic to expect the average person to know how to patch together APIs in order to deliver functionality. Moreover, I don't even think it's a bad thing. Most people call a plumber when their pipe springs a leak. Most people call a mechanic when their car starts spewing smoke. I think it's fair that most people would call a programmer when they need an application made.
People have also been trying to make programs composable for a long time. By 1990, they succeeded: Smalltalk, Oberon and Plan 9 all worked, though in very different ways. Plan 9 even dispensed with the head application, because you save typing a character when you implement it in AWK as NR<. And no one used these systems.
At this point it's clear that the average programmer, let alone the average user, actually likes getting paid to write mindless glue code and copy data from one spreadsheet cell to another. I've been teaching physics and maths for years, long enough to learn that normal people have a strong aversion to the sort of abstract thinking that these systems demand of them.
>At this point it's clear that the average programmer, let alone the average user, actually likes getting paid to write mindless glue code and copy data
Agreed. This is the point I was trying to make, but I think you said it better than I did.
Correct me if im wrong but the argument in the post is that currently, we do have unwilling and untrained world citizens, unable to compose useful programs/functions from baser functions and APIs. But he/she takes the utopian viewpoint; they can and will have a reason to learn. And those who dont will suffer or be at some minor or massive disadvantage. It was stated that at some point citizens of the world, on average didnt know basic maths. And on average, that changed or is at least changing...
So why not be hopeful that the modern laziness of the human who wishes to scroll through a twitter stream of Facebook feed slowly dissolves and is replaced by people who wish to make computation more useful to them? More personal to their needs, and more able to help them accomplish their goals of obtaining amd organizing knowledge and their life?
I agree with the premise, not that, currently, all of us are ready for such an implementation. It'll require a reboot of our education system, and what we think is important to teach in schools.
> Most people call a mechanic when their car starts spewing smoke. I think it's fair that most people would call a programmer when they need an application made.
The major difference between the mechanics world and programmers world is that one is 100% symbolic, the parts are (potentially) free, reusable, and non-degradable. Given someone knows functional math, and is provided with these free, reusable and non degradable parts, surely, itd be a much easier task than learning everything about cars and the ways they can fail.
This futuristic building block programming world still maintains professional programmers who create abstractions that are easily composed. After all, thats the hard part, right? (Beyond scaling and centralizing, which as the article points out, may be a problem caused by the need for centralization in the first place)
> I think it's utterly and completely unrealistic to expect the average person to know how to patch together APIs in order to deliver functionality.
I feel like you are making this sound harder than it really is. Again, its the easiest part of programming, and yes non programmers dont know how to do it, but is it any different (or difficult) than forcing or suggesting them to learn calculus (or pre-calculus) in high school?
> ... Visual Basic. The end result of every single one of those efforts has been exactly the same: a tool that the intended users do not use, and one that the programmers they hire hate to use.
Visual Basic 6 is the exception to your list. A LOT of laypeople used VB6 to create really useful programs. It is hard for people who weren't alive then to understand just how gigantic VB6 was (partially because VB6 predates the web).
Unfortunately, Microsoft killed VB6 with the transition to VB.net.
You want to be very careful where you're going with that. I've had to convert ad-hoc financial models written in Excel VBA into C#. The existing code was so bad, it was largely useless for actually learning what the system was supposed to do. I had to go back to the original analysts and ask them what they wanted their model to do. It was not a fun experience, and it's largely the reason I think that there should be a level of specialization with regards to programming. I felt like an electrician coming in to help with a homeowner's ad-hoc project, and finding that the entire house has been wired by the same (underqualified) homeowner, and now the building is a major fire hazard.
Yes, people use Excel to make complex applications. But it's the same as people jerry-rigging their own wiring, or attempting to use heavy machinery without the proper qualifications. It can work, but a lot of the time, it leads to collapse, disaster, and thousands of dollars in damage.
I've written about a related approach on 2011 with "Egont, A Web Orchestration Language" [1] and "Egont Part II" [2]. I imagined a giant spreadsheet/directed-graph metaphor where changes propagates and recalculates and people operate with other people namespaces instead of personal silos. In a way Facebook is in a good position of doing this but instead of focusing too much on recent news they should combine the capabilities of IFTTT with a data flow model and persistance.
I'm very slowly building myself what he calls a "programming environment" using python and rethinkdb.
It is very much just targeted at my own use. I'm not doing a lot to make it work well for other people, or non-programmers. But I still think it's an interesting technique that people here might like.
> Applications are bad enough in that they trap potentially useful building blocks for larger program ideas behind artificial barriers...
Through the lens of a developer, sure. As a consumer / user, you likely appreciate the simplicity this affords. Similarly, if you are a car enthusiast, you'd shudder at the thought of bringing your car to a Jiffy Lube for an oil change when you can pop the hood and do it yourself, but the majority of car owners are thankful they don't need to get under the hood and tinker with "all that stuff".
> "CardStack aims to create and maintain authoring tools that persist data in data stores that the user controls, rendering engines that enable scrumptious user interactions on the client while generating structured markup on the server, and distribution hooks into the native tools of popular social platforms and mobile operating systems."
I think tools like cap'n proto and rethinkdb are a step in that direction.
Rethinkdb comes pretty close to being a generic data store for arbitrary json, and cap'n proto does pretty alright with RPC across code bases.
I'm not entirely sold on a single, global, execution environment. But python is pretty nice for that kind of work flow. You can import from wherever. Soon, you'll be able to import from remote procedure calls.
I'm not sure what's going to work, but I think it is a solvable problem. We just need to focus on reducing API friction.
There seem to be 2 major friction points that prevent one application to be used by another or being a part of a flow:
1) Generating an API
2) Consuming an API
If there was a way to automate API generation based on parameters then presumably a person could create an API endpoint that gets them the data they want and then use that in an IFTTT recipe.
However to use it in an IFTTT recipe the API should also have a specification generated to we can automate a program like IFTTT to look at the specification and create the API consuming code.
So from a simplistic viewpoint it would be better to think of how to create a standardized way to auto generate APIs.