C# thoughts, opinions

N

Node_Pointer

Limp Gawd
Joined
Mar 26, 2002
Messages
313
What are your thoughts on C#?
Is it going to be around for a long time? Like C++.
There is alot of development in progress with c#. Will it continue or will all work become legacy?
C# is the next C++?
C# is the next generation of programming for M$?

Just thinking in text.
Have a great day!
 
C# is a really neat language. It fixes a lot of the problems of C++, but some of the problems remain.

Some of Microsoft's claims for the language (and the platform) are completely bullshit. For example, while it's an open standard and there are cross-platform implementations, none of them are very serious. (And, in my opinion, none are production-ready.)

More importantly, C# has some serious performance problems. While it's "Straight line" performance after being compiled is almost as good as C++, it relies on the .NET framework for any interaction with the outside world. The .NET Framework is interesting and powerful, but is absolutely miserable for serious commercial development, and probably unacceptable for many internal applications, too.

The C# tools are not nearly as mature as C/C++ tools. Profilers, debbuggers, and so on, for C++ have had a lot longer to develop and grow useful features after years of use.

This is also true for developers. No C# developer in the world has more than five or six years of experience. There are people who've been writing C++ code for more than 15 years. Any serious project involves critical aspects of the design that push the rules of the language and environment at least a little bit. Fewer people have less experience with these issues in C# and .NET than they do with C++ and its various environments.

I'm not sure I can call "C# the next C++". Languages move and morph. One of the publishers handed out a chart at conferences that showed how some langauges move around and mingle. It's a very interesting thing to study. One of the first things you notice is that nothing is the next anything; languages borrow different parts of different langauges to try and get the best of each one. After all, if C# was just the next C++, it would have all the problems that C++ had.

"M$" is a bit childish, isn't it? Meanwhile, I'm not sure what you mean by "the next generation of programming".

I hope that helps. If you've got more specific questions, please let me know and I'll see if I can help.
 
ROFLOL!!!!!! I did not mean to type "M$".

SORRY, it was my subconscious or something.

It is childish. I am just so used to seeing it that is seeped into my brain.

Thanks for the reply. Very useful insights.
 
C# is really not a C++ competitor.

Nobody who understands low-level performance models can even dream of reaching overhead-free CPU speed (e.g. with C++ code written by experts who control code size from generic programming and generally know what they are doing) with a language that uses a VM, has mandatory array bounds checking and structure slots initialization and most importantly cannot have pointer-free arrays of user-defined types. I leave other factors like inlining and compile-time computing to the reader's imagination.

I would never learn a language that only have one implementation if that implementation is not OpenSource. As a matter of fact I don't even do it if it is OpenSource. Mono does not count (yet).

Compile-time computing such as enabled by C++ templates (although in what is probably the least sane way to have a language) is important in any kind of high-performance project and let's be honest - almost all projects are high-performance projects or would become HP if they wouldn't be too broken for it.

Tools have been mentioned.

Note that you can "fake" any of the above factors in C# or Java if you are willing to make your program unmaintainable. Since most programmers who are about to choose between C++, Common Lisp, Java and C# or whatever cannot judge the amount of cheating in solutions shown to them the simpler languages get chosen more often than they would be if all the cards would be on the table.
 
uOpt said:
Nobody who understands low-level performance models can even dream of reaching overhead-free CPU speed (e.g. with C++ code written by experts who control code size from generic programming and generally know what they are doing) with a language that uses a VM,
Click to expand...
C# doesn't use a VM in the way that you're suggesting. It's always compiling to machine code before it executes. While it does pursue a hypothetical machine model, it ends up executing only machine code and doesn't rely on a VM for actual execution.

uOpt said:
most importantly cannot have pointer-free arrays of user-defined types.
Click to expand...
Huh? The .NET languages don't have pointers -- only references. Even substituting "reference" for "pointer", we're left with arrays of user-defined types that don't involve references ... something that's trivially possible in the .NET languages.
 
Considering that the .NET framework is a microsoft product, and that C# is one of the premiere .NET languages, it seems to me that we can expect to see C# stick around for quite some time. Isn't the .Net framework a part of Vista's install? These factors all suggest to me that C# will have some staying power.

