ATTENTION: You are viewing a page formatted for mobile devices; to view the full web page, click HERE.

Main Area and Open Discussion > General Software Discussion

Why the aversion to .NET Frameworks?

<< < (11/15) > >>

Renegade:
A friend of mine says, "C is the answer." Not C++. C. He's brilliant. He's the guy teaching the multiple PhDs at the premiere government technology think-tank about programming. I have a lot of respect for him. He's got more programming talent in his thumbnail than I'll ever have.

But... He's a freak. A brilliant freak. But a freak. Very few people are that good.

There are even freaks out there that love assembler.

Then... There are the rest of us. The ones that are good, but not gifted. Most programmers.

And then... There is the reality that at the end of the day, empty plates suck, big dinners rock, and C doesn't put food on the plate for most people.

I've got other friends that have been doing C/C++ for years, and when they discovered .NET, it was a revelation for them. They love it. They can get more done easier and faster.

Now, I'm going to get into some radical stuff and likely piss some people off. i.e. Nothing surprising. ;)


Perhaps a few people might remember HTML, as in HTML 1.0 all the way up to 4.01. It was fault tolerant. It enabled the Internet because it wasn't impossible to use. SGML is a beast. A nasty beast. Completely unsuitable for humans. HTML on the other hand has been wonderful.

Now, if you're a purist, you should likely be frowning on that dirty, nasty, sloppy HTML, and tout a much more robust and refined language like SGML. Ahem... Houston, we have a problem...

The reality is that it's usually pretty silly to look down on most languages. Here's a good example - PHP. Now, if you look at PHP, you have multiple methods that do the exact same thing. That is, when given the same input, the methods return the same output. This is bad. Very bad. Now, if you believed that, you have a problem because you probably don't understand PHP or C# or some other languages very well, or probably more correctly, you're confusing frameworks and libraries for the language itself. Those redundant PHP methods come in different modules and libraries. It's not a problem with the core PHP language. In the same way, frowning on C# is rather silly. Even if you hate .NET, which is NOT C#. The C# language is just a language. If someone wanted to, they could write a compiler that compiled C# to native code. You can use C directly from some command line shells. That doesn't mean that C is an interpreted language.

When it comes to JIT, well, it's a price that you pay. But seriously... Is startup time all THAT important? If a program takes 5 seconds or 15 seconds, so what? Is it annoying? Sure. Is it a deal breaker? Certainly not.

But what do you get in return?

Productivity.

Managed code.

Both of those are big deals. Very big deals. Managed code is simply the way of the future. With software projects becoming larger and larger, managed code offers, well... who cares. It's not really all that interesting.

What IS interesting is productivity. When a programmer can get done the same task in half the time as he would with other tools, this is good. It makes software development more profitable, which makes more software products viable, which puts more choices out there for consumers. It also makes possible projects that otherwise would not be profitable due to productivity issues. This makes niche software viable in areas that would otherwise go ignored.

All this is good for us as consumers.

As for .NET software out there, there's a LOT. Magic the Gathering Online is a .NET application. There are plenty of them out there in the consumer world, and not just the line-of-business application and server world.

There are times when C, C++, C# or whatever language you want to name just isn't appropriate. Not all languages are suited to all tasks. F#, Haskel, Erlang and other functional languages are very good at mathematics. Can you do the same things with C? Sure. Would you want to? Maybe and maybe not. It's all case by case.

C# is a great general programming language that really works well for a lot of things. But, it's a lot like chocolate ice cream - there are people out there that really like strawberry a lot more. That doesn't make strawberry or chocolate bad or good. It just makes them different.

As for Mono, well, again, it has a time and a place. And yes, there is software out there for consumers done in Mono.

The problem there is that unless you SEE the .NET framework (or Mono) installed, there's no good way to just tell if it's a .NET/Mono program or not. And a lot of them simply invisibly install with no indication that they are .NET/Mono. Why would they? Do you care? I certainly don't. When I use a program, I couldn't care less what language it is done in. Well, except for Objective-C because it's evil sent from the Devil and only total douchebags use it. Errr... Well, that might not be true, but it just felt good to say it anyways~! :P

I suppose we techies just love our holy wars!

f0dder:
... Especially people clinging on to C (and using the insecure libc functions) really shouldn't be doing any sort of networked code, please. ...-f0dder (November 16, 2010, 05:09 PM)
--- End quote ---

You mean people writing such non-networked code as; Linux, Apache and PHP? (all of which are still "clinging" to straight C).-widgewunner (November 17, 2010, 12:45 PM)
--- End quote ---
Yep.

Thanks to clining on to C (C++ isn't nearly as bad, but isn't necessarily the best choice either), we have wonderful buffer overflows, memory leaks, double-free exploits and what have you. Even when those problems are fixed, for long-running daemons you get memory fragmentation issues unless the developers have been very careful and use pooled allocators - or rely on the cruddy old one-process-per-connection model, or the less-cruddy-but-still-meh "use one process for N client connections then reap because we know we leak memory like a sieve" model.

