Why [did you choose] C# ?

I have to be very careful when discussing my thoughts on public MSFT statements, since I was previously an MSFT employee, and was party to many of the internal and confidential discussions....

That being said. Take a quick look at "why" the team may have made those statements.

1) In our discussions here, we could not come up with a compelling reason for using C++/CLI as a primary tool for developing business applications [which account for the vast majority of professional software development]

2) Many people are "comfortable" with either C# or even VB.NET. They can accomplish what they need, and do not have to faqce choices [e.g. Should I use Stack Semantics in C++/CLI]. Scott Meyers' said it best "Dont give users of your code multiple ways of accomplishing the same task. They will waste countless hours deciding which to use, when it really doesn't matter most of the time."

3) In any company, resources are limited (to at least some degree). Expending an effort on something that is not going to increase sales enough for the return on investment is simply bad business.

So [IMHO] rather than saying it is a "political statement". I would rather say it is a sound business decision based on both the underlying technical requirements of the available languages, and addressing the desires of the customer community.

Quote:

---

Originally Posted by cjard

Do you need to micromange your resources to this level?

---

In principle the answer is yes. It's a good thing that a language has some mechanism to implement the RAII idiom. C# and C++/CLI have it but Java doesn't. In Java you have to rely completely on the programmer to call a termination method (like dispose or close or whatever) before releasing an object to the GC, otherwise he has a resource leak on his hands.

It can always be discussed how the RAII idiom should be provided by the language but I definately think a GC based language should have it. Here in my view Java is wanting.

Note that this question isn't related to whether a GC is deterministic or not. Determinism in this context means that the pauses the GC imposes on the application is bound in time. It's not related to whether the language supports the RAII idiom.

Quote:

---

Originally Posted by _uj

I found this statement from the Visual C++ team.

...

The Visual C++ team

---

In summary:

"If you want to write unmanaged code, and occasionally reach into managed space, use C++/CLI"
"If you want to write managed code, and occasionally reach into unmanaged space, use C#"

Horses for courses? I dont think _uj has said, through this entire debate, which course she wants her horse to run..

Quote:

---

It's about in which direction the Microsoft money will flow.

---

As ever, but you can ally investment with technical merit, so I'd say the two are linked.

Quote:

---

I still prefer C++/CLI and nobody has put forward strongly convincing arguments that C# is a better language.

---

As far as I was aware, this discussion was never a urinating contest in such absolute terms of "C# vs C++; which is better?"
Several people have put forward convincing arguments why C# is better for them or better for their situation
This, of course, is contextual.. Debates as to the absolute "X is better than Y" dont get very far before they are deleted; its very tiring.

Quote:

---

What I have come to realize though is that the decision isn't that dramatic because the .NET languages can be quite easily mixed.

---

Indeed, you can even have a C# project, a COBOL.NET project and a VB.NET project added to your CLI solution, and singlestep the debugger back and forth between them seamlessly. Given that it's all bytecode, its not rocket science, but it looks that way ;)

End of the day, pick whatever youre happy with, but be sure that the tool is up to the job. It's not a "do or die" world, you can learn both C++/CLI and C# if you really want; doing so enables you to choose which one is best for a particular job. In terms of tools, i really like hammers; whacking nails in is a very satisfying thing. I also see that a hammer can whack a screw in, but i'll probably use a screwdriver. Horses for courses..

Quote:

---

Originally Posted by TheCPUWizard

So [IMHO] rather than saying it is a "political statement". I would rather say it is a sound business decision based on both the underlying technical requirements of the available languages, and addressing the desires of the customer community.

---

I agree. And okay "political" may not have been the right word but it is a communication of Microsoft's strategy (however they reached it).

I also agree that C# like Java are "safe" languages in the sense that they minimize the programmer's opportunities to "shoot themselves in the foot". Both Java and then C# came about as a reaction to the complexity of C++.

After the success of C# and after the failure of Managed C++ it's no big surprise really that C++/CLI has found it hard to establish itself as a strong alternative to C#.

Still, regardless of the above good properties of C# (programmer safety and popularity), it may not be the qualities I'm personally looking for in a language. I like the relative complexity of C++/CLI in relation to C#. I'm not that interested in that other programmers (possibly uneducated and unexperienced) find C# easier than C++/CLI.

