C# as a programming language

[Dave]

I want to spend two minutes on my soapbox.

I love C#. I am so productive in it it's ridiculous. But it's so easy to
write code that uses poor design principles. Example: just making
variables public instead of using properties. Another example: passing
references to forms to other classes so they can modify things (tight
coupling). So in essence, there are so many ways to do things that many of
them are just flat-out poor designs.

I'm just wondering what languages (if any) are more limited in the ways to
do things so that they force the programmer to use better design principles?

[Lebesgue]

It's not exactly about design principles, but there is a language that
forces exact formatting at least - it's the whitespace sensitive python.

I don't know of any language that would somehow force programmer to use
exact design principles.

I believe Visual Studio could be configured to run the code through FxCop at
the time when user compiles his code and refuse to compile when certain
FxCop rules are not met.

"Dave" <no**@nowhere.com> wrote in message
news:u8**************@TK2MSFTNGP02.phx.gbl...

I want to spend two minutes on my soapbox.

I love C#. I am so productive in it it's ridiculous. But it's so easy to
write code that uses poor design principles. Example: just making
variables public instead of using properties. Another example: passing
references to forms to other classes so they can modify things (tight
coupling). So in essence, there are so many ways to do things that many
of them are just flat-out poor designs.

I'm just wondering what languages (if any) are more limited in the ways to
do things so that they force the programmer to use better design
principles?

[Ian Semmel]

I think programmers who have come through the path of C++ (or another native
language) appreciate many of the features of C#.

However, I think that anyone who learns programming in C#, would find it almost
impossible to start programming in C++.

C# encourages unstructured programs.

Dave wrote:

I want to spend two minutes on my soapbox.

I love C#. I am so productive in it it's ridiculous. But it's so easy to
write code that uses poor design principles. Example: just making
variables public instead of using properties. Another example: passing
references to forms to other classes so they can modify things (tight
coupling). So in essence, there are so many ways to do things that many of
them are just flat-out poor designs.

I'm just wondering what languages (if any) are more limited in the ways to
do things so that they force the programmer to use better design principles?

[Bob Grommes]

Eiffel (including Eiffel.NET) supports interface contracts. It strongly
encourages their use but I don't recall if it forces you to use them.

The trouble with good design principles is that we can't all agree 100%
on them, and a product that adopts a particular hobby horse and turns it
into bondage-and-discipline immediately limits the market for the product.

As an example you could argue that COBOL (including COBOL.NET) supports
the 80 Column Mind and enforces it ... but most of us here probably
don't really want to turn back the clock like that ;-)

The best way to do what you suggest is probably at the IDE level, with
VS add-ins and appropriately constructed policies in VS Enterprise 2003
or VS Team 2005. That functionality is targeted more at shops that want
to enforce their own styles and procedures and workflows, so I suspect
that given enough resources you could construct something around almost
any ideology or requirement, whether technological or political.

As a final thought ... to quote Fred Brooks, "There Is No Silver
Bullet", so in my view the search for the Perfect Methodology and the
quest to enforce it is probably misdirected.

http://www.cs.unibo.it/~cianca/wwwpa...ure/Brooks.pdf

This is a craft as much as a science, and eventually you figure out that
to do it right requires experience, heart, intuition, creativity and
humility as much as it requires objective scientific analysis. I prefer
to glean the good and eject the dross from each school of thought, and
use what makes sense depending upon the situation. As such, I really
don't want my language and development environment dictating too much or
making too many assumptions.

Best,

--Bob

Dave wrote:

I want to spend two minutes on my soapbox.

I love C#. I am so productive in it it's ridiculous. But it's so easy to
write code that uses poor design principles. Example: just making
variables public instead of using properties. Another example: passing
references to forms to other classes so they can modify things (tight
coupling). So in essence, there are so many ways to do things that many of
them are just flat-out poor designs.

I'm just wondering what languages (if any) are more limited in the ways to
do things so that they force the programmer to use better design principles?

[James Park]

"Ian Semmel" <is***********@NOKUNKrocketcomp.com.au> wrote in message
news:OU**************@TK2MSFTNGP05.phx.gbl...

