Python won by perfecting two things: (1) syntax structure to be simple yet powerful, and (2) complete object/function standard library with module system.
As someone who spent some time working on Etherium data analysis, having to learn the details of how it all works, I don't see it ever becoming a large part of finance.
Bitcoin being a bubble and/or crashing is a meme nowadays - and a very uninformed one, since it has crashed at least 4/5 times by now, and none of the crashes was permanent.
Everything has an end, but at this stage, there isn't any more indication that the end will be soon (or even not-so-soon).
I think the implication with many of the "it's just a bubble" comments is that "it's just a bubble [...and after it crashes it will fade into irrelevancy (eg. tulips or beanie babies)]". In that respect the prediction has yet come to fruition. However, if you're talking about it being a bubble in the same way that the stock market or the economy has bubbles[1] you wouldn't be wrong. The GP mentioned "Once it pops then the fun will be over", which makes me think he's closer to the first camp than the second camp.
Your project is very cool. Could you help me fix my account though? I messed up two of the IDs: mfrager@github & mfrager@reddit. Will these be automatically purged from the keys.pub server after a certain amount of time for being invalid?
This is very cool but I screwed up 2 of my "sigchains" to Reddit and to GitHub by deleting the underlying messages (I didn't realize I wasn't supposed to) so now two of my identities are messed up and I can't even use the app. I get this message: "panic: Unknown user status content-invalid (13)". Great project, but needs a better way to clean up invalid keys and re-issue them.
I too would like to hear about getting facts from an sql db, and writing back results from prolog - it's hard to see how a prolog text file can/could be used as a source for transactional problems like booking (making sure the answer you find can be committed while still valid).
I suppose one could have a prolog service that came up with suggestions, ordered by preference, and then attempt committing them in order to the actual transactional storage layer. But I don't see how you could avoid re-implementing transactions.
With an rdms you could look for options, and attempt a booking in a transaction, and have a fairly established way to resolve conflicts.
As a feature to put on a checklist, not as the way they expect you to use them. Powerful graph databases generally have to come up with their own query languages.