In short I can take some pain if it gives some gain and that requires that C++/CLI offers some tangible benefits over C#. I will have to ponder this now with the information I have.

Quote:

---

Originally Posted by _uj

After the success of C# and after the failure of Managed C++ it's no big surprise really that C++/CLI has found it hard to establish itself as a strong alternative to C#.

---

I'm not sure Microsoft saw it as a competition either.. Look at it in purely monetary terms:
Microsoft want $$$, and that means taking some small amount of $ off a lot of people (developers)
Pander to the C++ technical gurus, and also support the internally developed company products that lean heavily on C++.. Invent C++/CLI
Pander to the "uneducated" programmers out there who are clearly too stupid(or jsut dont care) to understand the Really Hard Stuff in C++ -> invent C#

I reckon that both teams, within MS, have reasonably recouped the $ they spent on R&D the language.. MS took sensible business decisions, gave us a choice, we took our personal choices and gave MS $ because they pandered to us, everyone won.

They didnt bother with minor (Ruby...), old (COBOL...) or otherwise crappy (FoxPro...) syntaxes, and the brilliance being that the community will generate those syntaxes for free (for love, not $$)

Quote:

---

Still, regardless of the above good properties of C# (programmer safety and popularity), it may not be the qualities I'm personally looking for in a language.

---

That's the great thing about choice; buy a sports car and deactivate the traction control, airbags, anti-lock brakes etc..

Just a curio; howcome you never complained this loudly about Java? According to your posts, it's even more retarded than C# - did you always hate it?

Quote:

---

I like the relative complexity of C++/CLI in relation to C#. I'm not that interested in that other programmers (possibly uneducated and unexperienced) find C# easier than C++/CLI.

---

So, there's an element of snobbery here? If you could do the job in either C# or C++, you'd choose C++ because it's more "elite" and your programming peers are less likely to be "uneducated/inexperienced"?

For some, that may be as good a reason as any, but if that's your take, its a bit unfair to say that C# pros in this thread havent presented any good reasons in favour of C# (IMHO, of course)

Quote:

---

C++/CLI offers some tangible benefits over C#.

---

I would be very interested if you found a tangible benefit for general application development.

For me to consider it tangible it would have to either:

1) Be significantly easier to write and maintain.
2) Be measurably more performant.
3) Provide access to functionallity that is not possible with C#.

Keep me posted [PM's are fine] :wave:

This is a bit off topic, but inspite of the benefits of an RAII approach to thread locking, I find it interesting that many programmers still seem to take the explicit lock/unlock approach where a lock call is made in the try block and the unlock call is made in the finally block. I wonder why this is?

How come the topic of the thread has changed?

Is it possible for just anybody to do that or is it some freaking administrator who's had a mental breakdown? Set it back immediately.

Of course , anyone can post anything on any topic on any thread.

Are you suprised??? :confused:

Quote:

---

Originally Posted by cjard

Just a curio; howcome you never complained this loudly about Java? According to your posts, it's even more retarded than C# - did you always hate it?

---

I'm not complaining. I'm trying to compare the pros and cons of C# and C++/CLI.

And I actually was negative towards Java in my post #102. Have a look. It was a reply to you.

Quote:

---

So, there's an element of snobbery here? If you could do the job in either C# or C++, you'd choose C++ because it's more "elite" and your programming peers are less likely to be "uneducated/inexperienced"?

---

I wouldn't call it snobbery. In a sense complexity equals freedom. It gives you many options and I like that.

Quote:

---

Originally Posted by TheCPUWizard

Of course , anyone can post anything on any topic on any thread.

Are you suprised??? :confused:

---

Not at all :) I meant the name of the thread has changed. I called it "Why C#". Now it's something else. Who ever changed it, change it back!

Quote:

---

In a sense complexity equals freedom. It gives you many options and I like that.

---

Have you read Scott Meyers' "Effective C++" and "Effective STL books"?

If so, then I take it you disagree with his points, and have the ability to back it up.

If not, then I strongly suggest you read them.

Quote:

---

Originally Posted by TheCPUWizard

