Is .net the Emperors New Clothes?

DublinWriter

Basically after installing what I'd consider to be the ultimate in bloatware - VS2006 - I'm firmly convinced that .net is the Emperors New Clothes.

Unlike the Java VM environment, we now have had several releases of .net runtime environment - 1, 1.1, 2.0 and now 3.0 with as many Service Packs as yer having yerself en-route.

This should come as no surprise to MS-watchers as they've changed their defacto data-access methods from ODBC, ADO then RDO and basically I lost count after that.

The whole MS platform is a change-control nightmare for anyone of us maintaining real-world mission-critical applications in a corporate environment. Who knows what feature or API call might not be supported or changed in future versions of MS products.

What exact benefit do we get by developing for .net instead of win32s? The ability to run programs remotely? We can already do that via Java and pure-web apps.

The kicker for me was that the latest version of the display drivers for my ATI graphics card needed .net 2.0 installed. I mean, WTF? And even after installing all the stated pre-requisites, the installation fails because of a call to an unsupported .net assembly (1,000's of very p*ssed off ATI customers are experiencing this issue now worldwide).

Yet, the corporate world slavishly moves to .net like sheep in a herd, many recompiling legacy VB6 apps under vb.net with much cost and very little gain.

Is it only me who thinks that the Emperor is naked?

Ginger

Well this shows some of your lack of understanding of the whole .net process (and I say this not to be insulting so please dont take it as such)

One of things with the whole .NET framework is when you produce a DLL for example you can use strong naming tand version numbers to produce a key against the DLL which will mean that if someone else uses it, as long as they have the correct key they will ensure that they will always use that DLL,

So if you decided to upgrade your app to use v1.1 of your DLL, you can install it into the GAC with its version info and key, you could have version 1.0 of your app and version 1.1 running side by side quite happily (apologies if I dont explain this bit too well!).

Once the framework is installed and you design against it correctly(!!!) versioning just works. Also there is tools like ClickOnce to deploy and install, code policy security checks, common runtime which solves a massive problem had before when you had devs developing in different language

In C++ an INT was an INT, for VB devs interacting with C++ (and SQL Server for that matter) an INT was a LONG. So where the definition required an INT datatype you hoped that your VB dev realised that they probably needed a LONG datatype. What the framework really helps, is the common datatypes. So that whatever language you write in, the datatypes remain the same.

I have designed and built quite a few mission critical systems in .NET and find it so much easier to get there, deployment and because I use a lot of web services/shared dlls in my code, if I find a critical bug in my systems, i can update either and the change is reflected throughout my apps.

If you use the Enterprise templates you can reduce the amount of code you need to write and also ensure some sort of code standards across your organisation.

While I have never coded in Java I seem to have to download more and more versions of the runtime every other month. I have something like 10 updates installed on this machine as is.

You can also design the whole .NET experience without needing any version of VS, provided you know the command lines. Its just easier with the IDE

AARRRGH

There are tons of .NET jobs. Definitely a real platform here to stay.

http://www.jobseeker.ie/jobs.php?k=.NET&l=&x=0&y=0

damnyanks

DublinWriter wrote: »

Basically after installing what I'd consider to be the ultimate in bloatware - VS2006 - I'm firmly convinced that .net is the Emperors New Clothes.

Unlike the Java VM environment, we now have had several releases of .net runtime environment - 1, 1.1, 2.0 and now 3.0 with as many Service Packs as yer having yerself en-route.

This should come as no surprise to MS-watchers as they've changed their defacto data-access methods from ODBC, ADO then RDO and basically I lost count after that.

The whole MS platform is a change-control nightmare for anyone of us maintaining real-world mission-critical applications in a corporate environment. Who knows what feature or API call might not be supported or changed in future versions of MS products.

What exact benefit do we get by developing for .net instead of win32s? The ability to run programs remotely? We can already do that via Java and pure-web apps.

The kicker for me was that the latest version of the display drivers for my ATI graphics card needed .net 2.0 installed. I mean, WTF? And even after installing all the stated pre-requisites, the installation fails because of a call to an unsupported .net assembly (1,000's of very p*ssed off ATI customers are experiencing this issue now worldwide).

Yet, the corporate world slavishly moves to .net like sheep in a herd, many recompiling legacy VB6 apps under vb.net with much cost and very little gain.

Is it only me who thinks that the Emperor is naked?

Don't be daft - lots of places use old versions of Java and can hit the same problems. We're still using 1.2 for our app's.

.Net 3 just sits on top of .Net 2 from what I'm told - just add's the new functionality (the various foundations). Big fan of visual studio and netbeans. I have 4gig of ram so rarely notice silly things such as bloat

Mutant_Fruit

damnyanks wrote: »

What exact benefit do we get by developing for .net instead of win32s? The ability to run programs remotely? We can already do that via Java and pure-web apps.

Type safety, leak proof code, massive class libraries which can be accessed at the click of a switch. Cross platform code with minimum effort?

The kicker for me was that the latest version of the display drivers for my ATI graphics card needed .net 2.0 installed. I mean, WTF? And even after installing all the stated pre-requisites, the installation fails because of a call to an unsupported .net assembly (1,000's of very p*ssed off ATI customers are experiencing this issue now worldwide).

The catalsyt control panel is written in C# as far as i know. I assume the problem is that ATI didn't test their code enough before releasing. Thats hardly a fault of .NET. If the thing was written in C and they forgot to release one of the required native libraries you'd have exactly the same problem - thousands of unhappy people with failed installs worldwide.

Unlike the Java VM environment, we now have had several releases of .net runtime environment - 1, 1.1, 2.0 and now 3.0 with as many Service Packs as yer having yerself en-route.

I may be wrong in this, but isn't java on version 6 now? .NET is only on version 3 (or 3.5 depending on how you look at it). I don't see the issue here.

Merrion

In my opinion 'LINQ' is a total revolution in the way we write software...a fine set of clothes for any emperor ;-)

Mutant_Fruit

Also, .NET has some advantages over java:

http://tirania.org/blog/archive/2007/Nov-21.html

Read it and weep java lovers!

ianhobo

But he didn't say how he measured it, and made no reference to any speed issues with the different methods.......

Mutant_Fruit

Erm... the exact code used for testing is there. It's quite obvious how it was tested. An array of some kind was created and 8 million int types were stored in that array the the amount of memory consumed by the application was checked. Of course, you might be wondering which measurement was used to decide how much memory was in use, i don't know. Either way, whatever measurement was used showed C# as using significantly less.

As for speed, that wasn't tested, you're right. But as the code for all three tests (c# no generics, c# with generics and java no generics) is there, you could do that benchmark yourself. I'd hazard a guess that C# with generics will prove to be faster.

Note, there's no point in benching java+generics because java generics are purely a compile time check (as the article also states).

Hobbes

Mutant_Fruit wrote: »

Also, .NET has some advantages over java:

http://tirania.org/blog/archive/2007/Nov-21.html

Read it and weep java lovers!

I am not sure what it is your supposed to weep. Generics is Compile-time. All it does is put in the casts for you in the related areas of code. So there is no difference in using Generics vs not using Generics when it comes to speed.

The reason he is getting huge amounts of code size is that he is autoboxing int primitives. He isn't storing an integer value, he is storing Integer objects which is wasteful. It is not even recommended in the JVM specification to use autoboxing in such a way. The reason being it would be a memory+performance bloat.

The reason Integer Objects are wasteful is because they contain code for manipulating integer values. This data is not needed to be stored if you are only storing values. Also Integer objects are immutable, so the value can't be changed without creating a new object or sending it back to an integer.

I am sure I could knock up the same half-assed bloated code in .NET then claim it is a failing of .NET, but this is more to do with the fact he can't code in Java.

Hobbes

As for the OP. Comparing apples to oranges imho.

marco_polo

Mutant_Fruit wrote: »

Also, .NET has some advantages over java:

http://tirania.org/blog/archive/2007/Nov-21.html

Read it and weep java lovers!

That looks a bit to me look a bit to me like the old argument that Internet Explorer had a smaller memory footprint than Firefox (using the simple criteria that IExplorer.exe process was smaller that the Firefox.exe process in the taskmanager, but omitting to mention that most of the IExplorer.exe memory footprint was tied up with in the Explorer.exe process).

I am no expert of the differences between C# and java and I haven't used C# before (not cause I have anything against it just don't work with it).

I thought that Mono will not nescessarly create a Wrapper object for an int unless you then try and use it like an object (this is a good thing), so it is not really like for like so to speak as the java code explicitly creates a Wrapper object.

I was also under the impression that the main advantage of .net generics was improved performance at the cost of a slightly larger memory overhead ( it generates completely seperate code for List<int>, List<Person> etc). So this test is somewhat flawed as he has only created one type of the generic collection.

It is true that C# generics is superior to the current Java implementation, but not for anthing remotely like the reasons the author has stated.

I not a fan of either java or .net fan boys TBH I find them laughable, they are just programming tools with different strengths and weaknesses. The important thing is to use the right tool for the right job.

Hobbes

marco_polo wrote: »

It has to be said that overall there is no doubt that C# generics is far superior to the current Java implementation.

From what I have read that is correct. As mentioned Generics is just a compiler command. So it would change

List<String> s = new ArrayList<String>(); 
s.add("test"); 
out.println(s.get(0));

to

List s = new ArrayList();
s.add("test");
out.println((String) s.get(0));

So it does the casting at compile time. Not deffo but afaik Java6 resolves this in the JVM.

fasty

Merrion wrote: »

In my opinion 'LINQ' is a total revolution in the way we write software...a fine set of clothes for any emperor ;-)

LINQ is made of win! That said, DotNet is a pretty excellent framework even without it. I've been using it since 2.0 so my experience of teething problems is limited. Coming from C++/MFC it's just such a great was to develop.

Mutant_Fruit

marco_polo wrote: »

I thought that Mono will not nescessarly create a Wrapper object for an int unless you then try and use it like an object

That's true. Both mono and MS.NET won't create the wrapper object unless you explicitly (or implicitly) treat your int as an 'object'. Thing is the non-generic code used in mono (which is the version that took 178 megabytes of ram inc. runtime overhead) is as follows:

// Copied and pasted directly from the blogpost
object [] e = new object [size];

		for (int i = 0; i < size; i++)
			e [i] = 1;

Note that this is an object array. Therefore you are explicitly treating ints as objects so you're generating wrapper objects.

In the generics version a generic array is created, which is for all intents and purposes a standard int[]. This version of the code uses 38 megabytes of ram inc runtime overhead.

You can see the benefit to using generics in this case. You get a fully type safe and efficient class with all the functionality of an arraylist except with the advantage that there's no boxing.

Running the exact same code in java results in 240 odd megs of ram being used. There is no way to get a fully type safe and efficient class with all the functionality of an arraylist in java unless you roll your own or accept that you'll have boxing.

I was also under the impression that the main advantage of .net generics was improved performance at the cost of a slightly larger memory overhead ( it generates completely seperate code for List<int>, List<Person> etc). So this test is somewhat flawed as he has only created one type of the generic collection.

The test was designed to only show one thing: the object wrapper overhead is significantly higher in java than in C#. Yes, if you have 100 different instantiations of List<T> for 100 different classes, you'll have 100 instantiations in memory. Java uses the same instantiation for all types. However, if you're dealing with value types, generics wins out by far.

I am sure I could knock up the same half-assed bloated code in .NET then claim it is a failing of .NET

See the first codeblock i pasted up above. This is the very same half-assed bloated code as the java version. It creates the very same wasteful object wrappers as the java version. The point is .NET's wasteful wrappers are smaller than java's wasteful wrappers. Bear in mind the C# object wrappers are also immutable. Java and C# are the same in that respect. If you want to change the value, you create a new wrapper. So it's just as inefficient to box value types in C# as it is in Java.

The only point of the above test and my 'read it and weep' comment was that java has high overhead if you have a value type in an ArrayList. There is only 1 way to get around this issue - you replicate the ArrayList logic and make a strongly typed version for each of your value types. This avoids all autoboxing. This is exactly what C# generics does. So what you can replicate by hand in java, C# does automagically for the exact same effect.

Other ways around the issue are:
1) Declare everything as a class - no wasteful wrappers generated then as nothing needs to be boxed
2) Keep all value types in standard array (int[], float[], mystruct[]) as opposed to ArrayLists. This means you need to handle array resizing yourself and all that jazz.

