Revenge of Redmond – C# and the .Net Frameworks
-
: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.
-
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:
If you're so strained about performance, why do you even use C# to start with?
That statement of course makes no sense. The performance of an application or even an enterprise system might be dependent on a language choice. But of course it is even more dependent on requirements, architecture and design. Conversely this discussion related to goto would only be relevent to optimizing the performance of code. And of course one might wish to optimize any section of code regardless of language choice.
-
*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:
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.
Which of course has nothing to do with what I said.
-
Stefan_Lang wrote:
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.
Which of course has nothing to do with what I said.
That's what you said: 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. Since you seemed to be basing your argumentation on the example of that article I was making a point that some old article is not a valid argument from my PoV.
-
Stefan_Lang wrote:
If you're so strained about performance, why do you even use C# to start with?
That statement of course makes no sense. The performance of an application or even an enterprise system might be dependent on a language choice. But of course it is even more dependent on requirements, architecture and design. Conversely this discussion related to goto would only be relevent to optimizing the performance of code. And of course one might wish to optimize any section of code regardless of language choice.
jschell wrote:
That statement of course makes no sense.
Do I really have to point out the known facts about performance differences between C++ and C#? Or the consequences of having a garbage collection block vital threads in a real time system?
jschell wrote:
The performance of an application or even an enterprise system might be dependent on a language choice. But of course it is even more dependent on ....
You were the one who based your performance argument solely on the language, and more specifically on the availability of the goto command, not I. So you were assuming that to be a mandatory requirement as well. I think it's about time for me to step out of the discussion at this point. You seem capabale of countering your own arguments without my help just fine. ;P
-
jschell wrote:
That statement of course makes no sense.
Do I really have to point out the known facts about performance differences between C++ and C#? Or the consequences of having a garbage collection block vital threads in a real time system?
jschell wrote:
The performance of an application or even an enterprise system might be dependent on a language choice. But of course it is even more dependent on ....
You were the one who based your performance argument solely on the language, and more specifically on the availability of the goto command, not I. So you were assuming that to be a mandatory requirement as well. I think it's about time for me to step out of the discussion at this point. You seem capabale of countering your own arguments without my help just fine. ;P
Stefan_Lang wrote:
Do I really have to point out the known facts about performance differences between C++ and C#? Or the consequences of having a garbage collection block vital threads in a real time system?
That of course has nothing to do with optimizing a method. Perhaps you are not aware that this same discussion can apply to C++ as well?
Stefan_Lang wrote:
You were the one who based your performance argument solely on the language,
Wrong. I suggest you re-read what I posted and what I responded to.
Stefan_Lang wrote:
and more specifically on the availability of the goto command, not I.
Wrong. I specifically responded to your comment that booleans and conditional checks were just as good as goto.
-
That's what you said: 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. Since you seemed to be basing your argumentation on the example of that article I was making a point that some old article is not a valid argument from my PoV.
-
Stefan_Lang wrote:
Do I really have to point out the known facts about performance differences between C++ and C#? Or the consequences of having a garbage collection block vital threads in a real time system?
That of course has nothing to do with optimizing a method. Perhaps you are not aware that this same discussion can apply to C++ as well?
Stefan_Lang wrote:
You were the one who based your performance argument solely on the language,
Wrong. I suggest you re-read what I posted and what I responded to.
Stefan_Lang wrote:
and more specifically on the availability of the goto command, not I.
Wrong. I specifically responded to your comment that booleans and conditional checks were just as good as goto.
Ok, the way threads are displayed in this forum when trying to respond to a comment unfortunately hides most of the history. (is there a way to prevent it from folding? I've always found that very annoying, and never really helpful). It appears that while my memory served me right in that I wasn't the one to bring up the topic of performance, nevertheless it wasn't you, either. Sorry for bringing it to your door. Anyway, this is my last comment to this thread. I've made my points, you made yours. Obviously we disagree. Be that as it may.
-
Ok, the way threads are displayed in this forum when trying to respond to a comment unfortunately hides most of the history. (is there a way to prevent it from folding? I've always found that very annoying, and never really helpful). It appears that while my memory served me right in that I wasn't the one to bring up the topic of performance, nevertheless it wasn't you, either. Sorry for bringing it to your door. Anyway, this is my last comment to this thread. I've made my points, you made yours. Obviously we disagree. Be that as it may.
Stefan_Lang wrote:
Ok, the way threads are displayed in this forum when trying to respond to a comment unfortunately hides most of the history. (is there a way to prevent it from folding? I've always found that very annoying, and never really helpful).
I agree with that.
-
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.In the end it's all goto's. The processor turns everything into a goto to a memory address or register. Contained within a procedural function a goto is much more efficent than a bunch of if-then-else's or cases. It is also much more readable to an experienced programmer when used properly. Goto's are not bad; misuse or no use is poor practice.
-
In the end it's all goto's. The processor turns everything into a goto to a memory address or register. Contained within a procedural function a goto is much more efficent than a bunch of if-then-else's or cases. It is also much more readable to an experienced programmer when used properly. Goto's are not bad; misuse or no use is poor practice.
In the beginning was darkness. And God said, let there be
goto... Hmm, I think it wasn't quite like that ;) What I meant to say is just because in the end there aregotos doesn't mean they should be there from the beginning. In this case I was arguing about goto being in the language C# in the first place. Remember, this thread is about language, not about what programmers (or the compiler) makes of it. -
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.)
There are a few other things to think about here: 1) us dinosaurs lived through the debacle of P-Code. .NET is just another attempt at that solution. It is more successful because they have quad-core, multi-giga hertz processors to over-power their ineptitude. Because we lived through it, we find it difficult to embrace it again./ Maybe in a few years... 2) us dinosaurs lived through the first garbage collectors too. The ones that would lock-up your display for 30-60 seconds at a (random) time. We find it difficult to go back to those bad old days just because of more powerful processors make the lock up less than a second. 3) Redmond had to have C pound. They had a horrible time trying to be compliant with the C++ international standard language and library. And it only changed every ten years. You can't sell compilers when it only changes every ten years. You gotta get your own language, pile your employees on the standardization board and "make it your own". Those bi-yearly changes will be well worth it. 4) remember, dinosaurs that have programmed professionally for 30 years didn't do that by not paying attention. They got burned early with new sexy languages and techniques and are a bit skeptical of 'the latest thing'. We experimented with C++ using C-Front because it offered real advantages. But it didn't get used in production for another five years. OOP & OOD were watched carefully and embraced as they matured. .NET may make it but it ain't there yet.