Have you read Scott Meyers' "Effective C++" and "Effective STL books"?

If so, then I take it you disagree with his points, and have the ability to back it up.

If not, then I strongly suggest you read them.

---

I don't know what you consider to be Scott Meyers' points. That's "best practice" books aren't they. What has that to do with what I said about complexity?

Yes thet are "Best Practices" for C++ and STL respectively.

One of the key points in the book (which I alluded to earlier), is that choices can often be a BAD thing. If you have one methodology to accomplish a goal, and that methodology provides acceptable results from all aspects, then additional methodologies (especially if they are roughly equivilant) serve no purpose, and typically cause a decrease in productivity and maintainability of the resultant code.

To me this is in direct opposition to your previous statements on the "benefits" of C++. So I was wondering if you had some authoritive input to refute one of the most respected authors in this arena.....

Again, who the heck changed the name of my thread?

Quote:

---

Originally Posted by TheCPUWizard

Yes thet are "Best Practices" for C++ and STL respectively.

One of the key points in the book (which I alluded to earlier), is that choices can often be a BAD thing. If you have one methodology to accomplish a goal, and that methodology provides acceptable results from all aspects, then additional methodologies (especially if they are roughly equivilant) serve no purpose, and typically cause a decrease in productivity and maintainability of the resultant code.

---

That's your interpretation of something you read. What was it you read actually? Can you refer to the actual statement where the author is against choises? If nothing else it allows him to sell his books on how to best navigate the complexities of C++.

I can recommend an even better "best practicies" book where the authors don't claim choise is bad. It's C++ Coding Standards by Sutter/Alexandrescu.

Quote:

---

To me this is in direct opposition to your previous statements on the "benefits" of C++. So I was wondering if you had some authoritive input to refute one of the most respected authors in this arena.....

---

I don't need an authoritative source to tell me whether I like to have options. I just like it. I think it's fun. This is in no way in opposition to the importance of codified experience and guidance. I like that too.

On a more philosophical note most people agree choise is good. In fact you're the first one I've met in a long time who seems to think you've have found evidence to the contrary.

Admin, can this thread title be changed to "Why [did you choose] C# and other assorted rantings?"

Quote:

---

Originally Posted by TheCPUWizard

I would be very interested if you found a tangible benefit for general application development.

---

Ok, I'll bite.
:)

1) Real template classes in pure managed code.
2) Implementing IDispose is simpler in C++/CLI because the compiler adds a lot of boilerplate code for you automatically (and correctly!).

But as I've said, these benefits are outweighed by far bigger benefits found in C#.

Quote:

---

1) Real template classes in pure managed code.

---

I agree true templates are much more powerful than generics. However when you combine generics with reflection and dynamic code generation, I have yet to find an actual scenario where I was not able to accomplish the goal with readable, maintainable code that was less performant (when measured at the application level). [i]Do you have a concrete sample?[/b]

Quote:

---

2) Implementing IDispose is simpler in C++/CLI because the compiler adds a lot of boilerplate code for you automatically (and correctly!).

---

Yes it does add boilerplate, and that can be a little helpful. However, the biggest problem with IDisposable, is that it is be definition illegal to access an objects method after it has been disposed. Yet very few programmers (in any language) actually put the check inside of every method and property like they are supposed to. As an FYI: with "code snippets", adding the boilerplate to C# is literally 3 key strokes. Hard to be able to measure the impact of three keystrokes per class that implements IDisposable as a percentage of total development. Do you have any metrics that would indicate otherwise?

Quote:

---

Originally Posted by TheCPUWizard

I agree true templates are much more powerful than generics. However when you combine generics with reflection and dynamic code generation, I have yet to find an actual scenario where I was not able to accomplish the goal with readable, maintainable code that was less performant (when measured at the application level). Do you have a concrete sample?

---

Templates and generics have different purposes. You cannot accomplish with generics what you can do with templates. Templates are probably the single most important addition to C++ ever.

Concrete samples are everywhere. The C++ standard library depends on them. Boost depends on them. Another good example is Modern C++ Design by Alexandrescu presenting a concept called policy based class design. The book has resulted in a C++ library called Loki.

