Question time:

Results:

http://www.ausgamers.com/images/forums/leftbar.gifhttp://www.ausgamers.com/images/forums/rightbar.gif Yes: 70.2% (80 votes)
http://www.ausgamers.com/images/forums/leftbar.gifhttp://www.ausgamers.com/images/forums/rightbar.gif No: 10.5% (12 votes)
http://www.ausgamers.com/images/forums/leftbar.gifhttp://www.ausgamers.com/images/forums/rightbar.gif I don't run Windows: 5.3% (6 votes)
http://www.ausgamers.com/images/forums/leftbar.gifhttp://www.ausgamers.com/images/forums/rightbar.gif I don't know what it is: 14% (16 votes)

Total votes: 114

Please log in to vote!!

I don't run Windows, but I do have the Mono framework available. I haven't actually tried to run anything which uses it though.

You only need to know if the 1.0 framework is installed, or if its up to date?

Annything made for 1.1 or 2.0 will not work with 1.0 I think?

Annything made for 1.1 or 2.0 will not work with 1.0 I think?

And some applications cry if they were developed on 1.0 and you have 2.0 installed.

At least the s*** I use at work does.

Personally I blame the vendor.

If any version is installed

yeah, cad needs it

Personally - I think .Net is the dongs.

Personally - I think .Net is the dongs.

Agreed.

Most applications that use it happen to be prone to bloating and high memory consumption. Just take a look at the Catalyst Control Centre.

amen ^^^^

what exactly does it do?

It's supposed to be a cross-language-platform development framework from what I understand of it.

In my experiences "cross-language" refers to VB.Net and "cross-platform" refers to Windows running on an Intel platform or AMD platform.

Another fine example of a .Net application is WinMyth - the Windows frontend for MythTV. I've tried every version released for the past 2 years and still it doesn't work.

Most applications that use it happen to be prone to bloating and high memory consumption. Just take a look at the Catalyst Control Centre.

Like most things in Software Development this is the fault of the author, not the platform.

.Net can be used to produce neat, optimised and efficient code. A lot of the people now producing .Net apps are doing so in VB.Net rather than C#, because they are VB devs who are more comfortable with it. Also a lot of the tutorials for .Net languages focus on how to do things as easily as possible without touching actual code, breaking application layer principles merrily.

Having never worked in an unmanaged environment these new .Net devs then do things like indiscriminant object creation, leading to humongous memory footprints. Just because the code is managed and won't leak doesn't mean that you don't need to release objects - make sure that they are falling out of scope!

I've written a threaded network service in .Net 2.0 that has a 15k runtime memory footprint. Bad software development != bad environment.

Also, the .Net Framework is a common library for Windows development primarily using Visual Studio 2005 (or 2003? I think for version 1.0 / 1.1). Think of it as being like the STL for C++, but a proprietary Windows version.

It lets you as a dev choose between C#, VB, J# of Managed C++ and still use a common library of functions and API references etc. This makes it easier when a regularly-C# guy has to do a little maintenance in a VB guy's application.

It also allows Microsoft to put all their eggs in the same basket - the Common Language Runtime means that the same underlying code is being run for all the flavours, so they only need to optimise a single string / list / network class etc. Previously they had a s***load of disparate libraries like MFC / ATL and whatever the hell VB used etc.

.NET ftl

give me native C++ and custom libraries anyday. I made a small program that kills off processes that you specify in a text file (called Process Optimizer..). Despite it being 80kb with a window with two buttons no bigger than 300x100 pixels it still takes several seconds to load. Whereas a normal app would be instant. And it actually took time to paint the two little buttons...

And it actually took time to paint the two little buttons...

.Net development is not recommended for 486-based hardware.

this is on an Athlon 64 with 1 Gb ram + GF7800GS......!

Oh and when I made another tiny utility with a window and static text box in normal Win32 it starts instantly fully drawn...

last edited by эδєє at 17:22:54 11/Jan/07

Dunno 3Dee, I've written a fair few .Net apps now and never seen any of the delay you're noting.

Must be you ... in which case yeh, stick with win32 ;)

Like most things in Software Development this is the fault of the author, not the platform.

That is true, but who is at fault makes absolutely no difference to the end user who has to put up with the bloated software.

So by staying away from .NET applications, you avoid 75% (I made that figure up) of the bloat out there these days.

