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

Warp wrote:
>   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.

Of course, all these objections are fairly irrelevant when the OS is 
actually designed to help the GC system.

For example, nobody complains "UNIX signals are bad, because if you 
don't catch them, your process might have files open when it exits." No, 
the OS closes the files for you. It doesn't delete temp files, and it 
doesn't roll back half-completed transactional changes to the file 
system (e.g., it won't let you rename files such that all three change 
or none change, even if you dump core in the middle), but people don't 
seem to complain about this aspect for some reason.

In a system that actually actively supports GC, a program trying to 
access a file handle that someone else has open (and locked) will cause 
a GC in that program to finalize those resources, freeing up the lock, 
in exactly the same way that a modern desktop OS will page out inactive 
portions of one process to free up memory for other processes.

And again, there are pretty trivial techniques to prevent this from 
being a problem. At the top of your main loop, you do a quick GC to 
scavenge anything you accidentally freed.

And of course anything that allocated stuff on the heap has this sort of 
problem anyway, unless you wind up essentially writing your own GC anyway.

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

Only naive GC.  Of course, sophisticated GC needs support throughout the 
system. Some systems have this.

Other systems don't have this sort of problem at all, in that files are 
memory resources just like "in-memory" structures, so going out of scope 
deletes the file just like you'd expect.

>   C# may be slightly better in this regard, though.

Syntactically, it's a bit easier, but it's essentially the same 
mechanism under the covers. It's just easier to invoke it.

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

I don't think I've demand-paged in ages. Certainly not any process I've 
let run to completion.

I've noticed that every program I use that actually uses too much data 
to conveniently fit in memory (e.g., photoshop, mysql, various other 
database-like engines) all manage their own memory-to-disk paging.

I bet you could get a speed boost by leaving out the demand-paging bits 
on modern chips and just go back to swapping and overlays in the rare 
cases where people care, and let them implement it themselves. You'd 
still probably want virtual addressing, so I don't know how much you'd 
actually save if you did this.

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

I wouldn't say "no benefit". If the system is smart, it'll do a GC 
*before* it swaps out the task. That's the sort of thing I'm talking 
about: it'll save swapping time and swap space.

Erlang has a primitive called "hibernate", which does a GC on the 
process then swaps it out until it gets the next message. Normally you'd 
only do this if you expect to be idle for a while (say, the backup 
process waiting for the next scheduled backup to roll around).

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

Not really.

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

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

The restrictions are why people call them "references" instead of 
"pointers", just like you call them "pointers" instead of "addresses" 
because they can only point to one type of object. I.e., you can have an 
integer and a float at the same address, but you can't have one pointer 
that points to either of those. (And no, "void*" doesn't count void* 
points to neither, not either.)

It's really just a precision-in-terminology thing for people who make 
such distinctions in their everyday work of designing languages. :-)

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

Sure you can. C# has the same public/private/protected/<mumble> that C++ 
has. With the added advantage that private variables really are private.

(There's one more access class that I forget what it is, but it means 
basically visible across compilation units but not across "assemblies", 
where an "assembly" is a unit of distribution of object code, like a 
library or component. So you can have a type that's private to your 
entire graphics library, usable from everywhere inside the graphics lib 
without being visible outside it.)

>   This removes clutter from the AClass definition.

In C#, you don't have to do anything like that. You declare AClass as 
public, AClass::Inner as private, and you're done. You don't have to 
pick different files to put them in to enforce who gets to see them.

Nor, for that matter, do you need to do anything funky with private 
member variables in a class. If you don't give someone the source code, 
they don't see the private variables.

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

Well, in the cases where this is used, they're "properties" of the 
object. If you're setting whether the printer will print in color or 
not, you use a "property" and C# writes the setter and getter routines 
for you. It's not exposing a member variable - that's the point of 
making it a property.

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