Who's that administrator or moderator who think it's okay to change the titles of threads? What a stupid thing to do. I don't need some loser to better my writing. Now change it back immediately or I'll spank your sorry azz to a color YOU didn't choose.

Quote:

---

Templates and generics have different purposes. You cannot accomplish with generics what you can do with templates. Templates are probably the single most important addition to C++ ever.

Concrete samples are everywhere. The C++ standard library depends on them. Boost depends on them. Another good example is Modern C++ Design by Alexandrescu presenting a concept called policy based class design. The book has resulted in a C++ library called Loki.

---

I agree with your statements, and an very familiar with Alexandrescu's work.

However your points ignore two thirds of my original post..

Quote:

---

combine generics with reflection and dynamic code generation

---

I have not had any problems implementing all of the functionallity of STL, as well as having implemented many of Alexandresci's concepts (the ones which rely on the pre-processor were the most difficult). So I have still not seen a concrete [itpost or link to actual code] example of some template based construct which can not be accomplished in C# effectively.

Quote:

---

Originally Posted by _uj

I'm not complaining. I'm trying to compare the pros and cons of C# and C++/CLI.

---

Muahhhs, but surely you see that in some ways this is comparing the pros and cons of chalk and cheese? If you have a tummy upset, eat chalk. If youre having a glass of wine, try the cheese :)

Quote:

---

And I actually was negative towards Java in my post #102. Have a look. It was a reply to you.

---

I caught it (in the try..catch sense ;) ), cheers :P

In your day job, do you work in politics? I just wonder because you never seem to give a direct answer to a direct question :)

Quote:

---

I wouldn't call it snobbery. In a sense complexity equals freedom. It gives you many options and I like that.

---

Following this rule, if you write in assembler, you will have ultimate complexity and ultimate freedom..
Why not write in assembler?

Probably because it's too hard.. Or it's beyond that point of economical time spend.. You dont need that level of complexity, or freedom..

Consider thus, that the afficionados of C# dont need that extra level of complexity of C++ or the freedom it grants (and their replies here loosely summarise to them not seeing the benefit of the extra freedom, given the extra complexity).

Again you state that you like something, or that you make a choice based on "like" versus "need". If you didnt need to go any more complex than C#, would you still go more complex and use C++ because you "like" it?

If so, then there is no further purpose to this thread; you have made your decision.

Quote:

---

Why not write in assembler?
Probably because it's too hard..

---

No that is too easy. Just write in hex machine code either to disk using a hex file editor, or to ROM's using a ROM programmer.

Nw that FUN!!! :D

Quote:

---

Originally Posted by TheCPUWizard

No that is too easy. Just write in hex machine code either to disk using a hex file editor, or to ROM's using a ROM programmer.

Nw that FUN!!! :D

---

Heh:

A9 00
60

IIRC that's 'return 0' in C64 machine code.
:D

Quote:

---

Originally Posted by TheCPUWizard

I have not had any problems implementing all of the functionallity of STL, as well as having implemented many of Alexandresci's concepts (the ones which rely on the pre-processor were the most difficult). So I have still not seen a concrete [itpost or link to actual code] example of some template based construct which can not be accomplished in C# effectively.

---

C++/CLI has templates and C# has not. This difference isn't outweighted by your claim to not needing them because you're able to accomplish the same thing using generics. You can come close but you cannot fully replace templates. That's because the key feature of templates is that binding takes place at compile time and you cannot accomplish that with generics which binds at runtime. This gives templates the advantage of static typechecking something you miss out on with generics.

Programmers use available language features to simulate missing features all the time. But that's no strong argument against introducing the missing feature in it's own right if it's considered worthy. So who knows, one day C# may have templates too and then you won't have to work your azz off to simulate them any longer. Or you could escape this hardship right now by using C++/CLI instead of C#.

Quote:

---

Originally Posted by cjard

Quote:

---

And I actually was negative towards Java in my post #102. Have a look. It was a reply to you.

---

I caught it (in the try..catch sense ;) ), cheers :P

---

Well, if you don't understand something I write then please don't hessitate to ask. Is it the RAII idiom that's problematic? Just give me a hint and I'll explain it to you.

Quote:

---

Originally Posted by cjard

Quote:

---