Both of these methods have drawbacks though.

Hobbes

Mutant_Fruit wrote: »

The point is .NET's wasteful wrappers are smaller than java's wasteful wrappers.

But your showing an example of bad coding in Java which JVM spec actually says you should not use autoboxing in that manner. So if someone is using that method then they are already not using Java correctly.

That was the point I was getting across, and why I said it is comparing apples to oranges.

professore

Mutant_Fruit wrote: »

Type safety, leak proof code, massive class libraries which can be accessed at the click of a switch. Cross platform code with minimum effort?

So .NET can run natively now on linux and unix with MS support - I don't think so Ted.

Hobbes

professore wrote: »

So .NET can run natively now on linux and unix with MS support - I don't think so Ted.

Is there not Mono? Anyway the point of web services is to have the platform/hardware independent of the actual application. So as long as .NET behaves to Web services standards it doesn't matter if it is a windows box or a linux box and that is where the industry will be going.

Ginger

Well actually yes.. The mono project is doing just that with MS backing (in a weird way)

http://www.mono-project.com/Supported_Platforms

Also MS has released the source code for the .NET libs as well.

Mutant_Fruit

Hobbes wrote: »

But your showing an example of bad coding in Java which JVM spec actually says you should not use autoboxing in that manner. So if someone is using that method then they are already not using Java correctly.

