The higher the differential the higher the efficiency of heat to electricity transformation. If I remember correctly it's a big efficiency gain between 200C and 300C. From economic side of things, more bang for the buck.
Its a different discussion, quite off topic. When the boomers go into retirement, our current economic system with GDP growth focus has a big problem. Our system is based on produce more stuff and buy more stuff. But when the boomers retire, they will buy less stuff. Who will buy supply overhang? Nobody. Even worse, who will pay for the debt incurred to buy overly inflated asset prices, like housing and factories, when boomers start downsizing and start selling?
Look at Japan. They are 10 years ahead of us. It will be tough and depressing until the economic system adapted and prices normalized. On an opitmistic point, humanity will progress and when an economy cannot sell more stuff then it has to sell better stuff.
I think the author wording is a little bit confusing. I think he want to point out, that narrow AI is used successfully only in (niche) applications with narrow purpose. Niche here is not about total market size.
You need to very carefull to apply Kelly Criterion to stock market, as you cannot precisely calculate the p of your investments. If you assume a too high p then you will overbet and its only a matter of time to go bust (see N. N. Taleb MOOCS on Kelly). Thus the Kelly Criterion should be your UPPER bound for real-life investments with uncertain p, stay well below the betting amount what Kelly Criterion would suggest so that you stay longer in game.
Related to this, the best investors in the world are quite old guys. Why? Because they lived long enough to accumulate enough wealth to be of public interest.
This is nothing new. The independent media wrote about this a year ago and mainstream media organized an anti-fake news campaign against it. Now the mainstream presents itself as the saint - BS! 1 year ago mainstream did not check the facts or at least compare natural versus lab origin. No - they steam rolled independent media for publishing "fake" news, got them kicked off of social media and destroyed their income stream. Now it's factual news and they present themselves as saints, without apologizing for their wrong doing. I do not trust these mainstream media outlets anymore. I spend my money on independent news.
I disagree. As long as you use prepared statments and bounded parameters, your application is safe from SQL injections. NEVER use string concatiation to generate any SQL queries - not in your app and not in your database! Its unsafe and slow.
https://security.stackexchange.com/questions/15214/are-prepa...
Funny enough, I reversed engineered your numbers a few days ago. I guesstimated at least 3 million ARR with 2 - 10 FTEs. From revenue per FTE perspective you have the most impressive numbers I have ever seen!
I used the library in a hobby project, where I used sql outer joins to produce maps to dativity. Dativity controlled the sql transactions to change the process instances. It was simple to implement and it controlled different business processes.
The library itself is stateless thus it has no thread pool or anything that can execute scheduled tasks. Thus the trigger for change needs to come from the outside.
Edit: I do not think dativity tries to replace BPMN. Its an alternative approch with its pros and cons.
I do not think so. The regulation is constantly changing and the meaning of names change frequently. Thus a "Verified Account" can mean different things over the years. The problem with types and object orientation is, that the names used in the domain diverge from the name used in source code (class name, types). Think about a class diagram with class names relating to each other. To represent the domain language better, you need to change a lot in a class diagram. Dynamic languages reduce the problem, as a lot less names are needed. Clojure spec is used for specification of data instead of types, but there is also clojure typed (which uses javas type system).
It is nature of the problem space which requires you to produce high quality code. If you have a small error in your program, the financial market participants will use it against you to profit. What you loose, others win! Google "fat finger" for examples.
In banking you have to keep track of every transactions, see "double accounting". You never delete a transaction, you only retract! Mutablity can cause you a lot of trouble there. SQL DELETE and UPDATE are extremly dangerous! Clojure and datomic solves this through immutibilty.
Lastly time is relativistic, meaning that every IT system has a slightly different time. Normaly you never notice this. But they are the cause of tricky race conditions and cost you real money. Think about bank transactions, where you have a transaction date (date you send money) and valuta date (date your friend receives money). One transaction 2 different dates, depending which perspective you take (perspective is relativistic, Einstein is right even in IT!). Datomic linerialies transactions thus this problem does not occure on database level.