I wouldn't call it snobbery. In a sense complexity equals freedom. It gives you many options and I like that.

---

Following this rule, if you write in assembler, you will have ultimate complexity and ultimate freedom..
Why not write in assembler?

Probably because it's too hard.. Or it's beyond that point of economical time spend.. You dont need that level of complexity, or freedom..

Consider thus, that the afficionados of C# dont need that extra level of complexity of C++ or the freedom it grants (and their replies here loosely summarise to them not seeing the benefit of the extra freedom, given the extra complexity).

Again you state that you like something, or that you make a choice based on "like" versus "need". If you didnt need to go any more complex than C#, would you still go more complex and use C++ because you "like" it?

If so, then there is no further purpose to this thread; you have made your decision.

---

I was saying that I personally don't mind some extra complexity if it offers something tangible in return. For example I've used Java a lot and I appreciate C# for its somewhat higher complexity. Examples could be value types, the RAII idiom and runtime generics, something Java is lacking.

I like complexity but I'm no junkie for it. The extra complexity of C++/CLI won't shy me away but I won't pick C++/CLI just because of it.

To me personally the complexity difference between C++/CLI and C# is not a decisive factor in the choise between them. Other programmers may think differently. And many, maybe most, don't really have a choise. C# was picked for them because managers considered it a good idea to not give them too much complexity to do damage with. One should remember that the advent of C# has a lot to do with the needs of business to have access to a large pool of unsophisticated programmers willing to become cheap labour chained to their keybords in coding sweatshops.

So dear fellow C# programmer, break out of your misery and enjoy the freedom of C++/CLI in all its complexity! :)

I found the Visual C++ team statement (see #97) disappointing so I've asked a follow up question over at the Microsoft forums. I'm interested in under what circumstances the Visual C++ team recommends that Visual C# is rather used?

-------------------------------------------------------------------

>> The Visual C++ team

Thank your for this statement althought I find it disappointing. I would have hoped for C++/CLI to be a first class .NET citizen. Or maybe it still is? Visual C++ is an IDE after all and not the C++/CLI language itself.

So what does the statement actually imply for C++/CLI as a language. Has it now reached its final form and will there be no further evolution at all? I understand that C# maybe will develop faster and that more avant-garde features will be introduced, but what about C++/CLI? Will it be "as is" for the foreseeable future and improvements and enhancements won't even be considered?

And regarding the status of Visual C++ as an IDE for the development of managed applications. Lets say I wanted to develop a new large .NET managed application and an important part of the application will be native classic C++ (although with a thin interop interface). I also want the option of easy interoping with native C++ code should the need arise. Say I like C++/CLI as a language and I don't need lots of fancy stuff like visual GUI editors, just a decent coding environment.

Under the above circumstances do you recommend I rather use Visual C# than Visual C++?

Quote:

---

Originally Posted by _uj

Well, if you don't understand something I write then please don't hessitate to ask. Is it the RAII idiom that's problematic? Just give me a hint and I'll explain it to you.

---

When I said "I caught it, in the try..catch sense" I meant

Code:

---


  try{
    cjard.GetRespose(_uj, "java")
  }catch(Exception){
  }

---

There are many things I dont understand, but I dont feel that it limits me.. Though I understand RAII, I dont quite understand your point about it, or the disparity between your assertion that youre a capable programmer who loves complexity, but cannot remember (or decide when) to dispose her objects that need disposing and hence must use a language that disposes everything, automatically, just incase..
You derise languages that do not offer complexity, then praise a language that hides complexity by arranging operations automatically?
It seems somewhat hypocritical to me. Perhaps you can explain this aspect of your argument?

Quote:

---

Originally Posted by _uj

I like complexity but I'm no junkie for it. The extra complexity of C++/CLI won't shy me away but I won't pick C++/CLI just because of it.

To me personally the complexity difference between C++/CLI and C# is not a decisive factor in the choise between them.

---

It almost feels like youre going back on yourself? Previously you were asserting that C++ would be your choice because you value the freedom you perceive the extra complexity brings you.. Now youre saying the extra complexity wouldnt make you choose the language?

Quote:

---

Lets say I wanted to develop a new large .NET managed application and an important part of the application will be native classic C++ (although with a thin interop interface). I also want the option of easy interoping with native
C++ code should the need arise.

---

Eaahhah. That tickled me. Lets say your local council wanted to build a large, brand new swimming pool and an important part of the new pool will actually be the old pool because it has really nice tiles and.. um.. they spent a lot of money on them 25 years ago. And they quite like them. They also are still good buddies with the contractor who installed them as a personal favour and want the option of not upsetting that contractor so they can carry on using them.

If you want to develop a new, large .NET app, reusing a huge block of old code wont make it a new application, any more than some VB6 old timer uses the Upgrade Wizard to bring his old app into VB.NET, recompile it and say "woo, look. I made a new .NET app", relying on the Microsoft.VisualBasic.dll to make all the legacy calls work.

However, this is the first moment in this thread that I've started to see an acknowledgement from you that you might consider using a tool appropriate for a job, rather than the tool you quite like?

Quote:

---

Say I like C++/CLI as a language and I don't need lots of fancy stuff like visual GUI editors, just a decent coding environment

---

No need to use the IDE then? Youre only tied to the VisualC++ team because you like the language they are implementing, not the IDE. The other thing that puzzles me; you talk about language features like templates, that basically do a good job of writing code for you, then bash the IDE, which doesnt do much more than provide a nice place to write code and a couple of visual editors that also (just like templates) write some pretty good code for you. Volumes of it..

What exactly are you looking to bash here?

Quote:

---

Originally Posted by _uj

So who knows, one day C# may have templates too and then you won't have to work your azz off to simulate them any longer. Or you could escape this hardship right now by using C++/CLI instead of C#.

---

Crikey, you bang on about language features C++ has, that X doesnt have as though all X programmers are up in arms that they dont have them, and labour away for days implementing them over and over. I dont recall ever switching language because the new one was sexier than the old one, or had X, Y and Z features.. All my language switches have been based on the job requirement*, or prudence within context.

*perhaps with the exception of using C# despite being told to use VB.NET because VB.NET is a dirrrty language

Tell me; who is the more capable programmer: The one who is told "welcome to your new job. this year we have decided to move to vb.net." Is it
a) the one that responds "ok, i never used it but i dont think that will stop me writing good code" or
b) "ooh, you dont want to use that crap, use something powerful like C++/CLI because it is complex beyond your wildest dreams and you can do everything with it. it rocks, and I wont use anything less"