Personally, I have rather enjoyed C#. Granted I am just a student currently, but I find it to generally be very user-friendly. In my opinion, some of its main draws are the compiler (visual studio) and its nice libraries. Although, being a student, I got Visual Studio 2005 for free, so perhaps thats makes me biased.
 
rgratto2 said:
Considering that the .NET framework is a microsoft product, and that C# is one of the premiere .NET languages, it seems to me that we can expect to see C# stick around for quite some time. Isn't the .Net framework a part of Vista's install? These factors all suggest to me that C# will have some staying power.

Personally, I have rather enjoyed C#. Granted I am just a student currently, but I find it to generally be very user-friendly. In my opinion, some of its main draws are the compiler (visual studio) and its nice libraries. Although, being a student, I got Visual Studio 2005 for free, so perhaps thats makes me biased.
Click to expand...

I tend to agree -- there are times when you would really like to design a custom low-level component of your own, but there are other times when C# and the base class library is an easy solution to something small that you just want to get going.
 
Cyrilix said:
I tend to agree -- there are times when you would really like to design a custom low-level component of your own, but there are other times when C# and the base class library is an easy solution to something small that you just want to get going.
Click to expand...

Indeed. Admittedly, one of my favorite parts about it is its ease of use in creating an application. Previously, I was mostly accustomed to C++ and the beautiful command line output.
 
You are fooling yourselves. The problem isn't that C# might just be dropped, the problem is that MS can develop it into a direction you don't like and then - what? Delphi anyone?

You are also fooling yourselves when it comes to performance. Almost all long-term projects end up being thrown onto data that is several times the initially planned for size.

I wonder how this C++ code gets represented in C# without pointers:

Code: 
class foo {
    int foo1;
    char foo2[256];
} bar[2000];

Last I checked you could stuff user-defined data into arrays that directly contain the elements (not pointers to elements).
 
You are also fooling yourselves when it comes to performance. Almost all long-term projects end up being thrown onto data that is several times the initially planned for size.
Click to expand...

I wouldn't mind reading through some evidence for this... I was planning on starting a sizable project using both languages.
 
C# is what I learned this year. It is a very nice language. But like others has said, if you are going full blown commercial software, then its probably not the choice for you with the whole .NET framework and all.

First semester I learned it just as it is, and then second semester we took C# and learn how to apply it in ASP.NET Thats what im mainly using it for now and it does a great job at it.
 
Wingy said:
I wouldn't mind reading through some evidence for this... I was planning on starting a sizable project using both languages.
Click to expand...

Well, how am I supposed to that? I can't post my current and previous employer's data :)

All I can say is that after many years in the industry is that the growth of data for any computing domain is generally faster than the increase in hardware speed and capacity. That's because you have competitors who write faster programs than you and soon the customer's expectations adapt to the new capabilities.

And even without that, customers really really love to reinforce success. So if you get some cool thing working for them they have the business stormtroopers sit over your application 24/7 and figure out how to make more use of it.

More important: Besides the pure machine speed that you gain through having an overhead-free language and making good use of it, there's the problem that most programmer who choose slow languages and are hence unaware of performance impacts are also not bothering with algorithms. Then they get hit by the data increase extra hard, since these projects tend to be full of algorithms that have exponential performance decreases on data size. The simplest thing is probably a combination of two linear searches, which then means that twice the data gets you 1/4th the speed, even if you give the box twice as much memory so that everything fits. Then a competitor comes along which slows down by 20% when getting 10 times as much data and you sell french fries.

Now, I don't write middleware or other thin layers where performance actually doesn't matter, but these jobs all go to India anyway. As a software developer in the U.S. or Europe you have to stay sharp. And fast.
 
uOpt said:
I wonder how this C++ code gets represented in C# without pointers:

Code: 
class foo {
    int foo1;
    char foo2[256];
} bar[2000];

Last I checked you could stuff user-defined data into arrays that directly contain the elements (not pointers to elements).
Click to expand...

As below. I can't figure out why you think you need pointers to represent this structure. Is it that you want to take the address of bar and play around with the memory underneath, in a type-unsafe, unbounded way?