Truth is, C (and asm) simply can't be beat for systems level programming where size and speed (i.e. performance) really matter.-widgewunner (November 17, 2010, 12:45 PM)
--- End quote ---
This really depends on what your're doing. For a lot of code, especially dealing with networked stuff, having an efficient I/O model + efficient threading + a proper string class that stores length and doens't have multithreaded COW ref-counting bottlenecks + a fast non-fragmenting memory allocator (usually means garbage collecting) is going to matter a lot more than a slightly more aggressive native code optimizer.

The only place assembly belongs these days is extremely low-level code that needs to take advantage of CPU features. The OS low-level "ZeroPage" function, optimization for sound and video codecs, etc... but in regular usermode applications? Just about never. I wouldn't mind seeing C being dropped entirely in favor of C++ - yes, even for kernel development, although you'd probably use a subset of C++ features there (using it as a "Super C"). For library development & other-language interop, use C++ internally and a C interface to the rest of the world. But please, stop writing raw C code - the only legitimate reason would be developing for platforms where no C++ compiler is available, like some of the really limited microcontrollers.

vlastimil:
Eh, I am in ".net sucks" camp, because:

* I had a very bad experience with the first few versions. In order to use them properly, I had to learn a lot of useless things. Microsoft wants you to believe that writing .net apps is easy. That is true for simple apps that start, does it thing and ends. But writing larger, correctly behaving .net app is a nightmare. The problem is of course the collision of managed and unmanaged code and you still cannot avoid it, because Windows is unmanaged. I could tell you stories about memory and resource leaks caused by totally harmless and unexpected things. Using .net properly is harder than using C++.

* It misuses the C name. How does Ms sell the new VB? It renames it.

* Microsoft pushed it too early. It was full of bugs and it is still immature now.

* It is not innovative, it is just a Java clone. After Ms lost its case against Sun regarding Java modifications, they decided to use their marketing muscle instead. I hate this bully behavior.

* .net framework is too big, requires admin access and it is changing too often. A no-go if you actually want the broadest audience for your applications. (Don't argue with Paint.net, it is Microsoft's tool for spreading the .net framework.)

So, I'll switch to .net 5 years after the first managed Windows version is released I do not see that coming any time soon. Microsoft is not stupid, just sneaky 8).

f0dder:
The original versions of C# and .NET were lackluster - that's a pretty awfully bad reason for dismissing them today, though.

With C# 2.0 it became usable - generic and iterators.
With C# 3.0 it became interesting, and worthwhile to use - lambdas, extension methods, LINQ, anonymous types, and implicitly typed variables.

Yep, C# has borrowed a lot from Java, just like Java borrowed a lot from languages that came before it. It's my impression that C# (the language) has surpassed Java (the language) by now, and I definitely find it more comfortable to develop in C# than Java (which is partly because of the language, and partly the tools and framework).

The .NET framework definitely isn't perfect, there's bugs here and there, and it can be frustrating to figure out how all the parts play together... some of the standard interfaces you need to implement are pretty horrible (INotififyPropertyChanged is HORRIBLE, but at least you can abstract the horrors away somewhat). But there's also a lot of good stuff in there!

Even with some of the quirks, it's definitely a LOT more pleasant working with WPF than other GUI toolkits I've played with... With databinding leading to the MVVM design pattern and a convention-based MVVM framework, it becomes possible and almost pleasant to decouple GUI and model code, and get clean and testable applications.

Using .net properly is harder than using C++.-vlastimil (November 18, 2010, 06:16 AM)
--- End quote ---
The one thing from C++ I miss in C# is deterministic object destruction - RAII is great. Unfortunately, and for good technical reasons, that's just not going to happen. So we're stuck with IDisposable and using - but it's not really that bad once you wrap your head around it, and consider alternative ways to solve problems. Example: instead of returning an IDisposable object from a method, perhaps you should consider taking in a "do-work" delegate as input to the method instead...

* It misuses the C name. How does Ms sell the new VB? It renames it.-vlastimil (November 18, 2010, 06:16 AM)
--- End quote ---
Oh, that's flamebait if I ever saw it. Using C in the name is, imho, entirely appropriate - it's a C-based language after all, calling it a VB is really lame.

The problem is of course the collision of managed and unmanaged code and you still cannot avoid it, because Windows is unmanaged. I could tell you stories about memory and resource leaks caused by totally harmless and unexpected things.-vlastimil (November 18, 2010, 06:16 AM)
--- End quote ---
Some examples would be interesting, otherwise it's just FUD to me. And hey, p/invoke is a lot more pleasant than JNI.

Eóin:
The one thing from C++ I miss in C# is deterministic object destruction - RAII is great. -f0dder (November 18, 2010, 06:41 AM)
--- End quote ---

Of course there is always C++/CLI. Managed C++ was an ugly kludge but C++/CLI seems really elegant, and considering MS has C++ God :D Herb Sutter at the helm, it would seem that they take supporting and developing it very serious.

That said the Compact Framework doesn't support it, so no Windows Phone 7 programming :(

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version