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

  • Thread starter Thread starter consumer62000
  • Start date Start date
..Net isn't bad. The GC can be easily manipulated to maintain state by making
your state as static member variables. The GC will not destroy static
variables and careful crafting of the "using" statement wil allow you to
"nearly" guarantee that objects you expect to see are available and ones that
need to be reset are. This is not to say that VB.Net 2.0 should be used for a
mission critical real time system, but .Net does give you access to Win32
through PInvoke and COM interop through EnterpriseServices, so it is
definitely a step in the right direction.
 
(e-mail address removed)- A tip: Don't speak up at your meetings as your boss
might finally realize you're an idiot. This may be over your head, but
probably more your speed...
10 FOR I = 1 TO 10
20 PRINT "(e-mail address removed) is a HACK.";
30 NEXT I
40 GOTO 10

.... Now do us all a favor, stop clogging the internet, stop making our
profession look stupid, and go back to delivering pizza.

Regards
Coleman
A professional developer.
 
Tyrant Mikey said:
Never underestimate the power of mass stupidity. When you think people
can't be stupid in vast numbers, just look back on the 2004 elections.

I agree. By all that is holy, tens of millions of people actually voted for
Kerry!

Now to the topic, before things get ugly.

I am a physicist by trade. I have found plenty of things about .NET that I
don't like. For one thing, it has no native support for complex numbers, the
native math library is pretty sparse, and worse yet, generics are not well
suited for use in high speed arithmatic, which could likely have been easily
fixed.

For all my ranting about such things at times, I am quite capable of
realizing (when I'm not throwing one of my Bill Doesn't love me enough
tantrums) that .NET wasn't designed specifically to suit whatever needs I
might come up with. No, Bill wan't thinking just about me. He was thinking
about other people. There are, after all, a few people in the world who might
not develop software that needs to do a lot of bessel function calculations
with complex numbers. Just like there are probably a couple people in the
world who write software that doesn't have exacting real time requirements.

So here's my advice for others, who like me, on occasion, get bothered
because the whole Microsoft universe does not revolve aound them. Do what I
do.

When I need to use complex arithmetic without knowing beforehand if I need
doubles, reals, or whatever, I start by throwing my tantrum. I have a nice
blanket on the floor in a clear area, with no hard pointed objects that I
might injure myself on. I can lie down there, and safely kick and scream for
an hour or two. Then i sit up, take a deep breath, and try to actually
concieve the thought that the world does not revolve around me. The final
step is to write some code in native C++, using a template and the complex
math library, to do my math, that I can then call from managed code.

There is nothing wrong with a screw driver manufacturer suggesting that
hammers might actually work better with nails.
 
I am a physicist by trade. I have found plenty of things about .NET that I
don't like. .......
I can lie down there, and safely kick and scream for
an hour or two. ......
try to actually
concieve the thought that the world does not revolve around me.
Funny interesting post here ;-)
 
Hi PDHB,

Not sure what you mean by "native support" for complex numbers, but I have
written an app or 2 that uses complex numbers, and even a class for working
with complex numbers. The class is a sort of "catch-all," as I prefer to
dispense with the overhead in most cases, and just do the math myself.
Still, manipulating complex numbers isn't a whole lot more difficult than
working with real numbers

For example, I did a Mandelbrot Set visualizer awhile back. Here's the code:

public enum ColorScheme : int
{
DefaultGradient = 0,
GrayScale = 1
}

public struct Settings
{
public int Width;
public int Height;
public double MinX;
public double MaxX;
public double MinY;
public double MaxY;
public int MaxIterations;
public Fractal.ColorScheme ColorScheme;

public Settings(int w, int h)
{
Width = w;
Height = h;
MinX = -2.25d;
MaxX = 0.75d;
MinY = -1.5d;
MaxY = 1.5d;
MaxIterations = 2048;
ColorScheme = ColorScheme.DefaultGradient;
}

public Settings(int w, int h, double mnx, double mxx,
double mny, double mxy, int maxit)
{
Width = w;
Height = h;
MinX = mnx;
MaxX = mxx;
MinY = mny;
MaxY = mxy;
MaxIterations = maxit;
ColorScheme = ColorScheme.DefaultGradient;
}
}


