.NET SUCKS --- READ FOLLOWING. MICROSOFT IS A SUCKY CO

[Kevin Spencer]

To me the real issue around GC is that in heavy load situations is that

it bogs down to the point of bringing the system to a crawl. .Net 2005
may easy this some, I haven't had a chance to test it there.

But from what I've seen the current 2003 version's generational GC
system just doesn't cut it in high memory load situations. The ADO
libraries seem to call GC way to frequently as well which adds to the
problem.

Garbage Collection is not an excuse for poor memory management. However,
there are quite a few poor programmers out there, people who expect
Microsoft to do all the work of writing their programs for them, from cradle
to grave.

The .Net platform has many levels of development, from high-level classes
which work like Swiss Army knives (and are about as large compared to a
smaller tool as a Swiss Army Knife is compared to a kitchen knife) to
low-level unmanaged coding capabilities, and the ability to make Windows API
calls, use pointers, and everything that can be done in a "traditional"
programming platform, e.g. C++. A good developer is aware of the
environment, and manages memory well, rather than relying on Microsoft to
handle whatever he/she throws at them.

One excellent example is the use of strings. Yes, strings are managed.
De-reference one and it will be de-allocated at some point in the near
future. But why on earth would Microsoft have created the StringBuilder
class if it wasn't necessary to use one from time to time? Under the hood, a
string is still an immutable array of char. So, concatenating a string to
another string does 3 things, behind the scenes:

1. A new char array is created, allocating the size of both strings
combined.
2. The 2 source strings are read into the new array.
3. The 2 source arrays are discarded.

In other words, the amount of memory consumed by concatenating 2 strings is
temporarily twice the size of the 2 strings combined. Imagine the amount of
memory consumed by an application that does a lot of this! And, sadly,
because many "professional" programmers know very little about what is
happening inside their app, this particular scenario is played out over and
over again. I have even seen posts about the system running out of memory
due to this sort of poor practice.

A good developer educates him/her self about what is going on "under the
hood," and takes responsibility for managing memory, processor, and other
system resources. The purpose of Garbage Collection is to prevent memory
leaks, nothing more. It is not a panacea for sloppy programming.

The apps I write are fast and efficient. And I write nothing but .Net apps.


--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
I'd rather be a hammer than a nail.

 

[Tyrant Mikey]

IMHO, sacrificing COM for managed code is a good thing. COM sarted out
as a wonderful thing, but grew to be a nightmare. I, for one, am not
sorry to see it go the way of the dodo.

 

[CT]

Well, you might not be, but millions of VB(A) programmers potentially are.
Don't get me wrong, VB .NET is great, but it's a new tool, and support of
VB6 dying out...

 

[Guest]

Solid application design requires a logical, systems oriented approach to
development. Perhaps if you weren't so loaded with emotion and anti
Microsoft sentiment you could determine the actual reasons for your
application not meeting its requirement definitions rather than spouting off
like a trantrum throwing child.

Actually I found his childish rantings to be quite entertaining. It
certainly gave me a few chuckles.

But on a more serious note, since I am a lowly Junior Developer and utilize
these formus for learning experiences, I would like to echo what Mr. Loyd
Wrote

For example providing a code sample demonstrating your problem would be a
first step toward valuable & hinsightful feedback.

please do.

Timothy Brandt
Caliper Co.

 

[Will Chamberlain]

This thread can't die.

 

[Tyrant Mikey]

Actually, I still maintain VB6 code. Lots of it. And I can't wait for
it to be gone.

I don't mean to say or imply that anyone else MUST feel the same way
that I do. It's just my opinion, based on my own personal experience.
I'm glad .NET is here, and I'm glad it's being phased out here in my
shop. But I *am* intimately familiar with the reality that a HUGE
amount of code has to be maintained.

I hope Microsoft gradually phases out VB6 support, rather than
abruptly. But I do think that it needs to be done. Eventually the OSes
simply won't support it; that's just Microsoft's way. Here's hoping
that they give you plenty of time to migrate your systems to the new
platform, without leaving you stranded with unsupported technology.

That said, I do strongly believe that it's in everyone's best interests
to get on the .NET bandwagon as soon as is feasible for them. Microsoft
isn't going to support it forever, and they're not about to make it
open source or sell it to a 3rd party.

 

[Damien]

Actually, I still maintain VB6 code. Lots of it. And I can't wait for
it to be gone.

I don't mean to say or imply that anyone else MUST feel the same way
that I do. It's just my opinion, based on my own personal experience.
I'm glad .NET is here, and I'm glad it's being phased out here in my
shop. But I *am* intimately familiar with the reality that a HUGE
amount of code has to be maintained.

