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.
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.
> Isn't there a startup that's already applied for CFTC approval?
Well, there's TeraExchange which applied with the CFTC for trading dollar-denominated bitcoin swaps that are written, quoted and settled in US dollars.
Recently (days ago) the CFTC approved LedgerX for temporary registration as a Swap Execution Facility, which is one of the (multiple) registrations required pursuant towards LedgerX providing bitcoin options trading, as well as bitcoin clearing and settlement in actual bitcoin.
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?
That's a good point. In Delaware, liquidation preference would have to be accomplished through a preferred stock designation. Not sure what English law is, though. The terms might make more sense, both legally and culturally, from that perspective. This could possibly explain why commenters who know these guys are giving good reviews, while US-based commenters steeped in SV culture find this document strange.
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.
The Ruby bindings already support ACH via the "source" parameter (see https://stripe.com/blog/unifying-payment-types-in-the-api). We're putting the finishing touches on a guide to make migrating code from Balanced to Stripe as easy as possible: it should be out soon.
So you think we're better off just giving up on a perfectly good reason for these naming conventions and call "princ" "print" just because some poor language without the concept of Read-Eval-Print Loop named its function that way and then everyone else blindly followed?
Seriously, Lisp has long history and had half the "new amazing features of today" 30 years ago. There is a rationale for naming conventions. Just because you're free to call a string-spitting function "print" in Ruby or Pascal or whatever doesn't mean you can do it in a language with a proper REPL.
Alternative to 'princ' doesn't have to be 'print', it could be any of 'print-out' 'output' 'put' 'write' 'write-output', and that's just off the top of my head (yes, several of these can be ambiguous and might have different meanings, but still better than 'princ').
Just because CL has a long history, it doesn't mean that everything about it has to be correct. Otherwise why start a project of CL remodernization in the first place?
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.
