3 ms·
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 ac
by palakchokshi 10y ago
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 10y agohttps://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".