I have noticed that there is ...
-
Nemanja Trifunovic wrote: C# is a disaster: takes the worst part of C++ (syntax) without inheriting its main strengths: static type system, RAII, performance, flexibility. Actually, C# reminds me a lot more of Java than C++. Granted, Java can look a good bit like C++, but they both steal shamelessly from C (which i'll refer to here as "the second greatest language ever to exist", since we're basing all this on personal taste anyway) in the syntax department. Nemanja Trifunovic wrote: Geez, I learned 10 years ago that a cast is often a sign of an error in design Bah, that's C++ talk, that is. Any C programmer worth his salt knows: when in doubt, cast to void* and deal with it later... Design is for high-level concepts like algorithms and blame, not petty syntax details.
Shog9
I'm not the Jack of Diamonds... I'm not the six of spades. I don't know what you thought; I'm not your astronaut...
Shog9 wrote: "the second greatest language ever to exist" This begs the question: What's the greatest language ever to exist? :) -- Oneigaishimasu! I blog too now[^]
-
Nemanja Trifunovic wrote: C# may be a good fit for web development (although web developers :laugh: I've heard that quite often. Somehow people confuse .NET with something related to the Internet, I'm sure the marketing folks are happy, but the developers may be a bit annoyed. But seriously, what makes you think that C# is web concentric? Nemanja Trifunovic wrote: but for complex desktop apps and libraries it is a disaster. Can you back up that claim with facts? Nemanja Trifunovic wrote: the stupid thing creates a new object on heap whenever a string needs to be changed (just don't mention the brain-damaged concept of StringBuilder) How often do you really need to change the actual contents of a string? And when you do, in what way do you find StringBuilder insufficient or even awkward to use? Nemanja Trifunovic wrote: Oh, and what about all this casting up and down? Geez, I learned 10 years ago that a cast is often a sign of an error in design - with C# you need to cast all the time. :omg::~ Uhm, you do?, why?... I don't make any more type casts in C# that I do in C++. If you find yourself casting a lot, then it's time to consider if you're missing something in your design. Nemanja Trifunovic wrote: and in no time all the memory is gone and GC starts in the middle of processing. Yep, this makes C# unsuited for apps that are time critical such as Medical Equipment and action games. Now, when we talk Medical Equipment, and other Mission Critical hardware products, you'll find that even C++ is rarely used here. As for action games, while it's a dream for most programmers I think, it's hard to find a lucky bastard who actually got such a job. I think we can safely say, that most applications are 'simple' desktop apps, and you'll have a hard time finding anyone, that are really annoyed by the GC using a second or two. "After all it's just text at the end of the day. - Colin Davies "For example, when a VB programmer comes to my house, they may say 'does your pool need cleaning, sir ?' " - Christian Graus
jan larsen wrote: , and you'll have a hard time finding anyone, that are really annoyed by the GC using a second or two. *BZZzzzzzzzzzzzzzzzzzz* -- Oneigaishimasu! I blog too now[^]
-
Jörgen Sigvardsson wrote: C++ has more intrinsic features than C#. Amen to that :-) Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
<misc-info>Did you know that the pope's last word was "Amen"?</misc-info> -- Oneigaishimasu! I blog too now[^]
-
jan larsen wrote: , and you'll have a hard time finding anyone, that are really annoyed by the GC using a second or two. *BZZzzzzzzzzzzzzzzzzzz* -- Oneigaishimasu! I blog too now[^]
I meant Users. Of course we all strive for optimate performance, but most users don't want to pay 1000% overtime for a 100% performance gain. And I wouldn't even advice them to. Besides that, I don't think it's that easy to monitor a practical performance gain in a simple desktop app. The real bottlenecks are found in the DBMS and the network communication. Computers these days aren't that much troubled by a few forms and buttons :-) "After all it's just text at the end of the day. - Colin Davies "For example, when a VB programmer comes to my house, they may say 'does your pool need cleaning, sir ?' " - Christian Graus
-
Programmer2k4 wrote: a lot of VB .Net bashing (with the lack of a better word). Really ? That's TERRIBLE. Who did that ? We should tar and feather them immediately. Programmer2k4 wrote: I feel that VB .Net deserves more credit than what the language is currently given. Yeah, I agree. It's a great way for non programmers to get a pretty window on the screen, no doubt about it. Programmer2k4 wrote: Is VB .Net still for complete programming idiots? Well, here's the real problem. VB.NET initially was a nice .NET language implimentation using VB syntax. Then all the VB6 users got up in arms about all the hacks they were going to lose, so the quality of the language eroded. Put simply - VB.NET and C# do the same thing, as far as the machine is concerned. As far as the programmer is concerned, C# is cleaner, neater, and better designed. Also, the majority of people using VB.NET are moving from VB6, a known breeding ground for ignorance. In the old world, one group of people asked 'what's the best way to program', and one asked 'what's the easiest way to program'. Those in one camp moved from C++ to C#, if necessary ( it was for me, ASP.NET rocks ). Those in the other camp are grudgingly moving from VB6 to VB.NET and signing petitions that Microsoft continue to support VB6 because they, unlike me, are scared to learn a 'new' language. There are good VB programmers and bad C++ programmers. The difference is that code from a bad VB programmer will probably still compile and do something, which makes it far more dangerous. Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
Nicely put Christian. You've got my 5 for this one. :) Anna :rose: Riverblade Ltd - Software Consultancy Services Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.
-
<misc-info>Did you know that the pope's last word was "Amen"?</misc-info> -- Oneigaishimasu! I blog too now[^]
Jörgen Sigvardsson wrote: Did you know that the pope's last word was "Amen"? Poor fellow must have said "Oh man!" and someone misinterpreted it as "amen" :-) Nish
-
Quite late, don't ya think? Today is 3rd April... David Never forget: "Stay kul and happy" (I.A.)
David's thoughts / dnhsoftware.org / MyHTMLTidyYet another late delivery... The tigress is here :-D
-
Nemanja Trifunovic wrote: C# may be a good fit for web development (although web developers :laugh: I've heard that quite often. Somehow people confuse .NET with something related to the Internet, I'm sure the marketing folks are happy, but the developers may be a bit annoyed. But seriously, what makes you think that C# is web concentric? Nemanja Trifunovic wrote: but for complex desktop apps and libraries it is a disaster. Can you back up that claim with facts? Nemanja Trifunovic wrote: the stupid thing creates a new object on heap whenever a string needs to be changed (just don't mention the brain-damaged concept of StringBuilder) How often do you really need to change the actual contents of a string? And when you do, in what way do you find StringBuilder insufficient or even awkward to use? Nemanja Trifunovic wrote: Oh, and what about all this casting up and down? Geez, I learned 10 years ago that a cast is often a sign of an error in design - with C# you need to cast all the time. :omg::~ Uhm, you do?, why?... I don't make any more type casts in C# that I do in C++. If you find yourself casting a lot, then it's time to consider if you're missing something in your design. Nemanja Trifunovic wrote: and in no time all the memory is gone and GC starts in the middle of processing. Yep, this makes C# unsuited for apps that are time critical such as Medical Equipment and action games. Now, when we talk Medical Equipment, and other Mission Critical hardware products, you'll find that even C++ is rarely used here. As for action games, while it's a dream for most programmers I think, it's hard to find a lucky bastard who actually got such a job. I think we can safely say, that most applications are 'simple' desktop apps, and you'll have a hard time finding anyone, that are really annoyed by the GC using a second or two. "After all it's just text at the end of the day. - Colin Davies "For example, when a VB programmer comes to my house, they may say 'does your pool need cleaning, sir ?' " - Christian Graus
jan larsen wrote: I don't make any more type casts in C# that I do in C++ this is the most annoying aspect of working with collections in C# (i'm talking about 1.0 version which doesn't support generics, of course). you have to cast everything from object to your target type, or you must provide a different specialized collection for every type (and still you must support Add(object o) in interface, so there is no type safety in it). there is also no support for returning covariant types in interfaces: C++ also doesn't support it, but you can at least workaround this to some extent using templates. also, i find the handling of value types in containers horrible, with all the boxing/unboxing. ever tried to foreach over a collection of value type instances, and change something? you can't, you must change the the whole object, because you only get the copy. also, foreach is so much slower than simple for loop, that i don't even use it. OTOH, what i like in C# is intrinsic support for properties and events, but this is something you can have in C++ too, with some quite simple coding. and one more thing: the complete abomination of "using" statement to handle object lifetime. so they added a keyword (which already head 2 different meanings) to the language to support the IDisposable interface, which is just a convention on the framework level?
-
Programmer2k4 wrote: a lot of VB .Net bashing (with the lack of a better word). Really ? That's TERRIBLE. Who did that ? We should tar and feather them immediately. Programmer2k4 wrote: I feel that VB .Net deserves more credit than what the language is currently given. Yeah, I agree. It's a great way for non programmers to get a pretty window on the screen, no doubt about it. Programmer2k4 wrote: Is VB .Net still for complete programming idiots? Well, here's the real problem. VB.NET initially was a nice .NET language implimentation using VB syntax. Then all the VB6 users got up in arms about all the hacks they were going to lose, so the quality of the language eroded. Put simply - VB.NET and C# do the same thing, as far as the machine is concerned. As far as the programmer is concerned, C# is cleaner, neater, and better designed. Also, the majority of people using VB.NET are moving from VB6, a known breeding ground for ignorance. In the old world, one group of people asked 'what's the best way to program', and one asked 'what's the easiest way to program'. Those in one camp moved from C++ to C#, if necessary ( it was for me, ASP.NET rocks ). Those in the other camp are grudgingly moving from VB6 to VB.NET and signing petitions that Microsoft continue to support VB6 because they, unlike me, are scared to learn a 'new' language. There are good VB programmers and bad C++ programmers. The difference is that code from a bad VB programmer will probably still compile and do something, which makes it far more dangerous. Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
Christian Graus wrote: There are good VB programmers and bad C++ programmers. The difference is that code from a bad VB programmer will probably still compile and do something, which makes it far more dangerous. :laugh: this is so much true. i'm really thinking about using this as signature.
-
jan larsen wrote: I don't make any more type casts in C# that I do in C++ this is the most annoying aspect of working with collections in C# (i'm talking about 1.0 version which doesn't support generics, of course). you have to cast everything from object to your target type, or you must provide a different specialized collection for every type (and still you must support Add(object o) in interface, so there is no type safety in it). there is also no support for returning covariant types in interfaces: C++ also doesn't support it, but you can at least workaround this to some extent using templates. also, i find the handling of value types in containers horrible, with all the boxing/unboxing. ever tried to foreach over a collection of value type instances, and change something? you can't, you must change the the whole object, because you only get the copy. also, foreach is so much slower than simple for loop, that i don't even use it. OTOH, what i like in C# is intrinsic support for properties and events, but this is something you can have in C++ too, with some quite simple coding. and one more thing: the complete abomination of "using" statement to handle object lifetime. so they added a keyword (which already head 2 different meanings) to the language to support the IDisposable interface, which is just a convention on the framework level?
Zdeslav Vojkovic wrote: this is the most annoying aspect of working with collections in C# (i'm talking about 1.0 version which doesn't support generics, of course). you have to cast everything from object to your target type, or you must provide a different specialized collection for every type (and still you must support Add(object o) in interface, so there is no type safety in it). ICollection does not require an Add method, you only have to expose type loose methods if you're implementing eg. IList. That is why I rarely extends those interfaces :-) Agreed, untill 2.0 is out of beta, we still have a lot of work to do when using collections, but while we're at it, it annoys me even more that the STL doesn't come with a Hashtable. Zdeslav Vojkovic wrote: also, i find the handling of value types in containers horrible, with all the boxing/unboxing. ever tried to foreach over a collection of value type instances, and change something? you can't, you must change the the whole object, because you only get the copy. Que?, I don't think I can see the problem. What exactly is it that you want to do with the value type instance? And more important, how often do you actually have a collection of value types?, I can't remember that I ever had a live need for such a construct. Zdeslav Vojkovic wrote: also, foreach is so much slower than simple for loop, that i don't even use it. Unless of course you're iterating a linked list or a tree :-) Zdeslav Vojkovic wrote: and one more thing: the complete abomination of "using" statement to handle object lifetime. so they added a keyword (which already head 2 different meanings) to the language to support the IDisposable interface, which is just a convention on the framework level? I totally disagree,
usingis so intuitive to use, and would you really rather do this:Connection connection = null;
try
{
connection = new Connection();
Statement statement = null;
try
{
statement = connection.CreateStatement();
}
finally
{
if (statement != null)
{
statement.Dispose();
}
}
}
finally
{
if (connection != null)
{
Connection.Dispose();
}
}Instead of this?:
using (Connection connection = new Connection())
{
using (Statement statement= connection.CreateStatement())
{}
}"After all it
-
Zdeslav Vojkovic wrote: this is the most annoying aspect of working with collections in C# (i'm talking about 1.0 version which doesn't support generics, of course). you have to cast everything from object to your target type, or you must provide a different specialized collection for every type (and still you must support Add(object o) in interface, so there is no type safety in it). ICollection does not require an Add method, you only have to expose type loose methods if you're implementing eg. IList. That is why I rarely extends those interfaces :-) Agreed, untill 2.0 is out of beta, we still have a lot of work to do when using collections, but while we're at it, it annoys me even more that the STL doesn't come with a Hashtable. Zdeslav Vojkovic wrote: also, i find the handling of value types in containers horrible, with all the boxing/unboxing. ever tried to foreach over a collection of value type instances, and change something? you can't, you must change the the whole object, because you only get the copy. Que?, I don't think I can see the problem. What exactly is it that you want to do with the value type instance? And more important, how often do you actually have a collection of value types?, I can't remember that I ever had a live need for such a construct. Zdeslav Vojkovic wrote: also, foreach is so much slower than simple for loop, that i don't even use it. Unless of course you're iterating a linked list or a tree :-) Zdeslav Vojkovic wrote: and one more thing: the complete abomination of "using" statement to handle object lifetime. so they added a keyword (which already head 2 different meanings) to the language to support the IDisposable interface, which is just a convention on the framework level? I totally disagree,
usingis so intuitive to use, and would you really rather do this:Connection connection = null;
try
{
connection = new Connection();
Statement statement = null;
try
{
statement = connection.CreateStatement();
}
finally
{
if (statement != null)
{
statement.Dispose();
}
}
}
finally
{
if (connection != null)
{
Connection.Dispose();
}
}Instead of this?:
using (Connection connection = new Connection())
{
using (Statement statement= connection.CreateStatement())
{}
}"After all it
jan larsen wrote: ICollection does not require an Add method, you only have to expose type loose methods if you're implementing eg. IList. That is why I rarely extends those interfaces IList is what i meant. i'm not using C# for last six months, so i already started to forget details :) jan larsen wrote: Que?, I don't think I can see the problem. What exactly is it that you want to do with the value type instance? And more important, how often do you actually have a collection of value types i find it really annoying that something like this is impossible:
int[] ar = {1, 2, 3}; foreach (int i in ar) { i = i * 2; }of course, this is just a simplified example, but every so often i have a need to iterate over some simple data and change them. even worse, if it were reference type, it would also be impossible because the returned data is not a reference to real data, but to copy, which is essentially read-only, so foreach is generally usable only in read-only scenario. this just doesn't compile:string[] strs = {"aa", "bb", "cc"}; foreach (string s in strs) { s = s + "_x"; }jan larsen wrote: I totally disagree, using is so intuitive to use i know what's the use for "using" and that it is far better than try-finally, i believe that there is no need for both in the first place, and that it is just a hack. i simply don't like littering the language with workarounds for framework issues. i like the way it is done in C++/CLI when the object is automatically disposed when it goes out of scope (and i'm aware why this is not supported in C#) -
jan larsen wrote: I don't make any more type casts in C# that I do in C++ this is the most annoying aspect of working with collections in C# (i'm talking about 1.0 version which doesn't support generics, of course). you have to cast everything from object to your target type, or you must provide a different specialized collection for every type (and still you must support Add(object o) in interface, so there is no type safety in it). there is also no support for returning covariant types in interfaces: C++ also doesn't support it, but you can at least workaround this to some extent using templates. also, i find the handling of value types in containers horrible, with all the boxing/unboxing. ever tried to foreach over a collection of value type instances, and change something? you can't, you must change the the whole object, because you only get the copy. also, foreach is so much slower than simple for loop, that i don't even use it. OTOH, what i like in C# is intrinsic support for properties and events, but this is something you can have in C++ too, with some quite simple coding. and one more thing: the complete abomination of "using" statement to handle object lifetime. so they added a keyword (which already head 2 different meanings) to the language to support the IDisposable interface, which is just a convention on the framework level?
Zdeslav Vojkovic wrote: ever tried to foreach over a collection of value type instances, and change something? you can't, you must change the the whole object That sounds correct. A value type is immutable. IIRC that appies to value types in any OO language (if that condition does not apply then it is not a value type in the OO sense)
My: Blog | Photos | Next SQL Presentation WDevs.com - Open Source Code Hosting, Blogs, FTP, Mail and More
-
Zdeslav Vojkovic wrote: ever tried to foreach over a collection of value type instances, and change something? you can't, you must change the the whole object That sounds correct. A value type is immutable. IIRC that appies to value types in any OO language (if that condition does not apply then it is not a value type in the OO sense)
My: Blog | Photos | Next SQL Presentation WDevs.com - Open Source Code Hosting, Blogs, FTP, Mail and More
an integer is a value type (in .NET sense). this would mean that you can't change an integer. if you follow the same logic this should be illegal:
System.Drawing.Rectangle rc = new System.Drawing.Rectangle(5, 10, 15, 20); rc.Offset(1,2);if i can offset a rectangle this way, it should also be possible to do it inside foreach statement. -
Shog9 wrote: "the second greatest language ever to exist" This begs the question: What's the greatest language ever to exist? :) -- Oneigaishimasu! I blog too now[^]
-
Programmer2k4 wrote: Is VB .Net still for complete programming idiots? No. It's the other way around. VB creates programming idiots out of perfectly teachable, albeit inexperienced, programmers. This is an important distinction. We forget that we all (or almost all of us) have programmed in some sort of B language at one point or another. The lucky ones were able to mature out of their programming childhood. In other words, VB is like a bad parent. It can really screw up your childhood. Marc MyXaml Advanced Unit Testing YAPO
-
Marc Clifton wrote: In other words, VB is like a bad parent. It can really screw up your childhood. I love it!! Can I use that as my sig? Gary Marc Clifton: "In other words, VB is like a bad parent. It can really screw up your childhood."
Gary Thom wrote: Can I use that as my sig? Sure! :-D Marc MyXaml Advanced Unit Testing YAPO
-
<misc-info>Did you know that the pope's last word was "Amen"?</misc-info> -- Oneigaishimasu! I blog too now[^]
-
Programmer2k4 wrote: Is VB .Net still for complete programming idiots? No. It's the other way around. VB creates programming idiots out of perfectly teachable, albeit inexperienced, programmers. This is an important distinction. We forget that we all (or almost all of us) have programmed in some sort of B language at one point or another. The lucky ones were able to mature out of their programming childhood. In other words, VB is like a bad parent. It can really screw up your childhood. Marc MyXaml Advanced Unit Testing YAPO
Marc Clifton wrote: VB is like a bad parent. It can really screw up your childhood it can screw up your adulthood, too. after 18 months of forced VB-script, i find myself writing:
if (c > 10) then
{
c = 10;
}whenever i get to play with C++ again. Image Toolkits | Image Processing | Cleek
-
jan larsen wrote: ICollection does not require an Add method, you only have to expose type loose methods if you're implementing eg. IList. That is why I rarely extends those interfaces IList is what i meant. i'm not using C# for last six months, so i already started to forget details :) jan larsen wrote: Que?, I don't think I can see the problem. What exactly is it that you want to do with the value type instance? And more important, how often do you actually have a collection of value types i find it really annoying that something like this is impossible:
int[] ar = {1, 2, 3}; foreach (int i in ar) { i = i * 2; }of course, this is just a simplified example, but every so often i have a need to iterate over some simple data and change them. even worse, if it were reference type, it would also be impossible because the returned data is not a reference to real data, but to copy, which is essentially read-only, so foreach is generally usable only in read-only scenario. this just doesn't compile:string[] strs = {"aa", "bb", "cc"}; foreach (string s in strs) { s = s + "_x"; }jan larsen wrote: I totally disagree, using is so intuitive to use i know what's the use for "using" and that it is far better than try-finally, i believe that there is no need for both in the first place, and that it is just a hack. i simply don't like littering the language with workarounds for framework issues. i like the way it is done in C++/CLI when the object is automatically disposed when it goes out of scope (and i'm aware why this is not supported in C#)Zdeslav Vojkovic wrote: i like the way it is done in C++/CLI when the object is automatically disposed when it goes out of scope (and i'm aware why this is not supported in C#) Yes, but if you ever take an object allocated on the stack and store its address (by pointer or reference) as an element of a collection (for later retrieval), BOOM! Regards, Alvaro
Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is. -- GWB, 1999.
-
I am dead serious. VB is bad, but C# is a disaster. See this presentation[^] by Bjarne Stroustrup: The dilemma is real •The most elegant languages –(e.g. Smalltalk, ML, Haskell, Common Lisp) –Are not applicable for many important application areas –Are not efficient for many important problems –Are apparently not manageable for most programmers •The most efficient languages –(e.g. C, C++, Fortran) –Encourage low-level messing/hacking –Have problems expressing some important problems elegantly –Are hard to “restrain”for reasoning/analysis/transformation •Many language are neither fish nor fowl –(e.g. Java and C#) –Neither elegant nor efficient –Not applicable for many important application areas
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
C# is a disaster for anything aside from windows programming, and if you are using it for anything else, you're insane. As a windows application development language, C# (and .NET) are very nice indeed. "The Yahoos refused to be tamed."