thelambentonion
thelambentonion on Hacker News
for others following along: the comment history is mostly talking about how software engineering is dead because AI is real this time with a few diversions to fixate on how overpriced university pedigrees are.
cf. https://www.wsj.com/articles/famous-rich-powerful-missing-15...
https://foreignpolicy.com/2018/03/29/the-disappeared-china-r...
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.
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.
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.
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.
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]
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
It has a very strong type system, a compiler that can produce optimized and human readable JavaScript, and dead simple FFI. It _also_ doesn't rely on a runtime like Elm or GHCJS do, so the resulting code size is typically much smaller.
It's also been used to build some really interesting and unique takes on the frontend design problem (cf. Pux [0] and Halogen [1]).
Opaleye [0], an Arrow-based [1] DSL for Postgres SQL that allows the user to create type-safe, composable, and (generally) optimally fast SQL queries.
Halogen [2], a type-safe frontend framework for PureScript [3] that models view component interaction as an algebraic datatype containing query actions (among other fairly advanced concepts).
If someone is used to a certain level of abstraction, then the higher levels might seem unnecessary until they invest the time into learning them. The only thing unique to functional programming is that it has inherited a lot of terms from theory (profunctor, monad, algebra) rather than inventing friendlier ones.
[0] https://github.com/tomjaguarpaw/haskell-opaleye
[1] https://www.haskell.org/arrows/
There's some science, but the advertising here is a perfect example that many people have no idea how to spend their ad money in a way that meaningfully engages some target audience.
The seL4 project has produced a formally verified microkernel, open sourced along with end-to-end proofs of correctness [0].
On the web front, Project Everest [1] is attempting to produce a full, verified HTTPS stack. The miTLS sub-project has made good headway in providing development and reference implementations of 'safe' TLS [2].
These are only a few projects, but imo they're a huge step in the right direction for producing software solutions that have a higher level of engineering rigor.
[0] https://wiki.sel4.systems/FrequentlyAskedQuestions
[1] https://project-everest.github.io
[2] n.b. I'm not crypto-savvy, so I can't comment on what is or isn't 'safe' as any more than an interested layperson.
Scroll down for nyan mode, if you don't mind using an external package. :)
I suppose it might be worth it to keep including the disclaimer, as it'a possible I may be biased in some way that I'm not consciously aware of. Although it bears mentioning that if my former employer made half of SpaceX's promises, I'd be twice as skeptical! So a point in their favor.
I hope I'm not coming off as too much of an asshole in these threads; I really do want to see commercial space flight grow and succeed going forward. It's just that my experience and the conversations I've had with current and former SpaceX employees gives me an unhealthy dose of skepticism regarding a lot of their claims.
Re: that specific question, I may just have a different view of what constitutes a question on engineering challenges.
That AMA is of exceptional caliber, however, and there are definitely some gems to be found (see [0] and [1], in particular).
The fuel tank and rocket tech represent novel advances in rocket tech that are as-yet untested, afaik. A scaled-down test stand prototype and a prototype of a composite tank are certainly worthy of praise, but they still require an enormous amount of work to turn into a functioning product.
I'd also like to qualify some of my statements here: I don't think _any_ of these challenges are insurmountable. However I think that it would be impossible for all of them to be addressed on the time scale that Musk proposes, for the amount of money he has stated, with the manpower that SpaceX possesses.
[0] https://www.reddit.com/r/spacex/comments/590wi9/i_am_elon_mu...
[1] https://www.reddit.com/r/spacex/comments/590wi9/i_am_elon_mu...
AFAIK no one else within the community would think of saying that.
I'm sure that there are people within SpaceX studying this and taking it into consideration, but my concern is mostly with Musk's cavalier attitude towards individual safety.
I'd quite like to be proven wrong, spaceflight is an area very near and dear to my heart, but from my point of view Musk's reach appears to vastly exceed his grasp.
EDIT: I did enjoy the AMA though, as it provided some interesting insight into their plans for all of this.
Please provide a citation for this. As far as I'm aware, we simply have no idea the kinds of effects that radiation encountered during the flight would have on humans.
The sample size for human exposure to space-based radiation is incredibly small (limited to just the astronauts on the ISS, and even then that is protected by much of the Earth's magnetosphere).
Check out Robert Zubrin's article, which presents a much more salient critique of SpaceX's current plans than I could [0].
[0] http://www.thenewatlantis.com/publications/colonizing-mars
To pick a specific example, he seems to have very little concern for radiation shielding both during the trip to Mars or on the Martian surface. Both of these present incredibly harsh radiation environments for humans, and we need to develop solutions before we even consider sending explorers, let alone colonists.
Right now I'm keeping an eye on servant-auth [1] and the GHCJS implementation of servant-client [2], as they're both extremely compelling.
[0] Recently, I needed to test something against a work-in-progress API. I wrote out a rough type-level specification and had servant-quickcheck generate arbitrary data. When I needed to test more concrete data, it was trivial to incrementally move endpoints over to concretely defined stubs.
The quality of the language and documentation has been superb, and I feel more confident in my code than I did with another project written with JS bindings.
[0] I suppose the argument can be made that web-view components could be recycled with minimal effort, but that sounds like it'd be a worse story for end-users more often than not.
I like a lot of what you said, but I do disagree with that point. Immediate application of mathematical concepts may be gratifying, but making it the _only_ motivating factor behind maths can result in students who conflate the underlying machinery with its application [1].
Taking a pure maths course in undergrad with related subject matter prior to one of my Controls classes made the class substantially easier to understand. Learning the abstract concepts beforehand let me see the common applications more quickly than others.
I think the biggest difference is that when I learned some Calculus through Physics, it was a little more difficult to go from a concrete basis to a more general one. My understanding ended up being based on analogies to other concepts until I went back and covered the theory again.
[1] This is all my own opinion, I'm not an educator so the most I can do is pull from my own pedagogical experience :)
Idris is an experimental language exploring the practical benefits of dependent types, and providing a modular backend for code generation (e.g. it can emit either C or Javascript currently).
I wouldn't say that Haskell is somehow better at being translated to assembly than, say, C. The real power is in the ability for the language to express the author's intent, and for that intent to be reflected in the resultant machine instructions. It's something that's surprisingly difficult to do, and part of why there are so many languages with different syntax and semantics [2].
One way to try and guarantee that the author's intent is translated accurately is to try and add constraints in the form of a strong type system (e.g. Haskell). I think this is a rather neat idea, and at the very least worthy of some time skimming through papers or listening to talks.
As software gets more and more complex, more people are finding that these ideas are useful in non-academic settings. I think my favorite example is Galois' SMACCMpilot project, which seeks to write secure, verified autopilot code in a Haskell DSL [3].
[1] First appeared around 1990
[2] n.b. I'm not a subject matter expert, just an interested hobbyist
[*] Addendum: CS isn't my original field of education, so take all of these opinions with a heaping spoonful of salt. Corrections and clarifications to any of the above would be appreciated!
Chasing the next popular bit of research 10 years in advance is a bit of a fool's errand, so the best you can do is follow along with fields that you think are personally interesting.
For a more serious answer, I do think that FPGAs are going to become much more applicable to general-purpose-computing soon. Most of the tooling and language support around them is pretty archaic, and tools like CλaSH [1] make development much more friendly.
The Glasgow Haskell Compiler is also ostensibly a long-lived, continuously updating research project. Simon Peyton Jones summarized the State of GHC recently [3].
[1] And I try not to worry about it too much :)
[2] https://eb.host.cs.st-andrews.ac.uk/drafts/impldtp.pdf
[3] https://www.youtube.com/watch?v=dIxCHQEIGps
[*] Another paper that looks cool, but I can't really make head-or-tail of: http://okmij.org/ftp/Haskell/extensible/more.pdf