Could be useful for some things. I feel like it's a missed opportunity to employ somethings like session types, given the existence of a quasi-typed human-readable "schema" definition. It seems like one could (and should!) go further and make it an unambiguous protocol specification against which implementing programs could eventually be checked.
Good point. Is it possible to create an unambiguous protocol specification that scales to more complex interactions? If so, and if you know how, I guess you would need a different specification language to get expressiveness? Blink has an extensible schema but that won't cut it. Anyhow, we have so far not even tried to do what you want but we hope that there is nothing in Blink that puts limitations on doing that separately. There is a lot more that we don't try to do in the protocol core.
It seems rather generous to call this a database. It's files on a filesystem. The lack of any kind of transactional consistency guarantees (Dropbox is notoriously awful at this), and the lack of any sane mechanism for querying this "database" means that it's just "data", not a "database".
You're quite right. I think my complaint was that it reduces the definition of "database" to "anything that is used to store data", rather than the database being the json file(s) themselves, at which point we have degenerated to about the same terminological point where it would be reasonable to call saving CSV or MS-Access files into a Dropbox folder "Dropbox-as-a-Database", which seems an unhelpful label, if nothing else.
I think he calls it "database" because it is strongly integrated with the database syntax of the Opa language. You can declare and use this "dropbox-database" just like a Mongo one, independently of the notion of safe-ness of the database.
Consistent with the complaint leveled against my previous comment, I should think that this is really consistent with the DBMS syntax of the Opa language</pedantry>
Or we could question whether attempting to come up with problems to solve in order to create a business is a good idea at all. Perhaps we should build businesses because that's the best context in which to execute a solution to an actual problem?
Makes a fairly interesting point that seems obvious once you've read it, but which we actually don't have embedded as an assumption - that the level of user trust placed in us as developers is not matched by the level of care and responsibility which we actually feel when that trust is placed in us. Definitely some food for thought, and I think we need to take the entire issue much more seriously rather than just slapping anything together and forgetting about it.
What is the interesting point? That users should place a foolhardy, ridiculous level of trust in developers and processes that they don't know and have no insight into?
I don't know what it takes to build a lot of things, but I trust that the engineers will do a good job. I see no difference with software.
I've always found it odd that SWEs can harbor this type of opinion. That is, "it's the user's fault for trusting me/us." when every other engineering discipline would consider such a stance insane. All other disciplines would place responsibility directly on the engineering team. Whether a plane falls out of sky, a car explodes when rear ended, a bridge collapses, a chemical causes cancer, or an oven electrocutes the user, in all cases we'd point the finger at the engineers (or company that performed said engineering) and demand an explanation. I see no difference here.
Full disclosure: This is coming from someone who was originally studying to be a ChemE before switching to comp-sci.
It might be interesting to point out that in all the examples you give there exist strong regulatory requirements. Are you (we, collectively) saying that regulations and government oversight should be on the table for web sites that provide services requiring a certain level of security?
The regulatory compliance varies from state to state. For example, ChemE doesn't require a PE in most (all?) states. Typically, regulatory compliance is only required when the work involves some sort of interstate commerce.
With all the leaks and concerns over privacy lately, I think we'll see some sort expansion of the laws covering PII sooner than later. So wether or not I agree with it, I think this will happen.
That is, "it's the user's fault for trusting me/us."
No, it's the user's fault for trusting any given site more than necessary. People outraged that LinkedIn leaked the same credentials that they use for PayPal, for instance. That is ABSOLUTELY a user issue. LinkedIn, and many before, screwed up. People aren't upset as much about the root screwup though (I mean just reset your password and move on), but that, yet again, it reveals that people rashly and irresponsibly reuse credentials en masse.
Your analogies -- if we accept that software should be built like a bridge (which is ridiculous) -- is misplaced. LinkedIn, like a bridge, should be built well to the limits of its purpose. If a bridge has a defect, however, it shouldn't cause my house to fall down as a consequence.
The advantage of any programming language, framework, or library is that you know it already and it allows you to achieve things. I wouldn't personally advocate learning PHP today, but the idea that any language has intrinsic value divorced from its ability to achieve your purposes is mostly untrue.