I feel physical pain whenever I have to fire up the VB6 IDE.
Unfortunately, our largest system is written in VB6, and it's going to
take a long time to shift it to .NET (especially since, because of the
limitations of VB6, the whole GUI is in a huge monolythic project). I
expect we'll finally be done with VB6 in about 4 or 5 years time...

I hope Microsoft gradually phases out VB6 support, rather than
abruptly. But I do think that it needs to be done. Eventually the OSes
simply won't support it; that's just Microsoft's way. Here's hoping
that they give you plenty of time to migrate your systems to the new
platform, without leaving you stranded with unsupported technology.

Hasn't VB6 already fallen out of support? Seem to remember something
around about March this year?

Damien

 

[Guest]

Well...

I am pretty sure you have somthing else which is taking enough time to
execute rather than GC.
If you dont know what you are doing, just dont blame .NET.
One cant choose COBOL for writing a compiler and start blaming COBOL for its
inefficiency...!

 

[Guest]

Who would use an interpreted language for real time processing? Doesn't
sound like someone knew what they were doing when they chose a language
to meet their requirements.

You shouldn't use .NET for this type of thing... you C or C++ or some
other language that you control every aspect of the language.

Microsoft said when releasing C#, tat C# is as easy as visual basic yet
powerfull as C++. But, if C++ is to be used for stuff tat C# can't do...
wat's the point of introducing C# when, c# suckier than c++?

 

[Kevin Spencer]

Microsoft said when releasing C#, tat C# is as easy as visual basic yet

powerfull as C++. But, if C++ is to be used for stuff tat C# can't do...
wat's the point of introducing C# when, c# suckier than c++?