I think programmers who have come through the path of C++ (or another
native language) appreciate many of the features of C#.

However, I think that anyone who learns programming in C#, would find it
almost impossible to start programming in C++.
I learned to program in Java/C# first and I can't imagine how that could
have hindered my ability to learn C++.
C# encourages unstructured programs.

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

[Kevin Spencer]

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.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

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

"Dave" <no**@nowhere.com> wrote in message
news:u8**************@TK2MSFTNGP02.phx.gbl...

I want to spend two minutes on my soapbox.

I love C#. I am so productive in it it's ridiculous. But it's so easy to
write code that uses poor design principles. Example: just making
variables public instead of using properties. Another example: passing
references to forms to other classes so they can modify things (tight
coupling). So in essence, there are so many ways to do things that many
of them are just flat-out poor designs.

I'm just wondering what languages (if any) are more limited in the ways to
do things so that they force the programmer to use better design
principles?

[RBChallenger]

James Park Wrote:

"Ian Semmel" <isemmelNOJUNK (AT) NOKUNKrocketcomp (DOT) com.au> wrote
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?

Going one way or the other really isnt a jump imho, f# to C++ and vise
a versa either, other than the fact that C# gives you so much more. GUI
wise... Id rather poke myself with needles than write anything MFC.
--
RBChallenger
------------------------------------------------------------------------
RBChallenger's Profile: http://www.hightechtalks.com/m315
View this thread: http://www.hightechtalks.com/t365619

