Emphatically yes; Musk being the current head of Tesla and SpaceX has been the defining characteristic in preventing me from seeking work at either company. I'd be sending out applications to both if he announced his departure (or even a long sabbatical).
I believe very much in the missions that Tesla and SpaceX romanticize, but I cannot reconcile those with Musk's public behavior. Calling people pedophiles on the internet, trying to suppress unionization efforts, and seemingly lying about going private entirely on a whim does not pass ethical muster for me.
I'd really like to see something happen in Grand Rapids to help put it on the tech job map. My brief time working there was a _ton_ of fun, and I really hope that I'll be able to return at some point, either as a remote worker or (hopefully) for someone local.
As a quick aside, your source also advocates for free-market healthcare and rejects national healthcare legislation and Medicare under the guise of individual choice.
It has _also_ published such gems as "The Scientific Case against the Global Climate Treaty" and “New Perspectives in Climate Change: What the EPA Isn't Telling Us”.
In light of that, I'll take their advocacy with a grain of salt.
---
On topic, while I can't comment on the EMA specifically, during my (extremely) brief period working alongside a medical device manufacturer, fear of FDA was oftentimes the primary motivating factor in keeping them honest.
While that's entirely anecdotal, when there are _significant_ financial incentives on the table people's morals tend to get more than a little flexible. Pharmaceuticals represent an area with _significant_ financial incentives, and, while I do agree that the FDA takes more time than is strictly necessary, it's a little fallacious to say they "kill vastly more people than they save" through regulation.
Shotwell's response is in the best interests of her company, but SpaceX is (as well as Boeing) woefully behind on a reasonable timeline to reach human-rated flight for both their rocket and crew module.
We should have learned from both the early Apollo program, and the Shuttle failures, that human lives shouldn't be treated as expendable capital in this industry.
Both SpaceX's current announcement, and the US Gov's desire to put humans on the first flight SLS flight, are deeply troubling in that regard.
Launch Abort is a system that should _never_ have to be activated. If you use Launch Abort, the series of failures preceding it was so catastrophic that you had no alternative to avoid loss of life.
> having a slow and stable industry base that favors backwards compatibility, stability and performance
I feel as if GHC addresses backwards compatibility and stability fairly well with new language features being gated by language pragmas. [1]
I don't write much Haskell in production, and what I do write isn't very performance intensive, but GHC's been pretty impressive vs. other compilers with languages at a similar level of abstraction.
[1] Foldable/Traversable in Prelude was a relatively large breaking change, and it was handled in a way that minimized the impact to existing code while still advancing the language.
Big planes have an order of magnitude lower complexity than a rocket of the Falcon 9's caliber. That's a somewhat subjective statement, I'm sure, but even if it weren't the case there's so much variation between each Falcon 9 I'd be surprised if they could crank that many out with any reasonable amount of QA.
The Soviet Union managed to produce their Soyuz-U rockets at a higher pace than that some four decades ago [1] while achieving a success rate of > 97%. Sure, it's a different rocket with different capabilities, but it was also a long time ago.
Expanding on this a bit, the concept that Hoogle embodies is extremely powerful and I wish it were more widely available in other languages.
In Haskell's case, due to the particulars of the type system, something like Hoogle is _relatively_ straightforward. More importantly, the same system that makes Hoogle possible also enables safe code exploration and reuse.
Eschewing simpler examples for something a little more production-y, I dug up something that came about after a conversation a few weeks back:
( MonadIO m
, PersistEntity val
, PersistEntityBackend val ~ SqlBackend
) => m [Entity val]
Line by line, the signature (roughly) encodes the following [1]:
1) The context `m` must provide the ability to perform I/O
2) `val` must have some representation understandable by the Persistent ORM [2]
3) `val` must have some backend within the Persistent ORM [2] that satisfies the `SqlBackend` constraint
4) The function provides a list of `Entity val`, where `Entity` is a Persistent-specific implementation detail, within some context `m`.
IMO, this is incredibly useful for searchability because it encodes everything I said above (and more precisely, at that!). Further, these terms can be pulled apart, rearranged, and composed to form more, or less, specific concepts in a query.
This is _also_ useful for code reuse, as seeing these specifications can help identify points of repetition, and encourage higher levels of abstraction.
Apologies if this got a little away from the heart of the discussion and turned into a bit of a brain-dump towards the end :)
[1] I'm not using the most precise wording here, mostly due to my own incomplete understanding of things
[2] Persistent isn't exactly an ORM, but it's the closest analogy I can think of given how comprehensive it is
I love abstractions, although at times they become a barrier to edge use cases. I guess the art is determining how much to abstract.
Perhaps I am oversimplifying the way I was imagining the search. In my mind it could simply be a pattern match (including special characters) and return the results.
Then the zoom in/out capability would allow you to determine if the result is applicable.
cf. https://www.wsj.com/articles/famous-rich-powerful-missing-15...
https://foreignpolicy.com/2018/03/29/the-disappeared-china-r...