dkirkman

Tahoe has a surprising number of jurisdictions! I'm on the Nevada side, so I don't have personal experience with the SLT enforcement.

Here there seems to be a fair amount of teeth gnashing about airbnb -- there are clearly more people in the neighborhoods and rentals for locals are now hard to find. But the homeowners think it's raising property values and are kind of happy that if they ever leave Tahoe there is now a pretty straitforward way to hold on to their property. The end result is not much happening.

The SLT ordinance is addressing the what I think is the major fear for many -- that a nearby house will become an unbearable party house. I think pretty much all of the Tahoe jurisdictions have moved quickly to ensure that doesn't happen. In our neighborhood, I've been told the sheriff responds in minutes to a noise complaint, and that the visit results in fairly draconian fines to the property owner.

I think in general, it's very difficult if not impossible to realistically explore the counterfactual of "what would this property be if not for Airbnb".

However, in my neighborhood long term 12 month lease rentals most definitely seem to be being turned into Airbnb rentals. I live in Tahoe, so this isn't necessarily going to generalize to non-tourist areas. In the last five years there has been a steady conversion -- I personally know of four in my immediate neighborhood. (As in, they were long term rentals converted to Airbnb. I know the people that were kicked out of the long term rentals) When we'd recruit new people to Tahoe there used to be numerous options for local housing, things have gotten so bad that the company I work for opted to buy a condo to provide temporary housing for new recruits while they look for more permanent accommodations.

An additional (also anecdotal) data point: our realtor told us that investors looking to convert homes into Airbnb are very active right now.

On the plus side (potentially, not everybody agrees) Airbnb also seems to have converted a number of second homes that were previously unoccupied most of the year.

The whole issue of whether or not nanotech would end up just looking like enzymes was a big part of the famous Drexler/Smalley debate (http://en.wikipedia.org/wiki/Drexler%E2%80%93Smalley_debate_...)

I always found Smalley's arguments that nanotech would end up looking like biology convincing. Not that I think it matters much: would designing organisms that take the shape of a part and excrete an "exoskeleton" to realize it any less cool than assembling the same thing atom by atom?

> Your are not required to use exceptions or templates if you don't want to.

This is absolutely true -- at least if you're working alone. But I've always found the whole "let's use a subset of c++" to be untenable on long projects. Somebody always joins that's infatuated with Alexandrescu, or some random error handling strategy, and then you end up in endless debates about concepts vs. abstract base classes. Those debates can be fun, but they seem to too often leave behind hurt feelings and demoralized team members.

If you just throw back to c, all you have to deal with is the argument that "we should really use c++, because <insert some random thing>". Those don't last too long, you just have to respond that it's a c project :)

Yes, there are pills that will both increase insulin sensitivity (metformin), and to stimulate insulin secretion (the sulfonylureas). These are basically the first line of treatment. But the disease tends to progress to the point where they are no longer enough. The insulin resistance keeps increasing, and at some point insulin secretion also starts to fall off -- though it's usually still very high compared to a non-diabetic. At that point, exogenous insulin is all that's left. Unfortunately, it also seems to be used as a bit of a threat by MDs ("you'd better loose weight and start exercising, or you're going to need injections!")

BTW, I'm not an MD, just a somewhat informed layman. I just happen to be married to a type-1, and have type-2 running through my family, so I've been motivated to learn a bit about it all (mainly in an attempt at self-preservation!)

This isn't entirely snarky. The ACCORD trial was a spectacular failure (http://www.nejm.org/doi/full/10.1056/NEJMoa0802743). Nobody really knows why (as far as I know), but since high blood glucose is known to cause problems, and lowering it by giving extra insulin does not seem to help (remember that type-2's usually have high spectacularly insulin levels to begin with), we've got to consider other approaches.

Avoiding carbs seems to both normalize glucose and lower insulin in type-2s, so it's not a dumb approach. On the other hand, a low carb diet tends to increase insulin resistance, so if it turns out that both the glycemia and insulin levels are not the cause of the adverse symptoms, but rather symptoms in themselves, going low carb may make everything much worse. (e.g. it might make the numbers we can measure look better, while worsening whatever metabolic abnormality is causing the diabetes in the first place)

The precision of the timing and dosing depends a lot on what kind of diabetic you are. A type 1 with no endogenous production is going to need precision, and I can't imagine somebody wanting tight control giving up their pump and going with a pill!

type-2's on the other hand, have insulin resistance often accompanied by astonishingly high endogenous production. They can sometimes achieve nice control by just having a base of exogenous insulin that's just high enough for their pancreas to supply the rest of what they need -- the precision is supplied by the still largely functioning pancreas. I know at least one type-2 that has been put on insulin with instructions to inject X units with dinner, with no consideration of the actual content of the meal! Presumably a pill would work fine for that group.

