Revenge of Redmond – C# and the .Net Frameworks
-
I knew that the OP's name rang a bell[^].
*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
-
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.
-
I knew that the OP's name rang a bell[^].
*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
-
ArrayList was an abortion which should never have seen the light of day - particularly in a language that may be used for teaching. The generic List construct was a vast improvement. Personally, I would rather have seen
gotorestricted tounsafeblocks to make it harder for lazy people to use it...Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
OriginalGriff wrote:
ArrayList was an abortion which should never have seen the light of day
Nice slip there mister! :laugh:
'As programmers go, I'm fairly social. Which still means I'm a borderline sociopath by normal standards.' Jeff Atwood 'I'm French! Why do you think I've got this outrrrrageous accent?' Monty Python and the Holy Grail
-
Pete O'Hanlon wrote:
As for ArrayList - you honestly like your code to perform badly? Do the terms boxing and unboxing mean anything to you?
If you exclude value types, all the assumptions are invalid. Casting a reference type is as cheap as it gets.
leppie wrote:
If you exclude value types
And there's the rub. How much code do you have lying around that just targets reference types?
*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
-
leppie wrote:
If you exclude value types
And there's the rub. How much code do you have lying around that just targets reference types?
*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:
How much code do you have lying around that just targets reference types?
I think you rather mean, how much code you have lying around that does not use value types in non-generic containers? Big difference in the meaning. Anyways, in .NET 1.x, we all used type-safe arrays (when boxing/unboxing was costly), no problems there.
-
Pete O'Hanlon wrote:
How much code do you have lying around that just targets reference types?
I think you rather mean, how much code you have lying around that does not use value types in non-generic containers? Big difference in the meaning. Anyways, in .NET 1.x, we all used type-safe arrays (when boxing/unboxing was costly), no problems there.
leppie wrote:
I think you rather mean, how much code you have lying around that does not use value types in non-generic containers?
Fair point, well made.
*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
-
ArrayList was an abortion which should never have seen the light of day - particularly in a language that may be used for teaching. The generic List construct was a vast improvement. Personally, I would rather have seen
gotorestricted tounsafeblocks to make it harder for lazy people to use it...Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
Exactly the List construct is definitely the way to go! I started using arraylists etc and nowadays everything goes into a List and if I can I will make it a list of objects and unbox at the other end...
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
leppie wrote:
I think you rather mean, how much code you have lying around that does not use value types in non-generic containers?
Fair point, well made.
*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:
Fair point, well made.
The answer is 'a lot'. Every time you use the ASP.NET, (pretty much) every value type gets boxed (specifically session, application states and request and response variables). The performance impact is minimal at best. To answer you previous question (pedantically): LOTS, everything in IronScheme is a reference type. All value types are boxed. Some of them like symbols and booleans and numbers from 1 - 1000 are also interned (so that makes equality simply a reference check). As for performance, I have not seen better options where boxing can be avoided. The extra indirection is more costly than unboxing.
-
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
Generics are awesome and were a fairly bad omission from the original release, imo. The C# implementation is very good and they make it much easier to write type safe, efficient, clean code. LINQ, lambdas etc are just syntactic sugar and as long as you can read them, you don't have to bother learning how to write them, but they can increase elegance markedly when used appropriately. I don't agree with you at all, really, I think that the evolution of C# has been positive and made it an easier language to use.
-
Pete O'Hanlon wrote:
Fair point, well made.
The answer is 'a lot'. Every time you use the ASP.NET, (pretty much) every value type gets boxed (specifically session, application states and request and response variables). The performance impact is minimal at best. To answer you previous question (pedantically): LOTS, everything in IronScheme is a reference type. All value types are boxed. Some of them like symbols and booleans and numbers from 1 - 1000 are also interned (so that makes equality simply a reference check). As for performance, I have not seen better options where boxing can be avoided. The extra indirection is more costly than unboxing.
leppie wrote:
Every time you use the ASP.NET, (pretty much)
And yet another reason for me to rejoice that I don't write ASP.NET applications.
*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:
Fair point, well made.
The answer is 'a lot'. Every time you use the ASP.NET, (pretty much) every value type gets boxed (specifically session, application states and request and response variables). The performance impact is minimal at best. To answer you previous question (pedantically): LOTS, everything in IronScheme is a reference type. All value types are boxed. Some of them like symbols and booleans and numbers from 1 - 1000 are also interned (so that makes equality simply a reference check). As for performance, I have not seen better options where boxing can be avoided. The extra indirection is more costly than unboxing.
leppie wrote:
LOTS, everything in IronScheme is a reference type.
OK, I know you're being pedantic here, but replace IronScheme with C# - as this thread is about C# and not IronScheme.
*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
-
leppie wrote:
LOTS, everything in IronScheme is a reference type.
OK, I know you're being pedantic here, but replace IronScheme with C# - as this thread is about C# and not IronScheme.
*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 this thread is about C# and not IronScheme.
40% of IronScheme is written in C#. Same rules apply :)
-
Pete O'Hanlon wrote:
Now, if you'd picked on the var keyword, I'd have had to agree
But I would disagree, then. :)
Veni, vidi, vici.
I would have had space allowed :)
Gus Gustafson
-
ArrayList was an abortion which should never have seen the light of day - particularly in a language that may be used for teaching. The generic List construct was a vast improvement. Personally, I would rather have seen
gotorestricted tounsafeblocks to make it harder for lazy people to use it...Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
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. -
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.Because sometimes - very, very rarely - it is the best thing to do. It can save a mess of "get me out of here" bools, and a lot of otherwise unnecessary testing. Having said that, I haven't needed to use it in at least ten years - and I wish teachers were less lazy and didn't start with it on day one to make their lives easier...
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
-
Because sometimes - very, very rarely - it is the best thing to do. It can save a mess of "get me out of here" bools, and a lot of otherwise unnecessary testing. Having said that, I haven't needed to use it in at least ten years - and I wish teachers were less lazy and didn't start with it on day one to make their lives easier...
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
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. -
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.I agree. But the fact is there is code that you can't refactor for one reason or another: time is the most common. Or efficiency in a time critical segment. It's there. But don't use it until you are experienced enough to understand why it is a bad idea to do so...
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
-
I agree. But the fact is there is code that you can't refactor for one reason or another: time is the most common. Or efficiency in a time critical segment. It's there. But don't use it until you are experienced enough to understand why it is a bad idea to do so...
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
: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.
-
: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.
Sometimes, "virtually no time at all" is still too much! :laugh: You can tell I grew up in an Embedded environment, can't you? :-D
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
