Can you be more specific about how how her viewpoints create problems for you as a science educator? (I am speaking specifically about her content relevant to physics/particle physics/cosmology.)
Generally, she is careful to point out when she is voicing views based on her own preferences, speculating about things that have no observational data to back them up or giving personal hot-takes on various topics.
For everything else, aka, the things she accepts provisionally as true, she appears to favor the least speculative among current solutions/theories/approaches in physics. Much of her popular work is focused on critiques of the many speculative musings of physicists who, in her opinion, have moved into a kind of post-science research program.
Her acceptance/popularizing of the standard model and of general relativity as humanity's current best models of the universe indicate that her viewpoints tend to be highly conservative and evidence-based.
Again, most (all?) of her musings about things that might be true or things that might be interesting directions for research are clearly called out as such.
NASA has a lot of open source projects including a bunch that don't "go to space" but are used in space related projects (check each project for contributor guidelines):
Not to mention a bunch of open source CFD projects on github that are widely used and other similar tools. Again, not strictly software that goes to space, but you will find more of that too if you search for projects related to those mentioned above.
I’m curious to know if they ever looked at https://github.com/Microsoft/napajs from Microsoft or any other in-nodejs solutions to deal with the need for multithreading vs launching multiple processes...
For anyone interested, here is a sampling of available ML libs in JavaScript. The first two, including tensorflow.js, are sub-libraries of the major ML projects, and the others are custom JS libs:
You do realize that Python was not only built to appeal to "non-devs" as well ad devs but, does, in fact, enjoy some of its strongest support from them- scientists, engineers, statisticians, etc., who do not consider themselves to be good developers. And, man, they can develop some crappy code/systems in Python too.
I like Python too (as well as node,) but your characterization of node is over-broad and, imo, inaccurate.
Depending on your use case, you can also use ES6 features on AWS Lambda by embedding another node version in your zip package. You then use the lambda supported version of node to launch/bootstrap your chosen version when the lambda function is activated. Of course, Webpack still supports more ES6 features than node at the moment, but the gap is rapidly shrinking.
On a somewhat interesting note: transferable objects work similarly in web workers. There have been complaints, of course, that this makes it impossible to take advantage of shared memory in cases where it provides clear performance benefits.
I think this is the best article I've read about stream processing yet. Love how all of the related concepts are tied together and how concepts in one form of stream processing naturally fall out of the structure preferred in another form of stream processing.
The author's terrorism concerns are way overblown and the reasoning supporting them specious, but there is a more basic issue with hypersonic point-to-point transportation systems outside of the additional arguments related to current air travel, at least for vehicles designed to go suborbital/exoatmospheric:
Once we are talking about traveling to a destination and not simply going "straight" up and down, the costs, maintenance issues, safety requirements, development time, thermal management, mission management, guidance systems, etc., get within spitting distance of actually developing an orbital vehicle.
Future technology improvements and cost reductions cannot be ruled out, of course, but given the basic physics and what we know of the near future of aerospace technology, it seems a stretch (at least) to expect a profitable, safe point-to-point suborbital system to be a viable undertaking.
And once we are talking about orbital systems, where the cost and risk/reward equation at least seem to be more desirable and unrelated to point-to-point travel, the question of suborbital point-to-point fades into the background.
In a similar way, a separate marketing tech team can also create tension with the rest of the developers when marketing gains control over various parts of a site/service due to clear success in moving the revenue needle. There's almost nothing more frustrating for a developer than starting on a great product concept, but being told to drop it because marketing doesn't want such a product or feature to interfere with what they're doing (A/B testing, etc.)
Great work. This is exactly what I had been idly wondering about yesterday as I was setting up a new project that uses PM2. Does this obviate the need for pm2-interface, or will that project still be developed with a focus on the RPC angle?
I already commented on a different thread about the Flux architecture, but I'll state it again here: Flux seems like a slightly more constrained, perhaps less effective way of doing the same kinds of things that state machines do.
Is there something about Flux for typical use cases that makes it a better solution?
After reading the above article, I can see how Facebook ended up with their current approach, but it seems to me that Flux is a roundabout and possibly inferior way of using state machines to organize application logic and user interface communication. For instance, statements like "The Dispatcher can be made to reject actions while it has not finished processing a previous action." indicate (to me, at least) that Flux could likely be more efficiently coded and used if it were based explicitly on hierarchical state machines.