Archive for March, 2008

Latchkey Children

I recently heard, purely anecdotally, about a case where a neighbor called Child Protective Services when a ten-year old boy came home and his mother wasn’t there. His mother was out shopping or something, and had given him a key.

I don’t know if this really happened or not, but it seems like an extraordinary shift from when I was a kid. When I was ten, my parents put the key to our apartment building on a string around my neck. After school I walked home and used the key to get in. We lived across the street from the school, so this was not a big deal. There was a whole social phenomenon at the time: latchkey children.

I remember how annoying the string was, especially in gym class. When I got older I graduated to keeping the key in my pocket.

I guess that latchkey children must be rather less common now. Perhaps children with working parents now go to afterschool programs. I don’t know if this is good or bad, but it certainly seems different, as is true of many aspects of childhood today.


Walking Robot

I was very impressed by this walking robot (that link is to a video on YouTube). Watching it gave me a very strong feeling of “the future is now.” No doubt there are many hurdles to overcome, but it sure seems like we could all have a walking robot pack horse in ten years (well, those of us with enough money).

Since this is being funded by the defense department, it seems even more likely that these will be sent into combat. It’s impossible to argue against protecting a soldier. But it’s also hard for me to be comfortable with something that makes warfare easier. Even if we believe that our government is completely trustworthy, which we don’t, other governments will be able to buy these too. Put some armor on this thing and add a couple of guns and its even better than a tank: it can go lots more places, and it doesn’t require a driver. Scary stuff.

Of course, that’s probably how the ancient Egyptians felt when they first saw mounted soldiers coming at them. Military technology marches ever on.


St. Patrick’s Day

Growing up outside of Boston, St. Patrick’s Day was a significant holiday. We even got it off school–though to avoid church and state conflicts it was known as Evacuation Day, supposedly in honor of the date that the British troops were forced out of Boston in 1776. I was quite surprised to discover that this year St. Patrick’s Day was officially not on March 17 as usual, but was moved or omitted. Apparently because Easter is quite early this year, there is no room for St. Patrick’s Day.

I’m sure they celebrated it today in Boston, though.

Comments (2)

Social Entrepreneurs

A friend of mine who has been working for many years in an area that is now known as social entrepreneurship commented that there is no good economic model for it (he thinks of things like this because he went to business school).

This led me to think about economic models for charitable giving. Economists usually try to model people as rational utility maximizers: we all make decisions that we believe will make us happier. Of course this is laughably false on the face of it, though in many areas of interest to economists it works well enough. Many economic theories make a simple assumption which makes the model even worse as an approximation of reality, which is to treat money as a proxy for happiness.

Models like this don’t have a good way to handle charitable giving. They have an even harder time with major philanthropic organizations. What is Bill Gates buying with the Bill & Melinda Gates Foundation? Yet surely if homo economicus exists, Bill Gates is the type specimen.

Now, obviously I’m setting up a straw man here. Nobody really thinks that money is everything. But it’s awfully easy to make a mental slip into thinking that the simplifying assumption is the reality. A signal for this is the number of articles I see about “why do people give to charity”—as though it were some sort of weird decisions that needed to be explained (there was just such an article in last Sunday’s New York Times Magazine). Medieval Europeans would have needed no explanation. The fact that we need an explanation today is a crack in our conventional view of people–a place where the mirror we use to see the world in ourselves has broken.

Comments (2)

Compiler Warnings

There is an ongoing issue within gcc as to where warnings should be issued. The question is whether warnings should be issued only by the frontend, or whether it is also OK for the optimizers to issue them.

The advantage of issuing warnings in the frontend are that warnings are independent of optimization level. Also, the warnings are issued much closer to the user’s code, which means that it is easier for the user to understand what they mean, and it is easier to give very good location information.

The advantage of issuing warnings from the optimizers is that some warnings require the data structures built by the optimizers. A good example in gcc is the new strict aliasing warning. This warns about code which may violate the type aliasing restrictions in the language standard. Detecting this requires tracking how pointers are used in the program.

Some other warnings that gcc emits after the frontend are:

  • Warnings about large stack frames.
  • Warnings about optimizations which rely on undefined signed overflow.
  • Warnings about variables which may be changed by setjmp.
  • Some warnings about comparisons which are always true or false.
  • Warnings about unsafe loop optimizations.
  • Warnings about unused values.
  • Warnings about unreachable code.
  • Warnings about uninitialized variables.

The last two in this list are particularly troublesome. They are simple warnings, but whether they are issued changes based on the optimization level and changes from one compiler release to another. This is confusing and frustrating for users: a new compiler release can mean a new set of warnings.

On the other hand, the optimizers can do a better job. For example, the uninitialized variable warning can warn about uninitialized fields in a structure. It can also warn about variables which are passed to an inlined function by address, but are never initialized by that function. It would be possible to do these in the frontend, but harder.

The right choice may be to separate the warnings: do some basic checking in the frontend, and use different options for the warnings issued by the optimizers.

Comments (4)

« Previous Page« Previous entries « Previous Page · Next Page » Next entries »Next Page »