Code: 
namespace SharpArray
{
    class foo
    {
	    int foo1;
	    char [] foo2 = new char[256];
    };

    class Program
    {
        static void Main(string[] args)
        {
            foo[] bar = new foo[2000];
        }
    }
}
 
Wingy said:
I wouldn't mind reading through some evidence for this... I was planning on starting a sizable project using both languages.
Click to expand...

It's not hard to make your own evidence. What things are important to you? Perf? Development time? Debugging? Tools? Go investgiate it. Write a little snippet of code in both languages that does some interesting part of your intended application, or something representative of that same work. Then compare.

Bake-offs are fun and educational, if you do 'em right.
 
Wingy said:
I wouldn't mind reading through some evidence for this... I was planning on starting a sizable project using both languages.
Click to expand...

well where could it end up? if its gonna by 500nodes of a datasynapse linux grid, please don't do it in c#.
 
Full disclaimer: I (at the end of the day) work for MS.

There are pretty much two types of developers in the world today.

Dev 1 would program in MIPS if given the choice. S/he feels very powerful at a computer and resents any attempt to box him/her in with silly notions of not needing to malloc.

Dev 2 develops to get things done. The faster the better. There are tradeoffs, so this type is willing to trade control for ease of use.

The second you say that C++ is l33t, you begin treading down the slippery slope to Dev 2. Real developers of type 1 write in C and know that void pointers are great and that unmanaged code is the new managed code. C++ introduces automatic garbage collection, objects, etc. The true Dev 1 wants to control all of that.

Now, as a firm and solid member of the Dev 2 camp, I learned to program in Pascal and Basic. Moved on to VB, made it to C++ in college using the MFC. My sophmore year of college, we got .NET ('03) and I have been in love with it since the first day I didn't have to work with MFC in order to write a Windows app. The GUI of VB and the code behind of C++? That's C# at the end of the day which is probably the most beautiful language I've ever written in.

I think what you are actually quibbling about is Visual Studio and not C#. There are a few implementations of C# that don't run on the CLR, which is also an amazing invention. Anyone else want to go back to DLL Hell when merging C++ and C with VB code? Not this guy.

So, bash MS, Visual Studio, and everything else you feel like and I'll keep writing applications that make customers happy and me money.

Pick two: Fast, cheap, reliable.

Customers, when given the chance, want all 3, but since hardware is increasing at such a rapid pace, why write fast code when you can write reliable code on the cheap? Maybe in the lab but not for Fortune 500 companies.
 
Middle management at Microsoft bought into your "C++ is the assembly of the future" argument, and bought into it big-time. So much so that the mistake Microsoft made with the .NET languages was to invest in them for a few years to the point of postponing or cutting work on the native languages. Sure, some things got done-- but since VC++ 6.1 was canceled, Microsoft spent too much of its resources on the managed languages.

I agree that less skilled developers, like the Fortune 500 internal systems guys you're talking about, would rather be more productive than develop something with acceptable performance. And that's fine; it makes perfect sense to keep the sharpest tools out of the hands of the people who aren't skilled enough to use them. Their focus is their business, not their technology. It's absolutely the right thing to do, to make tools that are easier to use and let them keep that focus. That's what pre-.NET VB did, really. But to set it as the strategic direction for the whole company? Bad idea.

The rest of us--even people at Microsoft internally--would rather write code that doesn't have the size or performance problems that the CLR intrinsically brings. For truly good developers, this choice is still situational. There's times when a simpler, temporary solution is all that's required, and the .NET languages are appropriate for those applications. Until the problems in the CLR are fixed, though, there's plenty of room for C++ developers.

If the code you write for Microsoft ships outside of the company, I wish you'd go back to using MFC. Your customers don't want slow software just because you put "get things done" ahead of "thrill my customers".

flipflopsnowman said:
I think what you are actually quibbling about is Visual Studio and not C#.
Click to expand...
I can't figure out how you've come to this opinion. Can you explain why you think it is that people in this thread are talking about VS and not C#?
 
What I meant when I said "quibbling over Visual Studio" is that everyone is bashing the CLR (or CLI for non MS implementations) instead of discussing whether or not C# is a viable language.

The CLR is in its infancy, less than 10 years old, and is moving into it's third release. The flaws of the CLR are there and they do hamper development in some instances, but I find that the flaws do not "slow" the project down as much as bad development does.

Granted, you can write a much faster application via MFC, C, or whatever, but bad developers can and do slow MFC applications down to the speed of the CLR if they don't know what they're doing.

For instance, I'm working right now porting a .NET 1.1 application to .NET 2.0. The previous owners of the code did not know what they were doing and as such, the . NET 1.1 application was slow because of the poor design decisions they made. Now, if we ported the app from .NET 1.1 to C++ (not using the CLR) the application would be much faster and faster even than the .NET 2.0 with good code, I'm not going to argue about that.

Just because it is easier to write code via the CLR, it does NOT mean that the development can be done by anyone and I find it offensive that you are pretty much saying that .NET is for idiots. Idiots write in every language, they can just get stuff done in .NET that they can't in C/C++.

At the end of the day, the answer to the OP is this: It doesn't matter what language you write in (C/C++, C#, Java, Delphi, PHP, whatever) as long as you know how to write good code you will have a job for a long time.

If you're wondering what to learn, learn a language in each of these areas (preferably in this order):

1) Structured Language (Pascal, C)
2) Object oriented (C++, C#, Java, Smalltalk)
3) Logical language (Prolog, LISP)
4) Query language (SQL, mySQL)

