
The end of apps, and why UX designers should care about type theory (2013) - miguelrochefort
http://pchiusano.blogspot.com/2013/05/the-future-of-software-end-of-apps-and.html
======
palakchokshi
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.

~~~
thesz
[https://hackage.haskell.org/package/djinn](https://hackage.haskell.org/package/djinn)

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".

------
miguelrochefort
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.

~~~
quanticle
>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.

~~~
miguelrochefort
Please, you're giving me a headache.

My point is to get rid of apps (and websites), not make it possible to have
more.

------
NobleLie
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!

You _can_ do the latter with labels in gmail.

~~~
quanticle
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.

~~~
zyxley
But there's a programming environment out there that a lot of "non-
programmers" use all the time and use to make some very complex applications.

It's called Excel.

~~~
quanticle
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.

------
wslh
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.

[1] [http://blog.databigbang.com/ideas-egont-a-web-
orchestration-...](http://blog.databigbang.com/ideas-egont-a-web-
orchestration-language/)

[2] [http://blog.databigbang.com/egont-part-
ii/](http://blog.databigbang.com/egont-part-ii/)

------
traverseda
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.

[https://github.com/traverseda/rethink-
tools](https://github.com/traverseda/rethink-tools)

Python provides a way to import whatever functions calls.

Rethinkdb provides a generic data store. I can add fields (keys) to objects
(rows) as needed. This is somewhat analogous to pythons duck-typing.

It has excellent network transparency. I'll soon by trying to get a rethinkdb
server running on my phone, so I can load text messages into it.

I can also do basic queries across my data.

We'll see how it goes.

------
Ericson2314
Paul is now implementing the vision with
[http://unisonweb.org/](http://unisonweb.org/), check it out!

------
macandcheese
> 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".

------
100ideas
> "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."

[http://cardstack.io/](http://cardstack.io/)

------
hackaflocka
The author seems to be asking for all code to be written using a single
standardized language.

This premise won't work for me if I have to learn a new language, new
libraries and coding environments, just to implement a filter in my GMail.

~~~
traverseda
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.

------
nerdponx
A programming environment of composable programs sounds an awful lot like Unix