last edited by parabol at 17:29:47 11/Jan/07

Well, I guess that kind of makes sense ... in a completely wrong kinda way.

Personally I'll continue to evaluate sofwate on its merits though.

Personally I'll continue to evaluate sofwate on its merits though.

Feel free to evaluate all you like while you're stuck on a looooong splash-screen :)

I fully agree with what Parabol just said. I used to use catalyst control centre and smart ftp amongst other .NET apps, and now I just stay away from them whenever possible. Ditto Java.

Initially you will have memory bloat because around each application it has to load the .NET framework around it. So even the smallest program can still take up a fair bit of space.

As for speed performance problems, I haven't encountered anything that is a problem (apart from the usual badly written code).

Basically I'd much rather prefer my applications compiled into direct assembly (or rather machine code) then be running in a VM..

last edited by эδєє at 18:36:04 11/Jan/07

And you can now whack your CLR compiled binaries in to SQL Server in place of stored procedures and functions.

Please don't do it, you make DBAs cry. You need a very good reason to put CLR in your DB and the fact that you find it easier to write (or only know) VB/C#/AnalProbing isn't a good reason.

.Net isn't the ONLY reason that your memory bloats or the speed isn't present.

Given, yes it loads a framework, yes it's managed and JIT'ed at runtime, but its also highly optimized at runtime, and you can always ngen your assemblies and cache them.

often times, the complaints about memory/speed can be blamed on poorly written code. Just because you've got a garbage collector, doesn't mean you shouldn't manage system resources in the same way as when your developing native win32 applications.

As for speed, in c/c++ you can have some crummy algorythm that runs n^2 when you could run it logn, but because its native, it still responds. .Net is less forgiving but you will notice improvements if you can apply MSDN best practices to the problem your trying to solve.

I have the inter.NET saved on floppy disk installed in my memory cache booted off my front side bus.

Serious answer: v2.something (whatever the latest is)

I stopped using that stupid control center thing. It took FOREVER to even load. Now I just install the latest ATI drivers & ATI tray tools. Much faster & nicer.

last edited by whoop at 20:32:32 11/Jan/07

how do you tell?

Well just to prove you all .NET haters right, I have installed the visual studio 2k5 service pack on 2 different machines with different specs and it is the slowest f***ing piece of s*** i have ever seen install, and it tends to be a trend that is continuing and expanding into other applications.

And you can now whack your CLR compiled binaries in to SQL Server in place of stored procedures and functions.

Please don't do it, you make DBAs cry

Agreed Nats, however there are a few circumstances where it is prudent to do so. Some things SQL is not so good at. Such as string manipulation and dynamic numbers of columns, mind you I have not yet had a look at crosstabs in 2005 as of yet.

Arguably some of the above should be done on the client.

Agreed with Trotsky as well. NGen makes a significant difference, though virtual machines seem to be the next new/hyped thing in the industry. Unfortunately there are a lot of crappy programmers out there, and .NET even though it provides somewhat of a safety net, it also doesn't really encourage you to be a good programmer.

On a slight tangent, Microsoft seems to be pushing game developers to develop cross platform games, namely the xbox360 and Vista based pcs. Apparently to have get a game 'Vista Certified' you need to make sure it's control scheme is able to be mapped to a control pad.

I wonder if .NET 3.0+ is what they will be pushing people onto for games development, as in theory, having the controller support, all you would really need to do is have both Vista and the XBox 360 to both have .NET installed and it would be trivial to be able to publish a game for both.

On a side note, I too have been disappointed by the catalyst control centre, as it does seem to be bloat. Oh wells...

Or you can just not code like s*** in C++ and optimize as you code so that all your programs run ultra fast by default in good ol' machine code. As in, learn thing like trees and decent OO and stuff... :)

And you can now whack your CLR compiled binaries in to SQL Server in place of stored procedures and functions.

Please don't do it, you make DBAs cry

I did this, and it f***en rocks. That slow as s*** full text indexing can go f*** itself now that I have my own. Just don't disable the assembly safety checks and show a bit of care with the code and stress test it properly. The important bit is stress testing whatever you do 'under the hood'.

.NET ftl

give me native C++ and custom libraries anyday. I made a small program that kills off processes that you specify in a text file (called Process Optimizer..). Despite it being 80kb with a window with two buttons no bigger than 300x100 pixels it still takes several seconds to load. Whereas a normal app would be instant. And it actually took time to paint the two little buttons...