If you know those, get reference books for these as learning the language is simple when compared to the above.

1) Scripting language (JavaScript, VBScript)
2) Markup language (HTML, XHTML)

That should give you a great programming background and the ability to adapt to any language.
 
jonneymendoza said:
i have heard from various sources that c# is just a cut down version of java
Click to expand...
This is a popular oversimplification. It's the kind of thing someone who doesn't know what they're talking about (or someone who is too lazy to come up with a correct explanation) will say.

flipflopsnowman said:
What I meant when I said "quibbling over Visual Studio" is that everyone is bashing the CLR (or CLI for non MS implementations) instead of discussing whether or not C# is a viable language.
Click to expand...
What's the CLR go to do with Visual Studio? The CLR is completely independent of VS.

flipflopsnowman said:
Granted, you can write a much faster application via MFC, C, or whatever, but bad developers can and do slow MFC applications down to the speed of the CLR if they don't know what they're doing.
Click to expand...
Sure. But a good developer will write a fast C/C++ program. And they simply can't write a fast CLR application, since the layers of crap in the framework are out of their influence.

flipflopsnowman said:
Just because it is easier to write code via the CLR, it does NOT mean that the development can be done by anyone and I find it offensive that you are pretty much saying that .NET is for idiots. Idiots write in every language, they can just get stuff done in .NET that they can't in C/C++.
Click to expand...
Sorry, but I think what I wrote is the truth -- even though you're overstating and abstracting my position in order to support your own allegation that it's offensive.

Microsoft's goal with C# was to take the sharp edges off of C++ and try to improve developer productivity. Professional developers know where the sharp edges are and competently avoid them. Professional developers also know that there are instances where it's nice to take advantage of some of the features of C# and the CLR and it is acceptable to sacrifice control and performance.

Lots, and lots!, of software is written by people who aren't professional developers. They work at insurance companies and banks and so on -- and they're more concerned with business rules and procedures than they are with engineering. There's no question that these programmers need tools to help them get their work done, and are more than happy to sacrifice a bunch of performance in order to avoid learning what a pointer is.

It's not that these developers are "idiots", as you call them. It's just that they're not software engineers.
 
Aside from arguing about our e-peens, I think that we can both agree on a few things:

1) It is more important to be a good developer than anything else.
2) One of the abilities of a good developer is to figure out what is required and to use the best tools available to solve the problem.

Sometimes these tools are C, C++, C# or even Prolog.

I think our main place of contention is at what point you decide to use C/C++ vs. C#, which is, as always, up to the developer.
 
mikeblas said:
As below. I can't figure out why you think you need pointers to represent this structure. Is it that you want to take the address of bar and play around with the memory underneath, in a type-unsafe, unbounded way?

Code: 
namespace SharpArray
{
    class foo
    {
	    int foo1;
	    char [] foo2 = new char[256];
    };

