Yes. But the Mongols (Golden Horde) reached Germany eventually in the late 14th century, but that was their apotheosis; they never came back after that.
I think the problem with XML is that people tried to make it into something as comprehensive as CORBA (this is SOAP) so that all the decisions about the communication was done in-band. JSON requires everyone to make out-of-band decisions about what the JSON should look like: people talking to each other, imagine that! The former seems quaintly antisocial nowadays.
Thank you for writing it. Not enough of this sort of thinking on HN. Too much emphasis on the incrementalism of "pioneering the obvious". Not enough on the 10,000 foot view of the problem.
Goodness, the number of folks who divide the world into "solved problems" and "problems to be solved" missed the entire point of the article. This article was not about "what we can do to the world for our own needs"; it's about "how can we change our minds and perspectives (our selves) to do the work that needs to be done."
Replying to myself (facepalm): just to make sure people know what I think. I've been doing TDD since 2002. I'm of the "You will take this out of my cold, dead hands" variety on the usefulness of TDD. That doesn't mean that there's any science that proves it.
Let's keep in mind this Fowler post has no science in it. It's just some "lauded practitioners'" view of TDD. Our industry is driven by this kind of discourse. There's very little good scientific research to answer questions like these in software in general. How much is any good on TDD? One paper? Two?
I thought that was clear: prior to HFT, the seller would have made the deal with the buyer without the intermediary HFT because if the latency. HFT exists because of speed. Very hard to say "High Frequency Trading" without saying "High Frequency".
So that's the missing part you say? The Internet has been the biggest catalyst of disintermediation in history. But this is not disintermediatable without HFT?
Yes. So seller A wants to sell for $1.00 and buyer B is willing to buy at $1.06, an algorithm will calculate the presence of this potential (or actually have knowledge from other systems that this a certainty) and purchase seller A's stock with a margin of overhead of $1.03 and sell to buyer B for $1.06 netting $0.03.
Right a startup looking for funding (by its very nature) means you're creating a situation where your company will be in the process of going out of business the moment you get your capital. Your job is to prevent that eventuality.
So think of a new restaurant that loses money on every customer until they figure out how to take more money in through the till than they're paying out.
The point is Hickey brings up important points about language design as its experienced by devs actually using the language. Hardly anyone discusses this. Furthermore, you seem to be making my argument for me when you claim that Clojure doesn't have types so why complain about types. In Clojure you could write a type system to do all that, probably in a a dozen hours (the language is programmable after all), but it would be an academic exercise to most which is the point Rich is trying to make when he disparages other type systems.
That's a good link there. I think the answer to a smaller Rust is Go, however. The comparative compiler speed alone is worth the price of entry. Don't @ me ;)
Yeah that's not good design. Lowering a requirement should not make callers complying to a stricter one have to change anything. But, ohhh.. right only the type changed. so everybody stop what you're doing and start over.
Most Optional implementations are kinda terrible, though. They cost more than they save. If I have a function with a param and I release it with it required, but later I change it to be optional (loosening a requirement) does rust require everyone calling that function the old way to change their code? If so that not an improvement!
Yeah the borrow checker is an interesting solution to a problem I don't have with a managed language. It's the main "safety" feature people coming to rust are introduced. I'm in agreement about Rust here with a lot: "one does not let one's friends skip leg day" there's a lot more to good language design than memory management. Is it worth it?
Clojure has been there as a fullstack language for a lot longer. It also fulfills the story that Elm was trying to do for much longer. And Reagent is a much needed improvement on React.
The borrow-checker in Rust is kind of silly tool to use in the context of a managed language (that does GC) like Javascript. I don't get it. It's like using a backhoe to plant a few geraniums. Am I just not getting this?