|
Ask Cobol programmers how they like maintenance...
(and how they like the job market)
|
|
|
|
|
M i s t e r L i s t e r wrote: Ask Cobol programmers
Ask SAP what they did with outdated Cobol ABAP.
Ask why Vala project started.
However, this is not a way to compare or discuss, I guess.
C# is managed. It cannot and should not be compared to C++ (MFC is another story. It's just a framework not a language.), I believe.
The world still needs native code in many industries for several reasons. Now what is Microsoft offering for native coding better than C++? Again, I believe that MFC is still one of the best frameworks in Windows over C++.
Now no longer support MFC and help frameworks like QT to grow, why? because there's a need to native code that should be satisfied somehow.
// "In the end it's a little boy expressing himself." Yanni
while (I_am_alive) { cout<<"I love programming."; }
|
|
|
|
|
Yes, there is still a need for native code. The other man's protest seems to be an emotional attachment to his tools or using something new. We must remember that all of these things are merely tools, and every tool has its intended purpose. If we keep ourselves from trying to use a particular tool in every circumstance, then both C#/.NET and C++/MFC can happily coexist in the IT world.
With this in mind, I'm always looking for new tools to do new things. I am currently exploring functional programming, starting with Haskel then maybe F#, for its ability to express things as relationships and potentially easy parallelization. Just another tool. If I'm doing mathematical relationships, maybe Haskel. Expressing logic, maybe PROLOG or MERCURY. Prototyping GUI's, Visual Basic 6. Web services: J2EE, .NET, or Rails. Need to do anything: Common LISP. While this may be controversial, I've found that people who use many different tools and styles have an easier time solving complex problems, as they don't look at them in just one way (limited by their tool or language of choice).
|
|
|
|
|
NimitySSJ wrote: easy parallelization
Wow! tempting.
NimitySSJ wrote: people who use many different tools and styles have an easier time solving complex problems, as they don't look at them in just one way (limited by their tool or language of choice)
That's right but hard at the same time. Just invaluable experience during years of programming makes it possible I think. Not everyone can do it.
// "In the end it's a little boy expressing himself." Yanni
while (I_am_alive) { cout<<"I love programming."; }
|
|
|
|
|
|
"Just imagine if Vista was wholly written in C# with not a native code DLL or application in the bunch...." (El Corazon)
You shouldn't speak of such things! I just imagined an OS (Cosmos 7.0, maybe) running in C#/.NET. I hope you are going to cover the bill my heart doctor sent me for what resulted.
|
|
|
|
|
NimitySSJ wrote: I hope you are going to cover the bill my heart doctor sent me for what resulted.
uh uh uh uh.... well... uhmm.... I work for MS, yeah, that's the ticket.... call me at MS... my name is... uh... bill gates, yeah, that's the ticket... bill gates!
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
El Corazon wrote: Just imagine if Vista was wholly written in C# with not a native code DLL or application in the bunch....
W00t, just can't wait for that reboot time when the GAC got corrupted and Windows had to re-JIT itself before it finished loading.
|
|
|
|
|
Hamed Mosavi wrote: anywhere speed is more critical than UI (Games, Hardware related stuff like drivers, Scientific softwares with huge calculations,etc)
This is a very big reason why I use MFC 95% of the time. I develop scientific applications for medical imaging research that are very resource hungry. With the help of a 4 drive SATA hardware raid 5 my latest app loads > 1 GB of 3D image data to memory in less than 10 seconds. The second is that I have written 500K lines of MFC code.
John
|
|
|
|
|
M i s t e r L i s t e r wrote: What do you need old technology for? Move on...
You say it is old. I say it enables me to write high performance code. But then it would make sense to you only if you know what I'm talking about...
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
Indeed. The 15-30 second startup time required for .NET applications is sufficient indictment alone.
Software Zen: delete this;
|
|
|
|
|
You know this is a myth right?
This can only be slightly true if you're talking about very old and with very few resources.
C++ isn't dead, it should be used mostly for top notch I/O processes... massive stuff like heavy loaded ETL, or direct hardware connections...
If you port C++ to the C# world you'll have problems like trying to use C# in the C++ world.
Despite you can do both you'll have great drawbacks on both scenarios.
C# mostly on speed, and C++ on development process time (cost).
For me this Speed vs. Dev. Time is the thing that must be evaluated when deciding between these languages. We can't be blind on either side like almost everyone is like "Mine is better, yours is junk".
Don't forget that the objective is to sell a product and make the customer happy with it. Most customers don't care if it's C or C# or C$ or SQL or Access... they want it to work, well, fast and cheap as possible.
|
|
|
|
|
It's not a myth. Every .NET application I've ever used had an abysmally long startup time. Even "Hello world!" takes forever to start.
Software Zen: delete this;
|
|
|
|
|
Absoutely correct! Using the *new* and *improved* .Net-based SQL Management Studio is painfully sluggish compared to the *legacy* SQL2K Enterprise Manager and Query Analyzer. I wish they would bring back the native code versions of these tools.
onwards and upwards...
|
|
|
|
|
This is bad part of the IL...
As you should know, .net isn't compiled.
If you don't want to take advantage of that (like reflection for example) you can compile it directly to native code using ngen.exe
It will perform faster at first start.
|
|
|
|
|
Gary, I think you're wasting time arguing with someone who don't know what he's talking about. When he says C++ is dead, you could know what is all that he knows. May be someone should tell him that all the device drivers, all the high-performance graphic programs, all the high-performance games, all the high-performance embedded programs, linux, windows, etc., are written on C and C++. I would say he shares his IQ with sea cucumbers.
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
Rajesh R Subramanian wrote: I would say he shares his IQ with sea cucumbers.
Gentlemen, No fighting in the war room! The Sea Cucumbers are innocent. Leave them out of this.
codito ergo sum
|
|
|
|
|
Gary Wheeler wrote: It's not a myth. Every .NET application I've ever used had an abysmally long startup time. Even "Hello world!" takes forever to start.
Bah! It's your expectations that are the issue here; don't go and blame .NET because you're one of those types that think software shouldn't be slow.
|
|
|
|
|
<humble><eyes_downcast>
I'm sorry, sir. I'll drink the Kool-Aid™ this time.
</eyes_downcast></humble>
Software Zen: delete this;
|
|
|
|
|
|
AlexCode wrote: and C++ on development process time (cost).
not necessarily, this too is a myth. Much of what you can do in C#, you can also do in C++ in equivalent development speed. The difference is that MS has shifted focus, though they are shifting back. MFC was pushed out in favor of C# and dot net, leaving Qt and others in the real-time rapid C++ UI (even a product called "Ultimate" which based on C++ outperforms UI development under C# and Qt). Basically there is choice, and it is not "old technology" either with new capabilities having existed in Boost in preparation for the latest version of C++, and that latest version coming out later this year or early next, with some capabilities even C# dreams of, MS is considering bringing back MFC in a newer generation capable of accessing the latest, and greatest C++.
There are a lot of myths abounding, C++ never died, and C# is only faster in some areas, and even there, it depends on whos product for C++ you are comparing to.
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
"C# is only faster in some areas"
I don't think C# is faster that C++ in any area.
I just know that:
you take longer to develop the same thing in C++ than in C#.
You find cheaper C# resources (developers) for a project that C++ resources.
You have better tools to work on C# than in C++ (like the IDE).
You find cheaper 3rd party controls/tools to use on your products.
These aspects boost productivity, and my main concerns are based on the products.
Ship them as fast, cheap and good as possible.
I also want a program to be easily maintained and I don't want my products to depend on a small C++ guru dev team where it would be hard if any of them left.
This is where .net takes place.
If I make it the way that the customer likes, it will be made in C#.
|
|
|
|
|
AlexCode wrote: you take longer to develop the same thing in C++ than in C#.
No, *you* take longer. I am more productive with C++
AlexCode wrote: You find cheaper C# resources (developers) for a project that C++ resources.
True, if that is what you are looking for. The only problem is: you get what you pay for.
|
|
|
|
|
"you get what you pay for"
You have to know what you need... and 2 dev on the same level of knowledge the C# one is cheaper than the C++ dev.
And btw, you get what you design, plan and manage for, not what you pay for.
The problem is that:
1. Designers usually don't do code
2. Teams are allowed to put their imagination on their fingers
3. The development process is poorly conducted (if at all)
You have to choose your team by their qualities and team work, not by their price.
Cheers.
|
|
|
|
|
AlexCode wrote: Designers usually don't do code
no, junior programmers don't design, but junior programmers have been renamed as full programmers under the new "anyone can program with almost no knowlege because C# can turn baboons into expert programmers new way of viewing the world"... except that then you have no baboons typing out the works of shakespear and a lot of code that looks like it was designed by a baboon. So the company at the failing abilities of their programmers call in a designer who is really just a graduated baboon who thinks he knows how shakespear originally typed out the manuscripts by throwing darts while drinking ale, tells the other programmers what to do, they do it, and do it as poorly as it was designed, and the result is still what you pay for.
A good programmer does design code and write it.
AlexCode wrote: Teams are allowed to put their imagination on their fingers
again an issue of inexperienced code-warriors or overly opinionated code-warriors. You have "teams" and you have groups of cowboy programmers working in the same house. A team helps the team and keeps the design to spec.
AlexCode wrote: The development process is poorly conducted (if at all)
again from the view that C++ programmers who are experienced and know how to do things in all aspects of computer development from design to functional capability are outdated and unnecessary, you get what you pay for. If you actually had someone who knew how to program in all aspects of the development cycle, this wouldn't be a problem... but oh yeah, this kind of knowledge and ability is outdated and unnecessary and C# can fix it all like magic with a bunch of programmers right out of school...
myths hurt everyone even you. You are hurt by the myth that this level of experience and knowledge is no longer necessary, and yet you suffer the effects of loosing that ability. You aren't really at fault because this is a myth that has spread to management and managment now controls some of those aspects, but the myth is still spread and repeated often, that you don't have to be an expert to program C#. With minimal design, with minimal experience, anyone can throw together something that "works". And then the complaints come out that the development process is poorly conducted, because someone actually believes the myth is true, and we all suffer. But maybe that means that people should perpetuate the myth.
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|