Really cool! I'm working on a lamp that gives you daylight levels of light indoors (albeit no raleigh scattering and columnated light). On the bright side (pun intended), it's 50,000 lumens instead of ~4500. https://getbrighter.com/

My annoyance was managing state. I’d have to spend hours installing tools, downloading data, updating code, then when I want to go to bed I have to package it up and store as much as I can on s3 before shutting off the $$ server.

"Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming." - Rob Pike, "Rules of Programming"

The essence of programming is data.

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.

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.