So, I'm learning C# right now, and I've got a couple of notes I thought 
I'd share...

1) The designers have decided that Garbage Collection is a Good 
Thing(tm), and that pointers are Dangerous.  So, while it's actually 
possible to use pointers, they spend a lot of time telling you not to.

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?

In fact, 10 years from now, is the debate over GC going to seem like the 
debate between C and C++: sure, C can be faster, but for most developers 
the benefits of C++ outweigh the negligible speed penalty.

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

2) WHY is it considered a Good Thing that class methods must be written 
inline?  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.

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.

3) It's hard to believe how much some people are MS fanboys.  I picked 
up a number of C# books at the library (point of fact: I now have, in my 
possession, more books on C# from the local library, than my library had 
on *all* programming languages combined 15 years ago.  I know, because I 
read all of *those*, too).  Two of them have caught my eye, for being 
complete opposites:

The first has numerous errors in the code, and I mean extremely obvious 
things like:
   System.Console.WriteLine("Now assigning 10 to obj.value: ");
   obj.value = 20;
   System.Console.Writeline("Value of obj.value: {0}", obj.value);

Given that the above snippet is repeatedly (the program mentioned is 
repeated some four or five times), it's staggering to think that this 
error was never caught.  And it's only one example of the extremely 
sloppy editing.

Then, the author has the audacity to claim that MS's biggest mistakes 
with J++ were 1) Signing a contract with Sun, saying that they would 
accept Sun's standards on the Java language, and 2) Allowing the 
contract to be understandable.  These two items combined meant that when 
MS tried to "Embrace, Extend, Terminate" (or whatever that phrase is), 
Sun rightfully sued them and won.  Personally, I think their biggest 
mistake was to try to subvert another company's IP like that.

Now, this other book I'm reading has been edited well (I haven't found 
any errors in the code yet, or even in the grammar), and the author, 
despite writing a book on C# and obviously loving the language, still 
pokes fun at MS.  My favorite quote:
Q: How many OO programmers does it take to change a lightbulb?
A: None, MS changed the standard to darkness.

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.

Basically, C# allows you to give any member variable implicit get / set 
functions that are called when you access the variable normally.  In 
other words, you can access a member variable like this:

objA.val = objB.val;

And what will execute is:

objA.val_set( objB.val_get() );

Even though the variable 'val' can be a plain old int, or any other 
type.  I think this is really, really cool :)

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

I'm certainly not an expert on a plethora of languages but I do have 
some views on the points you raise.

1)  On Garbage Collection, I regard this as a huge factor in favour of 
C# and .Net.  The way that the language, type system, IL and GC are 
interwoven is superb.  It very substantially reduces the opportunity to 
create difficult to eradicate memory allocation / deallocation bugs.

Surely a C++ guru will know how to avoid or at least find and fix such 
problems but in .Net the problem to a large degree simply isn't there. 
End result in my experience is that it is actually practical for a 
non-guru to produce large sophisticated and functional programs.

And in regard to speed loss from GC, I really have not observed a 
problem.  You might think it is a huge overhead but it has not yet shown 
to be an issue at all for me.  I imagine that in certain types of 
applications it could be an issue in which case there are coding styles 
and techniques to minimise any impact and still remain within 'managed' 
code.

So it doesn't seem to be an issue at all.  People coming from other 
language backgrounds seem to have an impression that it is massively 
slower or a huge impost.  It seems like the opposite to me.

2)  Similarly this seems like a C vs C# pedigree thing.  Interfaces is 
certainly one answer.  The other i guess is that with the XML comments, 
Intellisense, Object Viewer, Class diagrams and other IDE goodies it is 
pretty easy to see the class jierarchy, properties, methods etc.

Story - My brother-in-law is a 20+ year veteran of C, C++ in embedded 
systems and under Windows using OWL and MFC.  My background is more PC 
and Mainframe assembler, a bit of C, lots of SQL and passing 
acquaintance with C++ (which I detest) and Java.

As I got into C# and .Net I found it to be very well thought out, rich 
and powerful.

Whenever we would discuss programming stuff he would raise two big 
things - GC and lack of header files (and therefore class prototypes). 
Here is a typical conversation that was unresolved for both of us:

Him:  How do you do X in .Net ?
Me:   Ah, that is still just like X
Him:  How do you do Y in .Net ?
Me:   You don't really have to or want to do that
Him:  I like to do that
Me:   But why when you don't need to
Him:  Well its good to because ...
Me:   But that isn't a problem in .Net because ...
Him:  Well I like to do it and it is a good idea
Me:   I can see that in C++ but they've really done away with that 
problem in C# / .Net
Him:  Well that can't be because I've seen problems when you don't do that
Me:   Yeah in C++ but you don't need to in C# and if you really want to 
you could probably do it using ...
Him:  Well I like to do it
Me:   Ok.

Guess what ?  Recently he's started really using VB.Net and now C#.Net 
and he pretty much raves over the improvements.  Suddenly there is no 
more discussion about the resistance points but we have fun talking 
about all of the neat new things and how well it all fits together.

