HN user
Software Engineer in Seattle.
http://www.almostinfinite.com.
[5] I'd like to give you a citation for this, but this theory, as far as I can tell has no official name.
"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.
For more than a decade, evidence has been piling up that humans colonized the Americas thousands of years before the Clovis people.
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]
OK, now can somebody explain to me the difference between .bashrc and .bash_profile?
This implementation only computes the distance if it's less than or equal to the threshold value, returning -1 if it's greater. The advantage is performance: unbounded distance is O(nm), but a bound of k allows us to reduce it to O(km) time by only computing a diagonal stripe of width 2k + 1 of the cost table. It is also possible to use this to compute the unbounded Levenshtein distance by starting the threshold at 1 and doubling each time until the distance is found; this is O(dm), where d is the distance.
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.
Here's my attempt to implement Levenshtein Distance in Go, with lots of comments:
https://github.com/cbartley/diffy/blob/master/src/diffy/diff...
Damore was fired because a shocking number of people apparently have a fundamental reading comprehension problem.
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'm OK with whiteboarding. I don't object to take-home assignments in principal, but I do object to them in practice -- they take up way too much time, and then part of the time you get ghosted after submitting them.
I think the right answer here, to the extent that there is a right answer, is to give applicants a choice.
Last time I was looking for a job (about 3 years ago in Seattle) I had a lot of trouble getting through the initial screening to even get to a technical interview. I didn't have a lot of luck until I started applying through AngelList. One notable thing about AngelList applications is that there was no HR/recruiter screening step you had to get through first.
There's a lot of the author's opinion embedded in that paragraph, and I'm disinclined to agree with it, but ... no wait -- was that paragraph generated by a Markov bot trained to make substanceless attacks on opinions that the author doesn't like?
I wonder if it's practical to stick a couple of Space Shuttle external fuel tank-sized liquid hydrogen tanks on a typical container ship and then run it on hydrogen. One of the problems with liquid hydrogen (not the only one) is that it's impossible to keep it from slowly off gassing. However, if the tank is large enough it would off gas slower than your engines would be consuming the hydrogen.
Half the gross weight of the entire system is fuel.
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.
It's pretty clear that hydrogen-powered automobiles are not going to be a thing -- electric batteries work very well for that use case. There are some cases where I think hydrogen might still work better than the alternatives.
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.
Introducing the Steel-Plate Composite Core: https://continuingeducation.bnpmedia.com/article_print.php?C...
If your software development organization can't ship software without an agile process, then it's unlikely that it can ship software with an agile process either.
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.
The Reddit live thread is here: https://www.reddit.com/live/13d5jgjysmbem/.
This paper considers that very question: https://agupubs.onlinelibrary.wiley.com/doi/pdf/10.1029/2009...
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.
According to the article:
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.
A few years ago I did some back-of-the-envelope calculations regarding sulfur dioxide injection into the stratosphere: http://curtisb.posthaven.com/someday-soon-chemtrails-may-be-....
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.
Some of these interfaces might be really fun to implement, but there are very few of them that I think I'd want to use.
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.
A lot of Go programmers didn't like this proposal at all. I'd like to think this is just because they didn't think it was good enough. However, it seems that many, many Go programmers didn't like it because they think Go error handling is just fine the way it is.
From the post:
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 this is the first article I've read to use the term "visible homelessness". For many people who live in Seattle, the world "homeless" really means visibly homeless, but for many political activists, the word includes people in shelters or living in the cars or otherwise keeping a low profile while not having a permanent address. I'm no expert but I strongly suspect that the best ways to help the visibly homeless and the not-visibly-homeless are pretty different. But activists are more than willing to conflate the two cases. This particularly arises in the case of affordable housing. Housing may indeed be the primary problem for the not-visibly-homeless. It seems pretty likely though (just based on observation) that the biggest problems for the visibly homeless are mental illness and substance abuse.
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.
I barely understand any article on quantum mechanics, but now I know that QTT is a thing and people are experimenting with it. That's why I personally upvoted the article but I admit I was on the fence about it. I'm hoping someone knowledgeable will comment on the article and I might gain just a little more understanding. Maybe.
From https://en.wikipedia.org/wiki/Cynefin_framework:
The Cynefin framework is a conceptual framework used to aid decision-making.
I kind of lean towards double the schedule and cut the scope in half and hope that maybe we can deliver a little extra credit work.
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.
Any software development methodology or process is going to come up short if it ignores the fundamental nature of software development, which is: We do not know what we're doing until we do. Any process or methodology that tries to extract promises out of the software development organization about things that are still in the we do not know what we're doing phase is going to result in disappointment at best and serious harm to the overall effort at worst.
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.
What would a Chinese-influenced programming language look like if its designer(s) had never had any exposure to alphabetic or syllabic writing systems?
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.
Programming languages and human languages are really not the same thing at all, unless maybe you consider some extreme outliers like AppleScript[1]. It seems like the choice of character set would make a bigger difference. Most of the today's popular languages would seem to be strongly impacted by making them compatible with code that is entirely in 7-bit ASCII. I don't know enough about other character encodings to try to imagine how they might make for a very different programming language design. What would a Chinese-influenced programming language look like if its designer(s) had never had any exposure to alphabetic or syllabic writing systems?