Considering the CFTC didn't regulate Bitcoin until today I wouldn't think so. Their application would have been received with a polite "save yourself some time and money, we don't regulate that" I imagine.
Unless someone was working with the CFTC to have them move it under their jurisdiction for a competitive advantage or something, but even then CME or ICE could jump in so that would be a risky move.
This is an interesting development. Typically commodities futures and options contracts can only be traded on a DCM (designated contract market) like ICE or CME. After leaving once DCM, the Chicago Climate Exchange, I started an exchange as a service startup, Exchangery, and sought DCM status. It requires a 12-18 month approval process, typically > 500k in legal fees, and a guarantee fund that is based on the amount of money moved across the platform. The last requirement could easily be 10s of millions for something like Bitcoin. It used to only be imposed on clearing firms, but post Dodd-Frank it is applied to the exchange as well.
This is drastically going to thin the players in the space, and probably force most bitcoin exchanges to stay strictly in the non-derivative trading world. It might also tempt players like CME and ICE in to trading futures on Bitcoin if they think the volumes are potentially large enough.
As far as SEFs go, they are limited to swap trading, which can be dressed up to act like an option but isn't really the same thing.
The document includes a 1x preference, anti-dilution, board seat, etc. Aren't those fundamentally the things that make their shares different than common? Can you disentangle the name 'preferred' from the added rights over common shares?
An article, 4 nouns and an adjective. This isn't parseable without 3 or 4 passes. The idea is spot on, it's short and simple, but improve the English to make a reader's life easier. You have seconds to let someone know what you do and this is wasting time.
> Torque Specs
> Fluid Capacities
> Body Dimensions
> Tow Ratings
> Maintenance Schedule
Ruby, Python, Javascript... You told other commenter's here that this list is meaningful to people in the know. It's not, there is no context. Why are you listing these words?
> We're building a community of comprehensive, accurate vehicle data. And we need your help gathering info about the cars and trucks you work on. Technicians and DIYers, join the beta program to get first access to the app and help shape the community.
Now I know what you want, but not really why. What is in it for me? This will presumably take me time and effort to use, what do I get out of it. Don't tell me it is obvious, again if I substitute tech terms for auto terms I still have at best a vague sense of what I am getting myself in to. Paint a picture.
I started about 1.5 years ago and it has been great. Strength training + cardio, planned by someone else, on a schedule, guided by a coach, with peers that encourage and motivate you. It pretty much addresses all of the psychological reasons people normally quit going to the gym after a month.
We're a marketplace that uses Balanced's ACH + escrow for moving money between buyers and sellers. I am glad to hear you will be supporting this on Stripe, but since I only have 90 days to migrate when will api/ruby support be ready and where can we find docs?
Perhaps the docs are available as soon as I migrate? I am hesitant to start that process until I have code written to support Stripe. I don't want to end up with my data on Stripe going stale while I am still using Balanced to move money. Of course I am only assuming that scenario is what would happen, the announcement is pretty thin on details.
Yes. Of course I wouldn't characterize it as blindly following so much as being able to rationally step back with some perspective and identify some trends as positive.
Lisps are a beautiful and powerful family of languages, but you are conflating the implementation with the idea. The names of functions from 30 years ago are not what makes Lisp special.
Yes, and notice how it doesn't stand for Rrepl-Evl-Princ Loop.
> There is a good rationale behind those names.
No, there is a good rationale for having separate functions, there is no logical rationale for prin1, princ and pprint.
Let's take "prin1 produces output suitable for input to read." from the link you provided. Since we are redesigning the language anyway, let's call that evalable-print or readable-print, or anything else in the world that semantically captures it's meaning. Because when you have a language with hundreds of obtusely named library functions it requires an unnecessary amount of cognitive load added to the already taxing act of programming. Functions that are easier to remember are directly related to code that is easier to read and understand.
No one is arguing that CL sucks, but that if you are going to re-skin the whole thing with learnings from modern languages, with features like string interpolation, then you might as well make the function names more intuitive while you are at it.
The specific example is talking about doing away with the format function in favor of the princ function. What is the argument against calling it print? No one is suggesting fprintf by the way.
You and the parent are also citing spoken languages, and certainly if you are a Chinese speaker then the difference between princ and print is going to be nominal to you. However, if you are a native English speaker, not so much. Really though, once you learn one programming language with standard library function names in English, then the second will be easier to learn if it uses similar names.
Back to the subject at hand, the case being made here is that most modern languages choose things a bit easier for the brain to parse; they aren't overly shortened, they aren't Hungarian notation, etc.. The reason for that is that it requires enough brain power to learn a new language, its structure, libraries and quirks without also having to memorize strange sequences of consonants.
Here is some code I wrote yesterday. Even if you never saw Ruby before in your life, don't know what blocks are, and have no idea what the array/enum functions are, you can probably figure out what this code is doing.
I do. There is a reason for the success of Ruby and Python, and why Elixir is dragging Erlang in to the present. It turns out you don't just have to write your language in the shape of the machine/vm but it can be a tool conformed to the mind of the programmer. "princ" is not easy to remember, read or associate to other things one already knows. The point of a project like this should not be to save old school programmers (who won't use it anyway) a few keystrokes, it is to throw away the cruft of decades of "a very good reason" decisions for something simpler and better thought out.
I really like the direction of this project, but I agree with the parent comment, it doesn't go far enough.
Mercaris, data and trading for Organic agriculture, based out of 1871, founders are grads of Excelerate (now Techstars Chicago), recently closed a Series A, hiring/growing.
How are all writes immediately consistent? What if two clients make simultaneous writes to each shard? Or more extreme, what if there is a net split and writes continue on both shards?
I suppose I could just ask if you have an architecture document floating around :)
As I mentioned the code that writes the event to the db notifies the client about it, so it knows about the client. This isn't really an issue.
In the case of an exchange I never split a single order book across multiple servers, but I can imagine a lot of applications where this could be an issue. How do you handle data consistency across nodes? Ultimately you have to solve the same issue...
Again, this isn't a big limitation for my use case. That said your answer has certainly given me a greater understanding of other circumstances where it would be very useful. Thank you.
So obviously that would be application specific. In the case of an exchange when a client connects they get a snapshot of the whole market and then begin receiving streaming updates that took place after that. I generally prefer ascending event ids over timestamps but either approach is workable. The logic about which id to start with can be managed by the server in a socket implementation or on the client when polling. So, disconnects/reconnects for that type of application are handled fairly elegantly.
Looking at the docs it doesn't appear this is meant to stream to the client, but to the server. From there you would still need to manage queues and sockets, etc.. I've had to write several exchanges that do something along these lines (stream order data to a client) and I've always accomplished it by having the code that writes to the db also push a client update to a queue.
I guess my question is why would this be a preferred solution? It seems to run afoul to the 'one job' design goal. What am I missing?