Then there is the framework which to me seems more comprehensive and 
consistent than anything for Java.

And I think that LINQ, anonymous types, extension methods etc in .Net 
3.0 / 3.5 are really extending the framework in powerful ways while 
maintaining and extending the core.

Call me a C# / .Net fanboy but don't call me one for Microsoft.  I 
reckon they should put the C# guys starting with Anders Hejlsberg in 
charge of the next OS they do.

Post a reply to this message

Paul Fuller wrote:

> Call me a C# / .Net fanboy but don't call me one for Microsoft.  I 
> reckon they should put the C# guys starting with Anders Hejlsberg in 
> charge of the next OS they do.

"The next OS they do"?

Heh. You're a funny guy...



I must admit, I did take a brief look at various .Net languages. But 
that's the biggest drawback of Haskell: It makes you hate normal languages!

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v7 wrote:
> Paul Fuller wrote:
> 
>> Call me a C# / .Net fanboy but don't call me one for Microsoft.  I 
>> reckon they should put the C# guys starting with Anders Hejlsberg in 
>> charge of the next OS they do.
> 
> "The next OS they do"?
> 
> Heh. You're a funny guy...

Well there will be a next Microsoft OS.  I just wish it would be lean 
and clean which is the opposite of Vista.

> 
> 
> 
> I must admit, I did take a brief look at various .Net languages. But 
> that's the biggest drawback of Haskell: It makes you hate normal languages!
> 

I haven't looked at Haskell much.  The obscure little fragments that you 
post and expound upon are enough to warn me away :)

Lambda expressions which are new to C# look similarly obtuse.  Maybe 
I'll see the light one day.

Post a reply to this message

Paul Fuller <pgf### [at] optusnetcomau> wrote:
> 1)  On Garbage Collection, I regard this as a huge factor in favour of 
> C# and .Net.

  Garbage collection is not the Holy Grail of programming (nothing is).
And you have to know about its weaknesses. Certainly these weaknesses
may not be relevant in many cases, but in some cases they may be.

  Garbage collection basically means that all your objects are destroyed
with a delay (or, at least in Java, may not be destroyed at all; I don't
know how it works in C#). In many cases this doesn't matter. However, in
the cases where it does matter it can be a real problem.
  Sometimes it may be imperative that the destructor of the object be
called *immediately* when that object goes out of scope. Delaying that
destructor call may even cause a malfunction in the program (sometimes
even in situations which happen rarely and may not be caught in testing).
One good example of this is a destructor which closes an open file handle
the object has: The number of open file handles is often limited, and if
they are not closed after use, the program may run out of them.
  Manually closing the file handle when it's not needed anymore is not
any better then manual memory management: There's always the danger of
a leak. Functions may be exited at unexpected places, etc.

  So, basically, garbage collection takes care of memory management,
often at the cost of reducing the possibility of the user implementing
automatic management of resources other than memory. These resources may
be system resources, or resources in the program itself. GC seems to
completely disregard them.

  In a language like Java the only way you can manage such resources is
by manually freeing resources when they are not needed anymore. This is
a step back to the C memory (and other resources) management: Laborious
and error-prone.
  C# may be slightly better in this regard, though.

  Another problem with GC, which admittedly is often not very relevant,
but in some cases may be, is that GC is very detrimental with regard
to swapping.

  Suppose that you have made a program which just sits in the background
and waits for some task requests (like those background applications in
Windows which often put a small icon in the taskbar). This application
may have reserved a fair amount of memory for itself, but for a given
task it might only need a small part of this memory.

  Since this application is idle, if the system is running out of memory
the system will swap the memory used by this application to disk. If then
this small task is requested, only the memory actually needed for the
task will be swapped out of the disk. The rest will be kept in the swap.

  However, assume that the GC engine happens to be triggered during this
task. What happens? Since the GC engine scans the entire memory used by
the application, *all* of its reserved memory will be swapped from the disk.
If there's nothing to gargabe-collect, all this swapping would then be
completely useless.
  If the system was running low on memory to begin with, this can be
quite detrimental. The system may start swapping like mad, all for
absolutely no benefit.

  So the question is: If you are making such an application, can you
tell C# to *not* to use garbage collection? Is GC optional?

  One of the biggest problems I see with GC is that in most languages
it's not optional.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Paul Fuller <pgf### [at] optusnetcomau> wrote:
>> 1)  On Garbage Collection, I regard this as a huge factor in favour of 
>> C# and .Net.
> 
>   Garbage collection is not the Holy Grail of programming (nothing is).
> And you have to know about its weaknesses. Certainly these weaknesses
> may not be relevant in many cases, but in some cases they may be.

Actually, I just got through reading a section about how to set up your 
objects to be destroyed as soon as possible, rather than waiting for the 
  normal run of the GC.  You implement a certain function ("Dispose", I 
think it was), and make a single call to the GC telling it that this 
class needs immediate destruction.

Then, any instances of that class are destroyed as soon as possible (re: 
when they go out of scope, usually), similar to how objects in C++ are 
destroyed.