[Peter Bromberg [C# MVP]]

Kevin,
Couldn't agree more. C# doesn't encourage unstructured programming.
Unstructured programmers who are too lazy to learn good structured
programming principals are what encourage unstructured programming.
Peter

--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com


"Kevin Spencer" wrote:

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.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

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

"Dave" <no**@nowhere.com> wrote in message
news:u8**************@TK2MSFTNGP02.phx.gbl...

I want to spend two minutes on my soapbox.

I love C#. I am so productive in it it's ridiculous. But it's so easy to
write code that uses poor design principles. Example: just making
variables public instead of using properties. Another example: passing
references to forms to other classes so they can modify things (tight
coupling). So in essence, there are so many ways to do things that many
of them are just flat-out poor designs.

I'm just wondering what languages (if any) are more limited in the ways to
do things so that they force the programmer to use better design
principles?

[William Stacey [MVP]]

| As an example you could argue that COBOL (including COBOL.NET) supports
| the 80 Column Mind and enforces it ... but most of us here probably
| don't really want to turn back the clock like that ;-)

Agreed. When I was doing Cobol, I knew I wanted something like c#, but did
not know it till I saw it.

[William Stacey [MVP]]

Agree. You can write bad code in any language, including cobol. So this
ability is not unique to c# or vb.net or perl or java or c++ or c, etc.

--
William Stacey [MVP]

[Kevin Spencer]

> Going one way or the other really isnt a jump imho, f# to C++ and vise

a versa either, other than the fact that C# gives you so much more. GUI
wise... Id rather poke myself with needles than write anything MFC.
The GUI isn't a part of C# - that's entirely Visual Studio.Net. Neither is
the CLR - That's the .Net platform. C# is a language, pure and simple.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

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

"RBChallenger" <RB*****************@no-mx.forums.yourdomain.com.au> wrote in
message news:RB*****************@no-mx.forums.yourdomain.com.au...
James Park Wrote:

"Ian Semmel" <isemmelNOJUNK (AT) NOKUNKrocketcomp (DOT) com.au> wrote
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?

Going one way or the other really isnt a jump imho, f# to C++ and vise
a versa either, other than the fact that C# gives you so much more. GUI
wise... Id rather poke myself with needles than write anything MFC.
--
RBChallenger
------------------------------------------------------------------------
RBChallenger's Profile: http://www.hightechtalks.com/m315
View this thread: http://www.hightechtalks.com/t365619

[SP]

"Dave" <no**@nowhere.com> wrote in message
news:u8**************@TK2MSFTNGP02.phx.gbl...

I want to spend two minutes on my soapbox.

I love C#. I am so productive in it it's ridiculous. But it's so easy to
write code that uses poor design principles.
Part of good programming is recognizing code smells and refactoring
accordingly.

Example: just making variables public instead of using properties. Another example: passing
references to forms to other classes so they can modify things (tight
coupling). So in essence, there are so many ways to do things that many
of them are just flat-out poor designs.
Some coupling is always required. Passing one class reference to another
class isn't (necessarily) poor design.
I'm just wondering what languages (if any) are more limited in the ways to
do things so that they force the programmer to use better design
principles?

Don't lean on a language to enforce better design principles. Lean on
yourself.

SP

[Jon Davis]

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:uq**************@TK2MSFTNGP02.phx.gbl...

Going one way or the other really isnt a jump imho, f# to C++ and vise
a versa either, other than the fact that C# gives you so much more. GUI
wise... Id rather poke myself with needles than write anything MFC.

The GUI isn't a part of C# - that's entirely Visual Studio.Net. Neither is
the CLR - That's the .Net platform. C# is a language, pure and simple.

Respectfully, while technically you're correct, practically I disagree. C#
is nothing without the Framework, just like Java is nothing without its
runtime library. The original post is not comparing C# with other .NET
langauges, he's comparing against the world of programming; for that matter,
the Framework as part of C# is quite relevant.

Jon

[Jon Davis]

I respectfully disagree. These aren't bricks; they're complex tools that
potentially have the ability to impose compile-time requirements on
structure and organization. You certainly CAN shoot, stab, poke, crush, or
mangle yourself in the foot with any instrument, but some instruments are
built with safety measure to discourage it or to help you remember not to.

Consider VBScript, for example. I have to tend to VBScript scripts every
day, despite using C# regularly, too. VBScript does not give you types, and
the ability to create classes as instantiable objects isn't obvious--it's a
discipline that has to be taught. The number of poorly written VBScript
scripts, because of the nature of the language catering toward laziness and
idiocy, has often led me to question my career path, because people who
could have had the potential to become great programmers were instead taught
to become sloppy, and I blame it almost entirely on the limitations of the
language.

C#, on the other hand, forces you to work with classes and requires you to
type everything. You have to make an effort to get around that. And that's
just one example.

C# is no brick!!

Jon
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:ug**************@TK2MSFTNGP05.phx.gbl...

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.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

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

"Dave" <no**@nowhere.com> wrote in message
news:u8**************@TK2MSFTNGP02.phx.gbl...

I want to spend two minutes on my soapbox.

I love C#. I am so productive in it it's ridiculous. But it's so easy
to write code that uses poor design principles. Example: just making
variables public instead of using properties. Another example: passing
references to forms to other classes so they can modify things (tight
coupling). So in essence, there are so many ways to do things that many
of them are just flat-out poor designs.

I'm just wondering what languages (if any) are more limited in the ways
to do things so that they force the programmer to use better design
principles?

[SpotNet]

It's the programmer/software engineer and not the language. I've seen highly
structured VB6.0 and VBA programs and spaghetti C++ code, and vise versa.
You can make a bigger mess of C++ than VB (due to the syntactic structures),
just as you can with C#, Java, QBasic, ... you name it. I think a language
called ADA attempted to force a structure (many years ago) but, I did hear
that through the grapevine. Such that if you gave 200 programmers a task in
this language, you'd get very similar code, don't know though. Where with
the others, you'd get 200 different algorithms, some very structured and
some you could add bolognaise to...

There's 2cents for ya'all for 1cent...

- SpotNet

"Dave" <no**@nowhere.com> wrote in message
news:u8**************@TK2MSFTNGP02.phx.gbl...
:I want to spend two minutes on my soapbox.
:
: I love C#. I am so productive in it it's ridiculous. But it's so easy to
: write code that uses poor design principles. Example: just making
: variables public instead of using properties. Another example: passing
: references to forms to other classes so they can modify things (tight
: coupling). So in essence, there are so many ways to do things that many
of
: them are just flat-out poor designs.
:
: I'm just wondering what languages (if any) are more limited in the ways to
: do things so that they force the programmer to use better design
principles?
:
:

[Kevin Spencer]

> Respectfully, while technically you're correct, practically I disagree. C#

is nothing without the Framework, just like Java is nothing without its
runtime library. The original post is not comparing C# with other .NET
langauges, he's comparing against the world of programming; for that
matter, the Framework as part of C# is quite relevant.
I'll assume that you're respectfully disagreeing only with my statement that
the CLR is not a part of C#. I can see your point. I was sloppy in my
remark. I meant to say that the Common Language Runtime Library of the
Microsoft .Net Framework is not a part of C#. The CLR or CLI might well be
thought of as integral to the language. However, the Common Language Runtime
Library, which includes the CLR, encompasses a plethora of additional
classes which are not in any way a part of the C# language. Neither is the
entire Microsoft .Net Framework, which includes quite a bit more than
language support.

I'm sure we still agree that the Visual Studio GUI is *not* part of the C#
language.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

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

"Jon Davis" <jo*@REMOVE.ME.PLEASE.jondavis.net> wrote in message
news:O8**************@TK2MSFTNGP05.phx.gbl...
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:uq**************@TK2MSFTNGP02.phx.gbl...

Going one way or the other really isnt a jump imho, f# to C++ and vise
a versa either, other than the fact that C# gives you so much more. GUI
wise... Id rather poke myself with needles than write anything MFC.

The GUI isn't a part of C# - that's entirely Visual Studio.Net. Neither
is the CLR - That's the .Net platform. C# is a language, pure and simple.

Respectfully, while technically you're correct, practically I disagree. C#
is nothing without the Framework, just like Java is nothing without its
runtime library. The original post is not comparing C# with other .NET
langauges, he's comparing against the world of programming; for that
matter, the Framework as part of C# is quite relevant.

Jon

[Otis Mukinfus]

On Fri, 21 Apr 2006 16:18:37 -0400, "Dave" <no**@nowhere.com> wrote:

I want to spend two minutes on my soapbox.

I love C#. I am so productive in it it's ridiculous. But it's so easy to
write code that uses poor design principles. Example: just making
variables public instead of using properties. Another example: passing
references to forms to other classes so they can modify things (tight
coupling). So in essence, there are so many ways to do things that many of
them are just flat-out poor designs.

I'm just wondering what languages (if any) are more limited in the ways to
do things so that they force the programmer to use better design principles?

I don't think you're talking about one language here and I don't think any
language should force programming style. As a good programmer, you should know
what to do and what not to do. That's why we make a better than average living.

Look at the MS data access automation stuff in VS 2003 and VS 2005. You can't
really use it for industrial strength applications, but it's a sort of "forced"
way of doing things (if you use it).

Frankly, I love C# too. I really love not having to remember if I released that
last memory allocation I made with maloc ;o)

Good luck with your project,

Otis Mukinfus
http://www.arltex.com
http://www.tomchilders.com

[Kevin Spencer]

Hi Jon,

I respectfully disagree. These aren't bricks; they're complex tools that
potentially have the ability to impose compile-time requirements on
structure and organization. You certainly CAN shoot, stab, poke, crush, or
mangle yourself in the foot with any instrument, but some instruments are
built with safety measure to discourage it or to help you remember not to.
I can't give you any credit for this one. While some languages are better
than others in a qualitative way, such as strong typing, etc., this does not
make any language safer to use than another one. My allegory of a brick was
a simplification. A brick is a component used to build a structure. A
programming language is a set of components to build logical structures. The
complexity is of no importance; hence, I used the simplest allegory I could
think of, for the sake of clarity. Conceptually, with regards to the point I
was making, they are the same. Both are components used to build structures.

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. For one
thing, you would have to eliminate certain components from the tool set in
order to make this assertion. The "safety measures" you speak of do not
apply to all components of the entire language. In addition, it is not the
individual components of the structure that determine the quality of the
structure; it is the Gestalt of the components that comprises the quality of
the structure. A process is not a collection of unrelated separate elements;
it is the combination of elements in complex relationships with one another.
Hence, we have the disciplines of design and architecture.

Taking the analogy of the brick as a simple example, let us imagine that a
brickmaker designed a new kind of brick, with a "magnetic" component that
caused it to snap to the nearest 90-degree increment with any brick layed
prior to it. This would prevent misalignment of bricks in a rectangular
structure. However, of course, not all structures are rectangular. So, the
brickmaker includes a configurable aspect that allows the angular increment
to be adjusted on a per-brick basis, or perhaps to an entire group of bricks
at a time.

Along comes a mason, and he happily proceeds to build a tower. However, he
designs the tower as a single column that is the same width at the bottom as
the top, 10 feet wide, and the height of the tower is 1000 feet. While the
bricks are most certainly aligned in perfect angular fashion, before the
tower is finished, it falls over. The ratio of the width of the tower to its
height is the reason for the failure. Bricks have little tensile strength,
and are heavy. A brick may seem like a very solid building block, but it is
the combination of them that causes the tower to fall, because it is not a
brick. Neither is it a collection of bricks. It is the sum total of all the
bricks that comprise its structure, combined with their arrangement, and the
resulting characteristics of the whole. In fact, no pair of bricks in the
tower has the same qualities as any other pair of bricks, due to its
placement in the structure. The relationship of each brick in the pair to
the other brick is affected by the relationship of that brick, and that pair
of bricks, to the entire structure. There is more force, for example,
pressing down on bricks that are lower in the tower. The lateral force on
each brick depends also upon its position within the tower.

Now, considering the brick again, we may agree that a brick is about the
most simple analogy one could make for a programming language, and that a
simple tower is the most simple analogy one could make for an application or
process written in a programming language. But you have already made the
assertion that a programming language is a set of "complex tools" that is
far more complex than a set of identical bricks. As my Uncle Chutney sez,
"Complex things are made up of lots of simple things." When you combine
components into a structure, the complexity of the structure increases
exponentially with each component added. New points of failure are
introduced, sometimes in the most unexpected of places. If the components of
the structure are complex, how much more complex is the resulting structure!

The World Trade Center in New York was designed to withstand the impact of
an aircraft the size of each aircraft that flew into each tower, and in
fact, it did. But both towers fell into a pile of "bricks." Both of them.
Why? Because the architects did not anticipate *all* of the factors that
were caused by the impact, and the remaining residence of each plane within
the structure. The planes, the fuel in the planes, and the resulting and
lingering fires, introduced factors which eventually caused a chain reaction
of events, which caused the towers to fall.

As for anecdotal evidence, I don't know how much C# code you've seen. You
mention that you have seen a lot of VB and VBScript. Well, I have seen a lot
of very poorly-written C#. And as for people being "taught to become
sloppy," well, I'm going to have to respectfully disagree with that
assertion. The language doesn't teach the developer to be sloppy. The
developer does that all by him/herself. One can write good VB and VBScript
in just the same way that one can write good C#. It is not the language that
determines the character of the developer. On the contrary, it is the
character of the developer that determines the quality of *anything* that
developer does, regardless of whether it is the writing of an application,
or the maintenance of the home, finances, or relationships.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

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

"Jon Davis" <jo*@REMOVE.ME.PLEASE.jondavis.net> wrote in message
news:Ou**************@TK2MSFTNGP04.phx.gbl...I respectfully disagree. These aren't bricks; they're complex tools that
potentially have the ability to impose compile-time requirements on
structure and organization. You certainly CAN shoot, stab, poke, crush, or
mangle yourself in the foot with any instrument, but some instruments are
built with safety measure to discourage it or to help you remember not to.

Consider VBScript, for example. I have to tend to VBScript scripts every
day, despite using C# regularly, too. VBScript does not give you types,
and the ability to create classes as instantiable objects isn't
obvious--it's a discipline that has to be taught. The number of poorly
written VBScript scripts, because of the nature of the language catering
toward laziness and idiocy, has often led me to question my career path,
because people who could have had the potential to become great
programmers were instead taught to become sloppy, and I blame it almost
entirely on the limitations of the language.

C#, on the other hand, forces you to work with classes and requires you to
type everything. You have to make an effort to get around that. And that's
just one example.

C# is no brick!!

Jon
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:ug**************@TK2MSFTNGP05.phx.gbl...

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.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

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

"Dave" <no**@nowhere.com> wrote in message
news:u8**************@TK2MSFTNGP02.phx.gbl...

I want to spend two minutes on my soapbox.

I love C#. I am so productive in it it's ridiculous. But it's so easy
to write code that uses poor design principles. Example: just making
variables public instead of using properties. Another example:
passing references to forms to other classes so they can modify things
(tight coupling). So in essence, there are so many ways to do things
that many of them are just flat-out poor designs.

I'm just wondering what languages (if any) are more limited in the ways
to do things so that they force the programmer to use better design
principles?

[William Stacey [MVP]]

| I'm sure we still agree that the Visual Studio GUI is *not* part of the C#
| language.

I agree too. It is not any more part of the language as WPF will be - just
another library with goodness.

[Jon Davis]

I think we'll have to simply agree to disagree, Kevin. Again, we're not
dealing with bricks, and the analogy does not fit.

Driving a car is likelier to fit. VBScript is like driving a bus. It takes a
lot of effort to drive safely in a bus, and just climbing into the cockpit
feels like you're toying with an oversized weapon. C# is more likely a
Mercedes-Benz. It has safety features and gadgets that help you stay safe.
Both cars enable you to drive on the wrong side of the road, and indeed the
Mercedes is in some ways more dangerous depending on whether the driver
respects the rules of the road, etc., because it can drive much faster.
However, I would still feel much safer in a Mercedes, because it doesn't
make you feel like you're endangering yourself and everyone else around you
as soon as you sit down in the driver's seat.

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.

Jon

[Jon Davis]

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:Ou**************@TK2MSFTNGP02.phx.gbl...

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

[Dave]

I come from a C background with a little C++. I assure you I can create a
more unstructured mess with C/C++ than with C#! Coming from C it took me a
long time to learn OOP (though really I did use OOP techniques with C such
as encapsulation and programming to the interface rather than to the
implementation). When I'm using C++ (which I don't any more) I tend to fall
back to C habits. At least with C# I start out thinking in terms of
classes. But my soapbox gripe was just how easy it was to do things in a
poor way (tight coupling, etc) with C#.

