26,433 karma · joined March 17, 2008
http://www.almostinfinite.com.
"The coastal migration hypothesis" - https://en.wikipedia.org/wiki/Coastal_migration_(Americas), which should not be confused with "the Southern Dispersal scenario (also the coastal migration hypothesis)" at https://en.wikipedia.org/wiki/Southern_Dispersal.
It's actually been longer than that. The site at Monte Verde [1] in Chile seems to have been widely accepted as a pre-Clovis site nearly 20 years ago (1997 according to Wikipedia [2]). Awareness of the site, at least among the archaeological community predates that (1989 [3]). The first radiocarbon dates indicating a pre-Clovis origin for the site go back to 1982[4].
The idea that Clovis was not the earliest culture in the Americas, and the commensurate theory that the earliest colonists must have been traveling by boat [5] goes back decades. I know I've been reading about it (in the popular press no less) since the 1990s. It seems like every article I read about it makes it seem like some new and revolutionary idea. The only conclusion I can draw is that archaeological science operates on time scales only slightly shorter than those the archaeologists study.
[1] https://en.wikipedia.org/wiki/Monte_Verde
[2] https://en.wikipedia.org/wiki/Monte_Verde#Acceptance
[3] https://en.wikipedia.org/wiki/Monte_Verde#Diffusion
[4] https://en.wikipedia.org/wiki/Monte_Verde#Discovery (third paragraph)
[5] I'd like to give you a citation for this, but this theory, as far as I can tell has no official name.
[Just quoting myself from https://news.ycombinator.com/item?id=12603556]
That's pretty cool, especially the doubling scheme. I'm using a modified form of Levenshtein Distance for comparing lines when diffing files, and that's pretty expensive since code files that are thousands of lines long are not uncommon. Since you are usually comparing one file to another version of itself, the differences are often small though, so an incremental approach would really pay off.
https://github.com/cbartley/diffy/blob/master/src/diffy/diff...
This article in The Atlantic is the best one I've seen on the issue: https://www.theatlantic.com/politics/archive/2017/08/the-mos....
I think the right answer here, to the extent that there is a right answer, is to give applicants a choice.
That's true for jet propellant, but it's not true for hydrogen. A hydrogen powered airplane would have to have a much greater volume than an equivalent airplane fueled with regular jet fuel, but it would have substantially less weight. I'm not sure how this would work out for overall performance, though -- you'd have substantially more direct drag to overcome, but on the other hand you'd have a lot less lift-related drag simply because you'd need a lot less lift.
As a thought-experiment, you could imagine an aircraft roughly the size and shape of a 757 but with the weight and payload capacity of a 737. This might be an acceptable design for a cargo carrying aircraft, but realistically, a passenger-carrying aircraft would need large cylindrical tanks on the wings for safety reasons, but also with increased drag.
> Not to mention, the entire distribution infrastructure is tooled out for liquid hydrocarbons.
In the specific case of hydrogen-powered commercial aviation, this doesn't matter at all, because there would not be a distribution infrastructure, at least as we generally think of it. Instead, we'd need to distribute water and electricity to airports, and the hydrogen would be produced and stored on-site. The equipment to make and store liquid hydrogen wouldn't necessarily be cheap, but over any significant period of time it would likely be dominated by the cost of electricity necessary to produce the hydrogen through electrolysis.
The economics of synthetic fuels for aviation are probably still better, but I think that it might be a lot closer than people imagine. If you could cheaply retro-fit existing airframes for hydrogen they'd be a lot closer still, but I don't think that's likely. It's an interesting possibility to think about though.
The most obvious one is aviation. There are a few battery-electric aircraft flying today but they have very short range. I don't think there's any conceivable battery chemistry that will allow anywhere near the range of hydrocarbon-powered aircraft.
However, liquid hydrogen has much greater energy density than hydrocarbon fuels. It's also quite difficult to work with. But when you're talking about a vehicle the size of a 737 (much less an A-380), the economics might ultimately be favorable.
It would probably require aircraft models specifically designed for liquid hydrogen -- the tanks are so large that the aircraft will have to be designed around them. That's probably a major impediment to adoption. It's possible that biofuels or synthetic fuels made from CO2 will instead replace fossil fuels in aviation, instead.
I'm not saying that agile processes are inferior or even no better than other software development processes. I'm just saying that there is some level of fundamental capability that a software organization must have before the process is even going to matter.
From the "Conclusions" section:
> Analysis of our results and comparison to the results of Kuylenstierna et al.[2001] and Skeffington[2006] lead to the conclusion that the additional sulfate deposition that would result from geoengineering will not be sufficient to negatively impact most ecosystems, even under the assumption that all deposited sulfate will be in the form of sulfuric acid. However, although these model results are feasible, should geoengineering with sulfate aerosols actually be conducted, local results due to weather variability may differ from the results presented here. With the exception of terrestrial waterways, every region has a critical loading value a full order of magnitude above the largest potential total amount of acid deposition that would occur under the geoengineering scenarios presented in this paper. Furthermore, our results show that additional sulfate deposition tends to preferentially occur over oceans, meaning the chance of such a sensitive ecosystem receiving enough additional sulfate deposition to suffer negative consequences is very small.
Also note that I did not say that sulfur dioxide injection was a good idea, only that we could afford to do it.
> One theory was that Canadians were perpetually avenging the “Crucified Canadian,” a battlefield rumour of a captured Canadian officer that Germans had supposedly crucified to a barn door near Ypres. The crucifixion was almost certainly fabricated.
The proposal for saving Antarctic ice in the submitted article may be just too big for humans to do. Sulfur dioxide injection, however, is dirt cheap, and we could definitely do that. I'm not saying it's a good idea, but we can do it.
For me, writing code is about the easiest thing I do. Other than identifier completion, I don't need much beyond a basic text editor.
On the other hand, understanding code -- not just exploring it, but understanding it -- is the the hardest thing I have to do, and that's where a good UI could be helpful. I only made a superficial scan, but it didn't really seem like any of these UIs were designed to do that.
I don't really need a map to a code base so much as I need a tool for making my own maps (not just one!) into the codebase as I try to understand it. Or understand at least enough of it to do my current task.
> Now, there’s no question that a few specific cities have seen big rises. The Bay Area is obviously one, Denver is one, and Seattle is another—though the market has responded recently in Seattle and housing development is now increasing. But if you look at big cities more broadly, there’s not even a generalized urban rent crisis.
The author's contention isn't simply that there's no housing crisis in places like Eastern Oregon, but rather that there's no housing crisis anywhere outside of a few major cities. He's also got a bunch of numbers to back up the assertion.
Now I'm inclined to think Drum's staked out a position that is too extreme in one direction (I live in one of those major cities!) but I feel like your position is too far in the other direction. I think we want to accurately characterize the problems we're trying to solve. Here in Seattle, housing supply is a big issue. But back in my hometown of Tulsa, I suspect housing is pretty cheap, and the problem is more likely a lack of good jobs.
I think we'd be better served by not talking past each other and instead make it clear which kind of homeless problem we're talking about at any particular time.
> The Cynefin framework is a conceptual framework used to aid decision-making.
It's important to note that padding schedules is not just done in software, it's a common practices in all sorts of engineering. It's not bad that we do this, it's bad that management often doesn't understand that we do this and doesn't understand why. The understanding why part is actually really important, because that means management can be expected to do their part in managing the uncertainty or at the very least they can be expected to be careful about not making the situation worse.
And it turns out that it's not unusual for software developers (and consequently software development organizations) to spend more time in the we don't know what we're doing phase than the we do know what we're doing phase. That sucks from a management point of view, but no amount of process is going to make the problem go away. The best you can do is manage the risk. We don't need good processes or methodologies nearly so badly as we just need management enlightenment about how software development actually works.
The first thought that came to mind as I was writing this was: some kind of logographic APL. I don't actually know what such a thing would like, but I'm sure I wouldn't be able to read it.