That was the point I was getting across, and why I said it is comparing apples to oranges.

It's still an apples to apples though. The C# spec also is quite clear that boxing isn't a good thing, especially in tight loops. The thing is, it's not always possible to avoid boxing, so the smaller the wrapper object the better. In short - c# generics offer a great way to get type safe non-boxing collections for value types, but java has no way to do that. If i want a non-boxing dictionary, i write: new Dictionary<int, float>. In java, i have to roll my own.

professore wrote: »

So .NET can run natively now on linux and unix with MS support - I don't think so Ted.

Oh but of course. However, the mono project doesn't actually have MS backing - except in the very specific case of Silverlight. It's also a clean room implementation of the class libraries, so it doesn't use an MS code.

Ginger

Mutant_Fruit wrote: »

Oh but of course. However, the mono project doesn't actually have MS backing - except in the very specific case of Silverlight. It's also a clean room implementation of the class libraries, so it doesn't use an MS code.

As i said, in a weird way they did, they didnt sue when they could have.

Mutant_Fruit

It is an open specification, so you can implement it if you want. There are some issues though in that not everything is covered in the spec. For example winforms and asp.net aren't covered (as far as i'm aware). I think pretty much everything else is covered, but i'm not reading the spec to find out

But yeah, there are some things implemented which aren't in the spec, but whether that means MS have a legal leg to stand on or not, i don't know. I have no idea how the law stands with regards to implementing a publicly visible interface so that your implementation looks like it does similar stuff to someone elses implementation.

