Chambers wrote:
> I have to wonder, is the whole debate about GC merely due to the fact 
> that current implementations aren't satisfactory?  If there were better 
> implementations that were more predictable about object destruction and 
> memory cleanup, and especially about when they clean up the fragmented 
> memory space, would developers be more willing to live with it?

No. There are very predictable GC engines used in hard-real-time 
systems. And GC tends to be as fast or faster than manual memory 
allocation in most situations as well.

> Or is GC a flawed concept to begin with, and doomed to mediocre 
> performance?

Actual measurements repeatedly show GC outperforming manual memory 
management in almost all cases.

Basically, there are any number of people who say "fast is better than 
correct" because they've never built programs where incorrectness costs 
money or lives.

> 2) WHY is it considered a Good Thing that class methods must be written 
> inline? 

Because it prevents you from duplicating the same information (the 
function declarations) in two different places. (Not that I necessarily 
disagree with you, but that's why.)

You can't accidentally declare the function taking a float in the 
headers and an integer in the body and have mysterious type crashes at 
runtime in spite of your static typing.

 > The language doesn't allow class prototypes, and claims this is
> a benefit because "header files aren't necessary."  I actually *like* 
> header files, a well written one gives you a great overview of the class 
> in question, and many times I refer to them rather than the 
> documentation for class libraries.

You generate that from the class body. You don't write it twice. That's 
for an IDE or document processor, not a human.

I like having a table of contents in a book, too. I don't want to 
maintain it manually as I write the book.

> Note: it may be that Interfaces solve this for me, I haven't gotten that 
> far in the language yet.  In a few more days, I will have.

Not really.

> error was never caught.  And it's only one example of the extremely 
> sloppy editing.

Yah, in the Erlang book he's got a bunch of places where the code call 
the function "add_one" and the prose calls it "addOne". Like he was used 
to one convention and found out that most people use the other 
convention or something. Which is confusing when you're passing 
parameters from three or four places (the code, the config file, the 
caller) and those parameters include the names of the functions to call 
and such.

> 4) Lastly, sometimes it's the little things that count.  Personally, I 
> love the fact that I don't have to right 'get' and 'set' functions for 
> member variables, even when accessing the data is not straightforward.

Even nicer, that you can decide later to change from a normal member 
variable to a getter/setter property, and all you have to do is 
recompile the callers without changing the source. (Do you even have to 
recompile the callers? I'd assume so, given how it's implemented.)

There's a lot of cool stuff in C#, especially in libraries they don't 
cover in tutorial-level books. I found the O'Reilly book very helpful too.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message