dwc

> The right comparison is with the distance at which this photo was taken: 18,000 miles, or about half an hour from closest approach.

Implicit in this statement: the camera was pointing close to the direction of travel and the target wasn't moving much within the field of view. Hugely easier than trying to image from the side at closest approach, which at best would have given a smeared image and at worst a complete miss.

It's still impressive and awesome. But always try to skew the odds of success in your favor when dealing with stuff like this. You have one pass and then the opportunity is gone.

Uniformity through imposing one paradigm on everything isn't attractive at all to me, especially for a paradigm I have no interest in using and avoid when I practically can.

> the language isn’t CLOS all the way down

I'm curious what you mean by this, why it's needed or would be a good thing, etc. As a multi-paradigm language, I'm not seeing why CL should have a particular paradigm "all the way down".

> And 10 years later, sharing stuff with people nearby still kinda sucks.

It does still suck, and once every few years I feel that. But that's a problem. Solving a minor, "kinda" pain point that people experience once in a while isn't that big of a win. I'm sure that other people want to do this more often than I do, but I'm also sure that this case is a small subset of the need to share stuff with others generally. I.e., you're always needing to share stuff, with people in Boston, LA, or Singapore, or your manager on another floor of the building, or wherever. You know how to do that. So while it seems silly that you can't share something more easily with someone sitting across the table from you, the methods you already use do work.

Phoenix AZ area.

I grow blue java bananas in my yard. Rajapuri bananas are fairly popular around here.

> It's unfortunate how much Google-hate is on HN these days because I think it's largely unjustified. There are definitely some bad (IMHO) leadership decisions but the rank-and-file are still culture carriers for a lot of the things that made Google great.

The fairly small number of people I know who are Googlers or Xooglers are all pretty awesome as techies and as people. That does little to change my opinion of Google itself. Sometimes it makes me even more cynical, thinking that management might take special care in internal messaging lest the rank-and-file revolt.

But from my perspective, from the outside, what Google does as a company is what counts for me and for society. All the good people inside don't ameliorate the external behavior of the company.

> A trusted network is fine, but are the telephone networks trusted?

In the old days there was an assumption that if you were in the network then you were trusted, which was always dicey but made more sense when Ma Bell controlled everything tightly. Since the monopoly breakup that model was no longer true, and many problems can trace back to the nature of back patching security onto an entirely different model that no longer fits reality.

Note on above: there are legitimate reasons for businesses to set Caller ID to something other than the call origin. But the "something other" should be selected from a set under the control of the business, not a free for all. I.e., a desk phone with DID may show as the main company number, etc.

This takes a little more work to account for, but it shouldn't be a roadblock.

Spoofed Caller ID is a lie, not anonymity.

Here's a proposal: 1) Caller may choose to hide/suppress their Caller ID, 2) mandatory option for phone carriers to allow Callee to completely block calls (no ring, no voicemail) that don't carry Caller ID, 3) When present Caller ID must be accurate.

The above allows anonymity but disallows deceit. It also provides opt-out for people not to receive anonymous calls. (Anonymity does not give you the right to have any given individual listen to you)

We could have had this for ages, as there are no great technical hurdles.

You start by saying that too much is blamed on leadership and then go on to describe the real reason which is a failure in leadership?

FWIW, I largely agree about the "cogs" idea. One particularly frustrating thing is seeing repeated failures and management fails to consult with workers about how it happened. Seeing the repeated problems the workers volunteer their insights to management about the underlying problems and possible solutions. But that info is either discarded (after "careful consideration") or warped to fit an existing but incorrect management narrative. The very idea that people doing the work could contribute anything meaningful beyond estimates doesn't seem to be palatable.

> One question I have is how sequestered the undersea carbon really is

Depends on how you interpret "sequestered". In the sense that it's locked away somewhere for a long time, like organic matter frozen into tundra, it's not very sequestered. But as long as there's lots of seaweed there'll be a lot of carbon taken up. Even though individual plants may die and release their carbon on a relatively short timeline, new growth will take up carbon.

Yes, correctness absolutely comes first.

One way to achieve greater simplicity is to negotiate for fewer/simpler requirements for the first revision. There's often a core set of functionality that can be implemented correctly in a simpler way, and that gets the work done. Once that's in place it's interesting to see how often people lose interest in what were "hard" requirements before. It's also common that new asks have little to no resemblance to those unimplemented features, and are instead things that they found out they needed after using the new system.

I like and use early exits when they fit well, which is often. And in this case I'd probably do as you suggest. But it's worth mentioning that even if you stick with if/else it's often worth it to put the simple case first to reduce mental load:

    if cache.contains(key) {
      return cache.get(key)
    } else {    
      v = db.query("..")
      expiry = calcexpiry(v)
      cache.put(k, v, expiry)
      return v;
    }

They would make forks ;)