Hobbes

Mutant_Fruit wrote: »

It's still an apples to apples though. The C# spec also is quite clear that boxing isn't a good thing, especially in tight loops.

If both languages say that using Auto-boxing in such a way is bad, then there is no point comparing it when your trying to show that out of the two bad ways .NET lets you use bad coding easier. That's not making me weep for Java.

It's not always possible to avoid boxing,

Yes it is, once you know how Java works in relation to auto-boxing. The safer way is just to use a privative array and code in such a way as not to waste memory.

That is if all you are doing is storing int data. If you are storing groups of data then you create a javabean.

#c generics and Java Generics work very differently so it is pointless comparing them.

Mutant_Fruit

Hobbes wrote: »

If you are storing groups of data then you create a javabean.

That would correspond to method 1 i mentioned before, making everything a class. This loses the benefit that structs offer you.

class MyInt
{
    public int Value;
}

An int[] storing 10,000 ints uses considerably less memory than a MyInt[] storing 10,000 MyInts. An int is 4 bytes, a MyInt is 4 bytes + object overhead. An int doesn't need to be garbage collected, a MyInt does. Those are the two main benefits of using value types over classes.

Of course, a MyInt can be put inside an arraylist without boxing, because you've already put the int inside a class. Thats the advantage to this method.

Hobbes

