What about the possibility that there were more positive articles about Obama because he was the better candidate, more interesting, and just generally led reporters to be more positive? Maybe instead of "bias" that's just "truth". McCain was boring and unpleasant.
After reading this post from 538 it occurred to me: reporters are actually putting a lot of effort into supporting the facade that the McCain campaign isn't depressing and lifeless. If they let through the truth of it sometimes, that's not bias, that's just doing some decent reporting from time to time.
A former place I worked at rented a server at CI Host, and when the sysadmin went there to deal with some issue he was pretty shocked by how scrappy they were. The "server" we rented turned out to be a desktop computer, amid a fairly precarious stack of such computers. When he went down there the data center was also unlocked with the door open.
It just sounds like a very very bad data center.
Here's the features I can think of that the XO has that the listed laptop does not:
Screen is readable in full sunlight
Power consumption is targeted at 2 Watts
Laptop can sleep while the screen stays on (e.g., when reading a book)
No moving parts
A minimal number of wires and connections (for instance, the motherboard is right next to the screen)
Water-resistant design -- you can pour a cup of water right over the keyboard without damage
802.11s wireless, allowing connections with peers and connections to the internet via peers
The wireless routing stays on even when the rest of the laptop is off
Built-in camera/video
NiMH (or LiFeP) battery, to avoid the safety issues of Li-ion batteries; generally toxic components are being avoided
Targeting 2000 cycles of the battery (typical batteries are 500-1000)
You can use a stylus on the touchpad
Monitor revolves into tablet configuration
If you want a scaled-down version of a normal laptop, the Classmate PC is basically designed like that. You can see a direct comparison in this table. Frankly it looks clunky and lacking in creativity when compared to the XO.
Generally the XO is designed for durability and low power consumption, not speed. It also takes into account its very specific target audience in many small ways. It's not a general-purpose machine, it doesn't have any commercial aspirations, it's purely a laptop for children, particularly those in developing nations.
Unlike WebTV this has a very good screen -- it's small, but it's completely usable. It runs normal Linux applications (they don't fit into the environment that well unless you make some modifications, but they do run). The processor is x86. It has a reasonable amount of memory and disk -- small by today's standards, but still reasonable even by today's standards. 256Mb of memory is really quite good. Also, unlike those products, this is not a niche product. This is intended to be deployed in considerable scale, and so it's a viable target platform all on its own.
I do think they should sell the laptops commercially for $200-$300 though so that people who might want to help the project could purchase one for that price and in doing so pay for 2 free laptops for poor children.
I also think that if they ever start mass producing them, they shouldn't be limited to just the poor nations.
They aren't limited to poor nations. They are being sold at cost, not below cost. Richer countries might be disappointed by the inability to use things like Microsoft Word on the machines. This isn't as big a deal in developing nations. Which is itself somewhat ironic; we're too obsessed with vocational education in this case.
My only question is why is Gnome used as the desktop? Gnome is a great desktop environment, but it seems like these machines, having only 128 MB of ram and no way to do swap partions (it would ruin a flash drive to use it for swap) it seems like fluxbox, XFce, or blackbox might be better. I realize the gnome is modified, but still.
They aren't using a traditional Gnome environment. They are using Matchbox for the window manager, and much of the other pieces are custom coded. It's described some on the Sugar page (Sugar is the name of the environment).
Don't forget: not everything proprietary is evil. If WindowsCE would provide much better and cheaper solution, OLPC would use it without thinking twice about it. Windows CE in fact *was* considered briefly at a point.
Of course they'd think twice, at least. The laptop is a platform targetted at the third world. It's being developed primarily in the first world. It's being deployed on a different scale than anything before. The kind of peer-to-peer interaction is new. Not unimaginably new, but the scale and independence of the students involved makes it qualitatively different. The project has to be approached with a certain sense of humility. It has to be an empowering tool for the people and communities that receive it, not just an embodiment of what certain people at MIT think it should be. F/OSS is very important to this goal. There's other goals the system has too, but this is still right up there at the top, and the OLPC page on open source I think makes that pretty clear.
Also, the laptop is not a loss leader. It is not an attempt to set up a market that can later be leveraged. It is not a coercive tool. It does not shift any kind of intellectual power to the first world away from the communities where it used. Proprietary software may not be provided with these kind of commercial intentions, but it's impossible to prove that, and there will always be question about the intentions of the entire project as a result.
It's proclaiming that it is OSS. All the while, they are including lots of proprietary stuff in it. They are riding on the OSS coattails. If they weren't harping how the were Open, I don't think they'd be getting the flak they are.
Where is there "lots of proprietary stuff"? All anyone is talking about AT ALL is the Marvell driver, and some speculation about the SD driver. Everything else is open source, down to the BIOS. In every case when there were problems with developing open source drivers, someone at OLPC has tried to figure out the right thing without actually blocking the project from moving forward. And who else ships a computer that is so open?
And "riding on the OSS coattails"? You really think Jim Gettys is just riding on the coattails of Linux?
Nothing in these graphs mentions the occupancy rates, which route selection and timetable management would affect a lot. Note that the most efficient mode of transport in BTU's per passenger, behind the "Skyweb" system (and if this information is being published by skyweb, forgive me if I take a bit of a "wait and see" stance on the figures they quote for their system) is... intercity bus!
I'm pretty sure they take into account average occupancy rate in the U.S., so for instance about 1.1 people ride in each car. Intercity travel tends to have very good occupancy, as prices are adjusted to keep occupancy high and seats booked ahead of time to also encourage good occupancy. Commuter rail also has good occupancy, because they tend to not run a very complete schedule, only running when there's a lot of passengers. A transit system that doesn't serve most of the people most of the time can have better occupancy, because it can pick just the most successful routes. Such a system also happens to be lousy, and still requires everyone to own cars.
A bus system in an airport would not have good occupancy. It would have to run for the full schedule when flights were arriving and leaving. It would have to have to keep a frequent schedule, as high wait times aren't really acceptable, especially for arriving passengers. And indeed, you look at airport shuttles and it's not uncommon to see a bus late at night with just a couple people on it.
When it comes to moving mass from point A to point B, rail is very efficient.
Moving mass, sure. People? No, not very efficient at all. People aren't actually very massive -- mass is the least of the problems involved with moving people. In fact, all the mass in mass transit is the train car (or bus) itself, I don't think human mass ever gets above 50% of the total, even at the most peak times.
Close to 100% full? I don't have any figures to dispute this, but somehow I doubt you have any to prove it either. In the example I used above (1 big diesel engine vs lots of little petrol motors), 50% occupation would still have been at least as efficient as having a car for every two passengers
The fact that this example used combustion engines is irrelevant. I could have illistrated the same point with a large electric bus (say, 400kw motor) vs many small electric cars (say, 75kw motors). Energy is energy. The point I'm making as about the economy of scale you get with one big, powerful vehicle that moves many people vs many little vehicles that move a few people each.
Where does this magical economy of scale come in? There's no economy of scale in physics. Weight costs energy. Stopping costs energy. Big electrical motors aren't particularly more efficient than small motors.
Railways are cheaper to build than roads. And they are a more efficient way of making contact with the ground (narrow wheels), which means less drag.
They are cheaper? This PDF shows rail as about 5x more. I don't know if I trust that PDF, but clearly rail is more expensive. The tolerances are much lower. As for drag, yes, iron-on-iron wheels cause less drag. They also mean that the grade must be very even, which is part of what makes rail more expensive to build, and part of what keeps rail from serving many areas without tunneling and other expensive infrastructure that only takes the rail further from people. Rails also have very poor braking, which is why they can't safely coexist with other traffic, also making them very expensive.
I'll concede that the "on-demand" nature of having pods ready to go when you are ready to go is more convenient and may save passengers the 5 or 10 minutes they would otherwise have to wait for a bus
It also costs you time on the bus or train waiting at stops that are not your own. The El in Chicago goes at about 15mph net. In Manhattan it is faster to walk than take the bus. The more convenient you make the stations, the more stations, and the slower the system; it has lousy scaling properties. Mass transit is really, really slow.
Ideally the system is set up so a user can reject a car -- it will then be sent in for maintenance/cleaning, and the user will just wait for the next car.
There's actually some open-source simulations out there of that kind of situation. One of them is iTS, which wasn't too hard to use.
Anyway, it's not too bad. It depends on the size of the system and number of cars, and the number of ports available for loading. It can beat typical shuttles fairly easily, though of course there will be wait times. Airports don't actually seem that bad; there's enough steps involved that there's always a stream of people moving about, the people from one plane are quickly dispersed. A more challenging situation is something like a stadium game letting out, when you really get huge numbers of people leaving at exactly the same time. But of course, no system works very well in that case.
- Efficient routing around disasters, with breakdown detection to prevent a single system failure from breaking the entire network.
I would expect this to be fairly easy. Many breakdowns could be avoided with on-board sensors which could detect problems, and automatically send the vehicle to a maintenance point after dropping off the passenger. In cases when tracks are offline (a broken-down vehicle, the track needs maintenance, etc) because there's redundancy in the rail system it should be easy to route around. Notably traditional rail mass transit has little redundancy, and so even expected events like maintenance can cause the system to go down or have severely degraded performance.
- Some sort of weight detection system to ensure that people do not leave anything on the vehicles (bags, bombs, etc). Normally a driver would point these things out but automated systems lack that ability.
That would be interesting. Probably even a well-designed interior could make forgotten items more obvious, though detecting deliberately forgotten items like a bomb would be good. This could make the system quite resistent to terrorism -- no more dangerous than someone blowing up their own car on the highway, or themselves on a street (which is dangerous, of course, but public transit give a terrorist more leverage). Even without this, I don't know if it would be anymore dangerous than the status quo.
- Some sort of 'digital nose' type device to detect the vehicles which have stink bombs, vomit, and whatever other lovely smells that can be accrued by frequent usage in a densely populated area, and allow the vehicles to be removed from service and cleaned instantly.
I think the plan here is to allow passengers to reject a vehicle. After being rejected, a vehicle would go to the maintenance area to be cleaned, and another vehicle would show up in its place.
- Decent integration with pedestrians. They need to be able to go as fast as possible so that fewer vehicles are needed, but must not clog up roads for traffic and pedestrians. Ideally some sort of sunken road could be used where appropriate perhaps, allowing large boulevards at ground level, and enabling their usage in pedestrianised areas.
Almost all these systems use elevated rail, so there's no integration. I've seen articles about a couple low-speed at-grade systems, often used for things like parking lot shuttles, guided by radio transmitters embedded into the road. Elevating the rails makes the safety issues a lot simpler, especially interchanges, though a novel at-grade system could have some pretty substantial benefits if it could be made to work.
- Easy to use for disabled people.
This is a common feature. Elevated rails require elevators in stations; otherwise it's just a matter of making them big enough to accept a wheelchair. For people with other disabilities that make them unable to drive (e.g., blind) it's a perfect system.
- Free or cheaper than driving a car or taking a bus.
It's hoped that these systems could be self-supporting, even including bonds to pay for infrastructure, while still having reasonable costs. This is in contrast to typical mass transit that isn't anywhere near self supporting and still isn't very cheap. Cars are difficult because the incremental costs are quite low, but other costs are quite high. This makes it difficult to compete with cars when someone already owns a car.
- Must run at all hours, not be limited like public transport is, as this encourages people to either stumble around cities drunk after clubs close, or sometimes risk driving home.
Because the cost of running the system at late hours is very low -- no extra drivers, no large but mostly empty vehicles -- there's no reason the system can't be 24 hours.
From an engineering perspective RUF takes on all the engineering burdens of each form, and combines them. The rail system has to carry cars that are engineered for the road, and typically much larger. Or, even worse, rails engineered for buses which are much larger than anything PRT would carry. A RUF rail system has to take into account a larger variance in vehicles and maintenance; while you can require regular inspections, with private vehicles it's not possible to get anywhere near the quality control that you can get with a controlled system with strict and automated maintenance schedules.
Cars, in turn, have to have all the same complexity they already have, and add the control systems for the tracks as well as seperate track wheels. Each car must still have a licensed and insured driver. Each car is going to have to park somewhere, which is not free. Capital costs of the RUF system are carried in part by private users, but only one of the smallest portions -- the largest portion of capital cost goes into creating the rail infrastructure.
PRT's advantages have to do with its scope. The rail required for PRT vehicles is substantially easier to build, install, and maintain than typical rail, because the load is so much less. Elevated rails carrying tens of tons of weight must be large and bulky, and are very expensive to construct. But because the vehicles on a PRT are required in numbers relative to the number of riders, and wear out relative to how many passenger-miles they go, the cost is directly related to the fare income, so that cost is one of the smallest hurdles for the system compared to the rail infrastructure. PRT is optimized for decreasing the cost of that infrastructure.
You could get by with one tenth the number of cars on the road today.
You'd have exactly the same number of cars on the road as you have now.
You could actually have less cars on the road at any one time, though 1/10 is clearly an attempt to say 1/10 as many cars total, as most cars are just parked, not being used. Parked cars take up a lot of valuable space, not to mention an unused capital investment, so it is useful to reduce total numbers.
It's likely that there would also be less cars on the road at any one time. Car sharing systems like Zipcar find that users use cars maybe 25% as much as they did before...? I don't remember the exact amount, and it's something they brag about in some forums and not others. Basically, if the cost of car use is entirely incremental -- you pay the real cost of every trip -- people won't use cars as much. But if you pay for most of the costs regardless of any trip (up-front cost of buying the car, plus up-front cost of insurance) then there is an incentive to make use of your investment by driving more.
Even moreso, with a taxi-like system people will use cars less, as many trips do not form a circle coming back to the original location. You could use public transit in one direction and not another. Or bike, but use a car if the weather gets bad by the time you are ready to come home. By actively choosing a car on each leg you won't bring your car around on trips simply because it may later be required. The availability of car-like options without the investment of a car increases the value of other types of transportation.
I think Pugs is only an interesting experimental platform, not a serious platform for writing real programs. It's too slow, it's an interpreter by design, and I'd be surprised if that changed. It's an important project for Perl 6, but it's only a step. They need to make another step; if not Parrot, then something else.
They didn't actually have even that level of sympathy. Only when the story became news did they drop the lawsuit. They have an abundance of sympathy for their client's PR.
As for this particular case: so the RIAA has long-established themselves as a bunch of shameless pricks. So what?
Yes, many people put up with shameless pricks, even admire them. But how does that lead to "so what"? Like most people I don't put up with shameless pricks or admire them, so it is important to identify such people.
Just because someone dies doesn't automatically invalidate a potentially valid legal claim. Sure tugs at the heartstrings, though, doesn't it?
Not the RIAA's heartstrings, apparently. Well, they probably don't have any heartstrings. This is useful to identify as well. This property, when identified in an individual, is labelled sociopathic.
But anyway, when a suit is brought about to redress some wrong it seems reasonable that it might be continued against the estate. The wrong still needs to be redressed, doesn't it? In this case the suit is punative, it is meant to punish. No wrong is righted. Death makes punishment moot. Well, you could punish the kid who actually used the filesharing, but I doubt that is legally or financially reasonable.
No one's arguing that the RIAA's model of figuring losses is valid, but it's equally (and massively) disingenuous, not to mention utterly ridiculous, to claim that nothing has been lost at all.
That is not true either. It is extremely likely that if a child (the actual "offender" in this case) does not have access to free music that they will simply do without. That's what I did when I was a kid. A lawsuit does not put the entire filesharing public on trial, just one person, and for an individual case it is entirely possible that nothing was lost at all.
No lambdas
Well, of course that isn't true. Lambda is syntactically limited in Python. Instead you have to use named functions if you are doing something complicated that can't fit in a lambda. That causes two changes: you have to come up with a name for the function (which I don't think is a substantial burden) and you have to declare the function before you use it (which can be a little annoying in some circumstances). But altogether, the lambda thing is way overused as a criticism; anonymous functions aren't all that important. no ternary operator (yes I know, not pythonic)
Python 2.5 has it -- RC1 should be out very soon no switch statement (think Ruby, not C++)
It can be nice sometimes, but I think it's overrated. Personally I usually use if/elif/else, which has some nice properties as the code evolves, but in other circumstances dictionary-based dispatch works well. scoping rules are wrong (for example, list comprehensions leak variables - C++ for loops don't!)
This is an admitted design mistake. Generator comprehensions (implemented after list comprehensions) do not leak variables, and in Python 3 list comprehensions won't either. I don't think it's a big issue that for loops leak variables -- I think it's actually reasonably intuitive that the value of the loop variable sticks around. Underscores! __init__ __new__ __getattr__ __setattr__ __len__ __getitem__ . . ..
Yes, these represent magic methods, something that has special significance to the system. Maybe other punctuation would be prettier in some circumstances, but not all. It also leaves all "normal" names to the application author; there aren't any non-magic methods that you have to worry about outside of your domain. range(1,5) = [1, 2, 3, 4]
I don't know what your problem is here. Do you want it to return [1, 2, 3, 4, 5]? That would be horribly wrong. Python gets its ranges right, no question in my mind -- returning an inclusive range would simply be wrong. The way Python does ranges and slicing means that one-off errors are pretty uncommon. Having other kinds of ranges would mess that up. Yes, Guido, map and filter suck, but only because Python lambdas suck. And nested list comprehensions look awful.
He's kind of conceded that, but has not seen any reasonable resolution in the scope of Python's existing design and syntax. There's compromises involved in language design, and not everything will look right given any particular syntax. In Python's case function expressions just don't work well. Instead Python offers a couple forms of syntax (list comprehensions most notably) that deal with some particularly common uses of function expressions in a way that does make sense. (And sure nested list comprehensions look awful -- don't use them! Use chained generator comprehensions or something more sane for the reader.) And hey, Python took it from Haskell, so it's gotta be pretty good.
It's not really related, but I found this interview with Carver Mead very interesting. Related in that it's also about progress (or non-progress) of scientific theory.
In fact Medicare and Medicaid are far more efficient than private healthcare; I think Medicare puts over 90% of the money (maybe quite a bit over 90%, I can't remember) into providing healthcare, where insurance puts something on the order of 70-80% of money into providing healthcare (the other being administrative overhead and profit), which doesn't even count the administrative costs born by healthcare providers, and some estimates are that only about 50% of money spent on healthcare goes into actually providing services. You can't save money by cutting Medicare and Medicaid. You just can't, period. In fact, it would save considerable money to expand those programs.
But basically, even though the quantum program never actually executes, you still need to create it, and you still need to put it in a certain spot so that its quantum effect on the world around it can still be measured, and from that, you can infer what the program would actually do.
This all smells of bullshit to me. Not on your part -- no offense intended to you -- but on the part of the quantum theorists who came up with these metaphors.
When I say something "does" or "does not" happen, I mean that I can see the effects or not. Or maybe I am ignorant of the result, and maybe I do not have the ability to measure the results at a particular time to a particular precision -- but this is a flaw of my own senses (however they might be augmented with instruments), it is not something intrinsic in the action itself.
In a quantum computer we are saying that something happens, which is the computation we were trying to determine. We can tell that it happened, because we get the answer. This is the definition of work, of something happening, of phenomena. So I would assert that our intuition is correct, that as presented this statement is a paradox ("Quantum Computer Works Better Shut Off") and that quantum theorists are just playing games with terminology.
But, to be honest, I'm just repeating my own interpretation of the ideas I read in this interview with Carver Mead, which seriously raised my skepticism about quantum theory as it is most commonly presented.
Not very insightful
on
Beyond Java
·
· Score: 4, Interesting
I have read parts of this book, and still need to write a review of my own since I got a review copy, and that's supposed to be the deal. If you are going to write a book "Beyond Java" you probably should have ventured beyond java a little yourself. I don't think the author did in a signficant way. It includes contributions by other people, but most of those people are primarily Java developers who have history with other systems or are flirting with them currently. This isn't sufficient to give you a feel for the lay of the land. This isn't enough to write a book.
If he had tried, he could have gotten insightful and well-thought-out contributions from developers who are experienced with the kinds of things he talks about. He could have edited them down to be concise and reasoned expositions on the benefits and pitfalls that might lie ahead for the Java developer interested in change. Not everyone is a cheerleader, lots of people with lots of experience and investment in these other technologies are willing to talk about them in reasoned ways, and offer some real wisdom about the good and bad. But he just talked to a bunch of Java guys. No offense to those guys, but transcribing a few email exchanges into a book isn't cool.
Slashdot Mirror
What about the possibility that there were more positive articles about Obama because he was the better candidate, more interesting, and just generally led reporters to be more positive? Maybe instead of "bias" that's just "truth". McCain was boring and unpleasant.
After reading this post from 538 it occurred to me: reporters are actually putting a lot of effort into supporting the facade that the McCain campaign isn't depressing and lifeless. If they let through the truth of it sometimes, that's not bias, that's just doing some decent reporting from time to time.
Has anyone used the Sony with this open source program: https://libprs500.kovidgoyal.net/ -- seems like it would make the book management easier.
A former place I worked at rented a server at CI Host, and when the sysadmin went there to deal with some issue he was pretty shocked by how scrappy they were. The "server" we rented turned out to be a desktop computer, amid a fairly precarious stack of such computers. When he went down there the data center was also unlocked with the door open. It just sounds like a very very bad data center.
What, if we didn't grow corn the fields would be no-CO2-absorbing wastelands? http://www.ecoworld.com/blog/2007/02/12/biofuel-is -not-carbon-neutral/
If you want a scaled-down version of a normal laptop, the Classmate PC is basically designed like that. You can see a direct comparison in this table. Frankly it looks clunky and lacking in creativity when compared to the XO.
Generally the XO is designed for durability and low power consumption, not speed. It also takes into account its very specific target audience in many small ways. It's not a general-purpose machine, it doesn't have any commercial aspirations, it's purely a laptop for children, particularly those in developing nations.
Unlike WebTV this has a very good screen -- it's small, but it's completely usable. It runs normal Linux applications (they don't fit into the environment that well unless you make some modifications, but they do run). The processor is x86. It has a reasonable amount of memory and disk -- small by today's standards, but still reasonable even by today's standards. 256Mb of memory is really quite good. Also, unlike those products, this is not a niche product. This is intended to be deployed in considerable scale, and so it's a viable target platform all on its own.
var mailto = 'm' + 'e@e' + 'xampl' + 'e.com';
document.write('<a href="mailto:'+mailto+'">'+mailto+'</a>');
It's easy to make it much harder, of course, and most (all?) spam harvesters don't interpret Javascript.
Also, the laptop is not a loss leader. It is not an attempt to set up a market that can later be leveraged. It is not a coercive tool. It does not shift any kind of intellectual power to the first world away from the communities where it used. Proprietary software may not be provided with these kind of commercial intentions, but it's impossible to prove that, and there will always be question about the intentions of the entire project as a result.
And "riding on the OSS coattails"? You really think Jim Gettys is just riding on the coattails of Linux?
A bus system in an airport would not have good occupancy. It would have to run for the full schedule when flights were arriving and leaving. It would have to have to keep a frequent schedule, as high wait times aren't really acceptable, especially for arriving passengers. And indeed, you look at airport shuttles and it's not uncommon to see a bus late at night with just a couple people on it.
Moving mass, sure. People? No, not very efficient at all. People aren't actually very massive -- mass is the least of the problems involved with moving people. In fact, all the mass in mass transit is the train car (or bus) itself, I don't think human mass ever gets above 50% of the total, even at the most peak times.Ideally the system is set up so a user can reject a car -- it will then be sent in for maintenance/cleaning, and the user will just wait for the next car.
Anyway, it's not too bad. It depends on the size of the system and number of cars, and the number of ports available for loading. It can beat typical shuttles fairly easily, though of course there will be wait times. Airports don't actually seem that bad; there's enough steps involved that there's always a stream of people moving about, the people from one plane are quickly dispersed. A more challenging situation is something like a stadium game letting out, when you really get huge numbers of people leaving at exactly the same time. But of course, no system works very well in that case.
Cars, in turn, have to have all the same complexity they already have, and add the control systems for the tracks as well as seperate track wheels. Each car must still have a licensed and insured driver. Each car is going to have to park somewhere, which is not free. Capital costs of the RUF system are carried in part by private users, but only one of the smallest portions -- the largest portion of capital cost goes into creating the rail infrastructure.
PRT's advantages have to do with its scope. The rail required for PRT vehicles is substantially easier to build, install, and maintain than typical rail, because the load is so much less. Elevated rails carrying tens of tons of weight must be large and bulky, and are very expensive to construct. But because the vehicles on a PRT are required in numbers relative to the number of riders, and wear out relative to how many passenger-miles they go, the cost is directly related to the fare income, so that cost is one of the smallest hurdles for the system compared to the rail infrastructure. PRT is optimized for decreasing the cost of that infrastructure.
It's likely that there would also be less cars on the road at any one time. Car sharing systems like Zipcar find that users use cars maybe 25% as much as they did before...? I don't remember the exact amount, and it's something they brag about in some forums and not others. Basically, if the cost of car use is entirely incremental -- you pay the real cost of every trip -- people won't use cars as much. But if you pay for most of the costs regardless of any trip (up-front cost of buying the car, plus up-front cost of insurance) then there is an incentive to make use of your investment by driving more.
Even moreso, with a taxi-like system people will use cars less, as many trips do not form a circle coming back to the original location. You could use public transit in one direction and not another. Or bike, but use a car if the weather gets bad by the time you are ready to come home. By actively choosing a car on each leg you won't bring your car around on trips simply because it may later be required. The availability of car-like options without the investment of a car increases the value of other types of transportation.
I think Pugs is only an interesting experimental platform, not a serious platform for writing real programs. It's too slow, it's an interpreter by design, and I'd be surprised if that changed. It's an important project for Perl 6, but it's only a step. They need to make another step; if not Parrot, then something else.
HLVM seems kind of interesting as well.
They didn't actually have even that level of sympathy. Only when the story became news did they drop the lawsuit. They have an abundance of sympathy for their client's PR.
But anyway, when a suit is brought about to redress some wrong it seems reasonable that it might be continued against the estate. The wrong still needs to be redressed, doesn't it? In this case the suit is punative, it is meant to punish. No wrong is righted. Death makes punishment moot. Well, you could punish the kid who actually used the filesharing, but I doubt that is legally or financially reasonable.
That is not true either. It is extremely likely that if a child (the actual "offender" in this case) does not have access to free music that they will simply do without. That's what I did when I was a kid. A lawsuit does not put the entire filesharing public on trial, just one person, and for an individual case it is entirely possible that nothing was lost at all.No lambdas Well, of course that isn't true. Lambda is syntactically limited in Python. Instead you have to use named functions if you are doing something complicated that can't fit in a lambda. That causes two changes: you have to come up with a name for the function (which I don't think is a substantial burden) and you have to declare the function before you use it (which can be a little annoying in some circumstances). But altogether, the lambda thing is way overused as a criticism; anonymous functions aren't all that important. .
Yes, these represent magic methods, something that has special significance to the system. Maybe other punctuation would be prettier in some circumstances, but not all. It also leaves all "normal" names to the application author; there aren't any non-magic methods that you have to worry about outside of your domain.
no ternary operator (yes I know, not pythonic) Python 2.5 has it -- RC1 should be out very soon
no switch statement (think Ruby, not C++) It can be nice sometimes, but I think it's overrated. Personally I usually use if/elif/else, which has some nice properties as the code evolves, but in other circumstances dictionary-based dispatch works well.
scoping rules are wrong (for example, list comprehensions leak variables - C++ for loops don't!) This is an admitted design mistake. Generator comprehensions (implemented after list comprehensions) do not leak variables, and in Python 3 list comprehensions won't either. I don't think it's a big issue that for loops leak variables -- I think it's actually reasonably intuitive that the value of the loop variable sticks around.
Underscores! __init__ __new__ __getattr__ __setattr__ __len__ __getitem__ . . .
range(1,5) = [1, 2, 3, 4] I don't know what your problem is here. Do you want it to return [1, 2, 3, 4, 5]? That would be horribly wrong. Python gets its ranges right, no question in my mind -- returning an inclusive range would simply be wrong. The way Python does ranges and slicing means that one-off errors are pretty uncommon. Having other kinds of ranges would mess that up.
Yes, Guido, map and filter suck, but only because Python lambdas suck. And nested list comprehensions look awful. He's kind of conceded that, but has not seen any reasonable resolution in the scope of Python's existing design and syntax. There's compromises involved in language design, and not everything will look right given any particular syntax. In Python's case function expressions just don't work well. Instead Python offers a couple forms of syntax (list comprehensions most notably) that deal with some particularly common uses of function expressions in a way that does make sense. (And sure nested list comprehensions look awful -- don't use them! Use chained generator comprehensions or something more sane for the reader.) And hey, Python took it from Haskell, so it's gotta be pretty good.
It's not really related, but I found this interview with Carver Mead very interesting. Related in that it's also about progress (or non-progress) of scientific theory.
In fact Medicare and Medicaid are far more efficient than private healthcare; I think Medicare puts over 90% of the money (maybe quite a bit over 90%, I can't remember) into providing healthcare, where insurance puts something on the order of 70-80% of money into providing healthcare (the other being administrative overhead and profit), which doesn't even count the administrative costs born by healthcare providers, and some estimates are that only about 50% of money spent on healthcare goes into actually providing services. You can't save money by cutting Medicare and Medicaid. You just can't, period. In fact, it would save considerable money to expand those programs.
When I say something "does" or "does not" happen, I mean that I can see the effects or not. Or maybe I am ignorant of the result, and maybe I do not have the ability to measure the results at a particular time to a particular precision -- but this is a flaw of my own senses (however they might be augmented with instruments), it is not something intrinsic in the action itself.
In a quantum computer we are saying that something happens, which is the computation we were trying to determine. We can tell that it happened, because we get the answer. This is the definition of work, of something happening, of phenomena. So I would assert that our intuition is correct, that as presented this statement is a paradox ("Quantum Computer Works Better Shut Off") and that quantum theorists are just playing games with terminology.
But, to be honest, I'm just repeating my own interpretation of the ideas I read in this interview with Carver Mead, which seriously raised my skepticism about quantum theory as it is most commonly presented.
If he had tried, he could have gotten insightful and well-thought-out contributions from developers who are experienced with the kinds of things he talks about. He could have edited them down to be concise and reasoned expositions on the benefits and pitfalls that might lie ahead for the Java developer interested in change. Not everyone is a cheerleader, lots of people with lots of experience and investment in these other technologies are willing to talk about them in reasoned ways, and offer some real wisdom about the good and bad. But he just talked to a bunch of Java guys. No offense to those guys, but transcribing a few email exchanges into a book isn't cool.