C# as a programming language

[Jon Davis]

Any component used to build any structure can be used well, or poorly. The
"safety measures" in the C# language, and in other languages, are there to
aid the developer in the process of building a good structure. This does
not in any way prevent the developer from building a poor structure.

I would like to add that this comment of yours does not jive with what you
originally said.

Your original comment was,

A programming is to developers what bricks are to masons. Just as any mason
can build a bad or a good brick wall using the same or different bricks,
any developer can write good or bad application code using any programming
language.

Right. Try building a skyscraper with hammer, nails, and 2x4's.

And looking strictly at your original comment, I think we're looking through
two opposite approaches; you're saying that no matter how good a tool is, it
can still produce bad structure if the user of the tool doesn't use it
right. What I'm saying is that if the user does not have the right tools, it
will be a bad structure regardless.

In the case of C# vs. VBScript, at the most basic levels, the latter
language offers little or nothing to the developer to establish good code,
whereas C# is enabled richly to allow someone with discipline to produce
very good application code.

Jon

 

[Ian Semmel]

I learned to program in Java/C# first and I can't imagine how that could
have hindered my ability to learn C++.




I wouldn't think any moreso than C++. Would you like to elaborate?

In C#, because of garbage collect, there is no need for programmers to plan how
resources are to be used, created and disposed of when no longer needed.

This is fine, when using C#, but if a programmer moves to unmanaged C++ (or
other language), most of the techniques learned have to be drastically revised.

The key to writing a structured program is designing a structured internal
database. In unmanaged code, the programmer has to consider what objects are
being worked on and their scope. No such constraints are really put on the C#
programmer who can just create objects whenever the apparent need arises and
forget about them.

Because the programmer is not actually doing the GC, does not mean that it is
not going on. Garbage collect is nothing new, and has been around for 30+ years
in various BASICs and other languages. When working on slower machines (eg
PDP-11), GC would give a severe performance hit, so we used to have to use
special techniques to avoid it. C# only works because of the increased computing
power of modern machines.

Don't get me wrong, I like C#. I just think that programmers who go to unmanaged
code from C# will have a lot of problems with resource management.

 

[Kevin Spencer]

And I don't care to to peruse your comments fully because you didn't give

me the benefit of a doubt about my experience. I do have to look at
VBScript daily--to my anguish. But I have written at least a few hundred
thousand lines of C# and I've worked with it since it went Beta.

I din't say or imply anything about your experience. You only mentioned
having looked at VB and VBScript code written by others. I could not
therefore tell or assume how much C# code (written by others) you had looked
at. I was not talking about your own code. I would assume that, since you
are posting here, you are a C# user. As for your capabilities, again, I did
not address what I did not know. I was simply stating something about your
only statement, which was that you had seen a lot of bad VBScript. I had no
idea how much C# you may or may not have seen, and I only spoke of my own
experience with having seen a lot of it, both good an bad.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Hard work is a medication for which
there is no placebo.

 

[Kevin Spencer]

What I'm saying is that if the user does not have the right tools, it will

be a bad structure regardless.

This is the statement I take issue with. I've made chicken salad out of
chicken s**t for most of my life. Fortunately, I have good chicken these
days, but I value the time I had little to work with. It made me a better
problem-solver.

The only difference is, it takes less time to make good chicken salad out of
good chicken than it takes to make good chicken salad out of chicken s**t.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Hard work is a medication for which
there is no placebo.

 

[Jon Skeet [C# MVP]]

In C#, because of garbage collect, there is no need for programmers to plan how
resources are to be used, created and disposed of when no longer needed.

That's completely untrue.

Firstly, there are resources other than memory - if you don't care
about when they're released, you *will* run into problems.

Secondly, even memory usage *can* be very significant. It depends on
what you're doing, but in some situations, you really, really have to
care about what memory is being used where.

Because the programmer is not actually doing the GC, does not mean that it is
not going on. Garbage collect is nothing new, and has been around for 30+ years
in various BASICs and other languages. When working on slower machines (eg
PDP-11), GC would give a severe performance hit, so we used to have to use
special techniques to avoid it. C# only works because of the increased computing
power of modern machines.

That's not entirely true. GC actually improves performance in many
situations. GC works now because collectors have been worked on for so
many years, and have improved significantly.