Living with a type 1 for a number of years has given me a similar view. On the other hand, very real (and often hyped) advances really do happen. When pumps first came out, they were almost magic, ditto with continuous glucose monitoring.

To be fair, the c++ programmer can also use reference semantics via pointers. Granted, garbage collection is not built into the language, but if desired, we can always write java-style code by using pointers for everything and using the Boehm collector. I don't know why we don't do this more often, most c++ codebases seem to have large sections that would benefit from such a style.

But when we want to use value semantics, for whatever reason, the more complicated value copy is, to some extent, just intrinsically complicated. In java, Object.clone basically has all of the same problems -- you sort of know what you'd like it to do for any given object in any given context, but you've got to read code to figure out what is actually going to happen.

> If I had to guess, I'd say it's based on the fact that math involves a lot of critical thinking and critical thinking is very difficult to teach.

I think it's even worse than that -- I suspect that many teachers in American public schools are terrified of math themselves, and they transmit that terror to their students. It's going to be very hard for a student to learn to view mathematics as reason if their teachers don't see it that way.

There was a point when I was in grade school and we were learning formulas for the area of different shapes. When a trapezoid came up and I noted that it could be decomposed into a square and two triangles, I was admonished to just use the formula from the handout. Don't get in the habit of trying to think while doing math, it'll just get you in trouble.

This was from an otherwise excellent teacher, but when it came to math we were to turn the thinking switch to "off". This fear of math seemed to not been exceptional, even among my high school math instructors. I may have had a bad run (public school in California in the 80s), but I've been told similar stories by most everyone I've met who eventually managed to figure math out on their own.

The problem is that in terms of getting jobs, promotions, and tenure, producing code has no value. Except for the people that actually write it, "programming" is generally considered to be a trivial task. So if you invest time writing data analysis code, the only way you can get a return on that investment is to keep it proprietary to your group and use it to get results before your competitors do.

We can't expect source code publication until we change the perception that it's trivial. If published code were as valuable as refereed papers for career advancement, the problem would be solved instantly. But if that change does not occur, requiring that analysis code be published will just stop the development of any new code (at least by career rational people) and probably hurt the field more than it helps.

> Thanks for posting. I would have thought narrow lines would produce the problem that those specific lines would become unavailable for study, or would be freely mixed with the "real" data in confusing ways. It didn't occur to me that they could simply be subtracted in a deterministic way.

Your original thought is basically correct: we do lose the ability to do any meaningful work at the wavelengths of the lamp emission lines. But the damage is concentrated at a few wavelengths. So we trade having noise over the entire spectrum for a few really, really noisy pieces of spectrum. It's generally a excellent tradeoff.

But even low pressure sodium lamps have some emission spread over a large wavelength range, so it is becoming increasingly difficult to do optical work near major urban areas. In the long run most of those sites will probably transition to mostly IR work.

On Mauna Kea (big island of Hawaii) the biggest sources of light pollution are the airports and harbors.

For the telescopes near big cities, I'm not sure if anybody has worked out the relative contributions of street lights to say billboards or car dealerships or backyard flood lighting. But from standing on the summit of Mt. Hamilton and looking down into the valley it would seem to be mostly street lights

Street lights that emit narrow spectral lines are not a problem at all for spectroscopy, except of course at the line wavelengths. I have a bit of experience here -- a few more than 400 nights observing spectroscopically at Lick Observatory, where we have just a wee bit of light pollution!

All lights, narrow or broad band, present problems for optical broad band imaging.

If we could get all cities to go with low pressure sodium lamps (that only emit at a few wavelengths), astronomers would be very happy. The only problem is that city residents tend to not like the monochromatic look you get from not having a broadband light source. So San Diego, for example, switched to low pressure sodium in the 80's to try to protect the skies for Mt. Palomar. But residents started screaming (it's leading to more crime!) so the city went back to high pressure sodium.

There are a few good reasons that one might prefer common lisp to scheme.

It has been stable for a good long time. Which is nice if you've got a giant repository of old code that you dust off and run from time to time.

CL has a standard way of specifying variable types when you want to do so, so it's possible to write high performance numerical code in a portable (across different compilers) manner. Or write macros to write portable code.

My view on macros is that being code transformers, when you write a macro you are basically writing a quick and dirty compiler. And like everything that's quick and dirty, they are full of bugs and gotchas. The fact that CL has separate function and value namespaces helps with decreasing the gotcha cross-section. The scheme community early on spent a lot of time dealing with this and developing hygienic macros, but as a lisper this just always felt a bit heavy. (This is probably just a lack of exposure).

From my perspective, the appeal of scheme as been its more pure focus on functional programming. But when I'm in that sort of mood I just reach for haskell now.