Re: Boxing and Unboxing ??

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance


"Bruce Wood" <brucewood@xxxxxxxxxx> wrote in message
news:1168997729.204419.286160@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Peter Olcott wrote:
What I am saying is to raise the C# language to a whole other level of
abstraction where programmers writing programs in this language never have
any
reason to know the first thing about separate value types and reference
types,
there is only one type, and it simply works correctly and efficiently without
paying any attention at all to the underlying details.

OK, then we disagree. I prefer the way that it is now.

The issue is that abstracting away details can be good or bad. It can
be good when the details are getting in the way of understanding a
problem; abstract away the details, and the problem becomes clearer. It
can be bad when the details _matter_; abstract away the details and you
obscure the problem because the details were an important part of the
problem or its solution.

Abstracting away details is the primary means of every advance in programming
technology. The advance from machine language to assembly language abstracted
away the details of having to memorize opcodes. The advance from assembly
language to 3GLs abstracted away the details of dealing with unstructured
control flow.

The great advance from machine code to assembly language to "C" to C++ is that
there is very little loss of performance and much greater ease of use. C# has
seemed to have effectively accomplished this same thing, and taken it another
quarter step of ease of use through reduction in details. I think that C# could
progress along the same path that it is on and abstract out the {value type,
reference type} detail with no loss to performance.


C++ has a unified type system that essentially lets the programmer do
anything they want. This includes both elegant and efficient solutions
to problems, as well as horribly inefficient misapplications of said
features. It gives you, as one author put it, "Enough rope to shoot
yourself in the foot with."

C# divides the type system into two groups, based on what you would
normally use the type for, and makes the types act (by default) in the
way you would usually want to use them. It reduces flexibility, but,
IMHO, makes the code easier to understand.

So is the unified abstraction that C++ offers a "bad abstraction,"
then? Not for those who have the high IQ necessary to understand how it
works, and understand which uses of types are good solutions and which
are misapplications. C# takes a lot of the guesswork out of it: how you
apply each kind of type (value vs reference) is baked into the
language. It makes it hard to do patently stupid things, but at the
cost of making the language a little less flexible.

I say that unifying C# value and reference types (a la C++) would make
the language harder to use well, not easier, and would reduce
programmer productivity.

There may still be separate value types and reference types under the covers,
but, the programmer using the language will care about these to the same
degree
that they care about which operand is located in which machine register, not
at
all.

A specious comparison. Changing the register in which an operand is
located doesn't change the semantics of my program. Passing something
on the stack and copying it on assignment, versus passing a reference
on the stack and copying a reference radically changes the semantics of
my program.

When I'm programming in C#, I don't "care" about the distinction in the
sense that it gets in my way. I know how the types work and I use them,
in the same way that when I drive my car I don't "care" about changing
gears. I've driven standard shift cars for so long that I no longer
even think about about the process... I just do it.

I _do_ think about value versus reference types in the sense that I
think about the semantics of my program. Do I want a particular type to
act like a value, or act like a (reference) object? That's an important
design decision that I would have to make even in C++, when I decide
whether to pass an object on the stack, or pass its address. In a way,
it's worse in C++ because I have to make that decision every time I
call a method or assign a variable. In C# I make a design decision when
I write the class and then I get the "usual" behaviour by default from
then on.

As I said, we disagree. :-)



.

Relevant Pages

  • Re: Catagories of Assembly Languages
    ... > them what to do because you care about them. ... as an assembly language teaching tool. ... >> The tool should have the flexibility to allow the programmer to ... It's only reasonable that an assembler, ...
    (alt.lang.asm)
  • Re: Boxing and Unboxing ??
    ... feature is worth the additional complexity it adds to the language. ... arbitrary type that could be a value type or a reference type, ... Person that has space allocated for it on the heap. ... the programmer will not even need to know the difference. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Boxing and Unboxing ??
    ... abstraction where programmers writing programs in this language never have any ... reason to know the first thing about separate value types and reference types, ... C++ has a unified type system that essentially lets the programmer do ... the programmer using the language will care about these to the same degree ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Catagories of Assembly Languages
    ... There is the group of professional programmer, ... them what to do because you care about them. ... private language. ...
    (alt.lang.asm)
  • Re: segfault w/ block, but not file scope
    ... >> Then we need to make it very clear to J Random Newbie that C doesn't ... >> support pass by reference as a languag construct. ... a programmer should *eventually* understand ... think that it's at least as important to use C (or any language) as a ...
    (comp.lang.c)