Interesting ideas. I think that anytime you pass data between code bases, you're going to end up converting it to/from json, xml, or some other intermediate format. It's a cost that I don't think we can avoid.
If you think outside the centralized server, I could fairly quickly implement my fragment of a distributed twitter. It's a matter of declaring a few objects/types, and writing code to do CRUD for my locally hosted parts, replicate those to some publicly accessible file host/web page, and them write an engine to scan all the other sites where the people I follow publish their data.
Two things that can't be replicated:
1> blocking of users. Once data is public, you don't get it back.
2> anonymous comments or replies. This would require scanning all replies, even of people you don't follow. It's possible this could be a service from a 3rd party aggregator.
What I'm seeing most of all is a glimmer of what is possible if you don't have to worry about security, and just solve problems. The walled gardens are a result of security issues, the network effects are a result of the small number of walled gardens. If you can tell your computer to do function X with data Y, and there is NO possible way it could get hijacked or confused into doing Z, then this could work.
The computer doesn’t have to do these locally—there’s no reason this couldn’t be implemented as a thin client.
I agree that data has to be converted, but I don’t agree that it has to be as manual as it is today. Consider this: In addition to your API, a second JSON file gets generated that describes the schema of the first. On the consuming developer’s end, their language & IDE uses that schema to let you call APIs or RPCs exactly like they were local functions.
I've been hiding in a cave for a long time, metaphorically. I've never had to deal with JSON or XML for that matter... I'm shocked that there's no metadata with type information at the top of either one? That's insane... everything is a gosh darned string? Ick!
If you have function calls without type information, anything can happen, a function call could result in your neighbor's pool being drained, and your bank balance being sent to Belize.
In Pascal, you have to have a type before you can declare a variable. This little inconvenience saves you from an entire class of errors.
If I'm going to import a random file from the internet, I have to be sure of the type of data in it before I'm going to touch it with a 10 foot pole (or barge pole in Britain).
I had no idea people got so foolish.
Back to your idea, of course there should be type information, either as a separate file, or at the head of the file.
In Pascal, I'd have the import routine check it against the RTTI (run time type information) of the local native structure as part of the import, and throw errors if there were problems. On export, the RTTI could create the type header file/section of JSON.
The closest thing we've had might be Lisp Machines, but that didn't work out.
That's why Emacs is still great: users can do whatever they want with it, and they do.
To a lower degree, we can sort of do that with workflow engines on the cloud (ex: Azure Logic Apps), or locally (ex: iOS Shortcuts).
As a user, I like being able to do that, but I do not like having to maintain my partially working thing, nor do I want to spend time ensuring it works as I expect (aka doing QA) outside of what I use it for today.
A big issue there is accessibility to a broader audience—something that Emacs and Lisp Machines don't quite have. Like you said, iOS Shortcuts is a very interesting example. You could say Internet-native automation tools like Zapier and Integromat fit the bill here too.
I wouldn't see potential maintenance or QA work as a deterrent to mainstream adoption. Users would underestimate it just like developers today do.
This reminds me of Microsoft ActiveX - all sorts of programs could embed each other, talk to each other, they had (some) compatible types and easy to use IDE (Visual Basic)
But even then, it did not get picked up. Sure, you could do a lot with MS Excel, but non-Ms software often had spotty or missing ActiveX support.
I often wonder if there is a better way when passing data between systems and needing to map trivial differences in data to satisfy the receiver of the data
Readit News
If you think outside the centralized server, I could fairly quickly implement my fragment of a distributed twitter. It's a matter of declaring a few objects/types, and writing code to do CRUD for my locally hosted parts, replicate those to some publicly accessible file host/web page, and them write an engine to scan all the other sites where the people I follow publish their data.
Two things that can't be replicated:
What I'm seeing most of all is a glimmer of what is possible if you don't have to worry about security, and just solve problems. The walled gardens are a result of security issues, the network effects are a result of the small number of walled gardens. If you can tell your computer to do function X with data Y, and there is NO possible way it could get hijacked or confused into doing Z, then this could work.I agree that data has to be converted, but I don’t agree that it has to be as manual as it is today. Consider this: In addition to your API, a second JSON file gets generated that describes the schema of the first. On the consuming developer’s end, their language & IDE uses that schema to let you call APIs or RPCs exactly like they were local functions.
If you have function calls without type information, anything can happen, a function call could result in your neighbor's pool being drained, and your bank balance being sent to Belize.
In Pascal, you have to have a type before you can declare a variable. This little inconvenience saves you from an entire class of errors.
If I'm going to import a random file from the internet, I have to be sure of the type of data in it before I'm going to touch it with a 10 foot pole (or barge pole in Britain).
I had no idea people got so foolish.
Back to your idea, of course there should be type information, either as a separate file, or at the head of the file.
In Pascal, I'd have the import routine check it against the RTTI (run time type information) of the local native structure as part of the import, and throw errors if there were problems. On export, the RTTI could create the type header file/section of JSON.
That's why Emacs is still great: users can do whatever they want with it, and they do.
To a lower degree, we can sort of do that with workflow engines on the cloud (ex: Azure Logic Apps), or locally (ex: iOS Shortcuts).
As a user, I like being able to do that, but I do not like having to maintain my partially working thing, nor do I want to spend time ensuring it works as I expect (aka doing QA) outside of what I use it for today.
I wouldn't see potential maintenance or QA work as a deterrent to mainstream adoption. Users would underestimate it just like developers today do.
But even then, it did not get picked up. Sure, you could do a lot with MS Excel, but non-Ms software often had spotty or missing ActiveX support.