The idea is that you can split up the program in parallel tasks in a fully automated way. If you as a programmer even have to think about parallelizing, I’m sorry, but then your compiler is “doin’ it wrong” and your languages is from the stone age.
This is not true in high-performance computing. If you don't want your CPU spinning its wheels on locks and cache misses, then you need to go quite low level -- and really think about the data structures you're using, and how to parallise tasks with next to no interthread communication.
The point of functional programming is that you don't have to think about locks or how to manage contention on your data structures because there is no such thing such thing as mutable data. And if you're just letting the compiler do the parallelization, you don't have to think about interthread communication, either, because the compiler will automatically find the places where function calls can be parallelized with zero interthread communication. Of course, if you structure your code so that it's inherently sequential then the compiler won't find any opportunities for parallelization, so you still have to think about that.
Of course, functional code ultimately gets translated to imperative code, because that's what our processors do. And that translation is being done by a program, which means it will never match the best that a talented human can do, in much the same way that hand-coded assembler, produced by a developer who knows the processor inside and out, will always beat the best-optimizing C compiler. But with functional programming, a good compiler can take significant advantage of multi-core systems for much less programmer effort. Is it as good at maximizing performance? Obviously not. But it's quite good, at much lower cost.
Look BOTH WAYS EVERY TIME 'cos we do have a few one way streets in Ye Olde Londone
Yes, you should always look both ways, but that doesn't reduce the value of the advice to look right.
When crossing the streets, most people look toward oncoming traffic in the near lane, then if there are no vehicles there they look toward oncoming traffic in the far lane. If that's clear, they then turn to look to the near lane as they begin crossing, then when they get to the centerline they turn to look the other way, so they're always looking at oncoming traffic in the lane they're crossing.
People from countries that drive on the right side of the road glance left, glance right, then look left as the step into the street. Doing that in a country that drives on the wrong, er, left side of the road means you risk stepping in front of the vehicle that hadn't yet come around the corner when you glanced right.
So, look both ways, but look RIGHT, not left, when stepping into the street.
Also, don't miss the Cabinet War Rooms in Whitehall (actually part of the Imperial War Museum).
Seconded! I spotted the Churchill Museum & Cabinet War Rooms by accident and decided to go in on a whim. Ended up spending most of a day there. Fascinating stuff.
I've heard Verner Vinge come up more than once now in positive reference to his writing (as opposed to him coming up in reference to his ideas)
His ideas are pretty stunning. I particularly liked the small-group hive mind aliens in "A Fire Upon the Deep". They used natural ultrasonic data links to combine a half-dozen relatively weak individual minds into a persistent collective mind with approximately human-level intelligence. I did find the basically feudal social structure a little unimaginative, but I recognize that there comes a point where the story has to be rooted in some familiar structures, for the readers' sake as much as the writer's. Those very interesting creatures were only one small piece of the book and its ideas.
I like reading the kinds of things that are too "out there," do you have any specific recommendations?
I have to admit that I really haven't been reading sci-fi much lately -- mostly I haven't been reading fiction, just not much time for it between work, family and a couple of "intellectual" hobbies that are absorbing my time (an OSS project, teaching myself functional programming and working my way through the projecteuler.net problems).
Anyway, from what I have read of late:
I'm currently reading Neal Stephenson's "Anathem', and I highly recommend it. Besides Vinge's "A Fire Upon the Deep", I also read "A Deepness in the Sky" and "Rainbow's End", and they all really impressed me. The first two are in very bizarre settings that are really inventive. The third is a near-future book that's a really interesting extrapolation of current technology, though not as mind-bending as the others. I also recently read Robert Reed's "Sister Alice", and it was quite interesting. Something a little more traditional and cliched that is nevertheless very good is David Weber's "Safehold" series, starting with "Off Armageddon Reef", and, of course, Weber's Honor Harrington series is the first I've ever read that has a scientifically-plausible notion of how battles in the immensity of space could realistically happen. Other than that, the Harrington series is entertaining and well-written, but not groundbreaking.
Sci-Fi lost the last of its steam when it switched from being Science Fiction to being Sci Fi. It's been part of a continuing downward spiral where while there have been more offerings recently, especially in mainstream culture, these offerings are increasingly more and more derivative and uninspired.
You need to read some of the good modern sci-fi. Vernor Vinge is the author everyone mentions, but there are others writing some really creative stuff. So creative, in fact, that a lot of people find it too "out there" to read comfortably, which was also the case with Golden Age science fiction. A lot of the recent Hugo and Nebula nominees are excellent, though the winners are typically a little more mainstream.
Actually I LOVE the multi-window layout on a multiscreen setup (image on one screen, tools on the other). But love to HATE it on a single screen setup.
I love it on both, at least on a system with a decent window manager. I think the biggest beef people have with GIMP's multi-window layout is that they're trying to use it on Windows.
jbengt wasn't really going for the "kids fuck up and shoot each other" argument methinks... was saying people use guns to shoot other people.
That's what I understood him to say, and what I responded to. The figure of 409 deaths in 2006 isn't restricted to just accidents, nor only to deaths inflicted on kids by kids, it is all firearm deaths of children in the year.
A point you inadvertently echoed.
There was nothing inadvertent about it.
The difference is they think the answer is less guns, you think the answer is more guns.
That's oversimplified to the point of being outright wrong.
I know that less guns won't significantly decrease the child death toll, because guns already play an insignificant role in child mortality. I have some reason to believe that more guns will reduce violent crime overall which may lead to some reduction in child murder, but might be offset by an increase in child suicide and perhaps by accidental firearms deaths (unless firearm education continues to improve).
The key point, though, is that whatever reduction in child deaths might be achieved by banning guns (even if we ignore the fact that most guns used to kill people are already illegal), it would be a bad trade against the corresponding loss of liberty.
It would be like reducing the number of trampling deaths caused by shouting "FIRE!" in a crowded theater by banning theaters.
What part of "the right of the people to keep and bear arms shall not be infringed" is so difficult for people to understand?!?!?!
The part where their kid gets shot by someone bearing arms.
(mods, please note, I'm not arguing a point about the constitution, I'm answering a question. Even though it was probably meant to be rhetorical, the question has real answers)
That's not a real answer. At least, it's not a very compelling one. The number of kids who are killed by firearms every year is very small. In 2006, for example (the most recent year for which the CDC's database has published data), 409 kids ages 0-14 were killed by firearms. That number includes deliberate homicides, suicides, accidents and deaths with undetermined intentions.
Of course, those 409 deaths are individually tragic, but compared to all of the other things that kill kids, firearms don't contribute significantly to child mortality. Heck, swimming pools kill nearly twice as many kids as firearms, and swimming pools are far, far behind automobiles. It should also be kept in mind that 3/4 of those deaths were homicides, mostly by adults, so even if there were no guns available many, perhaps most, of those children still would have died.
Weighed against the right of free people to defend themselves and their children, and their right to retain arms as a last-ditch defense against tyranny and invasion, those regrettable deaths simply don't measure up. Indeed it's not even unlikely that removing firearms from the hands of law-abiding citizens might increase the deaths of children whose parents are unable to defend them. Even the Brady Campaign acknowledges that approximately 100,000 Americans defend themselves with a firearm each year, and other studies put the number up to 25 times higher.
I agree to a limit. My philosophy is to code the comments, rather than comment the code.
I do the same, but I add a third step: delete the comments (most of them, anyway)
Comments are dangerous because they often become wrong and misleading when changes are made later. A misleading comment is far worse than no comment.
My process, then, is to write a detailed comment at the top of each function, then write a series of comments in the body outlining how it should work. Then I fill in the code iteratively, testing at each step (with unit tests). Once the code is fully functional, I go back and pare down the comments. Where a comment can be made unnecessary by simplifying code or choosing better names, I do that and eliminate the comment. Where that's not possible, I look to see if the comment itself can be made more concise, and I also check to see if maybe the comment implies something about the code that might not be true.
I consider myself to fully satisfied with the code when no comments are left because none are needed. I'm rarely fully satisfied, but I try.
I wrote about this at length last December: . For now, suffice it to say that cracking contests are no guarantee of security, and often mean that the designers don't understand what it means to show that a product is secure.
It should be pointed out that Schneier was talking about ciphers, not voting machines, and he was talking about companies announcing cracking contests and using the announcement as an indication of security, in lieu of actually providing enough information to allow serious review of security.
It's the combination of secrecy and cracking contests that is the snake oil warning sign. The only way we can determine if something is secure is to have lots of smart, knowledgeable people with full access to the details try to break it. With crypto stuff, this is normally done by publishing at academic conferences and in academic journals and then encouraging other academics to give it a shot, but that's far from the only way to do it.
If the biggest complaint you have is a vulnerability that was fixed in 2005 (even if it had previously occurred in 1998), then I don't think there's too much to worry about.
Lots of comments mentioning the lack of taking into account of the severity of the bugs, but what about the duration of the vulnerabilities.
Agreed. The most accurate way to assess vulnerability based on reported security defects is to categorize them by severity and then total up days of vulnerability by category. Additional weight should be given to vulnerabilities with a released exploit.
I agree--I just wish more sites would start supporting it. I also wish more developers would check the code out and make it more {stable,secure}
If you have a server on the net you could set up your own OpenID provider that uses GPGauth rather than a password. That would allow you to use GPGauth for all sites that accept OpenID authentication.
Or, instead of penalizing the people with the most capable cars, how about having stretches of roadway where the car train uses two lanes to bubble sort the car with the least braking power to the front of the line?
I love it!
Although I think a mergesort would be much more efficient, and it would look really cool from above. It might be fun to write a simulation.
Since I DNRA, does the system use the "1 car length for every 10 mph" some incredibly paranoid people use?
No, the whole point is to get the cars very close together so that they're all drafting on one another.
The fundamental problem with most automated driving schemes is that they address driving on freeways, which people don't mind all that much. Automatically retrieving your car from a parking garage or lot and bringing it to you would actually sell.
Depends on where you live. Where I live, 95% of my driving is on freeways, and I rarely have to walk more than 20 yards to get to my car in a parking lot.
Of course that makes collisions worse with any vehicle or obstruction in front of your 'train'... like, say, some wacko terrorist who steals a truck and then slams on the brakes in front of you.
It's possible. I expect that the lives saved by road trains, since issues of driver error would be largely removed, would vastly exceed those who might be killed by such events.
This whole 'road train' idea is just stupid for so many reasons that I'm surprised that anyone other than 'private transport is evil' commies keep trying to defend it.
I think it's a brilliant idea, and have thought so for years. I think it offers a way to get most of the benefits of public transportation while retaining the flexibility of private transportation.
Once the road trains get dedicated lanes, you can even start ramping the speeds up. If the trained vehicles are packed closely enough, you could move the train along at 100+ MPH more efficiently and more safely than all of the individual vehicles at 60 MPH.
And it would really, really be nice to be able to make large parts of long-distance trips in your private vehicle but without having to pay attention to driving. There are lots of obstacles to be overcome to make that really practical, certainly, but I think they can be addressed.
If they aren't paying attention, and don't brake, then there's even less problem. They'll be moving a little faster when they hit the deer, true, but generally the amount of braking you can do in such a situation doesn't make much difference anyway, and that way the vehicles behind won't have to worry about braking hard.
The vehicle that hit the deer will be badly damaged and have to come to a stop, but it won't be such a rapid stop that the rest of the train behind it can't slow.
I've seen at least half-a-dozen deer on the roads in the last couple of weeks. How is this going to work when one decides to run right through the middle of the train?
Well, I imagine what would happen is that the driver about to hit the deer would brake hard. The computer would relay this braking information to the following vehicles so they would all brake at very nearly the same instant. The problem that arises is that different vehicles have different braking capabilities, so if the vehicle about to hit the deer can brake harder than one of the vehicles coming behind, then we'd end up with a collision, maybe even a chain of collisions.
Ideally, the vehicles in front should have their braking artificially limited so that it doesn't exceed the braking ability of any following vehicle. If that were done, then the computers could ensure that collisions in the train don't happen.
Slashdot Mirror
He evaluated the joke lazily, too. Slashdot posts don't really count as output.
The idea is that you can split up the program in parallel tasks in a fully automated way. If you as a programmer even have to think about parallelizing, I’m sorry, but then your compiler is “doin’ it wrong” and your languages is from the stone age.
This is not true in high-performance computing. If you don't want your CPU spinning its wheels on locks and cache misses, then you need to go quite low level -- and really think about the data structures you're using, and how to parallise tasks with next to no interthread communication.
The point of functional programming is that you don't have to think about locks or how to manage contention on your data structures because there is no such thing such thing as mutable data. And if you're just letting the compiler do the parallelization, you don't have to think about interthread communication, either, because the compiler will automatically find the places where function calls can be parallelized with zero interthread communication. Of course, if you structure your code so that it's inherently sequential then the compiler won't find any opportunities for parallelization, so you still have to think about that.
Of course, functional code ultimately gets translated to imperative code, because that's what our processors do. And that translation is being done by a program, which means it will never match the best that a talented human can do, in much the same way that hand-coded assembler, produced by a developer who knows the processor inside and out, will always beat the best-optimizing C compiler. But with functional programming, a good compiler can take significant advantage of multi-core systems for much less programmer effort. Is it as good at maximizing performance? Obviously not. But it's quite good, at much lower cost.
Er ... scrub that!
Look BOTH WAYS EVERY TIME 'cos we do have a few one way streets in Ye Olde Londone
Yes, you should always look both ways, but that doesn't reduce the value of the advice to look right.
When crossing the streets, most people look toward oncoming traffic in the near lane, then if there are no vehicles there they look toward oncoming traffic in the far lane. If that's clear, they then turn to look to the near lane as they begin crossing, then when they get to the centerline they turn to look the other way, so they're always looking at oncoming traffic in the lane they're crossing.
People from countries that drive on the right side of the road glance left, glance right, then look left as the step into the street. Doing that in a country that drives on the wrong, er, left side of the road means you risk stepping in front of the vehicle that hadn't yet come around the corner when you glanced right.
So, look both ways, but look RIGHT, not left, when stepping into the street.
Also, don't miss the Cabinet War Rooms in Whitehall (actually part of the Imperial War Museum).
Seconded! I spotted the Churchill Museum & Cabinet War Rooms by accident and decided to go in on a whim. Ended up spending most of a day there. Fascinating stuff.
I've heard Verner Vinge come up more than once now in positive reference to his writing (as opposed to him coming up in reference to his ideas)
His ideas are pretty stunning. I particularly liked the small-group hive mind aliens in "A Fire Upon the Deep". They used natural ultrasonic data links to combine a half-dozen relatively weak individual minds into a persistent collective mind with approximately human-level intelligence. I did find the basically feudal social structure a little unimaginative, but I recognize that there comes a point where the story has to be rooted in some familiar structures, for the readers' sake as much as the writer's. Those very interesting creatures were only one small piece of the book and its ideas.
I like reading the kinds of things that are too "out there," do you have any specific recommendations?
I have to admit that I really haven't been reading sci-fi much lately -- mostly I haven't been reading fiction, just not much time for it between work, family and a couple of "intellectual" hobbies that are absorbing my time (an OSS project, teaching myself functional programming and working my way through the projecteuler.net problems).
Anyway, from what I have read of late:
I'm currently reading Neal Stephenson's "Anathem', and I highly recommend it. Besides Vinge's "A Fire Upon the Deep", I also read "A Deepness in the Sky" and "Rainbow's End", and they all really impressed me. The first two are in very bizarre settings that are really inventive. The third is a near-future book that's a really interesting extrapolation of current technology, though not as mind-bending as the others. I also recently read Robert Reed's "Sister Alice", and it was quite interesting. Something a little more traditional and cliched that is nevertheless very good is David Weber's "Safehold" series, starting with "Off Armageddon Reef", and, of course, Weber's Honor Harrington series is the first I've ever read that has a scientifically-plausible notion of how battles in the immensity of space could realistically happen. Other than that, the Harrington series is entertaining and well-written, but not groundbreaking.
Sci-Fi lost the last of its steam when it switched from being Science Fiction to being Sci Fi. It's been part of a continuing downward spiral where while there have been more offerings recently, especially in mainstream culture, these offerings are increasingly more and more derivative and uninspired.
You need to read some of the good modern sci-fi. Vernor Vinge is the author everyone mentions, but there are others writing some really creative stuff. So creative, in fact, that a lot of people find it too "out there" to read comfortably, which was also the case with Golden Age science fiction. A lot of the recent Hugo and Nebula nominees are excellent, though the winners are typically a little more mainstream.
Dude, I wasn't arguing with you. I was saying whether or not someone who's killed by a gun is a child is irrelevant.
Okay. The post I responded to specifically addressed kids, so I responded in kind.
I happen to be satisfied with the status quo, at least where I live. Concealed permits are pretty easy to get.
I agree that shall-issue is a good compromise.
Actually I LOVE the multi-window layout on a multiscreen setup (image on one screen, tools on the other). But love to HATE it on a single screen setup.
I love it on both, at least on a system with a decent window manager. I think the biggest beef people have with GIMP's multi-window layout is that they're trying to use it on Windows.
They give that version the name unstable for a reason. Try if if you don't mind your shit breaking every once in a while.
They call it "unstable" because it changes frequently, not because it has stability problems.
I've run unstable on my laptop for almost 10 years now, and in all that time, it broke once, for about a day (during a big upgrade of XFree86).
jbengt wasn't really going for the "kids fuck up and shoot each other" argument methinks... was saying people use guns to shoot other people.
That's what I understood him to say, and what I responded to. The figure of 409 deaths in 2006 isn't restricted to just accidents, nor only to deaths inflicted on kids by kids, it is all firearm deaths of children in the year.
A point you inadvertently echoed.
There was nothing inadvertent about it.
The difference is they think the answer is less guns, you think the answer is more guns.
That's oversimplified to the point of being outright wrong.
I know that less guns won't significantly decrease the child death toll, because guns already play an insignificant role in child mortality. I have some reason to believe that more guns will reduce violent crime overall which may lead to some reduction in child murder, but might be offset by an increase in child suicide and perhaps by accidental firearms deaths (unless firearm education continues to improve).
The key point, though, is that whatever reduction in child deaths might be achieved by banning guns (even if we ignore the fact that most guns used to kill people are already illegal), it would be a bad trade against the corresponding loss of liberty.
It would be like reducing the number of trampling deaths caused by shouting "FIRE!" in a crowded theater by banning theaters.
What part of "the right of the people to keep and bear arms shall not be infringed" is so difficult for people to understand?!?!?!
The part where their kid gets shot by someone bearing arms. (mods, please note, I'm not arguing a point about the constitution, I'm answering a question. Even though it was probably meant to be rhetorical, the question has real answers)
That's not a real answer. At least, it's not a very compelling one. The number of kids who are killed by firearms every year is very small. In 2006, for example (the most recent year for which the CDC's database has published data), 409 kids ages 0-14 were killed by firearms. That number includes deliberate homicides, suicides, accidents and deaths with undetermined intentions.
Of course, those 409 deaths are individually tragic, but compared to all of the other things that kill kids, firearms don't contribute significantly to child mortality. Heck, swimming pools kill nearly twice as many kids as firearms, and swimming pools are far, far behind automobiles. It should also be kept in mind that 3/4 of those deaths were homicides, mostly by adults, so even if there were no guns available many, perhaps most, of those children still would have died.
Weighed against the right of free people to defend themselves and their children, and their right to retain arms as a last-ditch defense against tyranny and invasion, those regrettable deaths simply don't measure up. Indeed it's not even unlikely that removing firearms from the hands of law-abiding citizens might increase the deaths of children whose parents are unable to defend them. Even the Brady Campaign acknowledges that approximately 100,000 Americans defend themselves with a firearm each year, and other studies put the number up to 25 times higher.
I agree to a limit. My philosophy is to code the comments, rather than comment the code.
I do the same, but I add a third step: delete the comments (most of them, anyway)
Comments are dangerous because they often become wrong and misleading when changes are made later. A misleading comment is far worse than no comment.
My process, then, is to write a detailed comment at the top of each function, then write a series of comments in the body outlining how it should work. Then I fill in the code iteratively, testing at each step (with unit tests). Once the code is fully functional, I go back and pare down the comments. Where a comment can be made unnecessary by simplifying code or choosing better names, I do that and eliminate the comment. Where that's not possible, I look to see if the comment itself can be made more concise, and I also check to see if maybe the comment implies something about the code that might not be true.
I consider myself to fully satisfied with the code when no comments are left because none are needed. I'm rarely fully satisfied, but I try.
Cracking contests are warning sign number 9 on Bruce Schneier's list of security snake oil warnings.
It should be pointed out that Schneier was talking about ciphers, not voting machines, and he was talking about companies announcing cracking contests and using the announcement as an indication of security, in lieu of actually providing enough information to allow serious review of security.
It's the combination of secrecy and cracking contests that is the snake oil warning sign. The only way we can determine if something is secure is to have lots of smart, knowledgeable people with full access to the details try to break it. With crypto stuff, this is normally done by publishing at academic conferences and in academic journals and then encouraging other academics to give it a shot, but that's far from the only way to do it.
Or if eventually the site is going to be DMCAed or whatever.
DMCA? Is someone alleging copyright infringement? I thought this dispute was about trademarks.
http://secunia.com/advisories/15601/ Seven year old vulnerability reintroduced into Firefox.
If the biggest complaint you have is a vulnerability that was fixed in 2005 (even if it had previously occurred in 1998), then I don't think there's too much to worry about.
Not many... but a few. More than support GPGAuth.
Lots of comments mentioning the lack of taking into account of the severity of the bugs, but what about the duration of the vulnerabilities.
Agreed. The most accurate way to assess vulnerability based on reported security defects is to categorize them by severity and then total up days of vulnerability by category. Additional weight should be given to vulnerabilities with a released exploit.
I agree--I just wish more sites would start supporting it. I also wish more developers would check the code out and make it more {stable,secure}
If you have a server on the net you could set up your own OpenID provider that uses GPGauth rather than a password. That would allow you to use GPGauth for all sites that accept OpenID authentication.
Ideally, the vehicles folllowing would follow at a distance based on the delta of their braking ability and that of the vehicle in front of them.
Assuming that doesn't lead to a following distance so large that the benefits of drafting are lost.
Very good point.
Or, instead of penalizing the people with the most capable cars, how about having stretches of roadway where the car train uses two lanes to bubble sort the car with the least braking power to the front of the line?
I love it!
Although I think a mergesort would be much more efficient, and it would look really cool from above. It might be fun to write a simulation.
Since I DNRA, does the system use the "1 car length for every 10 mph" some incredibly paranoid people use?
No, the whole point is to get the cars very close together so that they're all drafting on one another.
The fundamental problem with most automated driving schemes is that they address driving on freeways, which people don't mind all that much. Automatically retrieving your car from a parking garage or lot and bringing it to you would actually sell.
Depends on where you live. Where I live, 95% of my driving is on freeways, and I rarely have to walk more than 20 yards to get to my car in a parking lot.
Of course that makes collisions worse with any vehicle or obstruction in front of your 'train'... like, say, some wacko terrorist who steals a truck and then slams on the brakes in front of you.
It's possible. I expect that the lives saved by road trains, since issues of driver error would be largely removed, would vastly exceed those who might be killed by such events.
This whole 'road train' idea is just stupid for so many reasons that I'm surprised that anyone other than 'private transport is evil' commies keep trying to defend it.
I think it's a brilliant idea, and have thought so for years. I think it offers a way to get most of the benefits of public transportation while retaining the flexibility of private transportation.
Once the road trains get dedicated lanes, you can even start ramping the speeds up. If the trained vehicles are packed closely enough, you could move the train along at 100+ MPH more efficiently and more safely than all of the individual vehicles at 60 MPH.
And it would really, really be nice to be able to make large parts of long-distance trips in your private vehicle but without having to pay attention to driving. There are lots of obstacles to be overcome to make that really practical, certainly, but I think they can be addressed.
You assume they would paying attention
If they aren't paying attention, and don't brake, then there's even less problem. They'll be moving a little faster when they hit the deer, true, but generally the amount of braking you can do in such a situation doesn't make much difference anyway, and that way the vehicles behind won't have to worry about braking hard.
The vehicle that hit the deer will be badly damaged and have to come to a stop, but it won't be such a rapid stop that the rest of the train behind it can't slow.
I've seen at least half-a-dozen deer on the roads in the last couple of weeks. How is this going to work when one decides to run right through the middle of the train?
Well, I imagine what would happen is that the driver about to hit the deer would brake hard. The computer would relay this braking information to the following vehicles so they would all brake at very nearly the same instant. The problem that arises is that different vehicles have different braking capabilities, so if the vehicle about to hit the deer can brake harder than one of the vehicles coming behind, then we'd end up with a collision, maybe even a chain of collisions.
Ideally, the vehicles in front should have their braking artificially limited so that it doesn't exceed the braking ability of any following vehicle. If that were done, then the computers could ensure that collisions in the train don't happen.