It can be if the (typically polypropylene) tank is squeezed and fuel is aerosolized...
And there's always the risk of "explosive fire". Not a true explosion in the sense of detonation, but a fire that engulfs a car in 10 seconds is just as dangerous as a fire that does it in a 10th of a second. Especially if you're trapped in the vehicle.
I'm not very familiar with Citroens at all. I know a little bit about their early history because of the "The Car" episode of "The Secret Life of Machines" (which really focuses on unibody construction). If I recall correctly, E.G. Budd was trying to form a car company c1939, but instead ended up selling dies (for pressing body panels) to all the major manufacturers. Citroen was the first of these in 1940.
They've got video of a unibody Volkswagen-looking Citroen doing flips down sand dunes. The only thing that broke was the wind shield.
They went out of their way to avoid the engines colliding, because those inline 6 engines weigh a LOT. The video shows a front-left-fender vs front-left-fender collision. In a direct head-on crash, the Chevy's engine and transmission would cream the Malibus' much lighter engine/transaxle.
I am calling bull. Even though I agree that the Bel-Air's drivetrain is heavy. Why? Because the Bel-Air's frame failed, and let the drive train substantially deform the cabin in this test. This means, specifically, that the Malibu engaged the engine mechanically, during the course of the collision.
It is pretty clear that the Bel-Air's cabin is going to suffer a lot more damage than the Malibu's. Even in a fully head on collision.
Citroens have had unibody construction since the 40s. E.G. Budd came up with the idea for unibody steel construction, and Citroen bought into it in 1940 or so.
I have a hard time believing that you can predict that. Why do you think the Bel-Air's block would "cut through the Malibu" instead of cutting through the Bel-Air's cabin, like it essentially did in this test?
The big problem with older cars is that the body shape was sculpted from clay in a studio separate from the rest of the car designers, rather than being designed as part of an automobile. The end result being that the body shape had no basis in sound mechanical design.
Yeah... that just plain bull. Look up the "Budd Company".
Jeeps come with roll cages... A jeep driver won't be getting crushed. At worst (and this is a very real danger), a foreign object will enter the cabin and damage the passengers.
My observations were that I'd much rather be in an old tank like that in a minor accident. Anything major, and I'd rather be in a modern car with things like seatbelts, crumple zones and air bags.
"Minor" accidents can be much more severe if your body is taking the jolt instead of the crumple zones. Injuries like whiplash are extremely common in "minor" accidents. You might be able to get your Ford's frame straightened, but you can't get your neck fixed anywhere as cheaply or easily.
30 mph is not a minor accident, by the way. That's like falling out of a second story window (taking into account conservation of momentum leading to smaller forces on your body)
If there's anything like a formal specification for the program, it's a good idea to write tests to ensure the program meets it. Writing more tests than that is pretty pointless, and is presumptuous of the programmer. At worst, the tests will have to be removed, when a feature incompatible with the programmer's assumptions is requested.
If you're working on a personal or open source project, this is a good way of thinking about test writing. Write up a spec for your program or module, and tests to make sure it satisfies it. It's not hard.
Nice, structured and clean code is appreciated, but this is the real world we're talking about where deadlines are everything. Getting it up and running is the goal. Nobody cares if it's ugly and stiched together.
You would be surprised. Bad code means big problems if there is a service failure. It is more difficult to debug bad code. And in a world where deadlines are important, it is nice to be able to write clean code for a few hours and go home early, because of all the time you've saved by not writing shitty code.
That's a philosophical issue, not a computing one. Assuming the original implementation's data structures are nicely normalized, any implementation is going to have to "the same" data structures. As long as they preserve the normalization of data structures, there is no substantive difference between functions that take "high level OO" to ASM.
All you really have to do is parse the code, and implement semantics for the parse tree. You will have written a "high level OO to ASM" translator. An "assembler".
Repeat this mantra: there is no difference between data and code.
This is crazy. It's like picking a lock without damaging it and then stealing jewlery out of a sock drawer and then being forced by the court to buy the victim a fence, guard dog, improved lock and safe to keep their jewelry in to prevent future crimes.
This might be a better punitive action than locking someone up. I fully support this idea.
You'll also have to consider developer-friendliness (try rewriting a project that's 1 million+ lines of high-level OO code with garbage collection in assembly language: you'll never finish the job
Hint: write an interpreter. You can even pick and choose your OO semantics if the original language's don't appeal.
There are other, more efficient ways to avoid DLL hell. And while that may make sense on a desktop, it seems truly moronic on a mobile platform, where space, bandwidth, and RAM are scarce.
Space is scarce? Really? Do you think 80 or 100MB of QT are going to fill up a 16 GB drive? Do you think 30 or 50 QT applications are going to fill up a 16 GB drive, even if they all bring their own QT libs?
Apple has already chosen their way of avoiding DLL hell, and it doesn't include a package manager for dealing with random application libraries.
Some of the rejection stories coming out suggest otherwise -- that they dislike any "external framework".
It's not "external" if it's in your app. You can link to any library you want, as long as you include a copy of it in your application bundle.
How would you even express something like that? Nasty nesting, I'm sure. Even if you use "map" and "filter", you're screwed. You have to nest, because of Python's idiotic definitions of map and join.
And I'm sure you're not experienced enough to know why my version is significantly better. In effect, it's better because the important parts of every step are ALL RIGHT OF the textual representation of the last operation. So you DON'T need to move your eyes back and forth to keep track of scoping. So if you want to add a step to the computation on a list, you just add it at the end. If you want to add an intermediate step, you find where it goes, and insert it.
That's okay and all, but list comprehensions can require nesting. That's not good for maintainability. In fact, it is very bad. The sorts of things that ought to be thoughtless exercises (adding a hook to filter a list, so that you can pass the hook a function) become non-trivial exercises in themselves.
Consider the idea of taking a list, filtering by some predicate A, applying an expensive operation on the filtered list, and filtering the new list on some predicate B. Using list comprehensions, the "inner" list is:
[ expensive_operation x for x in list if A x ]
If you want to filter, and continue to use the same syntactic form, you have to do
[ x for x in [ expensive operation x for x in list if A x ] if B x ]
The fact that my eye has to go left and right and left and right, to find governing filters, braces, and so on, make it much harder to read to the equivalent (if Python was awesome)
list.filter(A).map(expensive_operation).filter(B)
I can keep that construct up for a few dozen method calls, and it will still be clear. Try nesting even four or five list comprehensions.
It can't give off more heat and be more efficient at the same time. However, it is placed close to you so that helps:)
I said hotter, not "give off more heat". Halogen lamps have an operating temperature that is significantly hotter than regular incandescent bulbs. This means, in particular, that the bulbs run significantly hotter (up to 4000K if I recall correctly). On the other hand, it also means that the color temperature of the bulb is significantly hotter, so that more light is radiated in the visible spectrum.
But as I said, this is a good desk accessory. It is near me because the light shining on me and my desk are what keep me warm, through radiant heat. A regular incandescent bulb would work for this purpose too, but why bother when a halogen bulb looks better (because of the color temperature) and is brighter for a fixed level of energy consumption?
Heck, this increased efficiency means more light/heat lands on me, instead of flowing out of the little vent holes at the top of every lamp. At that point, you're merely heating the air, which isn't a waste of energy exactly (at least in the winter), but isn't as efficient as keeping a person warm as shining a lamp on them and the surfaces they touch.
Yup. A halogen desk lamp makes a great accessory during Winter. It is more efficient than using a CFL and oil heating. I don't typically need to warm up my whole office, just the place I sit. The light also looks better than CFLs, or even regular incandescent bulbs. And halogen lamps are both hotter and 40% more efficient than regular incandescent bulbs.
You're seriously underestimating Bush Jr.'s cost to America. Yes, so far only 6 to 11T dollars worth of his promises have come to pass. But baby boomers are about to retire, and demanded more Medicare and Medicaid benefits. Including Social Security benefits, Bush Jr.'s promises are going to put us in a 60T dollar deficit by 2040.
Slashdot Mirror
It can be if the (typically polypropylene) tank is squeezed and fuel is aerosolized...
And there's always the risk of "explosive fire". Not a true explosion in the sense of detonation, but a fire that engulfs a car in 10 seconds is just as dangerous as a fire that does it in a 10th of a second. Especially if you're trapped in the vehicle.
I'm not very familiar with Citroens at all. I know a little bit about their early history because of the "The Car" episode of "The Secret Life of Machines" (which really focuses on unibody construction). If I recall correctly, E.G. Budd was trying to form a car company c1939, but instead ended up selling dies (for pressing body panels) to all the major manufacturers. Citroen was the first of these in 1940.
They've got video of a unibody Volkswagen-looking Citroen doing flips down sand dunes. The only thing that broke was the wind shield.
http://www.secretlifeofmachines.com/the_tv_series.shtml
They went out of their way to avoid the engines colliding, because those inline 6 engines weigh a LOT. The video shows a front-left-fender vs front-left-fender collision. In a direct head-on crash, the Chevy's engine and transmission would cream the Malibus' much lighter engine/transaxle.
I am calling bull. Even though I agree that the Bel-Air's drivetrain is heavy. Why? Because the Bel-Air's frame failed, and let the drive train substantially deform the cabin in this test. This means, specifically, that the Malibu engaged the engine mechanically, during the course of the collision.
It is pretty clear that the Bel-Air's cabin is going to suffer a lot more damage than the Malibu's. Even in a fully head on collision.
Citroens have had unibody construction since the 40s. E.G. Budd came up with the idea for unibody steel construction, and Citroen bought into it in 1940 or so.
I have a hard time believing that you can predict that. Why do you think the Bel-Air's block would "cut through the Malibu" instead of cutting through the Bel-Air's cabin, like it essentially did in this test?
The big problem with older cars is that the body shape was sculpted from clay in a studio separate from the rest of the car designers, rather than being designed as part of an automobile. The end result being that the body shape had no basis in sound mechanical design.
Yeah... that just plain bull. Look up the "Budd Company".
Jeeps come with roll cages... A jeep driver won't be getting crushed. At worst (and this is a very real danger), a foreign object will enter the cabin and damage the passengers.
My observations were that I'd much rather be in an old tank like that in a minor accident. Anything major, and I'd rather be in a modern car with things like seatbelts, crumple zones and air bags.
"Minor" accidents can be much more severe if your body is taking the jolt instead of the crumple zones. Injuries like whiplash are extremely common in "minor" accidents. You might be able to get your Ford's frame straightened, but you can't get your neck fixed anywhere as cheaply or easily.
30 mph is not a minor accident, by the way. That's like falling out of a second story window (taking into account conservation of momentum leading to smaller forces on your body)
Seriously.
Who cares about some schmuck's grades? What has he published?
Yeah, as long as there's nothing in front of you for miles and miles, going fast is not scary at all.
If there's anything like a formal specification for the program, it's a good idea to write tests to ensure the program meets it. Writing more tests than that is pretty pointless, and is presumptuous of the programmer. At worst, the tests will have to be removed, when a feature incompatible with the programmer's assumptions is requested.
If you're working on a personal or open source project, this is a good way of thinking about test writing. Write up a spec for your program or module, and tests to make sure it satisfies it. It's not hard.
Nice, structured and clean code is appreciated, but this is the real world we're talking about where deadlines are everything. Getting it up and running is the goal. Nobody cares if it's ugly and stiched together.
You would be surprised. Bad code means big problems if there is a service failure. It is more difficult to debug bad code. And in a world where deadlines are important, it is nice to be able to write clean code for a few hours and go home early, because of all the time you've saved by not writing shitty code.
That's a philosophical issue, not a computing one. Assuming the original implementation's data structures are nicely normalized, any implementation is going to have to "the same" data structures. As long as they preserve the normalization of data structures, there is no substantive difference between functions that take "high level OO" to ASM.
All you really have to do is parse the code, and implement semantics for the parse tree. You will have written a "high level OO to ASM" translator. An "assembler".
Repeat this mantra: there is no difference between data and code.
This is crazy. It's like picking a lock without damaging it and then stealing jewlery out of a sock drawer and then being forced by the court to buy the victim a fence, guard dog, improved lock and safe to keep their jewelry in to prevent future crimes.
This might be a better punitive action than locking someone up. I fully support this idea.
You'll also have to consider developer-friendliness (try rewriting a project that's 1 million+ lines of high-level OO code with garbage collection in assembly language: you'll never finish the job
Hint: write an interpreter. You can even pick and choose your OO semantics if the original language's don't appeal.
Heh, never mind that "DBI" is short for "Database Interface". There's no substantive difference between a database and a "datastore".
There are other, more efficient ways to avoid DLL hell. And while that may make sense on a desktop, it seems truly moronic on a mobile platform, where space, bandwidth, and RAM are scarce.
Space is scarce? Really? Do you think 80 or 100MB of QT are going to fill up a 16 GB drive? Do you think 30 or 50 QT applications are going to fill up a 16 GB drive, even if they all bring their own QT libs?
Apple has already chosen their way of avoiding DLL hell, and it doesn't include a package manager for dealing with random application libraries.
Some of the rejection stories coming out suggest otherwise -- that they dislike any "external framework".
It's not "external" if it's in your app. You can link to any library you want, as long as you include a copy of it in your application bundle.
I think the problem here is that you don't know anything about python.
I know enough about python to know that your attitude is typical among Python users.
So why is a list comprehension better than something like
list.filter(A).map(function).filter(B).map(C).filter(D)?
How would you even express something like that? Nasty nesting, I'm sure. Even if you use "map" and "filter", you're screwed. You have to nest, because of Python's idiotic definitions of map and join.
And I'm sure you're not experienced enough to know why my version is significantly better. In effect, it's better because the important parts of every step are ALL RIGHT OF the textual representation of the last operation. So you DON'T need to move your eyes back and forth to keep track of scoping. So if you want to add a step to the computation on a list, you just add it at the end. If you want to add an intermediate step, you find where it goes, and insert it.
That's okay and all, but list comprehensions can require nesting. That's not good for maintainability. In fact, it is very bad. The sorts of things that ought to be thoughtless exercises (adding a hook to filter a list, so that you can pass the hook a function) become non-trivial exercises in themselves.
Consider the idea of taking a list, filtering by some predicate A, applying an expensive operation on the filtered list, and filtering the new list on some predicate B. Using list comprehensions, the "inner" list is:
[ expensive_operation x for x in list if A x ]
If you want to filter, and continue to use the same syntactic form, you have to do
[ x for x in [ expensive operation x for x in list if A x ] if B x ]
The fact that my eye has to go left and right and left and right, to find governing filters, braces, and so on, make it much harder to read to the equivalent (if Python was awesome)
list.filter(A).map(expensive_operation).filter(B)
I can keep that construct up for a few dozen method calls, and it will still be clear. Try nesting even four or five list comprehensions.
And I still think "; ".join is disgusting. I don't mean to be condescending, but do you know what a "join" is? http://en.wikipedia.org/wiki/Join_(mathematics)
Or... you could just buy an Android phone.
If you want to play in somebody else's playground/shopping mall, Apple isn't going to stop you.
Ouch, how many millimeters do you think a fifth of an inch is? Hint: it's 5.
I remember robotic tape archivers in the 90s... All they need is a fat pipe.
It can't give off more heat and be more efficient at the same time. However, it is placed close to you so that helps :)
I said hotter, not "give off more heat". Halogen lamps have an operating temperature that is significantly hotter than regular incandescent bulbs. This means, in particular, that the bulbs run significantly hotter (up to 4000K if I recall correctly). On the other hand, it also means that the color temperature of the bulb is significantly hotter, so that more light is radiated in the visible spectrum.
But as I said, this is a good desk accessory. It is near me because the light shining on me and my desk are what keep me warm, through radiant heat. A regular incandescent bulb would work for this purpose too, but why bother when a halogen bulb looks better (because of the color temperature) and is brighter for a fixed level of energy consumption?
Heck, this increased efficiency means more light/heat lands on me, instead of flowing out of the little vent holes at the top of every lamp. At that point, you're merely heating the air, which isn't a waste of energy exactly (at least in the winter), but isn't as efficient as keeping a person warm as shining a lamp on them and the surfaces they touch.
Yup. A halogen desk lamp makes a great accessory during Winter. It is more efficient than using a CFL and oil heating. I don't typically need to warm up my whole office, just the place I sit. The light also looks better than CFLs, or even regular incandescent bulbs. And halogen lamps are both hotter and 40% more efficient than regular incandescent bulbs.
You're seriously underestimating Bush Jr.'s cost to America. Yes, so far only 6 to 11T dollars worth of his promises have come to pass. But baby boomers are about to retire, and demanded more Medicare and Medicaid benefits. Including Social Security benefits, Bush Jr.'s promises are going to put us in a 60T dollar deficit by 2040.