Only a useless f***head would use .NET for an application that only did that and bitch about bloat. You should be bitching about using the wrong tool for the job.

Don't get me wrong, I'm full of hate for .NET applications, but at least complain the right things.

Oh noes, I tried to screw my table together with a hammer and it was slow and s***. Screws are useless for putting together tables!!!

last edited by typo at 21:23:05 11/Jan/07

yup - V1 thru 3

Don't get me wrong, I'm full of hate for .NET applications, but at least complain the right things.

Oh noes, I tried to screw my table together with a hammer and it was slow and s***. Screws are useless for putting together tables!!!

oh noes - while I'm stupid enough to stay in this job I haveto do things the way the stupid boss thinks they need to be done

Well just to prove you all .NET haters right, I have installed the visual studio 2k5 service pack on 2 different machines with different specs and it is the slowest f***ing piece of s*** i have ever seen install, and it tends to be a trend that is continuing and expanding into other application

dude - it's our buiz. MS continue to make us need more powerful hardware, so hardware vendors can supply it.

In reality, we could probably all still get on with our old P3/Athlons (gawd knows most users don't need anything better) - but it's a pretty big business that is forced forward. There've never been many winners here - we just keep adapting to the new technology as we need to

Only a useless f***head would use .NET for an application that only did that and bitch about bloat. You should be bitching about using the wrong tool for the job.

Don't get me wrong, I'm full of hate for .NET applications, but at least complain the right things.

Um, what? Whats wrong with them? £1 million worth of orders are processed by my .net applications every month.

Visual studio 2k5 runs smooth as silk on my pc, which is a pretty average rig.

last edited by Thundercracker at 23:45:59 11/Jan/07

i'm surprised .NET web controls haven't taken off. then again they problem run in-process which makes them essentially useless since it is a race to see which website gets to load its preferred .NET runtime.

my patrol used to struggle crawling up steep rocky step-ups because the little 3.0 diesel relies on it's turbo too much to produce decent torque, so at low rpm where the turbo isn't yet contributing it would always stall or I'd have to ride the clutch - fitting 85% reduction gearing fixed it, it now idles up a cliff face even with 36" tyres

I dunno what programming language gearmaster's gear-cutting machines use for their templating software but it's probably not .net

^ Does your patrol take a while to start up?

Probably Java.

Or you can just not code like s*** in C++ and optimize as you code so that all your programs run ultra fast by default in good ol' machine code. As in, learn thing like trees and decent OO and stuff... :)

Higher level languages, such as managed languages, have their place. Specifically in large scale applications where memory leaks would be all too easy to let slip in if they were written in lower levelled languages. Also, higher levelled languages, such as .Net framework and Java languages often have a multitude of highly optimised structures that decrease the amount of coding that programmers have to do.

There are valid reasons why so many business applications are not written in C++.

oh noes - while I'm stupid enough to stay in this job I haveto do things the way the stupid boss thinks they need to be done

Oh noes, I wasn’t quoting you. I was specifically quoting эδєє’s homo example bitch.

mmmm bloated and slow .NET and Java apps
mmmmm out sourced apps

theres enough of them to keep performance testers in work for pretty much ever

:D

<3 .NET and Java


last edited by Raisty at 08:13:00 12/Jan/07

last edited by Raisty at 08:13:03 12/Jan/07

Well, I'm not bitching that they have there place in terms of functionality and ease of development and all that stuff. I'm just saying that don't go to .NET when you need a high performance program such as games (which are usually optimization heavy applications). Tho that didn't stop MS from throwing C# onto the Xbox 360. I suppose .NET would go fast on a triple-core..

Well, I'm not bitching that they have there place in terms of functionality and ease of development and all that stuff. I'm just saying that don't go to .NET when you need a high performance program such as games (which are usually optimization heavy applications)

I agree with this comment, however that's not what you f***ing said. In fact, it's not even close to your original s*** house example ...

I made a small program that kills off processes that you specify in a text file (called Process Optimizer..)

That's not what .NET was designed to do well.

.net security is pretty gaydongs.

.net security is pretty gaydongs.

The theory behind it isn't bad, Click Once (.NET 2.0) escalation of privileges is where they went wrong. At least they are enforcing best practice with regard to Zero Touch deployment in 2.0.

deploying troops

I made a small program that kills off processes that you specify in a text file (called Process Optimizer..)

That's not what .NET was designed to do well.

It can't loop through a text file well? Or kill processes well?

.net security is pretty gaydongs.

Security is such an overloaded term. Can you give a specific example?

It can't loop through a text file well? Or kill processes well?

A C file that reads N lines in a text file and then kills N processes would be faster and more efficient than a .NET application. .NET isn't designed to compete with small, system specific, native code binaries, it's designed to compete in extremely large environments.

I'll go you one step further: "A C file [snip] would be faster and more efficient than a .NET application."

I'd always prefer apps made in C for performance reasons, but I can't see anything wrong with making a .NET application that loops through a text file and kills processes and expecting it to run relatively quickly.

it's designed to compete in extremely large environments

If it can't do small tasks well, then how can it scale well to large ones?

I'm not sure whether I'm overlooking something here.

If it can't do small tasks well, then how can it scale well to large ones?

I'm not sure whether I'm overlooking something here.

Its not about scalability really. .Net can, and does do small tasks well. If you compare it to a process written in C or assembly to perform one small, tightly bound task then it will be beaten both in runtime performance and memory usage.

This is why people don't write drivers in .Net and it shouldn't be surprising to anyone who has much of an idea about Software Development. What .net excels at is as a productivity tool for developers working on custom medium- and large-size projects for desktop business applications.

Business operators are increasingly becoming aware that off-the-shelf solutions may not be the best option and that custom-made software packages are no longer the province of large corporations alone. In order to capitalise on this growing market developers need to be producing software quickly and efficiently so that the benefits of a custom package are not overwhelmed by the price tag.

A good developer using .Net saves metric f***loads of time (read: money) when preparing a package for a client, without sacrificing any of the project's requirements or goals. High-productivity development tools like .Net are expanding the market for development and paying for programmer's jobs!

I'm in my fourth year in the industry now and we've never had so much interest in development from medium and smaller players. Previously we had been almost exclusively caught up with large projects, but almost half our work is now short-term projects lasting 6 months or less for medium and small business.

Better still, we can hire someone with .Net experience or certifications and fuly expect them to hit the floor running with maintenance tasks on our existig products. This just wouldn't be feasible without productivity tools like .Net.

last edited by Hogfather at 13:57:48 12/Jan/07

I'm still confused why you wrote a program that loops through a text file and kills processes?

for /f %a in (filename.txt) do pskill "%a"

There's a job for every tool, obviously in your case there is a tool working on the job.

umm ladies, you can write .NET C++ apps so I don't know what the fuss is about

3d, you should profile your app before attacking the framework - without references to specific functions / code snippets that are 'slow' you're not really substantiating your claims...

my opinion is if you can't write a .net app that performs well (not the best, but well) you didn't try hard enough

I'll go you one step further: "A C file [snip] would be faster and more efficient than a .NET application."

In a perfect world … true. But it's more expensive to do so, for a number of reasons including, but not limited to: finding weird arse memory leaks, spending more time writing low level code instead of optimising high level concepts and a lack of tools that pre-write large sections of generic code.

To get to the same level of long term performance, organisations found that they had to spend less in managed languages than they did in unmanaged languages.

I'd always prefer apps made in C for performance reasons, but I can't see anything wrong with making a .NET application that loops through a text file and kills processes and expecting it to run relatively quickly.

I said it wasn’t designed to compete with C in small scale applications where the only metric is boot time, IO performace, or system calls; such as the example given.

umm ladies, you can write .NET C++ apps so I don't know what the fuss is about

C++.NET is a managed languages that introduces all of the overhead of the .NET framework. It just allows developers to write .NET applications using C++ syntax. You can write Unmanaged C++ code within Visual Studio .NET, but those code snippets don’t use the .NET framework just the Windows C++ libraries.

last edited by typo at 14:26:47 12/Jan/07

I'm still confused why you wrote a program that loops through a text file and kills processes?

I wrote it so that I'd run it before a game and it would kill all the little crappy processes like ctfmon.exe and s***. Worked a treat.

You can write Unmanaged C++ code within Visual Studio .NET, but those code snippets don’t use the .NET framework just the Windows C++ libraries.

The difference between managed and unmanaged code in VS 2005 is trivial, its just a compiler switch change.

You can still manage your own memory with the heap with new and delete statements etc. We haven't changed any of our legacy MFC apps, as they were made using Stingray libraries and we don't have a compelling need to use .net for them yet.

It wouldn't be hard to do, or a big drama, if there was a need to get exposure to .net to change an unmanaged c++ app into a managed one.

One thing you do lose is edit and continue functionality, but I don't tend to use that much anyway.

Is there a huge performance consideration for turning an unmanaged C++ app into a managed one? I guess I should try it and benchmark it myself but I'm lazy ;)

last edited by Hogfather at 14:41:03 12/Jan/07

But it's more expensive to do so, for a number of reasons including, but not limited to: finding weird arse memory leaks, spending more time writing low level code instead of optimising high level concepts and a lack of tools that pre-write large sections of generic code.

well, obviously; I was talking purely in terms of performance

Is there a huge performance consideration for turning an unmanaged C++ app into a managed one? I guess I should try it and benchmark it myself but I'm lazy ;)

If it ain't broke don't fix it. It's all well and good pushing these new technologies, but unfortunately it is easy to introduce bugs when migrating apps to new frameworks. Depends at what stage of the life cycle the app is at.

I recall some years ago, someone ported the quake 2 engine across to managed code and had some comparisons available, between the managed and unmanaged versions. I wonder how it stacks up today: codeproject

I'd always prefer apps made in C for performance reasons, but I can't see anything wrong with making a .NET application that loops through a text file and kills processes and expecting it to run relatively quickly.

I wouldn't expect any issues doing such a thing in .NET either, though I would have probably looked at the Windows Scripting Host first, and developed it in less time than it would have taken to develop in C.

A case of the right tool for the right job, I'm not sure if TicMan's solution works, but it is a hell of a lot more elegant than a compiled solution I'm guessing.

None of the vm based frameworks will run as quickly as native code due to the IL (the layer which allows platform independence VB.NET, C++.NET, C# etc-> IL) needing to be compiled once more. However if you NGen the code (compile it specifically for the target platform) it should load pretty quickly (which no doubt many people complain about) but there is still the overhead of hosting the runtime.

last edited by Predator at 15:57:25 12/Jan/07

Is there a huge performance consideration for turning an unmanaged C++ app into a managed one?

Managed C++ has .NET overhead.

Chalk one more up for "Don't run windows". I forgot I use Ubuntu and clicked the wrong one.

Managed C++ has .NET overhead.

Clearly (and obviously). Might night have been clear in the post, but I was actually looking for runtime comparisons in code execution tasks in an app ported to managed code. Or "when I push this button and that big, CPU and memory intensive task is run is it significantly slower".

I don't particularly care about the added application load time from .Net dependency. Almost all of our C++ applications make use of Crystal Reports 10 or higher, which requires the .Net framework.

Our users also don't bitch, because we tend to write the sorts of programs that they open up at the start of the say and then use all day long. +-5 seconds of load time at the start of the day is completely meaningless in this context. I have not once in the entire time since I left Uni had a single user make observations about startup time or memory footprints. Geeks care about what language a program is written in, 'real' users neither know nor care.

What they do care about is correctness, runtime performance and usability.

What they do care about is correctness, runtime performance and usability.

Or in two words "user experience"

http://homepage.powerup.com.au/~boldajis/images/ph.gif

something something ... dark side... something something...

... complete

That diagram was made by a lisp programmer.

haha that diagram is awesome

perl pwnz

I like php & c# where am I on that chart? :)

VB and java can burn in hell

^ is that why your avatar is a burning skull & crossbones?

coldfusion is off the chartz maen

weee i'm at the top of the chart :)

coldfusion is off the chartz maen

Because it's s***.

Note ... the chart graphs superiority complexes.

Not actual ability.

While searching through my hard drive I just came across this. I figured it was relevant.
http://content.imagesocket.com/thumbs/uf005726ee5.gif

Ah, all this sounds so nightmarish - heavy .NET framework. eugh.

Objective-C/Cocoa rocks. Well, I assume it's better, because OS X apps are sexy, run beautifully, and in the full year that I've been on OS X, I'm yet to experience anything dodgy.

Now compilable for win32 (sort of): http://www.cocotron.org/

Pascal ftw yo!