First, Chris is mistaken. C# is as powerful as C++, if you know how to use
it. And, in fact, you can use C++ and C, and even Assembler with C# any time
you need to (and I have done this myself, so I know what I'm talking about).

Second, "suckier" is a characterization, not an argument. It means nothing,
other than implying that you have a negative opinion of it. If you are a
programmer, you should know the difference between logic and rhetoric. If
you do not know the difference, you are a "sucky" programmer.

Third, the .Net platform, like any other software, was developed to fulfill
certain requirements. It fulfills them beautifully. Among these requirements
are cross-platform compatibilty, cross-language compatibility, better
avoidance of memory leaks in complex applications, and productivity.

The cross-platform compatibilty aspect is achieved in the same way that Java
achieves it: The software is compiled to a byte code that is
non-machine-specific, and compiled to native machine language at runtime.
However, this introduces a latency in run-time compilation, which has been a
long-time problem with Java. The .Net platform minimizes this by a
sophisticated caching mechanism, which makes it run faster than Java
overall. The proof that the .Net platform is cross-platform-compatible can
be seen in the Mono project (http://www.mono-project.com/Main_Page), which
is an open-source project for a number of different OS versions of the .Net
platform.

Cross-language compatibility is one thing Java has never had. This enables
developers to write .Net code in virtually any language of their choosing.
There are more .Net languages than there are for any other platform. Period.

Avoidance of memory leaks is achieved primarily through Garbage Collection.
While you seem to think that Garbage Collection is a bad thing, it happens
to be quite common to object-oriented technologies, including Java, Perl,
Lisp, Smalltalk, Flash MX, and quite a few others (see
http://www.memorymanagement.org/articles/lang.html for a more complete, but
not comprehensive list). Comparing apples to apples, the .Net platform
employs the most up-to-date, fastest, and most powerful Garbage Collection
available today. No other technology that uses GC has the quality that the
..Net platform has. You may benefit from reading the following FAQ about
Garbage Collection: http://www.iecc.com/gclist/GC-faq.html. You can find
much more complete information about the subject at
http://www.memorymanagement.org/.

Productivity is the final point I wish to discuss, as you think that C# is
"suckier than c++". C# is designed along the same lines, and to fulfill the
same requirements as C++, and C before that. It is concise. It is
strongly-typed. And it is easier to use than C++, with a more concise
syntax. It includes constructs that are designed to enable the developer to
spend less time writing code, which enhances productivity, such as
NameSpaces, Attributes, delegates, and so on. In addition, the .Net 2.0
platform introduces several new constructs, the most notable is Generics. C#
is less cryptic than C++ as well. It is important to note that C++ is over
10 years old, and was developed as one of the first object-oriented
languages. Programming has come a long way since then, and programming
languages and technologies have had to adapt. Fortunately, C is extensible.
And while the extension of C known as C++ was a good start, 10 or so years
ago, C# is the next logical extension of C, enabling programmers to write
much larger applications in a much shorter time.

The bottom line of all this is, ignorance may be bliss, but it doesn't pay
the bills. You sound like a young, lazy guy who doesn't want to learn and
adapt. Well, I'm almost 50, and I hope I never stop learning. Knowledge is
power. Yes, it's work, but if you don't like work, you shouldn't be a
programmer. If you don't enjoy solving new problems, you won't get far in
this business. And if you don't love programming, don't quit your day job.
Real-world programming is a pain in the butt, but it's a love-hate
relationship for those of us who are successful at it, and I wouldn't do
anything else if I had the chance. Yes, you bleed a bit on the cutting edge,
but what a view!

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Big things are made up of
lots of little things.

 

[Tyrant Mikey]

That doesn't mean that C# is a bad language or that it's less powerful
than C++. I'd actually argue that C# is just as powerful, but far more
productive.

What makes software written in C# unsuitable for "real time
applications" isn't the language--it's the platform. .NET is not a
platform suitable for developing real-time applications.

As for why they did that with C#? Well, first off, C# is far more
NATIVELY object-oriented than C++. Originally, C++ was an extension of
C, and came with lots of baggage from C (manual memory allocation and
cleanup, for one). C# is a brand new language, designed from the ground
up to be object-oriented. It isn't an existing language that had
object-oriented features strapped on top of it. Its primary similarity
to C and C++ is the syntax, but that's about it.

Also, you have to place all this stuff in its proper context.
Conspiracy theorists might somewhat justifiably draw the conclusion
that Microsoft developed C# because it got slapped on the wrists for
messing with Java. When designing C#, Microsoft didn't have to abide by
Sun's rules about what it could and could not add to the language. So
they built an entirely new language, designed to be object-oriented
from the ground up, using C-style syntax, but incorporating many of the
features that made VB such a productivity boon. The pervasive
familiarity with the C-style syntax makes it appealing to a *very*
broad number of users (C, C++, and Java programmers at the least),
while the productivity enhancements from VB make it likely that many VB
developers will take a look at it.

I think that if I was Billy Boy, I'd see that as a really good thing,
and more than enough justification for creating the language. And then,
I could look like a really good guy if I made them standards.

 

[Guest]

I admit that I'm not a fan of Microsoft and Microsoft Products. I use Linux
for my software development, and only test on Windows for the Windows bugs
that may affect my software. Personally, I try to avoid using the .Net API
wherever possible as I do not trust the inherent security and/or protocols,
nor do I trust the low number of confirmed vulnerabilities I have seen.

However, that stated and out of the way, I do feel that Microsoft .Net can
be a very useful and powerful API. I've looked into it a little, and some of
the features I have seen include native support for "web services" (other
wise known as SOAP calls), changing the C++ API from MFC (with everything in
the global namespace) to using a very direct and clean namespace system
(which can make code easier to read, but sometimes can make it more confusing
when you're dealing with a half of dozen namespaces).

I also know that some of the new Microsoft products, such as Great Plains,
MS SQL Server 2005, MS Office, and many more, I'm sure, speak natively to
..Net, which can allow for easier writing of extensions with out hanging
yourself in source code.

So, in short, .Net does not truly "suck." However it is not the correct
application program interface for all scenarios.

And that's my 2 cents.

~Michael
Cross-platform developer

 

[Kevin Spencer]

What makes software written in C# unsuitable for "real time

applications" isn't the language--it's the platform. .NET is not a
platform suitable for developing real-time applications.

That statement just flies in the face of statistical fact. And personal
experience.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Big things are made up of
lots of little things.

 

[Lloyd Dupont]

Nice test Kevin!

 

[Guest]

Want a real time response, revert back to on of the RTOS (do you know what is
that means?!!) Windows is not RTOS.
If you don’t know how to use one and write Assembly code; If you don’t know
how to use serial port to communicate any non-time critical data from an
embedded system back to a Windows or Linux platform then don’t blame the MS
for your idiotic skills set and go learn something.

It seems like every one here was polite enough not to say it back to you but
YOU ARE SUCK

 

[Jon Skeet [C# MVP]]

That statement just flies in the face of statistical fact. And personal
experience.

What statistical fact are you talking about? What *exactly* do you mean
by real-time applications? I suspect you're not thinking of the same
kind of thing as I am and some other posters are, in terms of
*guaranteed* response times etc.

It's not just .NET either - Windows itself is simply not a real-time
operating system.

 

[Kevin Spencer]

Sorry Jon. I misunderstood your use of "real-time." You are, of course,
correct.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Big things are made up of
lots of little things.

 

[Tyrant Mikey]

For the record, by "real-time application" I meant things like
high-speed device drivers and software that must process hundreds or
thousands of transactions per second *without exception.* (Things like
flight control systems and medical devices are good examples.) In my
experience, and given what I know about preemptive multitasking, that
kind of a guarantee can't be obtained using Windows and the .NET
framework, because your application's slice of the clock depends on how
many threads are running, their priority, and what they're doing. You
don't have enough low-level control to guarantee that you can do what
you want in the timeframe that your requirements demand.

So far, however, .NET applications are more than fast enough for
everything I've needed to do; any performance problems I've encountered
have always tended to be something I could have coded better (and
fixed, once I saw them).

 

[Jon Skeet [C# MVP]]

For the record, by "real-time application" I meant things like
high-speed device drivers and software that must process hundreds or
thousands of transactions per second *without exception.* (Things like
flight control systems and medical devices are good examples.) In my
experience, and given what I know about preemptive multitasking, that
kind of a guarantee can't be obtained using Windows and the .NET
framework, because your application's slice of the clock depends on how
many threads are running, their priority, and what they're doing. You
don't have enough low-level control to guarantee that you can do what
you want in the timeframe that your requirements demand.

So far, however, .NET applications are more than fast enough for
everything I've needed to do; any performance problems I've encountered
have always tended to be something I could have coded better (and
fixed, once I saw them).

That's probably the best summary we've had in the whole thread. Bravo!

 

[Guest]

[.....]
Let me tell you a scenario and you will see what I mean.
There is a large application that has communication with a real time
system . The app has to respond to the requests in no more than 1 s.
The app is a C# .NET app and everything is fine and everyone at
Microsoft is happy that they forced their "new" platform down someone's
throat.

Now imagine a scenario where the GC has to collect the memory. Well,
when GC runs all the threads are suspended and there is no response to
the incoming requests and application fails a critical requirement.

[.....]

[.....]

Solid application design requires a logical, systems oriented approach to
development. Perhaps if you weren't so loaded with emotion and anti
Microsoft sentiment you could determine the actual reasons for your
application not meeting its requirement definitions rather than spouting off
like a trantrum throwing child.

It might well be that the .NET framework is not for your project but more
often than not these crys of it being a buggy, unreliable, non performant
platform are in fact more indicative of piss poor application design and/or
development lacking in a "best practises" approach.
[.....]

Yes quite, this sounds like bad work. Its also true that the original post
was lacking in decorum. ......Anyway.....Before jumping to conclusions you
need to specify what "has to", in "The app has to respond to the requests in
no more than 1 s." really means. Will your reactor melt down? what / how
much does downtime cost you? is this system 365/24/7 or just in bursts? Are
thes systems distributed? (how?) Loads and loads of
stuff.......haha!......All these are crtical questions to the initial rather
loaded posting.

..NET C# still might not be the best choice in this mythical system. Code
will inevitably be more platform bound than with skilfull C/C++ or Java. Java
offers comparable levels of programming safety built in to the language, also
syntactic ease and simplicity.........but commercially available Java
development tools / IDEs excel over Microsofts Visual Studio and you get a
cross platform product.

As to if it had to and was only ever going to run on windows...blah bah...
and it had to be real time .....then you could conceivably run this C# code
with managed memory et al resources in a process / that did not get
interrupted by long calls to GC.collect().....reuse resources.....don't
create and destroy thousands of String things read from XML files accessed on
a network drive in Hong Kong via a VPN ....blah......blah.


If ......which is hopefully the case....this compnent is in fact some kind
of client or client service. .......quite likely it would be very nice to get
a smooth throughput....and you can do a lot to get that .....in the case of
the client service the critical thing is that the component is robust
generally over time and scaleable. To my mind the combination of "scaleable"
and "robust" means its worth considering that your component be deployable
seamlessly accross many platforms. In a really critical system it would be
nice in the event of a serious security hazzard on a particular platform to
simply shut it down until the heats off.

In the case of the client aka...some sort of GUI stuff.. I would avoid .NET
C# really because of vendor lockin. Most of us in our businesses have huge
software systems and fundamental in ensuring the ability to choose the
highest quality component over the long term is the ability to be able to
remove and replace a component so that the other parts of the system continue
to interoperate with the new chosen application / component.

Have you got humongous ammounts of data to deal with? Didn't they manage to
do some kind of Quake thing in managed code......sounds like you can get some
degree of smooth throughput. I just stumbled on this while I was downloading
the stuff needed to play with Half Life 2....looks like that is in C++ rather
than in C#.

If this .NET thing is actually doing data acquisition / storage then, back
to "has to.....1s".....how critical is it? If you had some sort of
application health monitoring / recovery procedure there may be loads of
situations it'd do the job. Of course you'd think that no one in their right
mind would run vital real time systems where the reliability of one or more
critical components was bound to a Windows platform - though I heard a story
a few years back that the British Navy were looking at moving to a W2K based
system on their bridges - dunno what came to that one.