    class Program
    {
        static void Main(string[] args)
        {
            foo[] bar = new foo[2000];
        }
    }
}
Click to expand...

Your array in C# is internally being represented by an array of pointers. Among other things that is done to be able to stuff subclasses of foo into it, too.

You also run initialization of all fields of all foos, not to mention one memory allocation call each, whereas in C++ you just expand the stack pointer.
 
uOpt said:
Your array in C# is internally being represented by an array of pointers. Among other things that is done to be able to stuff subclasses of foo into it, too.
Click to expand...
The point is that the data structure you offered is representable in C# without any trouble at all. The programmer doesn't see the pointers.

uOpt said:
You also run initialization of all fields of all foos, not to mention one memory allocation call each, whereas in C++ you just expand the stack pointer.
Click to expand...
How it's allocated depends on how you declare the structure in C++, and what constructors the involved objects do (or don't) have. Certainly, it's true that you've got more control over this in C++ than you do in C#. But that's the whole point of C#; take control away for some things to relieve the programmer from worrying about them.
 
mikeblas said:
The point is that the data structure you offered is representable in C# without any trouble at all. The programmer doesn't see the pointers.
Click to expand...

My comment was exclusively concerned, and marked as such, with run time performance.

mikeblas said:
How it's allocated depends on how you declare the structure in C++, and what constructors the involved objects do (or don't) have. Certainly, it's true that you've got more control over this in C++ than you do in C#. But that's the whole point of C#; take control away for some things to relieve the programmer from worrying about them.
Click to expand...

I am aware of these tradeoffs.

However, people often, and that includes this thread, deny any inherit performance disadvantages of languages like C# and Java. They are wrong.
 
uOpt said:
My comment was exclusively concerned, and marked as such, with run time performance.



I am aware of these tradeoffs.

However, people often, and that includes this thread, deny any inherit performance disadvantages of languages like C# and Java. They are wrong.
Click to expand...

well about 10days of messages have gone, but anyway :confused:

wrong is a strong word.

If a c# app is slower than a c++ app (gui), but the developer has done a better job at keeping the application responsive - then it will be seen as a better application.

for backend work you will very rarely have a choice of languages. kivasoft gave you the option of c++/java. tomcat doesn't.
 
I have been working with C# and .NET for over 3 years. I have also used C/C++ in a linux enviroment for the last 5 years. I prefer the simplicity of C# over C++ as a language. However, I prefer the performance of GNU C++ over C# .NET . .NET has too much going on behind the scenes. Every variable (an object in C# .NET) has extra data associated with it, such as hashes, typing information, etc. I am digressing, but I am just saying both these languages have their place in the world. Don't expect either of them to vanish.

Learn every language and platform you can. They each have their strengths.
 
sovs said:
If a c# app is slower than a c++ app (gui), but the developer has done a better job at keeping the application responsive - then it will be seen as a better application.
Click to expand...
What does that mean?
 
If you live in the real world and are just developing GUI apps I don't think you can go wrong with c# if that's what you want to use.

I've been developing apps with .net/c# for 2 years and overall I'm pretty happy with the performance.

I have yet to encounter a situation where I felt like I was cockblocked by .net or c# itself. At the end of the day I want to create working apps that run efficiently on XP-era machines and c# allows me to do this in a timely fashion. I wind up spending more time writing up logic charts/notes/etc about a project more than the actual coding itself.
 
Everything except the "run efficiently" part.
Click to expand...

I think we have conflicting issues of what "runs efficiently" means. :D

The users of my applications (real world) do not care if they click a button and have to wait 90 millseconds instead of having to wait 75 milliseconds if it were done in straight c.

If I had an application that needed to perform that operation 10 million times, I might considering using a different language though.

My only gripe about .net in general is that the memory usage is quite large. A small GUI app will use a pretty silly amount of ram compared to other non .net languages. Also .net apps tend to take a while to load up initially -- although after you've ran it once it will load up much faster as long you haven't rebooted.
 
ShoeLace said:
I think we have conflicting issues of what "runs efficiently" means. :D

