I work at a "large company", and I don't agree with most of this. Your write-up is highly subjective, and fairly pessimistic.
Some people hit the ground running, and teams/organizations/companies can thrive if they find ways to embrace that. Sometimes people get hired at the wrong level, and everyone benefits if some sort of work demonstrates that quickly. I have seen promotions happen based on prudent choices around one's individual strengths, simply by choosing to do a bit of the right work and getting eyes on your capabilities. There is no "one size fits all" prescription for what someone should work on.
Having a "shadow lead" can be one of the best situations for your growth, too. Not only do you get the experience leading a thing (for most of what that means, anyway), you may end up with a very strong ally when you knock it out of the park. I had a version of this experience, and I've watched others have it as well.
I'm guessing most of the negatives here are based on your personal experience, and for that I'm sorry. Hopefully you can encourage positive changes in your company's engineering culture.
LinkedIn - Infrastructure Software Development | Senior/Staff Software Engineer - Backend, Python | ONSITE Sunnyvale, CA | Full-time | https://www.linkedin.com/jobs/view/712546597
LinkedIn's Infrastructure Software Development team builds and manages the company's production infrastructure source of truth, data center inventory and configuration management systems, monitoring, and workflow automation systems that underpin all of LinkedIn's production operations. We're looking for strong Senior or Staff level backend engineers to help us build highly reliable systems. We're a small team of strong developers, your contributions would have a large impact on LinkedIn's operations. Experience building data center monitoring, reporting, automation, or capacity management tooling is a big plus, but not a requirement.
Our software craftsmanship standards and culture are amazing, and our benefits and work-life-balance are top notch too, if you're into those sorts of things. I'm an engineer on the team, happy to answer any questions.
Not so say Coursera doesn't have problems, but the start and end dates don't mean much as of earlier this year, when they rolled out their new platform. There's no penalty for late assignments[0], and you can switch to a later session of the course whenever you want[1].
Right, it sounds like they use tries with 5 bit keys. It's a very neat data structure, for sure, but _tree is just at a lower level. It doesn't impose structure. Tries can be implemented in _tree.
Thanks dangoor. It's a good day when someone shows me two recent projects that are very similar to my own. I started _tree a few months back because I couldn't find a project like it. Turns out I'm in good company.
_tree leans heavily on functional programming techniques, so it's not so different at all. The furthest it gets from functional is the modeling layer implementation, which is prototypal, and still just a thin layer over the core.
I haven't studied any clojurescript, but conceptually, compound operations on immutable structures, such as re-parenting a subtree or sorting a vector/list/set, would be implemented inefficiently without mutable intermediate objects. For example, imagine writing quicksort where exchanges cost O(n) instead of O(1). Performance would totally tank. It'd be silly.
That's why I expect clojurescript has mutable intermediates. I'd love for someone to prove this guess wrong, it would blow my mind. Anyway, that's what _tree's batch mode is, in essence: exposed access to the mutable, pre-finalized versions of _tree primitives.
Ah, right. Benchmark 1 is actually ~350ms on my machine. Thanks for the lesson in profiling asynchronous code. I revisited the React+_tree benchmark claims, too, and I think they are still spot on. If you're interested at all, I'd appreciate you taking the time to check my work there.
Thanks. I knew of Mori, but hadn't looked at it yet. Now that I've glanced, you could definitely implement something like _tree with Mori, but it'd be missing a few key things.
What jumps out most is that I'd really miss batch mode, which lets you escape from immutability and get a big performance boost for complex atomic operations. I think Mori must use something like this internally, but the docs don't indicate it being exposed.
It may be subtle, but I also really prefer _tree's syntax, where objects are fitted with their own methods (Mori does something like `mori.get(m0, 'foo')` instead of the more succinct `m0.get('foo')`). This is also the backbone of _tree's data modeling layer, which lets you work in terms of your domain, rather than a tree.
Performance comparisons are on my list of things to do.
Part answer to your question, part shameless plug.
Node cloning can be done fairly quickly if the bulk of the node data is shared. The `_tree` immutable tree library (https://github.com/drfloob/_tree#quality-metrics) has a 1,024 child-node benchmark. On my slow laptop, it can build 1024 node trees at ~10/second, and the performance appears logarithmic on node count (http://jsfiddle.net/9x7aJ/2734/). I found it fast enough for my client-side use cases, but Clojurescript's optimized branching scheme could probably be implemented to boost performance. And anyway, if 10ops/second isn't fast enough, `_tree.Tree.batch()` lets you temporarily bypass immutability if needed, making modifications much quicker.
> it seems like it is invoking React's event loop more than I would expect ... Perhaps this difference is because of requestAnimationFrame?
I think so, yes. The performance difference is already negligible with Om, so I didn't see a real need to optimize it any further. Pete Hunt's react-raf-batching (mentioned already) could probably be dropped in to get that last bit of optimization, but I haven't tried.
As for what I mean by "application data policy", I think that if you work with your application's data in such a way that it batches modifications, renders entirely from the top down, and uses fast `shouldComponentUpdate` implementations, you'd achieve most of the improvement you see in the Om vs React+Backbone TodoMVC comparison. Lots of things could achieve that. Immutability isn't a hard requirement to get those features done. And if my React+_tree example is any indication, requestAnimationFrame isn't buying you that much performance either.
I haven't really analyzed what Om's Benchmark 2 was doing under the hood, so thank you for that. I assumed it was doing something, but with the ~4ms benchmark, I just assumed that particular something was wizardry.
Benchmark to your heart's content! On my system, Om is about 4x faster on benchmark 1, and 1000x faster on benchmark 2. I don't think requestAnimationFrame has a lot to do with it, and immutability only slightly more; I think the real performance gain is in having an application data policy tailored to make the most of React's behavior.
To plug my own work a bit, I built a TodoMVC example with React and my own immutable data structure library in pure JS. It performs a lot like Om on both benchmarks, and actually seems a bit snappier in places, like toggling and clearing all completed todos:
All respect issues aside, generic names like this are a pain in the ass. "go" (google) and "react" (facebook) are similar. For example, Twitter-folk have taken to using #ReactJS to mean Facebook's React UI framework, but react.js[1] has been around a while already, and it does some similar stuff (if you squint a bit).
You can't mention or search for them without barfing out the company name, and sometimes a specific property alongside to be unambiguous about your meaning. It makes finding discussions and blog posts harder because people don't have a common language for these poorly-named things.
It just seems like these companies are shooting themselves in the foot. Is natural word-of-mouth growth no longer a concern?
I get your gripe, but there's a good use case for this stuff in building dynamic web applications. Just because a technology is misused doesn't mean the technology is to blame.
Literally the worst developers I've ever known are the sort that would eat this kind of thing up.
The worst developers in my opinion are those that appear highly proficient and effective until they're asked to actually produce something, then never produce anything of value whatsoever. They're infinitely worse than those who are clearly ineffective from the beginning. They're talented but immature; unwilling to do anything they don't see as a game; unable to see everyday tasks as games.
Some people hit the ground running, and teams/organizations/companies can thrive if they find ways to embrace that. Sometimes people get hired at the wrong level, and everyone benefits if some sort of work demonstrates that quickly. I have seen promotions happen based on prudent choices around one's individual strengths, simply by choosing to do a bit of the right work and getting eyes on your capabilities. There is no "one size fits all" prescription for what someone should work on.
Having a "shadow lead" can be one of the best situations for your growth, too. Not only do you get the experience leading a thing (for most of what that means, anyway), you may end up with a very strong ally when you knock it out of the park. I had a version of this experience, and I've watched others have it as well.
I'm guessing most of the negatives here are based on your personal experience, and for that I'm sorry. Hopefully you can encourage positive changes in your company's engineering culture.