That's kinda neat thanks!
472 karma · joined March 5, 2013
http://twitter.com/rseymour/
But after some amount of time, the ease of simply reading someone else's working codebase compared to debugging/designing and reading your own becomes overwhelming.
So off the bat, writing is easy, but as soon as the amount of code you've written gets near to the complexity of what you avoided reading, you're going to wish you'd just read up a bit.
There are a lot of serious javascript nerds who defensively coded the living crap out of react (and for that matter ember, angular, etc)... starting from scratch in light of that seems quite intense. Even if I were going to embark on such a quest (let's say for pure functional programming style), I'd probably start looking at the ideas in Om (clojurescript react) before writing my own.
I think I'm biased towards not coding because laziness pays dividends later once maintenance, etc come into play.
Joe Witt is a smart guy who put a lot of work into making a robust workflow tool there.
It seems like it would have failure modes in communities w/ transient populations. As in, if you give me 100 units, I'll buy 10 votes and know that I at least voted as much as I could. But in conditions where you have a fixed community it could work well.
Clearly in the real world if you have 100 credits, a Koch brother would have ~100 million credits... Bill Gates ~200 million credits... (based on US median net worth of $44,000 vs their respective 42billion and ~80billion)
But there are plenty of decisions to be made that could be done with fake credits in a controlled environment.
one could say they're... looking into it...
https://careers.microsoft.com/jobdetails.aspx?jid=170944&pp=...
I've done a bit of scala spark as well, and my initial thought was prototype in pyspark and then rewrite in scala if necessary. Just this week DataBricks announced they are working on changing some of the data structures behind RDDs to save on unnecessary java object creation hubbub https://databricks.com/blog/2015/04/28/project-tungsten-brin...
That and the SQL compiler thing seems pretty darn awesome. Spark has the nice benefit of being plug and play (w/ a joyful time of compiling and deploying) with legacy HDFS/Hadoop systems. That alone will keep it in toolboxes for a long time to come.
(Edit) this is apparently working in the latest scala 2.11 But it killed my adoption of scala for real work early on. https://issues.scala-lang.org/browse/SI-7099
I see it as the future of pop-functional programming. For example look at the way it handles type inference w/ JSON parsing. Compare that to what you have to do to parse JSON in Scala. It's subtle, but a major usability win.
There is a typo though: "in client" should probably read "if a client" or "if the client"
Bottom line: If you are poor and can figure out this loophole, just do it. On the balance I'm very, very glad I did.
After looking at the French version I see that "action perimeter" is from the french perimeter d'action (accents removed) which translates better in english (once again according to the interwebs) as: sphere of operations. http://dictionary.reverso.net/french-english/p%C3%A9rim%C3%A...
Once again, I'd go so far as saying the concept of functions works just as well here, but at least it gets over the near homonym of parameter/perimeter. The chaining of scoped actions is pretty vital to lisp, and I suppose functional programming in general.
My point being that require('react'); wasn't the best fit for their editor window (which doesn't need events to be intercepted, etc), but the idea behind virtual dom diffing and how they updated their window left an impact. The concepts behind react got them thinking in a new way, which is ultimately much more important than their dependency on a 0.x.y release library.
If anything, the design of react was a stepping stone to where they've ended up now. It wasn't "bad", so much as unoptimized for their specific task. For me I'm glad it can intercept events (usually), since it simplifies cross browser compatibility. Atom is essentially one browser version, so it doesn't need that overhead.
The thought that went into the virtual dom diffing strategy is an algorithmic nicety that software in general can and has already benefitted from. React itself is an implementation of that which provides real workflow improvements for web and now native platforms. That's pretty awesome and usable right now. I don't see this as a zero sum game, or as an all in investment strategy unless you are going into some arcane questions of licensing, the code and the ideas are out in the open. Ember, mythril, Om have all taken the ideas into new regions.
Even look at the atom editor, they switched to react for their editor component, then realized the general purpose dom diffing strategy which is very fast could still be optimized for their edit window. That's awesome. That idea is decoupled from react. Learning to read react code takes about 1 day to 1 week. It's pretty awesome.
Also, the canard about reactive programming... uhh... I just don't get what you're advertising here? That you're willing to use products like docker and node.js as advertised on your front page, but not react.js because... it's "bad"? Why so inflexible, why not try all the things and use what works as time permits?
It just creates the code for you, then you commit it. Easy enough.