Mutant_Fruit wrote: »

That would correspond to method 1 i mentioned before, making everything a class. This loses the benefit that structs offer you.

And also is bad coding if you don't. Your not encapsulating your data and you would have low cohesion.

An int[] storing 10,000 ints uses considerably less memory than a MyInt[] storing 10,000 MyInts.

Hence the reason you stay away from auto-boxing in those situations.

Of course, a MyInt can be put inside an arraylist with boxing,

That's not auto-boxing though. Auto-boxing is Java automatically interchanges between primatives+Wrapper classes (under certain conditions) to allow you to easily use collections classes and wrapper functions.

Your correct though, that would be the preferred method though if you had to manipulate that data.

Mutant_Fruit

Hobbes wrote: »

Hence the reason you stay away from auto-boxing in those situations.

A MyInt[] holding 10,000 MyInt classes does not boxing anything. There are no object wrappers created there. The extra memory usage is purely because instead of storing an array of 4byte value types, you're now storing an array of objects which are significantly larger than 4 bytes.

Anyway, java doesn't have 'structs', so you simply can't get the reduced memory usage by declaring an array of struct like you can in C#.

C#
public struct MyCSharpInt
{
     public int Value1;
     public int Value2;
}

If you have a MyCSharpInt[] containing 10,000 MyCSharpInt structs, it uses sizeof(int) * 2 * 10,000 bytes of memory. There are no garbage collectable objects either - another bonus. There is no equivalent to this in java. In Java you'd have to declare it as a class, which would then use:
(sizeof(int) * 2 + 24) * 10,000 bytes of memory. This is significantly more than in C#.

Hobbes

Mutant_Fruit wrote: »

A MyInt[] holding 10,000 MyInt classes does not boxing anything.

If you need to store just 10,000 ints then you would use one javabean which contains that 10,000 ints in an array object. You wouldn't create 10,000 MyInt objects.

I am sure you could if you wanted, but it is an extremely wasteful way to code and not how you are supposed to code in Java. So it is not a valid argument.

Mutant_Fruit

What if you wanted a 'dynamic' array, like an ArrayList except which doesn't box your value types. What would you do then?

EDIT: Also, the MyInt example was *just* an example. And in a few strings, a few floats and you have a 'real' class (or javabean), but the principle still holds.

Hobbes

Mutant_Fruit wrote: »

What if you wanted a 'dynamic' array, like an ArrayList except which doesn't box your value types. What would you do then?

Would probably need to start determining how to code it based on what it is your trying to achieve.

The user isn't going to start typing in 10,000 ints. So if it is from a file you could probably determine the best size and redefine the amount of memory to use.

It really depends on the situation.