Yeah, in the same way strings are immutable. You can't change a 12. But even if "immutability" is potentially a matter of perspective, the key feature is referential transparency -- nobody else can change your values.
All I was saying is that "class explosion", whatever that is, doesn't always trump the benefit of making similar things appear similar.
Autoboxing is needed less often in C#, but it's still needed because all types are subtypes of "object".
In a perfect world probably. But have you considered that there's a reason why primitive types are left as primitives even in C# (which had the opportunity to correct the mistakes Java made).
I'm not suggesting that primitive types be implemented using the mechanics of regular objects. I'm just saying that they could be made to appear to the programmer like regular objects. Combined with certain restrictions (e.g. no extending from primitives) and some compiler tricks, this can be made to work efficiently. The fact that Java's primitive types are all immutable makes this even easier -- immutable objects are very well-behaved.
And sure, your performance might suffer if you're not careful, but I don't think that's necessarily worse than having to force people to deal with the primitive/object difference even when they don't particularly care. It's kind of like the autoboxing situation today. If you're not careful you could end up with a bunch of unwanted boxing/unboxing operations. So when I need to be careful, I am. But when I just want to get something done, it's way easier to just let the autoboxing happen.
Any experienced c++ programmer will tell you that "classes if necessary, but not necessarily classes" is the way to go. Class explosion is not pretty, and makes for over-complex stupid implementations.
When trying to design a new, clean, high-level programming language, I probably wouldn't pay much attention to C++ rules of thumb.
Making everything behave like an object can make things much cleaner. It all depends on how exactly this is done, but a lot of complexity in Java comes from the fact that primitive types behave differently. C# did a bit better, but there's still the value-vs-class distinction which can trip you up in subtle ways.
I think you're wrong. From the coverage I've read, it's a method of processing and manipulating XML documents, and they designed an piece of XML editing software around it which they showed to Microsoft and Microsoft then stole the ideas from.
News coverage of technical things is so effing horrible. Most tech articles are written by people who don't understand programming but don't see why that should stop them from broadcasting their misinterpretation of technical information. You should just read the patent; most of it is very clearly-written.
It does not predate XML, and has nothing to do with XML-based standards.
Filed in 1994, it does predate XML. It doesn't predate SGML, though, and since core XML is essentially the same thing, it's probably safe. However, I it does affect XML-based standards -- specifically the ones that separate content from structure/presentation.
The Patent
It's a way to separate content from structure. So, for example, where and SGML document would store data like "<p>Hi <i>friend</i></p>", they store it as two separate pieces of data. The content piece would be "Hi friend", the structure piece would be "0:p, 3:i, 9:/i, 9:/p" (roughly). So now if you wanted to format that document differently, you could just use a different structure piece; the content piece doesn't change.
This exact technique obvious, so I don't think it should have been awarded a patent. But maybe what's obvious to us in 2009 may not have been obvious to the patent examiner in 1994 and, in any case, it doesn't look like any of the affected parties are going to try and argue obviousness. The important question is how generally will their technique be interpreted?
Taken narrowly, it's a way of putting XML-like tags in a separate file, mapping them back into the content using byte offsets. This is easy enough to work around. Taken broadly, it's a way of separating content from structure. So, any time you augment the content in one file by some kind of annotations in another, you're violating their patent. So HTML and CSS are problematic because the style information is in a separate file, even though the mapping is done using tag and class names and not using byte offsets.
I don't know much about patent litigation, so I don't know how much leeway they give plaintiffs. But I doubt Microsoft Word uses their exact technique; they probably do something similar to HTML+CSS or XSLT. So this victory could indicate that the courts are interpreting the technique broadly. Which sucks. Man, patents like this are killing the industry.
Man, the BetaNews article is horrible. Practically everything — except for the direct quotes from the Google blog post — is incorrect. I somehow expect more from someone who goes by "Scott M. Fulton, III".
Google's public documentation shows Protocol Buffers (which has yet to be formally abbreviated) is indeed conceptually different from XML, in that it's rooted more in procedural logic than structural declaration. In XML, there's a schema which defines the structures of tables and recordsets, which is separate from the document that relates the contents of records in that structure.
Nope, they're conceptually the same. The ".proto" files are like DTD or XSD. The actual document data is stored in a binary format (though there's also a text representation). The data manipulation API is similar what you get from Castor or JAX-B.
But here, in an unusual departure from the norm, the default values for these members are set to digits (for strings or literals) or values (for numerals) that define their place in a sequence -- where they fall within a record. Imagine if data were streamed onto recording tape, the way it used to be in the late 1960s and '70s. It's that streaming of the data sequence, without all the fenceposts, that differentiates XML from Protocol Buffers, by taking out all those markups that say when an entry or a record starts and stops.
The "= number" at the end of a field definition is not a "default value". It is a numeric tag that identifies that field. That said, "= number" is quite unintuitive syntax; maybe something like "@number" would have been less confusing.
Looking at some of the documentation, I don't think the aforementioned numbers directly index the field's location in the record. They lay down the present fields one after another, probably putting each field's tag number before the field data. This also allows them to avoid sending fields that use the default value. So they still need to specify how long each record is — either with "fenceposts" between records or a "length" specifier before each record.
In other words, you are right. Of course you can have memory leaks in garbage collected languages. And I wish people would stop using GC as an argument why languages as Java are so much better to use than C
Yes, the headline is stupid and you can leak memory in garbage-collected languages.
However, I do really think that garbage collection makes a huge difference in programmer productivity. Just because it doesn't solve every resource problem doesn't mean it's useless.
Re:Probably that you're running Ubuntu, like me.
on
GNOME 2.16 Released
·
· Score: 2, Informative
I've used Debian for around 5 years and while the GNOME/X11 upgrades do have problems, they work well enough that I'm content with the way it works.
I've used Ubuntu for around 9 months and had no problems at all with the Hoary-to-Dapper upgrade.
When I use Debian, I just select "testing" or "unstable" and continously update to the latest packages, which gets rid of the annoying version-lag that Ubuntu has. On the other hand, Ubuntu's big all-at-once upgrades makes quality assurance easier and so I expect Ubuntu upgrades to be smoother than Debian upgrades.
My troll-o-meter reads "probable", but I just can't help myself. Here we go again...
So any API with implementation bugs can't be considered well-designed and well-written?
Agreed!
Doesn't that rule out almost everything out there? Is there a library of comparable complexity to.Net that you believe is well-designed and well-written?
I have no idea about Dot Net - I have never used it - I don't use M$ software.
What's the largest piece of software you know of that is free of implementation bugs? Photo$hop[1] definitely has bugs.
Well who is the silly sausage in that case! If it is not specified then there are no guarantees. Assumption is the mutha of all stupidities.
The point is that this isn't Microsoft's fault, but they'll get the blame for "breaking" things between versions.
But older versions of Photoshop can indeed open and read Photoshop files saved by newer versions of photoshop that contain data that relate to features contained only in the newer version.
This is why software is more complicated than a Photoshop file. What would you do in.Net? Tell the JIT to insert no-ops for unresolved function calls?
"End users" generally never see software source code.
But programmers do and when you're talking about a library, they're the end users. Adding fine-grained version numbering to function names affects the programmer; it's ugly and I prefer a breaking change if it is enough of an improvement over the old API.
[1] OMG! I can't believe how hard I just pwned Adobe by replacing the 'S' with a dollar sign. They may never recover.
You miss my point - which is that the APIs of *well-designed* and then *well-written* software should provide output that conforms to its design specification.
So any API with implementation bugs can't be considered well-designed and well-written? Doesn't that rule out almost everything out there? Is there a library of comparable complexity to.Net that you believe is well-designed and well-written?
Also, part of the problem is that developers end up relying on unspecified behavior. One example (from The Old New Thing blog, I believe) is a querying function that returns some system information in a list. In.Net 1.1, the list was in sorted order. The fact that it was sorted was a side-effect of the implementation and wasn't stated in the function contract, but some developers ended up (probably inadvertently) relying on that behavior. In.Net 2.0, the list was no longer sorted. The output is still according to the specification, but the client application no longer works properly. This is not Microsoft's fault, but they might end up taking the blame in a generic "I tried running on.Net 2.0 and my app broke" kind of way.
With photoshop - it's file format was designed so that all versions of Photoshop can open any photoshop file saved by any other version of Photoshop. It was deliberately designed to be able to do that.
Older version of Photoshop can read the newer file formats? If so, how do they add new features and make them still work? Having to degrade gracefully is severly limiting. If it's only backwards compatibility, then I think Microsoft seems to be able to do that in MS Word. If there are, in fact, any backwards compatibility problems in the design itself, then yes, I consider that to be a screw up.
One difference between something like a Photoshop/Word documents and program source code is that nobody was ever supposed to read the former. They can add ugly-looking hacks (such as version numbers on each data structure) to make things work because end users don't have to look at the raw data. With source code, there is the occasional version numbering suffix, but doing that too frequently will make things worse than just fixing the API in-place and temporarily inconveniencing the developers that relied on the broken behavior.
IF software is well designed, and has followed a proper design process then its complexity is not a factor in how its APIs respond - because those APIs have been determined to provide a given response for a given input even before any coding was ever done in the first place. Any deviation from this is a flaw in the software and should be corrected before it is released.
You might want to read "The Old New Thing" blog; it recounts many instances where developers relied on more than the APIs stated contract (mostly Win32 stuff, but there are.Net examples in there too). And Microsoft does go to great lengths to avoid breaking popular software, but they can't control the development process employed by 3rd-party developers.
Have you taken a look at the list of breaking changes? They're mostly design and bug fixes. They could have created new functions (with the suffix "_New", or something) but I prefer fixing the functions in-place. Not allowing such changes is just going to cause a build-up of cruft. If you just want your older app to continue working, you can still use an older version of.Net, since multiple versions can be installed side-by-side on the same machine.
It's not that Microsoft is particularly incompetent. These problems come up a lot. The C and C++ standards, the Java API, the Linux kernel, Apache module API, etc. You're just not going to get it right on the first try. The reason Photoshop can do backwards compatibility is because the data it deals with is much more restricted than program code. It's easy for Photoshop to automatically upgrade old file formats. It's harder to do the same thing for source code (though Micrsoft has released migration tools that help).
That used to piss me off, but now I just remind myself that the more complex the API is the better. Allow me to explain my reasoning:
[snip]
So why is this good? Because many rival companys or programmers will likely give up after a few weeks/months of wasting time with such a frustrating thing. Sure, many will and do continue to struggle through it, but think of the competition for me if it was a well laid out API that was perfectly understandable and worked as expected.
Great. Now everyone is wasting time beating crappy APIs into submission instead of working on useful functionality. Makes you wish Win32 only came with Intercal bindings.
I know the production.Net implementation is free, but the Java one is semi open source. Don't strawman the IDE stuff; I never said anything about Visual Studio.
I didn't know about the patent grant. That's good news.
Now all that's left is your claim Sun controls Java while C# and.Net are more open because they are ECMA standards. For all practical purposes, Microsoft is in at least as much control of the future of C# and the.Net libraries as Sun is in control of Java. It doesn't matter how many standards bodies get involved. Nobody cares what the ECMA says. The only thing people will care about is the de facto standard -- Microsoft's implementation. So many important and widely-used parts of the.Net libraries aren't covered by any ECMA standards. As long as the licensing terms are acceptable, I don't care where the spec comes from.
I'm not saying that Java is any better, but C# is not "much more free".
C# and.Net are actually much more "free" technologies than Java is
Microsoft is in complete control over the future of the C# language and the.Net libraries and runtime. Just because they do the standards dance doesn't mean they've given up control. Do you honestly think that C# or.Net can change in a way Microsoft doesn't approve of?
The ECMA even allows the standard to be patent-encumbered as long as Microsoft provides "reasonable and non-discriminatory" licensing fees. That makes me feel completely safe.
Microsoft's policy on making changes is to solicit customer feedback and then work internally to come up with the design. Compare this to the JCP. I'm sure that, in practice, Sun has more clout than the other participants, but their control isn't total. Design-by-committee may or may not be be stupid, but it is definitely more open.
Have you seen the Java 6 website? No, the license isn't the friendliest, but it's the production JVM. Rotor is just the research implementation.
Don't get me wrong...I think C# and.Net are open enough to allow implementations like Mono. I, personally, don't believe Microsoft will sue. I just don't understand how you can say C# and.Net are "much more" free than Java.
there's nothing at all "closed" or "proprietary" about C# or.Net [emphasis is mine]
Aside from the production implementation and the related patents, right?
Doing whole-program optimization wont help language-level scope requirements. The programmer, when he runs the initial compile (with "javac" or whatever), needs the compiler to acknolwedge that his "File" object's lifetime is limited to a given scope. A link-time optimizer could later go in and refine the scopes to make things faster, but the refinements aren't available for the programmer to take advantage of.
Another idea: One of the qualifiers (perhaps the default) should specify that the compiler can choose whatever type it predicts will be most efficient, of the types it can prove valid. A dynamic compiler might make very good use of that freedom.
Inference would work well for local variables and private functions, but you probably don't want any public API signatures to be inferred. So, you'd still have a lot of explicit typing to do.
A dynamic compiler might make very good use of that freedom.
By your definition (objects in memory that cannot affect any future computation), you can have garbage in programs that don't even allocate memory, for example if there's dead code or library bloat. Does "Hello World" have a memory leak?
GP's definition was obviously referring to heap objects. I think you're equating "garbage" with "memory leak". Just because garbage exists doesn't mean there's a memory leak. A memory leak is garbage that will never bee freed (or maybe just kept around for way too long).
I don't think memory hogging = memory leaking, and whether something can affect future computation is not always definable.
Not sure what you mean by "definable" but yes, it is an undecidable problem in general (even ignoring external events such as a customer coming back to look at his Amazon.com shopping cart). It is possible, though, to make conservative guesses. For example:
1. Dog d = new Dog(); 2. d.bark(); 3. print("hi"); 4. d = null;
A collector might deallocate the Dog object immediately after line 2 because it inferred (somehow) that the object would never be used in the future. You don't necessarily have to wait until the reference (in variable "d") is set to null.
If you accept automatically-destroyed stack objects in a GC language, you have to face the possibility of heap objects containing dangling pointers to destroyed stack objects.
Your point would be relevant if this thread were called "The Pros and Cons of Memory Safety". Yes, guaranteeing memory safety does make things harder. But if you don't require memory safety (and I don't see how you could, since C++ definitely doesn't provide it), GC mixed with stack objects works just fine.
The scope qualifiers ("stack", "object", or "heap") apply to types, not to constructor invocations. Good defaults could alleviate the problem (and I, for one, think the payoff is worth it) but it's a lot of extra finger work. Think C++ const-correctness times 3 (at least).
The analysis required by the compiler is basically escape analysis. Currently escape analysis is usually a tranasparent optimization -- if it can't prove your object is bounded by the stack, it puts it on the heap. When scoping is part of the language, you'll get an error message instead and you have to go and fix your code (which could involve major restructuring).
Finally, note that all this extra crap gives you a system that offers a much higher level of verifiablity than C++ does. If all you want is to be able to constrain non-memory resources to some lexical scope, then C#'s "using (...) {... }" does the job. The only difference is that the resource's scope is explicitly delimited with braces. There's no technical reason the feature couldn't be changed to use the same implicit scope rules as C++. Garbage collection definitely doesn't get in the way.
Slashdot Mirror
Yeah, in the same way strings are immutable. You can't change a 12. But even if "immutability" is potentially a matter of perspective, the key feature is referential transparency -- nobody else can change your values.
All I was saying is that "class explosion", whatever that is, doesn't always trump the benefit of making similar things appear similar. Autoboxing is needed less often in C#, but it's still needed because all types are subtypes of "object".
I'm not suggesting that primitive types be implemented using the mechanics of regular objects. I'm just saying that they could be made to appear to the programmer like regular objects. Combined with certain restrictions (e.g. no extending from primitives) and some compiler tricks, this can be made to work efficiently. The fact that Java's primitive types are all immutable makes this even easier -- immutable objects are very well-behaved.
And sure, your performance might suffer if you're not careful, but I don't think that's necessarily worse than having to force people to deal with the primitive/object difference even when they don't particularly care. It's kind of like the autoboxing situation today. If you're not careful you could end up with a bunch of unwanted boxing/unboxing operations. So when I need to be careful, I am. But when I just want to get something done, it's way easier to just let the autoboxing happen.
C# started out essentially the same as Java. But at this point it's way better.
When trying to design a new, clean, high-level programming language, I probably wouldn't pay much attention to C++ rules of thumb.
Making everything behave like an object can make things much cleaner. It all depends on how exactly this is done, but a lot of complexity in Java comes from the fact that primitive types behave differently. C# did a bit better, but there's still the value-vs-class distinction which can trip you up in subtle ways.
News coverage of technical things is so effing horrible. Most tech articles are written by people who don't understand programming but don't see why that should stop them from broadcasting their misinterpretation of technical information. You should just read the patent; most of it is very clearly-written.
Filed in 1994, it does predate XML. It doesn't predate SGML, though, and since core XML is essentially the same thing, it's probably safe. However, I it does affect XML-based standards -- specifically the ones that separate content from structure/presentation.
The Patent
It's a way to separate content from structure. So, for example, where and SGML document would store data like "<p>Hi <i>friend</i></p>", they store it as two separate pieces of data. The content piece would be "Hi friend", the structure piece would be "0:p, 3:i, 9:/i, 9:/p" (roughly). So now if you wanted to format that document differently, you could just use a different structure piece; the content piece doesn't change.
This exact technique obvious, so I don't think it should have been awarded a patent. But maybe what's obvious to us in 2009 may not have been obvious to the patent examiner in 1994 and, in any case, it doesn't look like any of the affected parties are going to try and argue obviousness. The important question is how generally will their technique be interpreted?
Taken narrowly, it's a way of putting XML-like tags in a separate file, mapping them back into the content using byte offsets. This is easy enough to work around. Taken broadly, it's a way of separating content from structure. So, any time you augment the content in one file by some kind of annotations in another, you're violating their patent. So HTML and CSS are problematic because the style information is in a separate file, even though the mapping is done using tag and class names and not using byte offsets.
I don't know much about patent litigation, so I don't know how much leeway they give plaintiffs. But I doubt Microsoft Word uses their exact technique; they probably do something similar to HTML+CSS or XSLT. So this victory could indicate that the courts are interpreting the technique broadly. Which sucks. Man, patents like this are killing the industry.
Man, the BetaNews article is horrible. Practically everything — except for the direct quotes from the Google blog post — is incorrect. I somehow expect more from someone who goes by "Scott M. Fulton, III".
Nope, they're conceptually the same. The ".proto" files are like DTD or XSD. The actual document data is stored in a binary format (though there's also a text representation). The data manipulation API is similar what you get from Castor or JAX-B.
The "= number" at the end of a field definition is not a "default value". It is a numeric tag that identifies that field. That said, "= number" is quite unintuitive syntax; maybe something like "@number" would have been less confusing.
Looking at some of the documentation, I don't think the aforementioned numbers directly index the field's location in the record. They lay down the present fields one after another, probably putting each field's tag number before the field data. This also allows them to avoid sending fields that use the default value. So they still need to specify how long each record is — either with "fenceposts" between records or a "length" specifier before each record.
Yes, the headline is stupid and you can leak memory in garbage-collected languages.
However, I do really think that garbage collection makes a huge difference in programmer productivity. Just because it doesn't solve every resource problem doesn't mean it's useless.
I've used Debian for around 5 years and while the GNOME/X11 upgrades do have problems, they work well enough that I'm content with the way it works.
I've used Ubuntu for around 9 months and had no problems at all with the Hoary-to-Dapper upgrade.
When I use Debian, I just select "testing" or "unstable" and continously update to the latest packages, which gets rid of the annoying version-lag that Ubuntu has. On the other hand, Ubuntu's big all-at-once upgrades makes quality assurance easier and so I expect Ubuntu upgrades to be smoother than Debian upgrades.
Ironically, your post epitomizes something I hate about Slashdot.
My troll-o-meter reads "probable", but I just can't help myself. Here we go again...
What's the largest piece of software you know of that is free of implementation bugs? Photo$hop[1] definitely has bugs.
The point is that this isn't Microsoft's fault, but they'll get the blame for "breaking" things between versions.
This is why software is more complicated than a Photoshop file. What would you do in .Net? Tell the JIT to insert no-ops for unresolved function calls?
But programmers do and when you're talking about a library, they're the end users. Adding fine-grained version numbering to function names affects the programmer; it's ugly and I prefer a breaking change if it is enough of an improvement over the old API.
[1] OMG! I can't believe how hard I just pwned Adobe by replacing the 'S' with a dollar sign. They may never recover.So any API with implementation bugs can't be considered well-designed and well-written? Doesn't that rule out almost everything out there? Is there a library of comparable complexity to .Net that you believe is well-designed and well-written?
Also, part of the problem is that developers end up relying on unspecified behavior. One example (from The Old New Thing blog, I believe) is a querying function that returns some system information in a list. In .Net 1.1, the list was in sorted order. The fact that it was sorted was a side-effect of the implementation and wasn't stated in the function contract, but some developers ended up (probably inadvertently) relying on that behavior. In .Net 2.0, the list was no longer sorted. The output is still according to the specification, but the client application no longer works properly. This is not Microsoft's fault, but they might end up taking the blame in a generic "I tried running on .Net 2.0 and my app broke" kind of way.
Older version of Photoshop can read the newer file formats? If so, how do they add new features and make them still work? Having to degrade gracefully is severly limiting. If it's only backwards compatibility, then I think Microsoft seems to be able to do that in MS Word. If there are, in fact, any backwards compatibility problems in the design itself, then yes, I consider that to be a screw up.
One difference between something like a Photoshop/Word documents and program source code is that nobody was ever supposed to read the former. They can add ugly-looking hacks (such as version numbers on each data structure) to make things work because end users don't have to look at the raw data. With source code, there is the occasional version numbering suffix, but doing that too frequently will make things worse than just fixing the API in-place and temporarily inconveniencing the developers that relied on the broken behavior.
Actually, it's $4.25 million.
You might want to read "The Old New Thing" blog; it recounts many instances where developers relied on more than the APIs stated contract (mostly Win32 stuff, but there are .Net examples in there too). And Microsoft does go to great lengths to avoid breaking popular software, but they can't control the development process employed by 3rd-party developers.
Have you taken a look at the list of breaking changes? They're mostly design and bug fixes. They could have created new functions (with the suffix "_New", or something) but I prefer fixing the functions in-place. Not allowing such changes is just going to cause a build-up of cruft. If you just want your older app to continue working, you can still use an older version of .Net, since multiple versions can be installed side-by-side on the same machine.
It's not that Microsoft is particularly incompetent. These problems come up a lot. The C and C++ standards, the Java API, the Linux kernel, Apache module API, etc. You're just not going to get it right on the first try. The reason Photoshop can do backwards compatibility is because the data it deals with is much more restricted than program code. It's easy for Photoshop to automatically upgrade old file formats. It's harder to do the same thing for source code (though Micrsoft has released migration tools that help).
Yeah, and since raster images are as complex as program source code, the analogy is perfect.
Great. Now everyone is wasting time beating crappy APIs into submission instead of working on useful functionality. Makes you wish Win32 only came with Intercal bindings.
I know the production .Net implementation is free, but the Java one is semi open source. Don't strawman the IDE stuff; I never said anything about Visual Studio.
.Net are more open because they are ECMA standards. For all practical purposes, Microsoft is in at least as much control of the future of C# and the .Net libraries as Sun is in control of Java. It doesn't matter how many standards bodies get involved. Nobody cares what the ECMA says. The only thing people will care about is the de facto standard -- Microsoft's implementation. So many important and widely-used parts of the .Net libraries aren't covered by any ECMA standards. As long as the licensing terms are acceptable, I don't care where the spec comes from.
I didn't know about the patent grant. That's good news.
Now all that's left is your claim Sun controls Java while C# and
I'm not saying that Java is any better, but C# is not "much more free".
Microsoft is in complete control over the future of the C# language and the .Net libraries and runtime. Just because they do the standards dance doesn't mean they've given up control. Do you honestly think that C# or .Net can change in a way Microsoft doesn't approve of?
The ECMA even allows the standard to be patent-encumbered as long as Microsoft provides "reasonable and non-discriminatory" licensing fees. That makes me feel completely safe.
Microsoft's policy on making changes is to solicit customer feedback and then work internally to come up with the design. Compare this to the JCP. I'm sure that, in practice, Sun has more clout than the other participants, but their control isn't total. Design-by-committee may or may not be be stupid, but it is definitely more open.
Have you seen the Java 6 website? No, the license isn't the friendliest, but it's the production JVM. Rotor is just the research implementation.
Don't get me wrong...I think C# and .Net are open enough to allow implementations like Mono. I, personally, don't believe Microsoft will sue. I just don't understand how you can say C# and .Net are "much more" free than Java.
Aside from the production implementation and the related patents, right?
If the wattage were sustained, then yeah, the timeframe doesn't matter. But the term "10kW per car" implies that the wattage isn't sustained.
Doing whole-program optimization wont help language-level scope requirements. The programmer, when he runs the initial compile (with "javac" or whatever), needs the compiler to acknolwedge that his "File" object's lifetime is limited to a given scope. A link-time optimizer could later go in and refine the scopes to make things faster, but the refinements aren't available for the programmer to take advantage of.
Inference would work well for local variables and private functions, but you probably don't want any public API signatures to be inferred. So, you'd still have a lot of explicit typing to do.
What do you mean by a "dynamic compiler"?
GP's definition was obviously referring to heap objects. I think you're equating "garbage" with "memory leak". Just because garbage exists doesn't mean there's a memory leak. A memory leak is garbage that will never bee freed (or maybe just kept around for way too long).
Not sure what you mean by "definable" but yes, it is an undecidable problem in general (even ignoring external events such as a customer coming back to look at his Amazon.com shopping cart). It is possible, though, to make conservative guesses. For example:
A collector might deallocate the Dog object immediately after line 2 because it inferred (somehow) that the object would never be used in the future. You don't necessarily have to wait until the reference (in variable "d") is set to null.
Your point would be relevant if this thread were called "The Pros and Cons of Memory Safety". Yes, guaranteeing memory safety does make things harder. But if you don't require memory safety (and I don't see how you could, since C++ definitely doesn't provide it), GC mixed with stack objects works just fine.
The scope qualifiers ("stack", "object", or "heap") apply to types, not to constructor invocations. Good defaults could alleviate the problem (and I, for one, think the payoff is worth it) but it's a lot of extra finger work. Think C++ const-correctness times 3 (at least).
To avoid C's strchr(...) const problem, the qualifiers need to play well with type parameterization.
The analysis required by the compiler is basically escape analysis. Currently escape analysis is usually a tranasparent optimization -- if it can't prove your object is bounded by the stack, it puts it on the heap. When scoping is part of the language, you'll get an error message instead and you have to go and fix your code (which could involve major restructuring).
Finally, note that all this extra crap gives you a system that offers a much higher level of verifiablity than C++ does. If all you want is to be able to constrain non-memory resources to some lexical scope, then C#'s "using (...) { ... }" does the job. The only difference is that the resource's scope is explicitly delimited with braces. There's no technical reason the feature couldn't be changed to use the same implicit scope rules as C++. Garbage collection definitely doesn't get in the way.