/// <summary>
/// Class for visualizing the Mandelbrot set
/// </summary>
public class MandelbrotSet
{
private int _MaxIterations = 500;
private System.Drawing.Color _SetColor = System.Drawing.Color.Black;
public System.Drawing.Color SetColor
{
get
{
return _SetColor;
}
set
{
_SetColor = value;
}
}

public event ProgressArgsEventHandler ImageProgress;

public Settings Settings;

public Bitmap CreateImage()
{
Bitmap b = null;
int stride;
BitmapData bmData;
System.IntPtr Scan0;

try
{
b = new Bitmap(Settings.Width, Settings.Height,
PixelFormat.Format24bppRgb);
bmData = b.LockBits(new Rectangle(0,0, Settings.Width, Settings.Height),
ImageLockMode.WriteOnly, b.PixelFormat);
stride = bmData.Stride;
Scan0 = bmData.Scan0;
unsafe
{
byte * p = (byte *)(void *)Scan0;

int nOffset = stride - Settings.Width*3;
int nWidth = Settings.Width * 3;

for(int y=0;y<Settings.Height;++y)
{
for(int x=0; x < Settings.Width; ++x )
{
// Calculate color for this pixel
System.Drawing.Color c = ResolveZ(GetComplexCoord(x,y));
p[0] = c.B; // Reverse byte order in bmp
p[1] = c.G;
p[2] = c.R;
p += 3;
}
if (ImageProgress != null)
ImageProgress(this, new ProgressArgs(y, Settings.Height));
p += nOffset;
}
}

b.UnlockBits(bmData);
return b;
}
catch (Exception ex)
{
Utilities.HandleError(ex);
throw(ex);
}
}

/// <summary>
/// Gets the Complex Coordinate values of an xy coordinate in the image
/// </summary>
/// <param name="x">x coordinate in the image</param>
/// <param name="y">y coordinate in the image</param>
/// <returns>Complex Coordinate at that point</returns>
public Complex GetComplexCoord(int x, int y)
{
double xdist = Settings.MaxX - Settings.MinX; // distance between
MinRx and MaxRx
double ydist = Settings.MaxY - Settings.MinY; // distance between
MinIy and MaxIy
double xratio = (double)Settings.Width / xdist; // distance per pixel
double yratio = (double)Settings.Height / ydist; // distance per pixel
double real = Settings.MinX + ((double)x / xratio);
double imaginary = Settings.MaxY - ((double)y / yratio); // Reverse from
bottom to top
return new Complex(real, imaginary);
}

public System.Drawing.Color ResolveZ(Complex C)
{
return ResolveZ(C, new Complex(0,0), 0);
}

public System.Drawing.Color ResolveZ(Complex C, Complex Z, int iteration)
{
if (iteration == Settings.MaxIterations)
return _SetColor;
int interval = (int)(Settings.MaxIterations / 12);
// Zn + 1 = ZnSquared + C
double real = (Z.real * Z.real) - (Z.imaginary * Z.imaginary) + C.real;
double imaginary = 2 * Z.real * Z.imaginary + C.imaginary;
Complex resultZ = new Complex(real, imaginary);

if ( 4 < ((Z.real * Z.real) + (Z.imaginary * Z.imaginary)))
{
switch(Settings.ColorScheme)
{
case ColorScheme.DefaultGradient:
if (iteration < 64) // Interval = 1 (0 to 64) (64 its)
return System.Drawing.Color.FromArgb(0,0, 64 + (iteration * 3));
else if (iteration < 320) // Interval = 5 (64 to 320) (256 its)
return System.Drawing.Color.FromArgb(iteration - 64, 0, 255);
else if(iteration < 512) // Interval = 8 (320 to 512) (128 its)
return System.Drawing.Color.FromArgb(255,
iteration - 320, 512 - iteration);
else if(iteration < 640) // Interval = 10 (512 to 640) (128 its)
return System.Drawing.Color.FromArgb(255,
iteration - 384, 640 - iteration);
else if (iteration < 768) // Iteration = 12 (640 to 768) (128 its)
return System.Drawing.Color.FromArgb(255, 255, (iteration - 640) *
2);
else
return System.Drawing.Color.White;
case ColorScheme.GrayScale:
double ratio = (double)Settings.MaxIterations/192d;
int i = (int)(((double)iteration / ratio)) + 64;
return System.Drawing.Color.FromArgb(i, i, i);
}
}
return ResolveZ(C, resultZ, iteration + 1);
}

public MandelbrotSet()
{
Settings = new Settings(400, 400);
}

public MandelbrotSet(int width, int height, double minrx,
double maxrx, double miniy, double maxiy)
{
Settings = new Settings(width, height, minrx, maxrx, miniy, maxiy, 2048);
}
}

