Because next to F#, Ocaml frankly said sucks. And I don't mean to be a troll. Almost anything you look at in Ocaml, F# has it better. Libraries, performance, interoperability,...
All of the facilities of CLR are available from F# -- that includes vast core.NET libraries, all of 3rd party.NET libraries, interoperability with all of the code that runs on CLR,... To give a transportation analogy: the libraries available in Ocaml are to libraries available in F# like a car's driver is to a seagoing ferry.
Ocaml was developed by INRIA to support their own R&D program, pretty much. There is, understandably, little incentive for them to have Ocaml do much more besides what they themselves need. It's OK, really, there's only so much you can do with limited funds and the day only being 24h long.
Never mind that there are serious technical issues with the virtual machine that runs Ocaml bytecode, and with the runtime library that supports native-compiled Ocaml. Those issues are benign enough to allow Ocaml to be deployed in certain scenarios, but for a language platform to be widely used they are pretty much non-starters. F# runs on CLR, a platform that gets as much or more development resources allotted to it yearly than Ocaml saw through the whole of its long existence, including that of Caml-lite.
No, this isn't a prelude to cancellation. MS is a heavy in-house F# user. All of static verification tools that Windows kernel team uses are AFAIK written in F#, and every driver that's signed by MS was tested using a static analysis tool written in F#.
Heck, they have seen so much internal demand for F# that they developed it in the first place -- initially, their static verifier codebase was written in Ocaml. They figured there's possibly so much more to be done in that area, that they developed a whole new programming language. That's as much commitment as you can get, in my book.
Ocaml, F#'s cousin, is used by a large private investment house -- Jane Street. F# itself is used in MS's static code analysis tools, like the driver verifier, and surely in a lot of in-house tools.
Not quite so. There are plenty of companies out there that use Ocaml, F#'s undermaintained cousin. Jane Street, a private investment house, is one having perhaps the biggest Ocaml codebase next to Microsoft's. I see that MS opensourcing of F# compiler will lead to perhaps well-earned retirement of Ocaml from mainstream use. I think the biggest issue with Ocaml was that it was mainly a reasearch tool, maintained by INRIA. The developers have little incentive to have Ocaml do much besides what they need for their R&D, and that's understood and I don't think there's anything wrong with that. What it leads to, though, is that Ocaml is rough around the edges, and not really ready for primetime outside of niches.
Tampering? LOL. I bought it, I own it, it is a physical product. For all I care they deserve a middle finger for even suggesting that what I do with their kinect box would be tampering.
the Wii balance board just about works because the sensor can look over the table at the control and doesn't need to know what I'm doing with my legs
Umm, what sensor can look over what? The Wii balance board is a 3-component force plate sensor (Fz, Mx, My). As long as you have enough room to stand on it without touching anything else, you're golden. It could be used in a port-a-potty if you didn't mind the smell.
The voltage limits in a typical electric drive system are there due to the battery voltage, not due to motor's insulation. Any motor worth its salt should have its insulation system survive 2-3x overvoltage without damage. Ergo -- no way to "melt" an electric truck motor by going fast downhill, what you may well kill is the output switches (half-H bridge triad) of the power supply.
I'd be careful with this argument. A painting is basically a mechanical log of painter's hand position over time. A book is basically a mechanical log of a bunch of keystrokes. While driving is mostly utilitarian by nature, there are drivers who "play" with their cars -- do things that are creative in nature and not merely utilitarian. Just like book writing can keep food on the table, driving can get you to your destination, but still you can be creative: play with brake lights, engine revs, etc. A log of an average soccer mom's grocery shopping trip is probably not in the scope of copyright law, while someone's who played a beat with the engine while at the red light -- probably would be in scope.
Someone in charge of ECU software design must have been asleep at the desk. Any engine over-rev on a manual gearbox should be immediately mitigated by applying compression braking. With this in effect, I can't really understand what's the problem. Sure, someone who chose a wrong gear and over-revved the engine will have to deal with effects of braking, possibly doing skid recovery and whatnot. In any case selecting too low of a gear with too little throttle applied will always cause the drivetrain to drag like crazy.
There is zero reason for this not to work like it should on a 2.5 year old MacBook with 4G of DDR2. You shouldn't need to have an SSD to have a modern paging VM system react 'instantaneously' to a human. We the people are slow. The fact that you can observe any sort of a UI latency at any point in time when running a modern OS is an abomination, and a statement of how lousy the widely used programming practices are. And I'm dead serious. Something is very, very wrong when a 100+ MHz CPU running a modern OS can be easily outrun, in terms of UI latency, by a system that's a quarter century old and runs on less than a 10MHz clock.
VM has plenty of impact on human observable latencies since apart from memory protection there is no way to have VM without also having paging. And there's no way of killing paging that I know of. Swap -- sure, paging -- no. Even if it was possible to disable paging, it takes one clever programmer who decided it's OK to mmap gigabyte+ files, and you are out of memory in no time flat. With paging enabled, VM lets you do mmap while keeping wired number of pages reasonable, at the cost of uncontrolled latencies.
Without paging, VM's only purpose is address space mapping and memory protection -- in that case you're right that it doesn't introduce human-observable latencies, but at the same time it's next to useless in keeping most of current applications running.
Disabling swap doesn't disable paging. I don't know of any way of disabling page eviction to disk, not on Linux, not on Windows, not on OS X. That's what VM is about. You can have a process binary running, and only parts of its image will be in memory -- others are on disk, and the VM system will bring it in. The problem is that the VM is very bad at knowing what's the critical path and what are the priorities when it comes to page eviction. Any sort of hints given by the application are advisory, in the mainstream kernel trio (Linux, OS X, Windows NT-derived). This is in spite of the application always knowing best what its needs are.
Not quite. They are protected from dissemination from the original source, but if you come up with something through independent research then you're in the clear. The latter includes reverse engineering: the trade secret law got nothing to do with reverse engineering or rediscovery. It applies if you go into a factory and copy something w/o authorization (it can be documents, but the law applies even if all you do is look at things and then use the knowledge).
While the image repainting was slow simply due to memory bandwidths back then, one can't but be amazed at the instantaneous response from the right-hand menu system. It seems like it took one or two vsyncs for the new menu to appear in response to a keystroke. This is something that you still can't get on modern OSes simply because there's always the VM subsystem in the way. On OS X, working normally with few running applications and plenty of memory, I can get 100+ms lag when switching between menus. Sure, the median may be pretty good, but the worst case is annoying. It interferes with the workflow. Never mind the everpresent lag on the workspace of most applications, be it photo editing, spreadsheet, CAD, etc.
I think that VM paging-induced lags are something that can't be overcome as long as we keep programming like we do -- with the assumption of infinite memory, more or less. I would really like to see a gradual shift towards realtime scheduling and applications where at least the core code and data is permanently wired. In the days of CP/M, WordStar was dealing quite well with slow links between the CPU and the terminal: you could type while it was trying to refresh the menus and the workspace. In the worst case, if you typed really fast, it'd only paint the characters you typed and nothing else. The timing was done such that it took into account the terminal baudrate, so things suitably improved when you'd switch the baudrate to something faster (38400 was a big deal back then, many systems only supported 19200 and defaulted to 4800 or 9600bps).
These days there are plenty of applications where everything is unresponsive due to paging just a tiny part of the UI. You'd think that the hot path would be resident and responsive, and that the GUI systems would cope with multiple application threads all doing GUI operations. Alas, neither X11 nor winapi got that right, and I don't know offhand whether multithreaded UI operations are allowed by OS X. Heck, you'd think that message-based interthread/interprocess communications would enable one to queue messages in face of stalled threads (say disk I/O stalls), and let the core user experience stay on par with expectations circa 1980.
Paging is the sole killer of user experience in modern applications, and it's not easy to work around it in environments where only one thread in a process can paint on the screen.
Re:Yes, yes, for loops!
on
Land of Lisp
·
· Score: 1
I don't know if you wished to imply that it's not possible in C++, but both reduce and map are fairly trivial to implement in C++. Off the bat:
template R reduce(R (*fun)(const E&, const R&), const R& init, const C& coll) {
R result = init;
for (C::const_iterator it = coll.begin(); it != coll.end(); ++it) {
result = fun(*it, result);
}
return result; }
template C map(E (*fun)(const E&), const C& coll) {
C result;
for (C::const_iterator it = coll.begin(); it != coll.end(); ++it) {
result.push_back(fun(*it));
}
return result; }
or, simpler, for collections that support random access iterators:
template C map(E (*fun)(const E&), const C& coll) {
C result(coll.size());
std::transform(coll.begin(), coll.end(), result.begin(), fun);
return result; }
With projects like that, you won't know the risk until you try. A couple times. So even though the risk has a cost, there's no way to tell what cost it has. There are highly paid IMHO clowns who pretend to be able to put a price to such risk, but it's a mere pretense. They are very poor predictors of any individual project's risk, they can only gauge risk in bulk, across several unrelated projects. IOW, they know a lot about everything, but nothing about something in particular. So whatever risk they come up with has only to do with a nonexistent aggregate. It's like with curving grades: individual students get efd up even though on average things look peachy; said average usually is unrealized, too.
As for the cost of relaunching Hubble with ACS: last time I checked, it could have even been cheaper than a Shuttle service mission if you take into account indirect costs. Politics at work. If Hubble somehow got serviced using other means (say Soyuz spacewalk, or a replacement mission), people would scream bloody murder that it wasn't the Shuttle that was used to service it. Even so the last service mission almost didn't happen.
There's no conspiracy theory to that, just plain good old politics at work. Daily Washington life, if you will.
Re:metaprogramming FTW!
on
Land of Lisp
·
· Score: 1
You don't have to look far.
Anything related to string handling, with multiple and recurring strlen()s, strcpy()s, strdup()s, etc. I'm porting an originally Xlib/Xt-based C project to Qt / C++ and anything string-related shrinks in size like crazy. Other things shrink too once you use what you got with C++/Qt.
Anything related to data lifetime: C only handles PODs and POD elements in structs. And those don't need anything special: by default, they don't get initialized, and destroying them implies just releasing the memory occupied by them. Everything else? You have to manually call initialization, copying, and destruction functions -- you have to write those even if you merely aggregate data types exposed by library APIs. You forget something and you deal with uninitialized data or memory leaks. C++ takes care of all that. Case in point: in C++ a struct containing a public std::string is safe to use and doesn't require any extra code, compiler writes it all for you. In C, you have to at least call free() on the string pointer before you call free() on the struct pointer.
There are plenty of semi-standard (glib) and roll-your own (look around) approaches to type hierarchies in C. They all involve slapping a type field into a structure, and plenty of typecasts. Not only downcasts, but also upcasts (casts to a parent type)! In C++, you get dynamic_cast for every instance of a polymorphic class, upcasts are automatic, and typeid() lets you determine the actual type of said instance.
C containers cannot be, by definition, type-safe unless you duplicate code. And even if you're OK with duplication costs of type safety, there is plenty of manual construction-and-deletion necessary everywhere.
In short, even C++ gives you solid benefits in type safety, expressiveness and productivity over C, never mind LISP.
Re:metaprogramming FTW!
on
Land of Lisp
·
· Score: 1
Metaprogramming does not have to be obtuse, it just happens to be implemented that way in C++; in Lisp it seems to be a natural fit but only after you get a feel for how Lisp code should look, feel and behave.
Or, more to the point: it would cost about the same to launch a whole new Hubble, with ACS on board, that it cost to service the one on orbit. The latter carried less risk, I guess.
I think the time is ripe to get on the bandwagon of safety-critical software development methodologies. It has been shown over an over that there is a bunch of code, in widespread use, whose failures cause extensive economical harm -- even if the harm to the individual is small, the collective expense is major and measured in USD billions. Flash Player and Reader fall into the category of software whose safety shortcomings cause extensive economical harm. Why are those developed using "standard" (read: cavalier) methodologies, I don't know. Flash Player and Adobe Reader should be developed at least to FAA software level C, ideally to level B. Or SIL3 per IEC61508. At least Adobe would directly feel how much it really costs to have feature bloat. No one adds features willy-nilly to SIL3 code.
Yes, I agree about hub motors. On a train engine (as opposed to a powered car), the bogey can be almost as tall as the chassis. On a car, you want the wheel and moving suspension to be ideally massless.
I also think that you should be able to have a high-RPM gas turbine under the hood, to drive a generator. When you have high RPMs, the torques can be kept small -- thus you can have a very compact generator. On top of that, since the turbine runs at constant speed, the generator can provide a fixed-frequency multiphase high-voltage AC. The electronics that generate DC from such a voltage can be optimized for the very voltage and frequency, thus making them very efficient. I'd think you could even get by with a permanent-magnet (brushless) genset that way -- low torque with low current means that you don't need as high of a magnetic field.
The fact that the turbine can run on a lot of different fuels only adds to the benefits.
If it's 80 degrees outside, then the air coming out of the vents will likely be around 84. There better be a shower and a change of clothes at your destination, because you'll be stinky and sweaty.
With AC motors, the re-capture system adds precisely 0kg to the weight and is always included. Any EV worth its salt uses AC motors -- that includes both hybrids and all-electric cars.
Yes -- with water and CO2 from the air, and the efficiencies aren't all that bad. Since the process requires pressurizing reagents at various stages, you can do even better than using electricity as the sole source of power. Any power plant (thermosolar, nuclear, conventional) can supply steam that you can use to run compressor turbines, and you can use waste heat to pre-heat some reagents etc. To dissociate water you merely need to heat up the steam enough, you don't need electrical power for that.
Slashdot Mirror
Because next to F#, Ocaml frankly said sucks. And I don't mean to be a troll. Almost anything you look at in Ocaml, F# has it better. Libraries, performance, interoperability, ...
All of the facilities of CLR are available from F# -- that includes vast core .NET libraries, all of 3rd party .NET libraries, interoperability with all of the code that runs on CLR,... To give a transportation analogy: the libraries available in Ocaml are to libraries available in F# like a car's driver is to a seagoing ferry.
Ocaml was developed by INRIA to support their own R&D program, pretty much. There is, understandably, little incentive for them to have Ocaml do much more besides what they themselves need. It's OK, really, there's only so much you can do with limited funds and the day only being 24h long.
Never mind that there are serious technical issues with the virtual machine that runs Ocaml bytecode, and with the runtime library that supports native-compiled Ocaml. Those issues are benign enough to allow Ocaml to be deployed in certain scenarios, but for a language platform to be widely used they are pretty much non-starters. F# runs on CLR, a platform that gets as much or more development resources allotted to it yearly than Ocaml saw through the whole of its long existence, including that of Caml-lite.
No, this isn't a prelude to cancellation. MS is a heavy in-house F# user. All of static verification tools that Windows kernel team uses are AFAIK written in F#, and every driver that's signed by MS was tested using a static analysis tool written in F#.
Heck, they have seen so much internal demand for F# that they developed it in the first place -- initially, their static verifier codebase was written in Ocaml. They figured there's possibly so much more to be done in that area, that they developed a whole new programming language. That's as much commitment as you can get, in my book.
Ocaml, F#'s cousin, is used by a large private investment house -- Jane Street. F# itself is used in MS's static code analysis tools, like the driver verifier, and surely in a lot of in-house tools.
Not quite so. There are plenty of companies out there that use Ocaml, F#'s undermaintained cousin. Jane Street, a private investment house, is one having perhaps the biggest Ocaml codebase next to Microsoft's. I see that MS opensourcing of F# compiler will lead to perhaps well-earned retirement of Ocaml from mainstream use. I think the biggest issue with Ocaml was that it was mainly a reasearch tool, maintained by INRIA. The developers have little incentive to have Ocaml do much besides what they need for their R&D, and that's understood and I don't think there's anything wrong with that. What it leads to, though, is that Ocaml is rough around the edges, and not really ready for primetime outside of niches.
F# should IIRC run just fine under Mono.
Tampering? LOL. I bought it, I own it, it is a physical product. For all I care they deserve a middle finger for even suggesting that what I do with their kinect box would be tampering.
the Wii balance board just about works because the sensor can look over the table at the control and doesn't need to know what I'm doing with my legs
Umm, what sensor can look over what? The Wii balance board is a 3-component force plate sensor (Fz, Mx, My). As long as you have enough room to stand on it without touching anything else, you're golden. It could be used in a port-a-potty if you didn't mind the smell.
The voltage limits in a typical electric drive system are there due to the battery voltage, not due to motor's insulation. Any motor worth its salt should have its insulation system survive 2-3x overvoltage without damage. Ergo -- no way to "melt" an electric truck motor by going fast downhill, what you may well kill is the output switches (half-H bridge triad) of the power supply.
I'd be careful with this argument. A painting is basically a mechanical log of painter's hand position over time. A book is basically a mechanical log of a bunch of keystrokes. While driving is mostly utilitarian by nature, there are drivers who "play" with their cars -- do things that are creative in nature and not merely utilitarian. Just like book writing can keep food on the table, driving can get you to your destination, but still you can be creative: play with brake lights, engine revs, etc. A log of an average soccer mom's grocery shopping trip is probably not in the scope of copyright law, while someone's who played a beat with the engine while at the red light -- probably would be in scope.
Someone in charge of ECU software design must have been asleep at the desk. Any engine over-rev on a manual gearbox should be immediately mitigated by applying compression braking. With this in effect, I can't really understand what's the problem. Sure, someone who chose a wrong gear and over-revved the engine will have to deal with effects of braking, possibly doing skid recovery and whatnot. In any case selecting too low of a gear with too little throttle applied will always cause the drivetrain to drag like crazy.
There is zero reason for this not to work like it should on a 2.5 year old MacBook with 4G of DDR2. You shouldn't need to have an SSD to have a modern paging VM system react 'instantaneously' to a human. We the people are slow. The fact that you can observe any sort of a UI latency at any point in time when running a modern OS is an abomination, and a statement of how lousy the widely used programming practices are. And I'm dead serious. Something is very, very wrong when a 100+ MHz CPU running a modern OS can be easily outrun, in terms of UI latency, by a system that's a quarter century old and runs on less than a 10MHz clock.
VM has plenty of impact on human observable latencies since apart from memory protection there is no way to have VM without also having paging. And there's no way of killing paging that I know of. Swap -- sure, paging -- no. Even if it was possible to disable paging, it takes one clever programmer who decided it's OK to mmap gigabyte+ files, and you are out of memory in no time flat. With paging enabled, VM lets you do mmap while keeping wired number of pages reasonable, at the cost of uncontrolled latencies.
Without paging, VM's only purpose is address space mapping and memory protection -- in that case you're right that it doesn't introduce human-observable latencies, but at the same time it's next to useless in keeping most of current applications running.
Disabling swap doesn't disable paging. I don't know of any way of disabling page eviction to disk, not on Linux, not on Windows, not on OS X. That's what VM is about. You can have a process binary running, and only parts of its image will be in memory -- others are on disk, and the VM system will bring it in. The problem is that the VM is very bad at knowing what's the critical path and what are the priorities when it comes to page eviction. Any sort of hints given by the application are advisory, in the mainstream kernel trio (Linux, OS X, Windows NT-derived). This is in spite of the application always knowing best what its needs are.
Not quite. They are protected from dissemination from the original source, but if you come up with something through independent research then you're in the clear. The latter includes reverse engineering: the trade secret law got nothing to do with reverse engineering or rediscovery. It applies if you go into a factory and copy something w/o authorization (it can be documents, but the law applies even if all you do is look at things and then use the knowledge).
While the image repainting was slow simply due to memory bandwidths back then, one can't but be amazed at the instantaneous response from the right-hand menu system. It seems like it took one or two vsyncs for the new menu to appear in response to a keystroke. This is something that you still can't get on modern OSes simply because there's always the VM subsystem in the way. On OS X, working normally with few running applications and plenty of memory, I can get 100+ms lag when switching between menus. Sure, the median may be pretty good, but the worst case is annoying. It interferes with the workflow. Never mind the everpresent lag on the workspace of most applications, be it photo editing, spreadsheet, CAD, etc.
I think that VM paging-induced lags are something that can't be overcome as long as we keep programming like we do -- with the assumption of infinite memory, more or less. I would really like to see a gradual shift towards realtime scheduling and applications where at least the core code and data is permanently wired. In the days of CP/M, WordStar was dealing quite well with slow links between the CPU and the terminal: you could type while it was trying to refresh the menus and the workspace. In the worst case, if you typed really fast, it'd only paint the characters you typed and nothing else. The timing was done such that it took into account the terminal baudrate, so things suitably improved when you'd switch the baudrate to something faster (38400 was a big deal back then, many systems only supported 19200 and defaulted to 4800 or 9600bps).
These days there are plenty of applications where everything is unresponsive due to paging just a tiny part of the UI. You'd think that the hot path would be resident and responsive, and that the GUI systems would cope with multiple application threads all doing GUI operations. Alas, neither X11 nor winapi got that right, and I don't know offhand whether multithreaded UI operations are allowed by OS X. Heck, you'd think that message-based interthread/interprocess communications would enable one to queue messages in face of stalled threads (say disk I/O stalls), and let the core user experience stay on par with expectations circa 1980.
Paging is the sole killer of user experience in modern applications, and it's not easy to work around it in environments where only one thread in a process can paint on the screen.
I don't know if you wished to imply that it's not possible in C++, but both reduce and map are fairly trivial to implement in C++. Off the bat:
template R reduce(R (*fun)(const E&, const R&), const R& init, const C& coll)
{
R result = init;
for (C::const_iterator it = coll.begin(); it != coll.end(); ++it) {
result = fun(*it, result);
}
return result;
}
template C map(E (*fun)(const E&), const C& coll)
{
C result;
for (C::const_iterator it = coll.begin(); it != coll.end(); ++it) {
result.push_back(fun(*it));
}
return result;
}
or, simpler, for collections that support random access iterators:
template C map(E (*fun)(const E&), const C& coll)
{
C result(coll.size());
std::transform(coll.begin(), coll.end(), result.begin(), fun);
return result;
}
With projects like that, you won't know the risk until you try. A couple times. So even though the risk has a cost, there's no way to tell what cost it has. There are highly paid IMHO clowns who pretend to be able to put a price to such risk, but it's a mere pretense. They are very poor predictors of any individual project's risk, they can only gauge risk in bulk, across several unrelated projects. IOW, they know a lot about everything, but nothing about something in particular. So whatever risk they come up with has only to do with a nonexistent aggregate. It's like with curving grades: individual students get efd up even though on average things look peachy; said average usually is unrealized, too.
As for the cost of relaunching Hubble with ACS: last time I checked, it could have even been cheaper than a Shuttle service mission if you take into account indirect costs. Politics at work. If Hubble somehow got serviced using other means (say Soyuz spacewalk, or a replacement mission), people would scream bloody murder that it wasn't the Shuttle that was used to service it. Even so the last service mission almost didn't happen.
There's no conspiracy theory to that, just plain good old politics at work. Daily Washington life, if you will.
You don't have to look far.
Anything related to string handling, with multiple and recurring strlen()s, strcpy()s, strdup()s, etc. I'm porting an originally Xlib/Xt-based C project to Qt / C++ and anything string-related shrinks in size like crazy. Other things shrink too once you use what you got with C++/Qt.
Anything related to data lifetime: C only handles PODs and POD elements in structs. And those don't need anything special: by default, they don't get initialized, and destroying them implies just releasing the memory occupied by them. Everything else? You have to manually call initialization, copying, and destruction functions -- you have to write those even if you merely aggregate data types exposed by library APIs. You forget something and you deal with uninitialized data or memory leaks. C++ takes care of all that. Case in point: in C++ a struct containing a public std::string is safe to use and doesn't require any extra code, compiler writes it all for you. In C, you have to at least call free() on the string pointer before you call free() on the struct pointer.
There are plenty of semi-standard (glib) and roll-your own (look around) approaches to type hierarchies in C. They all involve slapping a type field into a structure, and plenty of typecasts. Not only downcasts, but also upcasts (casts to a parent type)! In C++, you get dynamic_cast for every instance of a polymorphic class, upcasts are automatic, and typeid() lets you determine the actual type of said instance.
C containers cannot be, by definition, type-safe unless you duplicate code. And even if you're OK with duplication costs of type safety, there is plenty of manual construction-and-deletion necessary everywhere.
In short, even C++ gives you solid benefits in type safety, expressiveness and productivity over C, never mind LISP.
Metaprogramming does not have to be obtuse, it just happens to be implemented that way in C++; in Lisp it seems to be a natural fit but only after you get a feel for how Lisp code should look, feel and behave.
Or, more to the point: it would cost about the same to launch a whole new Hubble, with ACS on board, that it cost to service the one on orbit. The latter carried less risk, I guess.
I think the time is ripe to get on the bandwagon of safety-critical software development methodologies. It has been shown over an over that there is a bunch of code, in widespread use, whose failures cause extensive economical harm -- even if the harm to the individual is small, the collective expense is major and measured in USD billions. Flash Player and Reader fall into the category of software whose safety shortcomings cause extensive economical harm. Why are those developed using "standard" (read: cavalier) methodologies, I don't know. Flash Player and Adobe Reader should be developed at least to FAA software level C, ideally to level B. Or SIL3 per IEC61508. At least Adobe would directly feel how much it really costs to have feature bloat. No one adds features willy-nilly to SIL3 code.
Yes, I agree about hub motors. On a train engine (as opposed to a powered car), the bogey can be almost as tall as the chassis. On a car, you want the wheel and moving suspension to be ideally massless.
I also think that you should be able to have a high-RPM gas turbine under the hood, to drive a generator. When you have high RPMs, the torques can be kept small -- thus you can have a very compact generator. On top of that, since the turbine runs at constant speed, the generator can provide a fixed-frequency multiphase high-voltage AC. The electronics that generate DC from such a voltage can be optimized for the very voltage and frequency, thus making them very efficient. I'd think you could even get by with a permanent-magnet (brushless) genset that way -- low torque with low current means that you don't need as high of a magnetic field.
The fact that the turbine can run on a lot of different fuels only adds to the benefits.
If it's 80 degrees outside, then the air coming out of the vents will likely be around 84. There better be a shower and a change of clothes at your destination, because you'll be stinky and sweaty.
With AC motors, the re-capture system adds precisely 0kg to the weight and is always included. Any EV worth its salt uses AC motors -- that includes both hybrids and all-electric cars.
Hats off. This deserves a +5.
Yes -- with water and CO2 from the air, and the efficiencies aren't all that bad. Since the process requires pressurizing reagents at various stages, you can do even better than using electricity as the sole source of power. Any power plant (thermosolar, nuclear, conventional) can supply steam that you can use to run compressor turbines, and you can use waste heat to pre-heat some reagents etc. To dissociate water you merely need to heat up the steam enough, you don't need electrical power for that.