I just remembered another point I was thinking, though.

The whole point of GC is to make memory management easy.  In fact, 
that's why languages like Java and C# don't like pointers.  However, 
they're really sidestepping the issue, because memory management is 
*hard*.  You don't get rid of the problem by masking it with prettiness; 
instead, you need to train better programmers.

If someone can't logically think through the memory usage of their 
program, maybe they shouldn't be programming.

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

"Chambers" <ben### [at] pacificwebguycom> wrote in message
news:47eb3257$1@news.povray.org...
>
> 3) It's hard to believe how much some people are MS fanboys.

All too common in the IT area, unfortunatly. I hate them, no matter what
flavour they come in. Try reading one of gamespot's console forums (or on
second thoughts, don't)

Personally, I can't stand anyone who's so in favour of one
language/consol/game/... that they can't look objectivly at alternatives.

Post a reply to this message

Chambers <ben### [at] pacificwebguycom> wrote:
> 1) The designers have decided that Garbage Collection is a Good 
> Thing(tm), and that pointers are Dangerous.  So, while it's actually 
> possible to use pointers, they spend a lot of time telling you not to.

  That depends on your definition of "pointer".

  In my books Java references *are* pointers. They may have some restrictions
compared to, for example, C pointers, but they are pointers nevertheless.

  What is it that makes it a pointer? Easy: If you do an "a = b;", does
the object get copied, or do now 'a' and 'b' refer to the same object?

> 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?

  GC is ok most of the time. However, there are situations where it may
have negative effects, as I commented in the other post.

> In fact, 10 years from now, is the debate over GC going to seem like the 
> debate between C and C++: sure, C can be faster, but for most developers 
> the benefits of C++ outweigh the negligible speed penalty.

  "C is faster than C++" is a persistent myth. This has never been so.

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

  Beats me.

>  The language doesn't allow class prototypes, and claims this is 
> a benefit because "header files aren't necessary."

  This sounds like a hindrance to modularity. I assume that you can't
have types, functions and variables which are local to a compilation unit
and are completely invisible to the outside?

  In C++ I use this a lot. Not only do I try to make the public interface
of a class (or module) as minimal as possible, I also try to make the
private part as small as possible too. If something is only used by this
class, but it can be moved out of the class, I do so: I move it inside
the compilation unit where that class is implemented. Even if something
is inside this class, for example an inner class, if I can I only
pre-declare that inner class and declare/implement it in the compilation
unit. That is, for example like this:

// AClass.hh
// ---------
class AClass
{
 public:
    ...

 private:
    class InnerClass;
    ...
};

// AClass.cc
// ---------
class AClass::InnerClass
{
    // Implementation of InnerClass here.
};

  This removes clutter from the AClass definition.

> 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.

> Basically, C# allows you to give any member variable implicit get / set 
> functions that are called when you access the variable normally.

  Some would argue that's exposing the class' internal structure (even if the
variable is not *really* public), and thus it's against good OO principles.

  Usually one should completely avoid get and set methods for member
variables. (Granted, this is not always possible, but in a well-designed
program it can usually be mostly avoided.)

-- 
                                                          - Warp

Post a reply to this message

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

Paul Fuller wrote:
> And in regard to speed loss from GC, I really have not observed a 
> problem.  You might think it is a huge overhead but it has not yet shown 
> to be an issue at all for me. 

Now that I think about it, I remember reading that MS's goal was to come 
up with a GC that ran faster than a page fault.

> So it doesn't seem to be an issue at all.  People coming from other 
> language backgrounds seem to have an impression that it is massively 
> slower or a huge impost.  It seems like the opposite to me.

It *used* to be slow, 20 or 30 years ago. But that's like complaining 
that C++ is hard to debug because after you run it through cfront and 
compile the C code, you've lost all the source file line numbering.

> passing acquaintance with C++ (which I detest)

I saw a LOL line on another conversation.
    > > Having used Ada and C++ extensively,
    > > I'll take Ada over C++ any day.
    > Never having used Ada at all, I'll take Ada over C++.

> As I got into C# and .Net I found it to be very well thought out, rich 
> and powerful.

It's still statically typed and compiled, so you still have the troubles 
interfacing with Other Stuff sometimes. Like SQL - you still wind up 
changing things in several places when you change the type of 
arrangement of a SQL table.  I found that annoying for doing prototyping.

> about all of the neat new things and how well it all fits together.

It really is amazingly well thought out as a language. Plus they've 
added generics, partial classes, inline SQL, etc.

> Then there is the framework which to me seems more comprehensive and 
> consistent than anything for Java.

Yep. Again, of course, they had the hindsight of what Java had to 
explore and then maintain.  Java was kind of "the first one you throw 
out once you learn what you actually want," IMO.

> Call me a C# / .Net fanboy but don't call me one for Microsoft.  I 
> reckon they should put the C# guys starting with Anders Hejlsberg in 
> charge of the next OS they do.

I thought that was the idea behind Vista? Most of it rewritten to .NET?

-- 
   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