[Ian Semmel]

James Park wrote:

"Ian Semmel" <is***********@NOKUNKrocketcomp.com.au> wrote in message
news:OU**************@TK2MSFTNGP05.phx.gbl...

I think programmers who have come through the path of C++ (or another
native language) appreciate many of the features of C#.

However, I think that anyone who learns programming in C#, would find it
almost impossible to start programming in C++.

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

C# encourages unstructured programs.

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.

"Jon Davis" <jo*@REMOVE.ME.PLEASE.jondavis.net> wrote in message
news:eu**************@TK2MSFTNGP02.phx.gbl...I think we'll have to simply agree to disagree, Kevin. Again, we're not
dealing with bricks, and the analogy does not fit.

Driving a car is likelier to fit. VBScript is like driving a bus. It takes
a lot of effort to drive safely in a bus, and just climbing into the
cockpit feels like you're toying with an oversized weapon. C# is more
likely a Mercedes-Benz. It has safety features and gadgets that help you
stay safe. Both cars enable you to drive on the wrong side of the road,
and indeed the Mercedes is in some ways more dangerous depending on
whether the driver respects the rules of the road, etc., because it can
drive much faster. However, I would still feel much safer in a Mercedes,
because it doesn't make you feel like you're endangering yourself and
everyone else around you as soon as you sit down in the driver's seat.

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.

Jon

[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 Davis" <jo*@REMOVE.ME.PLEASE.jondavis.net> wrote in message
news:e1**************@TK2MSFTNGP03.phx.gbl...
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:Ou**************@TK2MSFTNGP02.phx.gbl...

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

[Jon Skeet [C# MVP]]

Ian Semmel <is***********@NOKUNKrocketcomp.com.au> wrote:

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.

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

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too