BTW, you can find quite a bit in the Microsoft Managed DirectX class
libraries as well.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Big things are made up of
lots of little things.
 
Jon Skeet said:
When I'm developing in Java, I develop much faster, even
though the language occasionally constrains me (in terms of lack of
events and properties). Then again, in C# I miss the Java-style
enums...

Java style enums? Are you talking about the pattern from Effective Java
(#21)? You could do that same thing in C#, although since C# supports enums
(which Java gets in 5.0) they seem to be equivalent in that way.

You're right about the IDEs - although Visual Studio with a third party
addin (that I can't mention or my post will be edited, but it's by a major
Java IDE vendor) goes a long way to making up the difference. And doesn't
eclipse support C# these days? Wouldn't that work better for you than using
Visual Studio?

When I'm in Java I miss having REAL properties, instead of the silly
getter/setters.
 
Chuck Wagner said:
Java style enums? Are you talking about the pattern from Effective Java
(#21)?

I can't remember off the top of my head what Effective Java recommends,
but Java enums are fully-fledged objects with methods which can be
overridden by some elements of the enum, etc.

They're also supported by the compiler to enable things like switching
on the values.
You could do that same thing in C#, although since C# supports enums
(which Java gets in 5.0) they seem to be equivalent in that way.

No, C# enums and Java enums are very, very different.
You're right about the IDEs - although Visual Studio with a third party
addin (that I can't mention or my post will be edited, but it's by a major
Java IDE vendor) goes a long way to making up the difference. And doesn't
eclipse support C# these days? Wouldn't that work better for you than using
Visual Studio?

No, Eclipse doesn't support C#. There's a plug-in which does syntax
highlighting and calls the command-line compiler, but that's about it.
It's a world away from being a properly supported language.
When I'm in Java I miss having REAL properties, instead of the silly
getter/setters.

Indeed. And events, and delegates.
 
Wonder who would consider communicating with real time system using Windows ?

Suppose Windows crashes, would you expect your real time system to blast ?

Huh..?

Looks like somebody who does not know what he is writing about...

Regards,
Maruthi
 
Hi,
It seem that by trying to use .NET for real time, we are trying to open a
nut with the help of a screwdriver. What I mean to say is .NET is not
designed for realtime applications. Its not the case of one size fits all. We
can't overlook all the great features of .NET on the behalf of the fact that
it doesn't support realtime apps.
The question asked "why did you create .NET then?" can be answered best by
thinking about the fact "Why at all high level programming languages were
developed? Was machine language not enough?"
I hope I am able to deliver my thoughts on this.
 
Technically Windows is not a realtime OS.
He should never rely that any Windows program will respond within 1 second,
if he does then he has a design error.
Look at Windows explorer, opening certain sites could take a long time and
it blocks execution of other programs during that time.

The GC might be a problem, especially in games, but in his case the solution
would be in that he creates a device driver that does not rely on .NET, and
that does respond to the request faster. Then the .NET program should
connect with that device driver.
It would be a selfish assumption that if you cannot create a real-time
program with .NET that no one else on the whole planet should be allowed to
use .NET. This .NET is a new technology that makes programming more fun, and
adds more security to the application.
 
Prem Kumar said:
Hi,

I am a software engineer in .net since 3 years

I am huge supporter of each and every tech. developed from microsoft


But ...

Mr Tim Wilson , you must accept that your this .net fantacy is not mean for
real time software . no matter how less time the GC takes

Beacuse for realtime applicatons the most bigges reqirement is that its main
thread must not be paused at any cause , but this is the frequent case in
any application developed using .net framework

U should accept that Microsoft is not really concetrating to produce a
really good programming platform.

they are just doing like

"Handing over a toy to a crying child"

Thats why , even after the advent of .net (5 yeast elapsed) they could not
beat the Java in market.

Event i am strongly attached with Microsoft and its technologies


Do reply me what do you think about this at


(e-mail address removed) ,
(e-mail address removed)

Prem Kumar
Associate software Engineer
Larsen & Toubro Infotech Limited
Navi Mumbai
Vashi
India
 
Prem Kumar said:
Hi,

I am a software engineer in .net since 3 years

I am huge supporter of each and every tech. developed from microsoft


But ...

Mr Tim Wilson , you must accept that your this .net fantacy is not mean for
real time software . no matter how less time the GC takes

Beacuse for realtime applicatons the most bigges reqirement is that its main
thread must not be paused at any cause , but this is the frequent case in
any application developed using .net framework

U should accept that Microsoft is not really concetrating to produce a
really good programming platform.

they are just doing like

"Handing over a toy to a crying child"

Thats why , even after the advent of .net (5 yeast elapsed) they could not
beat the Java in market.

Event i am strongly attached with Microsoft and its technologies


Do reply me what do you think about this at


(e-mail address removed) ,
(e-mail address removed)

Prem Kumar
Associate software Engineer
Larsen & Toubro Infotech Limited
Navi Mumbai
Vashi
India
 
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.

Yes, you are right.
Well,any MS people here who can defend their sucky product,
I know they will say "don't use .NET for this or that...use C or C++
etc"
My q to them is why did you create .NET then?

Microsoft tell us that you can use .NET for *everything*, but they use
it for very few of their products. That's a clue.

Basically, you should use it for code where the GC will not have a
detrimental affect. GUI apps generally are fine, because they spend the
majority of their time waiting for user input. Web apps are fine because
you can blame bad performance on the network (<g>).

Don't use .NET for services because services have privileged access to
the OS and so you don't want such code to suddenly suspend itself.

It's a pity Microsoft does not tell the truth about such things.

Richard
 
Jon said:
Um, how exactly do you propose to use the Disposable pattern to free
memory? Calling Dispose doesn't free memory, it just allows an object
to clean itself up.

As far as I know there's no way of explicitly freeing memory in .NET -
at least not in C#.

Application.Exit()

<g>

Richard
 
Chris said:
Who would use an interpreted language for real time processing?

..NET is not interpreted. The IL code is JIT compiled on a per method
basis at runtime, once a method is JIT compiled the machine code will be
called every time the method is called.
Doesn't sound like someone knew what they were doing when they chose
a language to meet their requirements.

What do you mean? .NET is not a language it is a runtime.
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.

Indeed.

Richard
 
Kevin said:
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).

No. Platform Invoke is not the same as being able to use inline assembly
code like many C++ compilers can do. So I refute your arguement that C#
is as powerful as C++. However, C# is better because it does not have
all of the complicated 'power features' of C++.
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.

It depends on who you ask. I think Microsoft's requirements for what it
wanted .NET to do has changed considerably over the last 5 years (in
fact I *know* so). I guess it fills your requirements, and that is fine.
However, it would be nice if Microsoft would make public what their
requirements are. They won't.
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

Nope. .NET is not cross platform and Microsoft have never claimed it to
be.
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.

So what? This does not mean that it is cross platform - it is not the
official .NET product. The official Microsoft .NET product is not cross
platform. Try and run an assembly written for the desktop on a PDA with
the .NET compact Framework and you'll see that is the case.
Avoidance of memory leaks is achieved primarily through Garbage
Collection. While you seem to think that Garbage Collection is a bad

<sigh> you've not been following the conversation. The problem is that
the .NET heap is memory hungry and the GC nmechanism is processor
hungry.
And it is easier to use than C++, with
a more concise syntax.

Yup, I agree. But bear in mind that VB6 was also easier to use than C++
;-)

