Revenge of Redmond – C# and the .Net Frameworks
-
Ever since my birth I've seen a growing ignorance of behalf of people. They assume what they don't need must be irrelevant to the world, if they don't understand something it must be born out of stupidity, and the future was perfectly predictable if you are as smart as them. Sorry. Umm... peace.
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchypeterchen wrote:
Ever since my birth I've seen a growing ignorance of behalf of people.
I doubt that. Much more likely that the only differentiation, if any, is that you are more aware of rate that is fixed.
peterchen wrote:
They assume what they don't need must be irrelevant to the world, if they don't understand something it must be born out of stupidity, and the future was perfectly predictable if you are as smart as them.
Of course a converse truth also exists.... People who assume that everything that is new should be useful to everyone, that is was created after only a great deal of careful consideration and it should be used whenever possible without constraint. And any attempts to constrain, limit or criticize something new is based solely on the ignorance with no possibility of any other reason.
-
I still don't get why any modern language needs
gotoat all.gotois a first generation language command. It was already bad for procedural programming, worse for OO, and catastrophic for anything involving multithreading. Not to mention functional programming.Stefan_Lang wrote:
...worse for OO, and catastrophic for anything involving multithreading
How can you construct "catastrophic" code with a goto involving threads for which you cannot do the same thing using some other idiom that involves branching? Certainly both Java and C++ compilers generate most branching idioms that exist in the language specifically by substituting structures that use goto. And both of them seem to handle threading without problems related to that.
-
I think the
C#nature of 'evolving language' is a design choice, not a flaw. If you like only theC#original features, then why don't use just them?Veni, vidi, vici.
CPallini wrote:
If you like only the
C#original features, then why don't use just them?Based on your assertion you might as well claim that your coworkers can write code using fortran, cobol, assembly as well as C#. After all it is only a matter of personal choice and has no impact otherwise.
-
gggustafson wrote:
What I liked the most with the original C# language were the ArrayList and garbage collection
Garbage collection is still there. What makes you think it's disappeared. As for ArrayList - you honestly like your code to perform badly? Do the terms boxing and unboxing mean anything to you? As for the other features - in the most part, they are there to make the job of the day to day developer a lot easier. They aren't in there for the benefit of some ivory towered academics who don't do this for a living, they are for people who have applications to write for customers quickly and easily. I'm sorry, but I find your arguments specious. Now, if you'd picked on the var keyword, I'd have had to agree, or the lack of full templating support.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
Pete O'Hanlon wrote:
As for the other features - in the most part, they are there to make the job of the day to day developer a lot easier
Unless you have some real statistics to back that up it is nothing but subjective nonsense. In my experience programmers spend most of their time dealing with design (even at the implementation level) issues, logic/design/architecture bugs, library learning/usage, and other issues of which the vast majority have nothing to do with language semantics. Now maybe you spend every day all year long doing nothing but constructing generic collections and linq expressions but that isn't what most developers do. So it isn't possible for a language construct to have a significant impact.
-
I've heard a great deal of praise heaped on C#, but in my encounters with it to this point, I've always come away bruised. In part, that's because it's still changing (and VS .NET with it). In part, it's because I'm a dinosaur who expects the facilities I've come to know and love to remain available and convenient when I "upgrade." But more significant than those reasons or any others is this one: I dislike being "protected from myself."
I like pointers.
I prefer permissive type conversions.
I'm a high expert at picking floating-point numbers apart from their binary representations. (Ever seen old-style IBM floating-point? What about CDC's 60-bit version?)
If I can't substitute an address for an integer or vice-versa, I'll throw a fit.
And don't you dare move something I've put in allocated memory! I'll do my own "garbage collection," thanks very much.My first language was assembler on a PDP-9. I moved from there to the Data General NOVA 1200, still programming in assembler, and from there to the PDP-11, and then to the Intel 8080, 8085, and Zilog Z80, still programming in assembler. Over those years, various persons attempted to convert me to the glories of FORTRAN, Pascal, Algol, APL, PL/I, LISP, and Forth. I spurned them all: not one of them permitted me to do everything I felt I might need to do in some hypothetical situation. When I was introduced to C, for the first time I felt I could "go machine-independent" without losing the full freedom of the machine.
Today I program in C++ and microcode for special-purpose devices. I'm uninterested in C#, Ada, or any other language that attempts to restrict what operations I can attempt. I find it puzzling that other software engineers are willing to accept such shackles. But hey, I told you already: I'm a dinosaur.
I wonder if you'll miss my sort when we're completely extinct...
(This message is programming you in ways you cannot detect. Be afraid.)
Fran Porretto wrote:
Today I program in C++ and microcode for special-purpose devices. I'm uninterested in C#, Ada, or any other language that attempts to restrict what operations I can attempt. I find it puzzling that other software engineers are willing to accept such shackles. But hey, I told you already: I'm a dinosaur.
Errr...If I was writing what you were then I suspect I would use C++ as well. But I seriously doubt that I would start with C++ for a generic web server. And the reason for that is because it would be easier to get it up and keep it running by using C# or Java. Just so there is no doubt, without checking the actual years I believe I still have more experience with C/C++ than I do with C#/Java. And of course in terms of the original post, C++ itself is now on its 2 major update (ANSI) which does add new features. Template introduction in version 1 was a significant undertaking and before that there was no standard and there were in fact differences between C++ vendors before that which allowed for variations in the semantics of the language. At that time I remember one vendor telling me that Stroustrup was wrong, so I can't see how some evolution is not a good thing.
-
Over the many years that I have been programmer, I have detected a growing arrogance on the part of Microsoft employees. I find this strange because Microsoft depends so much upon its customer base. Yet, whenever some flaw is found in its software, Redmond is quick to argue that the bug is really a feature. This has occurred to me, personally, since Visual Studio 4. This arrogance spiked with the release of the C# programming language and its associated multiple .Net frameworks. Having been a member of the X3J9 Pascal technical committee (circa 1978), I am aware of what makes a “good” programming language. We teach these attributes to serious students of language design. Unfortunately, Redmond either didn’t take the classes or neglected their import. As a result, we have C# in its fourth generation (surprisingly not called "C#-4GL"). Generics, LINQ, and so forth have been added. Unfortunately, they were not part of the original C# language. They are "corrections" to missteps taken by Redmond in its attempt to be all things to all people. And they make my programming job much more difficult. I truly would like to see a new, simple, stripped-down version of C#. What I liked the most with the original C# language were the ArrayList and garbage collection. I believe that all the rest is unnecessary object oriented revenge. Peace.
Gus Gustafson
I have learned that every time someone complains about a corporation's developers' arrogance, the real complaint is that said developers are not doing exactly what the complainer wants. The developers' philosophy becomes arrogance, and their explanations pompous lectures.
-
:sigh: Yes, indeed. You don't always get the time required to get your code clean. I can in fact understand that in such circumstances you may feel forced to stick with goto. That however doesn't justify to make it available as part of a new language. Regarding efficiency I disagree though: you can always store the condition that you would use to trigger a goto in a boolean variale and then just skip over the remaining blocks of code. That takes virtually no time at all. That's what I usually do.
-
CPallini wrote:
If you like only the
C#original features, then why don't use just them?Based on your assertion you might as well claim that your coworkers can write code using fortran, cobol, assembly as well as C#. After all it is only a matter of personal choice and has no impact otherwise.
-
I've heard a great deal of praise heaped on C#, but in my encounters with it to this point, I've always come away bruised. In part, that's because it's still changing (and VS .NET with it). In part, it's because I'm a dinosaur who expects the facilities I've come to know and love to remain available and convenient when I "upgrade." But more significant than those reasons or any others is this one: I dislike being "protected from myself."
I like pointers.
I prefer permissive type conversions.
I'm a high expert at picking floating-point numbers apart from their binary representations. (Ever seen old-style IBM floating-point? What about CDC's 60-bit version?)
If I can't substitute an address for an integer or vice-versa, I'll throw a fit.
And don't you dare move something I've put in allocated memory! I'll do my own "garbage collection," thanks very much.My first language was assembler on a PDP-9. I moved from there to the Data General NOVA 1200, still programming in assembler, and from there to the PDP-11, and then to the Intel 8080, 8085, and Zilog Z80, still programming in assembler. Over those years, various persons attempted to convert me to the glories of FORTRAN, Pascal, Algol, APL, PL/I, LISP, and Forth. I spurned them all: not one of them permitted me to do everything I felt I might need to do in some hypothetical situation. When I was introduced to C, for the first time I felt I could "go machine-independent" without losing the full freedom of the machine.
Today I program in C++ and microcode for special-purpose devices. I'm uninterested in C#, Ada, or any other language that attempts to restrict what operations I can attempt. I find it puzzling that other software engineers are willing to accept such shackles. But hey, I told you already: I'm a dinosaur.
I wonder if you'll miss my sort when we're completely extinct...
(This message is programming you in ways you cannot detect. Be afraid.)
I've balanced the downvote, because:
- Your point makes sense.
- Univoting a substantiated argument like yours is plain silly.
That said, I think
C#is not a good language choice for you (and developers similar to you). On the other hand, there is a plethora of developers having different needs (e.g. liking better development speed than code performance) and I supposeC#targets the latter folks.Veni, vidi, vici.
-
Pete O'Hanlon wrote:
As for the other features - in the most part, they are there to make the job of the day to day developer a lot easier
Unless you have some real statistics to back that up it is nothing but subjective nonsense. In my experience programmers spend most of their time dealing with design (even at the implementation level) issues, logic/design/architecture bugs, library learning/usage, and other issues of which the vast majority have nothing to do with language semantics. Now maybe you spend every day all year long doing nothing but constructing generic collections and linq expressions but that isn't what most developers do. So it isn't possible for a language construct to have a significant impact.
Balanced the Univote. While I disagree with your arguments, you made them cogently so there's no reason for someone to downvote you.
jschell wrote:
maybe you spend every day all year long doing nothing but constructing generic collections and linq expressions
I wish. I spend most of my time now in project plans, bid and tender documents, as well as the company accounts.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
Over the many years that I have been programmer, I have detected a growing arrogance on the part of Microsoft employees. I find this strange because Microsoft depends so much upon its customer base. Yet, whenever some flaw is found in its software, Redmond is quick to argue that the bug is really a feature. This has occurred to me, personally, since Visual Studio 4. This arrogance spiked with the release of the C# programming language and its associated multiple .Net frameworks. Having been a member of the X3J9 Pascal technical committee (circa 1978), I am aware of what makes a “good” programming language. We teach these attributes to serious students of language design. Unfortunately, Redmond either didn’t take the classes or neglected their import. As a result, we have C# in its fourth generation (surprisingly not called "C#-4GL"). Generics, LINQ, and so forth have been added. Unfortunately, they were not part of the original C# language. They are "corrections" to missteps taken by Redmond in its attempt to be all things to all people. And they make my programming job much more difficult. I truly would like to see a new, simple, stripped-down version of C#. What I liked the most with the original C# language were the ArrayList and garbage collection. I believe that all the rest is unnecessary object oriented revenge. Peace.
Gus Gustafson
-
I've heard that argument over and over again. While I can perfectly understand that notion when I look at certain pieces of code, the fact that the code is so convoluted that
gotois considered the best way to get out of it, is a very strong indication that you should refactor that code, not usegoto.gotois a short circuit. That's the kind of thing a good programmer strives to avoid. Using it intentionally is reserved for dubious causes such as stealing a car. ;) P.S.: saying it may be 'the best thing to do' implies that there are other options. In my experience, programmers telling me 'that it's the best' judge it to be the best for all the wrong reasons. But anyway, it's at least partially subjective. In 26 years of C++ programming I've yet to see a piece of code that convinces me of using goto, but that's just me. Others may have different preferences.Stefan_Lang wrote:
gotois a short circuit.I'm honestly curious to know what you think of
breakandcontinue. Those are short-circuits too, just in a more limited context. But of course they can't jump to previous code which it seems to me is the most harmful use of goto. -
Nope. For instance, I often use a subset of
C++for 'procedural' programming in small projects. However it is stillC++and won't require different build tools or knowledge.Veni, vidi, vici.
CPallini wrote:
However it is still
C++and won't require different build tools or knowledge.I can assure you that a developer who has only used C#/Java experience will in fact "require different...knowledge" to maintain C++. And a developer who has experience in C#/Java/C++ is going to "request different ...knowledge" to maintain fortran/cobol too.
-
This post could have been reduced to: I am too set in my ways and stubborn to learn a new generation of programming languages and the benefits that they offer. You can enjoy your pointers and manual memory management all you want, but you won't be writing any enterprise level web systems with them. And that's exactly the point, isn't it? Use the tool that works best for the job. If you can't see the benefits of a particular tool, that does not indicate that there aren't any; it only indicates that you are unable to recognize them.
RedCatsRic wrote:
You can enjoy your pointers and manual memory management all you want, but you won't be writing any enterprise level web systems with them.
Err...you do realize that C++ is and can be used for "enterprise" systems and for "web systems" right? As a very real and prominent example of that Apache is written in C++ (and/or C.)
-
:sigh: Yes, indeed. You don't always get the time required to get your code clean. I can in fact understand that in such circumstances you may feel forced to stick with goto. That however doesn't justify to make it available as part of a new language. Regarding efficiency I disagree though: you can always store the condition that you would use to trigger a goto in a boolean variale and then just skip over the remaining blocks of code. That takes virtually no time at all. That's what I usually do.
-
I've heard that argument over and over again. While I can perfectly understand that notion when I look at certain pieces of code, the fact that the code is so convoluted that
gotois considered the best way to get out of it, is a very strong indication that you should refactor that code, not usegoto.gotois a short circuit. That's the kind of thing a good programmer strives to avoid. Using it intentionally is reserved for dubious causes such as stealing a car. ;) P.S.: saying it may be 'the best thing to do' implies that there are other options. In my experience, programmers telling me 'that it's the best' judge it to be the best for all the wrong reasons. But anyway, it's at least partially subjective. In 26 years of C++ programming I've yet to see a piece of code that convinces me of using goto, but that's just me. Others may have different preferences.Stefan_Lang wrote:
In 26 years of C++ programming I've yet to see a piece of code that convinces me of using goto,
There was an article/column in the C\C++ users Journal in that time period that was implementing printf (or maybe sprintf) which is part of the standard C library and it used goto quite a bit. As I remember it I doubt other constructs would have made the code more readable nor easier to understand. Other constructs might have been the same speed but introducing artificial conditionals would not have met that goal. And back then many applications would have been impacted by a slower implementation of that method.
-
Stefan_Lang wrote:
gotois a short circuit.I'm honestly curious to know what you think of
breakandcontinue. Those are short-circuits too, just in a more limited context. But of course they can't jump to previous code which it seems to me is the most harmful use of goto.I am grudgingly willing ;) to accept these. Especially the use of break in a switch statement is something I do not know any good way around.
-
Stefan_Lang wrote:
In 26 years of C++ programming I've yet to see a piece of code that convinces me of using goto,
There was an article/column in the C\C++ users Journal in that time period that was implementing printf (or maybe sprintf) which is part of the standard C library and it used goto quite a bit. As I remember it I doubt other constructs would have made the code more readable nor easier to understand. Other constructs might have been the same speed but introducing artificial conditionals would not have met that goal. And back then many applications would have been impacted by a slower implementation of that method.
*shrug* There was a time where I would contemplate other peoples programming styles in published media and maybe adapt some of it. But I have long since realized that everyone makes mistakes and just because something is published doesn't mean it's good. That said, I have to point out, again, that my argument was about language designers putting the goto command into a language, not programmers using what language designers gave them.
-
Stefan_Lang wrote:
That takes virtually no time at all
That of course is the detail since if you are already optimizing a piece of code based on a measured (not guessed at) need then a conditional branch is in fact slower than an unconditional one.
That point is moot: I said the language designers shouldn't have put goto into C#. If you're so strained about performance, why do you even use C# to start with?
-
Stefan_Lang wrote:
...worse for OO, and catastrophic for anything involving multithreading
How can you construct "catastrophic" code with a goto involving threads for which you cannot do the same thing using some other idiom that involves branching? Certainly both Java and C++ compilers generate most branching idioms that exist in the language specifically by substituting structures that use goto. And both of them seem to handle threading without problems related to that.
Lock(someSharedVariable)
if (someCondition) goto someOtherPlace;
doStuff(someSharedVariable); // do some stuff
Unlock(someSharedVariable);That's what I mean by catastrophic, only that in real code, there may be alot more fluff around, hiding the fact that you're actually accessing a shared resource and jumping out of the context before releasing a lock.