Quote:

---

Originally Posted by _uj

So dear fellow C# programmer, break out of your misery and enjoy the freedom of C++/CLI in all its complexity

---

Lmao..
"When I want your opinion, I'll give it to you" -- ulrika ;)

I'm a fellow programmer? You mean you use C#? But I thought you used C++/CLI because C# was too n00bish for you? I get more amusingly confused by the minute.. ;)

I'm not actually in any misery, C# doesnt make me suffer, I find the C++ syntax significantly more misery invoking than the C# but I'm intrigued to find out why you dont.. Are you a good teacher? you answer technical questions pretty well but that's not usually an indicator..

One quick question though; once I embrace the religion of C++hristianity, and all is light and my problems go away, will I spend my life preaching this new-found religion to other, significantly more inept and uneducated serfs, plebs and other such C# programmers? :)

ps, if this was a wikipedia article, it would probably look like:


"C# was picked for them because managers considered it a good idea to not give them too much complexity to do damage with [citation needed] . One should remember that the advent of C# has a lot to do with the needs of business to have access to a large pool of unsophisticated programmers willing to become cheap labour chained to their keybords in coding sweatshops[citation needed] . "

Quote:

---

Originally Posted by cjard

ps, if this was a wikipedia article, it would probably look like:

"C# was picked for them because managers considered it a good idea to not give them too much complexity to do damage with [citation needed] . One should remember that the advent of C# has a lot to do with the needs of business to have access to a large pool of unsophisticated programmers willing to become cheap labour chained to their keybords in coding sweatshops[citation needed] . "

---

Are you stunned by the naked truth? I just expressed bluntly what everybody knows except maybe naive programmers who think "programmer safety" is a concern for their well-being. The citations you feel is missing could be measured in tons. I won't pursue this though because it was just a joke really. :)