The users of my applications (real world) do not care if they click a button and have to wait 90 millseconds instead of having to wait 75 milliseconds if it were done in straight c.
Click to expand...
Maybe. I'm assuming you're doing UI work in response to the user, and in my experience the disparity between C++ and C#/.NET is far greater than the numbers you provide. By a factor of more than 100, sometimes.

My only gripe about .net in general is that the memory usage is quite large. A small GUI app will use a pretty silly amount of ram compared to other non .net languages. Also .net apps tend to take a while to load up initially -- although after you've ran it once it will load up much faster as long you haven't rebooted.
Click to expand...
NGEN can help with that, but it's a PITA to apply correctly.
 
NGEN can help with that, but it's a PITA to apply correctly.
Click to expand...

Hmm, I never heard of this before. A quick google shows that it may have a lot of potential. I'll have to research it more later. Thanks.

Maybe. I'm assuming you're doing UI work in response to the user, and in my experience the disparity between C++ and C#/.NET is far greater than the numbers you provide.
Click to expand...

Depends. Let's say I have an app where a user can manage "content". The content in this example could be text. The app may consist of a datagrid, few textboxes, a checkbox or 2, and perhaps a drop down list.

The user does not care how many milliseconds it took for the drop down list to be populated by reading a directory of files then inserting their names into the list. As long as it appears to be instant that's good enough.

The same can be said about populating the other GUI elements.

I've loaded up 500kb XML files which were inserted into DataSets, which were then displayed to a user in a DataGrid where they could modify and interact with the content. Joe Blow user only cares about what his eyes see. If the file loads up nearly instantly, he's happy.

Users are more concerned with an easy to use and bug free interface. Obviously performance is important, and I will do everything in my power to optimize code to the best of my ability (which is #1 on my list) but sometimes you have to draw the line.

.net allows you to tie in a modern, non-clunky (if coded well!) UI, with reasonably efficient code for non-critical GUI apps extremely fast.
 
ShoeLace said:
As long as it appears to be instant that's good enough.

The same can be said about populating the other GUI elements.
Click to expand...
I completely agree. Problem is, C# makes it hard to get response that appears instantaneous because message handling and painting in the CLR is so slow.

For optimization and performance, a C# programmer ends up starting pretty far in the hole because of the shortcomings of the environment and the performance problems in the CLR. They can spend lots of time climbing out of the hole -- at which point, they're losing the developer productivity advantages they were expecting.
 
As a C#/.NET developer, in the 3-4 years I've been using it, I have only twice had language/runtime related performance problems, and even then, I'm not sure C++ would have been any better. One is a WinForm that takes forever (2-4 seconds) to load the first time (JITing a lot of code and loading several dll's from disk), and the other is repeated casts from double to decimal (don't ask). In general, in my problem domain, performance bottlenecks are:

1. Network latency.
2. SQL Server (mostly network latency)
3. Third party components/applications.
4. Disk I/O.

I'm not suggesting someone should develop a AAA video game with C#, but for a lot of applications out there, CPU time and Memory usage are not the limiting factors.
 
Earp said:
As a C#/.NET developer, in the 3-4 years I've been using it, I have only twice had language/runtime related performance problems, and even then, I'm not sure C++ would have been any better.
Click to expand...
If you don't know that C++ was (or wasn't) better, you must not have made a head-to-head comparison. I think that, if you do such a comparison, you'll see the problems in C# and WinForms very quickly.

It's a pity that the forum rolled back; I made a detailed post that described most of the big problems in WinForms, but it's gone now.
 
All languages have their purposes.

I have to say in my current internship I am working mainly with C# (for the first time) and I find it a great and easy to use language.

What we work on uses Fortran for models, C++ to interface with the Fortran, and C# front end to manage and display a UI. (I think they would like to migrate all the C++ over to C# for ease of use, but the C++ is used in other places of the company)

There is a point where arguing about overhead makes absolutely no sense, even in commercial applications. We sell our product for a sh*t load of money, but it doesn't matter that we have C# in it, why? The CPU is still sitting at 90% idle. The computers are plenty fast for what we are doing, and in almost all situations they will be. You just need to chose a language that fits your specific needs.
 
You must log in or register to reply here.
Back
Top