Richard
 
<DISCLAIMER>This is not a flame or an argument for the sake of arguing!
I know that sometimes my posts come off that way, so I'd like to clear
it up now.</DISCLAIMER>
Kevin Spencer wrote: [snip]
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.

It depends on who you ask. I think Microsoft's requirements for what it
wanted .NET to do has changed considerably over the last 5 years (in
fact I *know* so). I guess it fills your requirements, and that is fine.
However, it would be nice if Microsoft would make public what their
requirements are. They won't.

You *know* so? How? What information sources do you have that we do
not? Can you please post them so we can be equally as informed? Thanks.

Don't get me wrong. I'm fairly certain myself that their requirements
for it have evolved (but perhaps not *changed* altogether). But I
wouldn't tell anyone that I *knew* something without being able to back
it up with facts.
Nope. .NET is not cross platform and Microsoft have never claimed it to
be.

I'm sorry, but I have to disagree with that point. The shared source
CLI (available at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/faq111700.asp)
compiles and runs on Windows and FreeBSD.
From the referenced Microsoft page:

The Microsoft® Shared Source CLI Implementation is a file archive
containing working source code for the ECMA-334 (C#) and ECMA-335
(Common Language Infrastructure, or CLI) standards. These standards
together represent a substantial subset of what is available in the
Microsoft .NET Framework. In addition to the CLI implementation and the
C# compiler, the Shared Source CLI Implementation contains a cornucopia
of tools, utilities, additional Framework classes, and samples. It will
build and run on the Microsoft Windows® XP and the FreeBSD operating
systems.

According to WikiPedia:

FreeBSD is a free, open source, Unix-like operating system descended
from AT&T UNIX via the Berkeley Software Distribution (BSD) branch
through 386BSD and 4.4BSD. It runs on processors compatible with the
Intel x86 family, as well as on the DEC Alpha, the UltraSPARC
processors by Sun Microsystems, the Itanium (IA-64) and AMD64
processors. It also runs on the PC-98 architecture. Support for the
ARM, MIPS and PowerPC architectures are in development.

Sounds fairly cross-platform to me. But that may depend on what you
mean by PLATFORM. To me, it means a different CPU or operating system.
Again, it's that whole issue of getting two geeks to agree on what a
word means.

<CONJECTURE>
Despite its small share of the desktop computer market, Microsoft has
continued to dump lots of money into the development of software for
Apple computers (which are (1) now running Unix [the core of OSX] and
(2) soon coming to Intel chips). It would be far more economical for
Microsoft to be able to write one codebase for Office and deploy it to
both operating systems without having to recompile.

Just something to think about.
So what? This does not mean that it is cross platform - it is not the
official .NET product. The official Microsoft .NET product is not cross
platform.
Oh, now that's just splitting hairs. :) .NET is a platform, not a set
of binaries. Further, it is an open standard, and you can obtain the
source from Microsoft itself.

Now brace yourselves for this: .NET itself is not Microsoft .NET.
Microsoft .NET is Microsoft's implementation of the .NET standard (the
CLI and the BCL). It is conceivable that one day there will be Apple
..NET, Google .NET, and so forth, each providing an implementation of
the .NET standard that differs internally from Microsoft's
implementation. While that's conjecture at this point, you *can*, in
fact look at Mono for a perfect example of it. Microsoft .NET is
Microsoft's implementation of the .NET standard; Mono is an open-source
implementation of .NET for several different operating systems and
CPUs.

