I feel like there needs to be some sort of intermediate black screen between the questions, a visual "palette cleanser" if you will. I was actively noticing the saturation of the color decline as I stared at the screen.
A commonly trotted out argument for continued investment in manned space flight is technological spillover: that all the money we give to NASA generates positive benefits in other sectors of the economy. I'm not so sure space toilets are generating that spillover. This seems like a uniquely expensive humans-in-space engineering problem. I echo the sentiments of Why Not Mars (https://idlewords.com/2023/1/why_not_mars.htm):
> The web of Rube Goldberg devices that recycles floating animal waste on the space station has already cost twice its weight in gold and there is little appetite for it here on Earth, where plants do a better job for free. [...] I would compare keeping primates alive in spacecraft to trying to build a jet engine out of raisins. Both are colossal engineering problems, possibly the hardest ever attempted, but it does not follow that they are problems worth solving. [...] Humanity does not need a billion dollar shit dehydrator that can work for three years in zero gravity, but a Mars mission can’t leave Earth without it.
Given some system under test (SUT) with inputs (T, G...) and expected outputs derived from the inputs T', G' etc., a property based testing framework attempts to exercise the entire domain of values assignable to T, G, etc. against the SUT.
The generators of T, typically called an Arbitrary<T> can be constrained, e.g Arbitrary<number> could generate any float or just non-negative integers. Ideally we would define an Arbitrary<float64> or Arbitrary<u64>.
A sufficiently expressive type system makes it easier to narrow the gap between what is generated and what is assignable to type T, making it clearer what the valid input domain to the SUT is.
I am sorry, I am not a real computer scientist and I find it difficult to find the right term.
With "sufficiently expressive", I mean things like dependent types and refinement types, that can express the constraint on a unit vector.
It seems to me that this is more or less the same thing, but Monte Carlo. Like MCMC vs symbolic Bayesian inference.
Note that this is contrary to the convention used in the Erlang community, where the number is used to disambiguate function definitions with different parameter counts, e.g. in https://www.erlang.org/docs/18/man/supervisor.html we see definitions of `start_link/2` and `start_link/3`.
It is a stylistic convention to always add this number to any reference to a function, even if there is only one definition.
> All this would be inexplicable enough if, indeed, AVCOAT was the only known material from which heat shields could be built. But while Lockheed continues to soak the US taxpayer and play chicken with the lives of NASA’s astronauts with this “flight proven” (but completely different) design, Lockheed happily built a PICA heat shield for JPL’s large Mars rovers Curiosity and Perseverance, and SpaceX’s Dragon capsule also uses PICA-3.
It's just a process to loop over a number of cycle prompting each thing taking minutes to run. It's a recipe for a massive headache as context switching costs more than 7 minutes (that arbitrary number the article came up with)
I never understood why Rust couldn't figure this shit out. Scala did.
> If a crate doesn’t implement serde’s traits for its types then those types can’t be used with serde as downstream crates cannot implement serde’s traits for another crate’s types.
You are allowed to do this in Scala.
> Worse yet, if someone publishes an alternative to serde (say, nextserde) then all crates which have added support for serde also need to add support for nextserde. Adding support for every new serialization library in existence is unrealistic and a lot of work for crate authors.
You can easily autoderive a new typeclass instance. With Scala 3, that would be:
trait Hash[A]:
extension (a: A) def hash: Int
trait PrettyPrint[A]:
extension (a: A) def pretty: String
// If you have Hash for A, you automatically get PrettyPrint for A
given autoDerive[A](using h: Hash[A]): PrettyPrint[A] with
extension (a: A) def pretty: String = s"<#${a.hash.toHexString}>"
> Here we have two overlapping trait impls which specify different values for the associated type Assoc.
trait Trait[A]:
type Assoc
object A:
given instance: Trait[Unit] with
type Assoc = Long
def makeAssoc: instance.Assoc = 0L
object B:
given instance: Trait[Unit] with
type Assoc = String
def dropAssoc(a: instance.Assoc): Unit =
val s: String = a
println(s.length)
@main def entry(): Unit =
B.dropAssoc(A.makeAssoc) // Found: Playground.A.instance.Assoc Required: Playground.B.instance².Assoc²
Perhaps I'm insufficiently caffeinated, but isn't the author describing the expression problem? That basically nails what type classes are for (in Scala and elsewhere), no?
reply