Quote:

---

Originally Posted by cjard

There are many things I dont understand, but I dont feel that it limits me.. Though I understand RAII, I dont quite understand your point about it, or the disparity between your assertion that youre a capable programmer who loves complexity, but cannot remember (or decide when) to dispose her objects that need disposing and hence must use a language that disposes everything, automatically, just incase..

---

Everybody makes mistakes and the more unlikely a mistake is the harder it is to find. So both experienced programmers and newbies benefit from built-in language safety.

Quote:

---

You derise languages that do not offer complexity, then praise a language that hides complexity by arranging operations automatically?
It seems somewhat hypocritical to me. Perhaps you can explain this aspect of your argument?

---

There's often a tradeoff between on one hand simplicity and safety, and on the other hand efficiency and flexibility (and thus complexity).

I've said (many times now) that I personally don't mind more complexity if it also delivers some tangible benefits (in the form of higher efficiency and more flexibility). I don't think I can express this clearer now.

Quote:

---

Originally Posted by cjard

It almost feels like youre going back on yourself?

---

And I feel you've entered on a nitpicking path here. If you have something you want to discuss please say what it is and be specific. I don't have time to consider general rantings about everything. I've made lots of replies directly to you but you just leave them without comment. To discuss I need some structure otherwise this isn't going anywhere.

Quote:

---

Originally Posted by _uj

And I feel you've entered on a nitpicking path here. If you have something you want to discuss please say what it is and be specific. I don't have time to read through and make sense of general rantings.

---

Wha? But you have time to complain repeatedly that an admin has changed the title of your post.

And I have not seen (either here or via PM) a single re-world business application scenarion that addresses the points I made way back in post #106).....

Quote:

---

Originally Posted by _uj

And I feel you've entered on a nitpicking path here.

---

When I read a spec, and it's confusing I seek clarity. I wouldnt enjoy working for you if you dismissed it irritatedly as nit-picking..

Quote:

---

If you have something you want to discuss please say what it is and be specific.

---

I have asked you many direct questions to you that have gone completely unanswered and ignored...

Quote:

---

I've made lots of replies directly to you but you just leave them without comment.

---

...and I have deliberately avoided rising to some of your comments that I felt were being a little provocative/inflammatory.

Interestingly, I'm not ripping into you for not answering my questions; why rip into me for choosing to pay little more than a couple of sarcastic references to your flamebaits?

Quote:

---

To discuss I need some structure otherwise this isn't going anywhere.

---

This discussion goes wherever you take it, given that you dont really respond to points others make, and digress spuriously to irrelevant topics such as thread renames.. Is there something of your conversational style I have misunderstood?

Quote:

---

Originally Posted by _uj

I just expressed bluntly what everybody knows except maybe naive programmers who ....

---

I like you; you make me laugh. I dont know where you get this from, but your opinions do tickle me. There's a very amiable quality to your needling; when I consider how you would debate this in person, I actually see Sabine Schmidt, ridiculing Jeremy Clarkson for his appalling efforts to drive a 2.7 litre bi-turbo diesel Jaguar round the Nurburgring in less than 10 minutes, before she went out and wiped the floor with his time, in a Ford Transit van.

With the obvious exception, of course, that your English is much better..

Quote:

---

Originally Posted by _uj

I've said (many times now) that I personally don't mind more complexity if it also delivers some tangible benefits (in the form of higher efficiency and more flexibility). I don't think I can express this clearer now.

---

Yup.. I totally understand that, which was why I expressed a while ago that, really, you already made your decision to use C++ because you perceive it is the only language capable of offering you the complexity you feel you need, regardless of context. What are we debating now?

This topic reminds me of an old adage. "Make things as simple as possible, but no simpler".

Yes, there are programming situations that require complexity. In my [30+ years] experience, these are almost always related to scientific programming, industrial control, embedded systems, hardware interfaces, etc. They almost never appear in business applications (which according to a 2005 Gartner survey accounted for over 85% of all code developed, and was the prime focus of over 92% of proffesional programmers). So even assuming that 10% (and I believe this to be high, as the routines containing the complexity can usually be encapsulated into a small portion of the total system) of the code in the above type systems require the complexity. We are dealing with about 0.8% of all code being developed.