So on the one hand, you're right. Microsoft .NET isn't platform
independent. But .NET itself is. It helps to keep them separate.
Try and run an assembly written for the desktop on a PDA with
the .NET compact Framework and you'll see that is the case.

Trying not to laugh out loud at this one. :)

Let's be realistic. You can't POSSIBLY expect to design an application
for a desktop whose minimum display size these days is 800x600 and
expect them to run on PDAs. Further, look at all the equipment you can
connect to a desktop that can't be connected to a PDA. And no one in
their right mind would constrain the design of a desktop application to
the constraints of a PDA application. That's not even CLOSE to being
realistic.

However, let's think about that. You still wrote the application in
..NET. You compiled it with the same tools. You used a set of classes
from specific namespaces, but who wouldn't? If every platform used the
same namespace and classes for its UI and functionality, you'd be right
back to the least common denominator scenario that generated those
hideous, terrifying, sluggish, loathesome interfaces common to Java
during the pre-Swing era. You can count me out on that one.
<sigh> you've not been following the conversation. The problem is that
the .NET heap is memory hungry and the GC nmechanism is processor
hungry.

Can you back that up with facts? Links? Statistical data? Under which
particular circumstances is it processor hungry?

I thought we had previously beat this to death and determined that it's
overally pretty darned sophisticated, and only gets processor hungry
when you do things with the specific intent of breaking it. (Someone
correct me if I'm wrong there.)
Yup, I agree. But bear in mind that VB6 was also easier to use than C++
;-)

Yup, I agree too. :)
 
.NET heap is memory hungry and the GC nmechanism is processor hungry.

I'm afraid YOU haven't been following the conversation. That message, and
all of the replies to it, and most of this thread, are over a week old. It's
ancient history, and I don't want to revisit it.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.
 
Back
Top