dwc
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.
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".
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.
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.
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.
This takes a little more work to account for, but it shouldn't be a roadblock.
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.
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.
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.
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.
if cache.contains(key) {
return cache.get(key)
} else {
v = db.query("..")
expiry = calcexpiry(v)
cache.put(k, v, expiry)
return v;
}Exactly right.
> That's what law enforcement want from this: If you know someone that knows someone that might have committed a crime, they want to invade your privacy "just in case."
It's worse. While they will say that's what they want (and they do want that), what they really want is to look at anyone at any time for any reason. Say, if you tweet something disparaging about police they'd love to be able to look at your info without asking anyone, to see if they can find something on you.
It's mentioned (and little more) in the article at the end, but it still seems odd to invoke Gibson's name and not talk about this more.
1. https://twitter.com/GreatDismal/status/1005958197654351872
How that actually plays out in a market like ours hasn't (can't) been fully tested, but it seems a promising idea.
I'd view that as incomplete (rather than ambiguous) until applied to a specific date. "You people in the Hawaii office feel free to join the Boston 2PM call whenever you want" is a fine thing to say even though you don't know what the Hawaii time will be until you know the date.
Rather than "has become" this is publishers using their leverage to achieve this situation.
Only if you work on the same kinds of things everyone else works on. There are certainly tons of jobs that qualify in that regard.
For other kinds of work there aren't packages that cover needed functionality, because either there wouldn't be many consumers of a package or the functionality is actually new. This is where I've found myself over the last couple of decades and I like it better, personally.
My current job is network programming on the core product of my employer. It's "legacy" in the sense that it's been around a long time but it's actively developed and continually extended to meet rapidly evolving customer needs.
I also wrote C in my previous job doing non-flight software for a space mission, analyzing telemetry, processing image data, automated planning of camera targeting, etc. Much other work was done in scripting languages, and when those weren't performant enough for the task then I wrote C libraries to do the heavy lifting for them to interface with.
You don't live in a bubble. There are whole segments of the software industry where you'll never see C developers, and there are many companies where you C could (should?) be used but isn't because it's unhip and old. Software development these days is pretty fragmented and there's a tendency for people to think that their experience describes everything, but it's not the case.
Expanding on an aspect of that...
Usually portability, along with many other such things, should be considered as a higher level goal. Decide on the portability requirements and then pick the best options within constraints. This varies wildly between projects! The same dev team may come to different decisions on various projects.
I think that the nature of the context can vary a lot. Some art speaks to people on a primal level, and the context is shared human experience. Other art needs more shared cultural context. Then there's art that requires the context of the artist's life to really move you.
In short, I concede your point that context matters. I think it can and does vary quite a bit.
I still don't want to conflate works requiring the context of knowing and understanding the artist with thinking a work is deep because the artist is well regarded.
The reason? Otherwise why build it? Yes, there are cases where AGI as subhuman-level intelligence would have utility, but the remaining cases are far more numerous and have far more utility.