Oh, and I am fairly sure the person responsible for the above quotation was neither "in-experienced" of "(sicentifically) naive"...It was Albert Einstein who spend his life trying to always find simper solutions. ;)

Quote:

---

Originally Posted by Arjay

Wha? But you have time to complain repeatedly that an admin has changed the title of your post.

---

Sure, it's the most extraordinary event that's happened in this thread. It was when some ADMIN decided he knew better than me what I wanted to call my own thread.

I don't have words for it really so I just call it "legally questionable".

Quote:

---

Originally Posted by cjard

Yup.. I totally understand that, which was why I expressed a while ago that, really, you already made your decision to use C++ because you perceive it is the only language capable of offering you the complexity you feel you need, regardless of context. What are we debating now?

---

Well you're wrong because you haven't been listening.

Quote:

---

Originally Posted by cjard

With the obvious exception, of course, that your English is much better..

---

I don't speak native english but on the other hand I'm a very good programmer. Is my english language mistakes bothering you? I don't mind you pointing them out so I can avoid them.

Quote:

---

Is my english language mistakes bothering you? I don't mind you pointing them out so I can avoid them.

---

Actually I took cjard's comment as a complement o you. I have never had even the slightest problem understanding your posts (from a linguistic point of view...I still don't understand your opinions ;) ]

Quote:

---

Originally Posted by _uj

Sure, it's the most extraordinary event that's happened in this thread. It was when some ADMIN decided he knew better than me what I wanted to call my own thread.

---

Well, IMESHO, the current title is actually more pertinent to the discussion; it was previously a bit ambiguous, dont you think?

That said.. the suggestion a few pages back was hilarious.. ;)

Quote:

---

Originally Posted by _uj

Well you're wrong because you haven't been listening.

---

ROFL.. of course I have! I've just been struggling at all this cross purpose talk that's going on!

I note with further interest that you have still to answer pretty much every direct question I've asked of you ever since you complained that I dont respond to your points..

Not that I'm complaining that you dont respond to my questions.. I dont mind, I just find the double standard amusing. :)

Quote:

---

Originally Posted by _uj

I don't speak native english but on the other hand I'm a very good programmer. Is my english language mistakes bothering you? I don't mind you pointing them out so I can avoid them.

---

Well, I would offer a "you teach me C++, I'll teach you English" deal, but I'm not that cruel; you would have vastly more work to do than I, and a significantly thicker student, no doubt (being a C# programmer and all :D:D)

Why c#, well I always slowly advance myself to new technolgies in software developing. My first programming language was C then C++ (about a year I wrote my C++ code in C style :rolleyes: ) and now it`s a C#. Why? because current project I`m working with is writing on C#.

Re-reading the thread, I realized I didn't respond to the following a while back:

Quote:

---

C++/CLI has templates and C# has not. This difference isn't outweighted by your claim to not needing them because you're able to accomplish the same thing using generics. You can come close but you cannot fully replace templates. That's because the key feature of templates is that binding takes place at compile time and you cannot accomplish that with generics which binds at runtime. This gives templates the advantage of static typechecking something you miss out on with generics.

---

I have previously agreed that generics and templates are different animals. However, my comment of:

Quote:

---

And I have not seen (either here or via PM) a single re-world business application scenarion that addresses the points I made way back in post #106).....

---

Still stands.

If someone can point out a business application scenario, where the differences between templates and generics has proven to:

a) Introduce or Limit Business Functionallity of a Business Application
or
b) Require a a significant difference in development time of a Business Application.
or
c) Caused a measurable and significant performance impace on a Business Application
or
d) Caused a measurable and significant maintainability issue on a Business Application

Then I would be very interested in hearing the deatails....

Quote:

---

Originally Posted by TheCPUWizard

If someone can point out a business application scenario, where the differences between templates and generics has proven to:

a) Introduce or Limit Business Functionallity of a Business Application
or
b) Require a a significant difference in development time of a Business Application.
or
c) Caused a measurable and significant performance impace on a Business Application
or
d) Caused a measurable and significant maintainability issue on a Business Application

Then I would be very interested in hearing the deatails....

---

I'll get back to you on that one.