jakub_h

It will continue to be ignored until it approaches the relevant pricing tier.

Falcon already delivered DSCOVR to Sun-Earth L1, while PSLV only flew MOM to a highly elliptical Earth orbit and MOM had to use its own propulsion for TMI.

This Bob Hoover? https://en.wikipedia.org/wiki/Bob_Hoover

> "SpaceX wants to use 42 Raptor engines which were initially designed for an upper stage single engine usage"

That's not what really happened, and anyway, Raptor is a 35% larger engine than BO's/ULA's BE-4. So by your definition, if ULA's/BO's engines are "big", then SpaceX's engine is "even bigger".

That may be fixable at compile time, I believe. In the worst case, you could write a patch. (Dijkstra would prefer a half-open indexing scheme anyway.)

Coincidentally, this very book on auction theory was suggested to me by a fellow faculty member about three months ago. I guess I really ought to find some time to read it!

> And from my experience, it's way easier to model data with three simple structures; vectors (= arrays), maps and sets.

So, Lua tables? ;)

"Passport-protected open network"...heh, that reminds of the "anonymous functions" in PHP (the ones documented with the sentence "Creates an anonymous function from the parameters passed, and returns a unique name for it") :D

It's not mixed-in, it's in a separate tank. But since the tank is an aluminum alloy (often with copper or lithium mixed in) these days, I wonder about its behavior in the presence of an ignition source (some magnesium in the bullet or perhaps even just friction?).

There's no Dewar vessel on the LV as far as I'm aware of. The surface of the stage is the propellant tank, made of simple Al-Li alloy, several millimeters thick. It works fine because of the large mass of the LOX and the comparatively short time of the stage's operation. You just can't transfer enough heat into the stage naturally in the short twenty or thirty minutes between fueling and launch to cause any trouble.

Before they started supercooling the LOX, it was even easier because heat transfer into LOX tanks is conventionally managed by boil-off (in launchers without supercooled propellants, latent heat keeps the liquid at a stable temperature and a trickle refills the tank continuously until a minute or two before launch).

.50 BMG is supersonic but drops in velocity rather quickly, like any other small caliber round. Depending on the position of the shooter (especially if opposite to the recording equipment relative to the LV, for example), chances are that the cameras with mikes recording the LV might have problems hearing it. I'm not sure at what distance it drops into subsonic region but the size of the target should allow for some pretty large distance. Powder load could also be tweaked. One has to assume a shooter with significant resources if a deliberate action against a multiple-$100M target is the premise.

It would make you an ignoramus in all things Latin, I assume? Given that "viri" means "(a plurality of) human males"...

Reminded me of Part 4 of https://www.inf.ethz.ch/personal/wirth/FPGA-relatedWork/Comp... . Intellasys/GreenArrays are kind of similar but only with tiny local memory.

That sounds like Audio CAPTCHA.

I call it "the reverse case of ZX-80".

You mean something like Oberon?

It's a pervasive element, though. Which to me means two things. First, I wonder if there isn't a way of adding it (really) transparently into a language. Basically, whenever there's a possibility that a value is a function of old values, chances are that a previously used result is still available. Second, strategies can have massive time and space implications, but that's exactly why being explicit about them in the application's code in any way should be avoided at all costs: they shouldn't change the semantics, only pragmatics. Given that compilers already do this with simpler things (are my local variables actually on stack or are they kept in registers?), one has to wonder if this isn't one of those things that computers could perhaps figure out on their own in the future, just like we don't allocate registers by hand anymore either. In a similar way that, say, ATLAS finds out by trial and error the best way to perform FP linear algebra within a system of parametric code solutions. I think the "here's what I mean, give me a piece of code that does this" approach could have massive impact in the future. Transparent caching, glue code/plumbing, automatic algorithm selection based on result constraints etc. all seem like possible applications.

In fact, it is well known that the two hardest things in programming are cache invalidation, naming things, and off-by-one errors.

We totally can! We'll just ask the output be at least 8 out of 10. The output being...uh, the average of grades from our ten resident artists. ;)

Funnily enough, I've yet to see him do that. The logical next question is obviously "so what are these other people for?".

Perhaps something related to continuous optimization? I think Oberon experimented with that.

This took me a while to get. But at least I'm not apparently a completely hopeless case...

Interesting, any references?

It's still a simplistic toy, albeit a highly formalized one nowadays.

> Thankfully, I've not felt the need to even consider this approach for the past 20 years.

That's because of all the branch predictors, probably. ;)

> Tesla cars are an expensive luxury brand and have no real revolutionary potential at the moment. The revolution is to make affordable electric cars and the infrastructure to build them

So...their plan being to bootstrap the large-scale manufacturing of affordable vehicles with a smaller number of more expensive sales, you're saying that Tesla simultaneously is and isn't revolutionary at the same time?

Isn't it somewhat hypocritical to not want to pay for the expensive marginal case but to ask for someone else to do it for you?

A/C can also freeze water to shift the load very cheaply.

> "If you have a reliable natural gas distribution network, like the rest of the world, batteries don't make any financial sense versus gas power plants."

"The rest of the world" also has measurably more expensive gas. ($10/mmBTU for large scale users around here).

If you want an actual rich object model, why aren't you using CLOS instead? Java's objects costs you a lot of potential performance with few of the benefits.