Matrix looks interesting!
1,393 karma · joined August 13, 2010
As of today (2/3/2016), this account is now 2000 days old with 1369 karma. I've decided to celebrate by announcing a switch to a (for better or worse) far-less-anonymous account, "pmarreck".
A lot of the other deficiencies are a consequence of any decentralized, open resource, due to "tragedy of the commons" effects. Those will always require active admin participation to resolve.
At least EFF had a small win here https://supporters.eff.org/civicrm/mailing/view?reset=1&id=1... despite losing the fight against idiotic CISA.
http://www.feelguide.com/2014/11/19/harvard-unveils-mri-stud...
But the guard code are just macros, so... ;)
But I do believe that Erlang underneath does have actual limits.
As an owner of a Tesla, no, there is no such thing (at least in the US), and please stop spreading misinformation (if you are talking about the US).
And the car is not COMPLETELY silent... the wheels make noise on the road. I've driven a completely electric car for at least a year, never got even closely into a pedestrian "situation", and I live in a highly populated area (NYC and its suburbs).
After spending a few months with Elixir (at least in my case), you pretty much DO know Erlang. You just don't prefer to work in it. ;) I mean, the easy interop is right there, the semantics are (especially with OTP) nearly identical, you often call into Erlang, the data structures are almost the same, but you just get a heck of a lot more out of the box, even simple design decisions like "the first argument to a function is always the main thing being acted upon" have tremendous repercussions such as enabling the lovely |> transformation operator (from F# and OCaml). You get a more sane treatment of strings, you get "true" macros, you get great tooling (while still being able to take advantage of FABULOUS Erlang tooling like :observer.start() )...
Elixir complements Erlang quite nicely IMHO. And if my best guess is correct, Elixir will take Erlang into more places than it can currently imagine...
every other scheme that people suggest replacing it with runs into difficulties because you can't predict the amount of time (roughly) it takes to do the work. in Bitcoin's case, you CAN predict (roughly) the amount of time it will take to roll 3 1's in a row when repeatedly rolling a 6-sided die.
What if the leader goes down? What if 2 leaders get accidentally elected in the wake of that?
What if the elected leader is a bad agent?
I don't like non-leaderless decentralization schemes. All you're doing is adding mobility to centralization.
AFAIK, that's not possible. Secure hashing algorithms tend to fracture instead of completely break, so there will be some warning; to change to a new algorithm, simply more than 50% of the Bitcoin miners would have to mine on the chain that relies on that new algorithm, and it thus becomes "voted" in.
I wanted to get into Clojure but I really wanted a language that almost entirely forced me to forego mutability (due to the large class of bugs I've seen in the past because of it) and Elixir seemed to provide that, Clojure did not, it was more live-and-let-mutability-live... and I didn't like that.
Regarding your question, it's my understanding that (again, due to everything being immutable), larger data sent between nodes in the same BEAM VM is not copied, it is reference-counted and garbage-collected and any changes are copy-on-write but only for that part of the data structure (due to implementation of Persistent Data Structures underneath).
One thing I'm VERY curious about with regards to Clojure is Datomic. Elixir (IMHO) could really use a fully queryable, immutable DB. After I drank the immutable kool-aid, it was jarring to have to think about mutation in global state again whenever I touch a database, to the point that I'm considering foregoing SQL as long as possible and just dealing with Mnesia or Basho's Riak and writing implementation-agnostic wrappers around my datastores (the latter is probably a good idea anyway).
Mutexes need to die in a fire. ;)
In Elixir this is literally as simple as adding "async: true" to your test modules.
It will also force you to write tests that can run concurrently... which has a few nice side effects for your code design generally.
Good grammar never gets old. In fact, it boosts your income: http://www.forbes.com/sites/cherylsnappconner/2013/03/11/rep...
> Now, producing something worth reading is another story?
I've become less of a grammar nazi over the years (falling in love with a dyslexic woman will just... force you to do that lol), but I see it as kind of like colorblindness... If everyone is telling you your colors don't match, and you don't see it, it doesn't mean it doesn't bother them (or that you shouldn't care). Or if you're deaf and make random noises that you don't hear, but they bother others... perhaps you should figure out how to stop. That sort of thing. It's a discord thing.
Disclaimer: I'm pro-Github... well, other than the fact that it's centralizing a decentralized SCM. ;)
Agent -> ets -> dets -> mnesia -> riak (or sql tooling etc.)
(Agent http://elixir-lang.org/docs/v1.1/elixir/Agent.html is just a state-holding process. Erlang folks can probably write one of these in their sleep, Elixir added a bit of wrapping-paper around it.)
If you're writing an app, I think it's best to be storage-agnostic from the get-go. You shouldn't be building up queries in your core app code- push it to the edge of your code, because otherwise it's not separating concerns. All your app (business logic) code should delegate to some wrapper to work out the specifics of retrieving the data; your app code should just be calling something like Modelname.specific_function_returning_specific_dataset(relevant_identifier) and let that work out the details. That way, if you ever upgrade your store, you just have to refactor those queries but your app code remains the same. On top of that, in your unit tests you can pass in a mimicking test double for your store to do a true unit test, and avoid retesting your store over and over again wastefully. (You'd still of course have an integration test to cover that, but it wouldn't be doing it on every test.)
Trivia- This was actually the very first game in history to use WASD, I believe. (Even though this copy doesn't default to it, the original one did.)
I don't hear audio. Is there audio? The audio was one of the best parts of this game!
If you mean "vetted by a tiny handful of fallibly-human organizations such as Nature and Cell who may or may not decide to accept your paper regardless of its actual merit and based mostly on how 'hip' the research is," well then we're back to the hazing/cliquey-clusterfuck thing again.
"Grants" seem equivalent to "angel investments" in the startup world... which seem a lot saner, btw.
http://blogs.sciencemag.org/pipeline/archives/2013/09/10/gre...
Long Beach seems to be starting to embrace the idea with things like its Bridgeworks project http://liherald.com/stories/New-startup-incubator-coming-to-...
I kind of want to start a company myself, there...
How can an entire discipline that is supposedly based on rational evidence-finding be such a cliquey clusterfuck? You're basically saying that if you don't follow the community rules, which more or less boil down to "hazing," you'll be excommunicated. Sounds like a cult, to me... as is any culture where "fear" is the primary motivator not to try something different.
Don't the laws of nature exist everywhere? Why can't anyone "do science," then?
I am glad I work in a meritocracy-based industry where anyone with any background can "ship" and succeed, and that has a low tolerance for bullshit.
Nevermind, I remembered how to Google... http://www.howtogeek.com/202825/what’s-the-difference-betwee...