i don't like object oriented programming
-
you know what? I'm still kind of curious about this but I think I'm scrapping the specialization. I'm not sure what I'm going to do about maintenance though. =( This will almost double the code size.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
Good luck hey ^^
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
Generic
Do()method's IL:.method public hidebysig instance void Do(!T 'value') cil managed
{
// Code size 58 (0x3a)
.maxstack 2
.locals init ([0] int32 intV,
[1] bool V_1)
IL_0000: nop
IL_0001: ldarg.1
IL_0002: box !T
IL_0007: isinst [mscorlib]System.Int32
IL_000c: brfalse.s IL_0022
IL_000e: ldarg.1
IL_000f: box !T
IL_0014: isinst [mscorlib]System.Int32
IL_0019: unbox.any [mscorlib]System.Int32
IL_001e: stloc.0
IL_001f: ldc.i4.1
IL_0020: br.s IL_0023
IL_0022: ldc.i4.0
IL_0023: stloc.1
IL_0024: ldloc.1
IL_0025: brfalse.s IL_0031
IL_0027: ldarg.0
IL_0028: ldloc.0
IL_0029: call instance void class ConsoleApp1.A`1::Do(int32)
IL_002e: nop
IL_002f: br.s IL_0039
IL_0031: ldarg.0
IL_0032: ldarg.1
IL_0033: call instance void class ConsoleApp1.A`1::DoDefault(!0)
IL_0038: nop
IL_0039: ret
} // end of method A`1::DoA new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
yep, that's a call to the runtime to do a type check. See isinst? i'll consider our bet a gentleman's bet =D
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
Generic
Do()method's IL:.method public hidebysig instance void Do(!T 'value') cil managed
{
// Code size 58 (0x3a)
.maxstack 2
.locals init ([0] int32 intV,
[1] bool V_1)
IL_0000: nop
IL_0001: ldarg.1
IL_0002: box !T
IL_0007: isinst [mscorlib]System.Int32
IL_000c: brfalse.s IL_0022
IL_000e: ldarg.1
IL_000f: box !T
IL_0014: isinst [mscorlib]System.Int32
IL_0019: unbox.any [mscorlib]System.Int32
IL_001e: stloc.0
IL_001f: ldc.i4.1
IL_0020: br.s IL_0023
IL_0022: ldc.i4.0
IL_0023: stloc.1
IL_0024: ldloc.1
IL_0025: brfalse.s IL_0031
IL_0027: ldarg.0
IL_0028: ldloc.0
IL_0029: call instance void class ConsoleApp1.A`1::Do(int32)
IL_002e: nop
IL_002f: br.s IL_0039
IL_0031: ldarg.0
IL_0032: ldarg.1
IL_0033: call instance void class ConsoleApp1.A`1::DoDefault(!0)
IL_0038: nop
IL_0039: ret
} // end of method A`1::DoA new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
adding ugh - it's not only doing that, it has to box the value first! i forgot about that. Ugh. It makes a copy of the int on the heap just to do a type check No. Just no. Moral of this story is do not trust the C# compiler to significantly optimize your code.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
adding ugh - it's not only doing that, it has to box the value first! i forgot about that. Ugh. It makes a copy of the int on the heap just to do a type check No. Just no. Moral of this story is do not trust the C# compiler to significantly optimize your code.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
I have to say I am a little confused.. They have numerous intelligent blog about performance... They have fair performance comparison against C++ code with well know perf test with many close call and sometimes better performance... Though when one occasionally check the IL or assembly it seems not really good... All of that leave me quite bewildered....
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
I have to say I am a little confused.. They have numerous intelligent blog about performance... They have fair performance comparison against C++ code with well know perf test with many close call and sometimes better performance... Though when one occasionally check the IL or assembly it seems not really good... All of that leave me quite bewildered....
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
last i checked it's about 30% slower and that's according to their own benchmarks. I expect real world performance to be somewhat worse, if only because of the unconscious tendency to want to test the fast parts of the code. occasionally you get better performance because of the JITs ability to do smart register allocation but the performance difference between that and C++ is barely significant in virtually all cases, and it doesn't crop up as regularly as MS would perhaps suggest. There used to be some really good in depth articles about .NET performance that covered a lot of this stuff but as .NET has matured, it seems there are less of these today. I don't normally care about cycle counting, but I do when the code has to be tight. Here it does, in my case.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
I have to say I am a little confused.. They have numerous intelligent blog about performance... They have fair performance comparison against C++ code with well know perf test with many close call and sometimes better performance... Though when one occasionally check the IL or assembly it seems not really good... All of that leave me quite bewildered....
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
In general I've found a lot of my old habits I picked up in the 80s and 90s before i had access to really smart C++ compilers have served me well under .NET. They say you don't have to be careful about heap allocation, and that's kind of true because of the way their garbage collected heap works, but it still costs. They claim the cost is "incrementing a pointer" - in reality that pointer gets incremented enough if forces the .NET host to do a garbage collection and reallocation which costs significantly. So basically all it's really doing is pushing the costs of each heap allocation down the road - and then "batches" the individual costs together when it does the mark, sweep and allocate. They do too much heap allocation in .NET IMO. the IEnumerator pattern is a big culprit but not as much as boxing. Boxing/Unboxing just floors me. That slams the heap. Fortunately the new reference types and stackalloc can alleviate this somewhat, but not nearly enough.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
I've strongly considered it. I might eventually move, but I'm familiar with C#. Maybe if they had Haskell I would have moved already. Edit: Adding, one of the drawbacks of functional programming is lack of state, and some of these equations are so complicated that state is necessary for optimization and I wonder how a functional language will handle such a thing. Recomputing or doing lazy iteration over these algorithms is grossly impractical even if it's "correct"
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
Memoization might be useful for you. It's basically a way to cache function results with a given input in a dictionary and return the cached value instead of running the calculation again.
-
Memoization might be useful for you. It's basically a way to cache function results with a given input in a dictionary and return the cached value instead of running the calculation again.
yeah. in fact, I need to explore memoization more anyway for implementing a PEG parser.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
i never have. give me templates. or you may as well just give me something procedural. if i can't do generic programming i'm a sad honey bear. C# is barely adequate. And it's too object centric IMO. generics need to be able to do more. I want traits. I want the runtimes to do what i can make a C++ compiler do with templates. I probably just got the BAC up of this entire board saying that, but there it is.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
I like object oriented programming. I view generics as just a limited and difficult-to-type variant of object oriented programming, with a bit of type recursion thrown in so it takes longer to compile. I've never run into object hierarchies that have the penguin-is-a-kind-of-bird-but-can't-fly problem in practice. I try to keep object hierarchies I create three layers deep or less. Five for template classes so I can use CRTP. I've got the visitor pattern if I really need it for aspect-oriented programming.
-
I like object oriented programming. I view generics as just a limited and difficult-to-type variant of object oriented programming, with a bit of type recursion thrown in so it takes longer to compile. I've never run into object hierarchies that have the penguin-is-a-kind-of-bird-but-can't-fly problem in practice. I try to keep object hierarchies I create three layers deep or less. Five for template classes so I can use CRTP. I've got the visitor pattern if I really need it for aspect-oriented programming.
that's fair. it sounds like you come from primarily an OO background based on how you view generics. You're not wrong or anything, i think it's just perspective. When I see a template or a generic i see GP and sometimes AOP potential, with object orientation being secondary because I'm used to looking at things through a C++ lens, and OO just isn't the dominant paradigm there. I go as deep as I need to and factor on a case by case. I know a lot of people have a lot of hard and fast rules, but I'm a bit more fluid, although I do try to avoid deep hierarchies as a rule. I'm currently working on a document object model that's deeper than I'd like, but DOMs are kind of their own beast. They're typically nested inheritance-wise to three deep and that's where mine is in 40% of it. The other 60% are Expression elements (binary,unary, etc) so those go deeper. like i said, case by case for me.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
i never have. give me templates. or you may as well just give me something procedural. if i can't do generic programming i'm a sad honey bear. C# is barely adequate. And it's too object centric IMO. generics need to be able to do more. I want traits. I want the runtimes to do what i can make a C++ compiler do with templates. I probably just got the BAC up of this entire board saying that, but there it is.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
To be honest it depends on what kind of coding we are talking about. I never did buy entirely into the 'OOP is the cosmos' argument. However, for a coding assignment, whilst a student, I once had to write a C++ app as 'monolithic code'. This was quite a complex database managing app. Later on, we were given a very similar task using OOP in C#. I can honestly say the later was at least two orders of magnitude easier! However, there are many tasks for which OOP is overkill, which is where scripting languages come into their own. Peeps do write complex software in scripting languages, but my preference is for OOP whenever the code starts to exceed a certain complexity. There is a current bakclash against OOP, but in part this is driven by abuses and misunderstandings of OOP. Python, for example, though clearly a powerful language does not support OOP in my opinion, never mind being the 'object-oriented language' some claim it to be. The most central feature to OOP is encapsulation (along with access modifiers). To me this makes a lot of sense. Inheritance is sometimes a useful feature but it is not the most important feature of OOP and I suspect that it is over-used. I don't particularly like OOP that over-uses inheritance or sticks to over-complicated design patterns just to 'look professional'. I do like the way C++ supports OOP but is not itself object-oriented (though I detest the way it 'disembodies' classes). I think of it like this: the real world consists of objects interacting through an interface: to shake somebody's hand you don't need to know how their muscles, nerves and circulatory system works! Nor should you have direct access to these parameters in order to interact with the person! I like OOP because it simulates the real world in so many ways.
-
To be honest it depends on what kind of coding we are talking about. I never did buy entirely into the 'OOP is the cosmos' argument. However, for a coding assignment, whilst a student, I once had to write a C++ app as 'monolithic code'. This was quite a complex database managing app. Later on, we were given a very similar task using OOP in C#. I can honestly say the later was at least two orders of magnitude easier! However, there are many tasks for which OOP is overkill, which is where scripting languages come into their own. Peeps do write complex software in scripting languages, but my preference is for OOP whenever the code starts to exceed a certain complexity. There is a current bakclash against OOP, but in part this is driven by abuses and misunderstandings of OOP. Python, for example, though clearly a powerful language does not support OOP in my opinion, never mind being the 'object-oriented language' some claim it to be. The most central feature to OOP is encapsulation (along with access modifiers). To me this makes a lot of sense. Inheritance is sometimes a useful feature but it is not the most important feature of OOP and I suspect that it is over-used. I don't particularly like OOP that over-uses inheritance or sticks to over-complicated design patterns just to 'look professional'. I do like the way C++ supports OOP but is not itself object-oriented (though I detest the way it 'disembodies' classes). I think of it like this: the real world consists of objects interacting through an interface: to shake somebody's hand you don't need to know how their muscles, nerves and circulatory system works! Nor should you have direct access to these parameters in order to interact with the person! I like OOP because it simulates the real world in so many ways.
I mean, C# is also easier for a number reasons besides OOP. I can write a purely OOP app in C++ (which I'd only do to prove that it can be done) and it would still be much harder to write than in a garbage collected, managed programming environment like .NET CLI/CLR and C#
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
i know how to code OO. i just don't like OO because it requires a lot of code to do a little bit.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
When I was growin' up, I was the laziest kid I knew and I knew a lot of people. I'm still one of the laziest devs I know, but I make my deadlines and I know how to code myself out of a job. Your problem might not be OO, but design patterns that contain more layers than lasagna like MVVM or have dependency injection. Another issue might be .NET (assuming its what you work in) I've started playing with python. If you wanted to get stuff done by doing as little as possible as often as possible with maximum results, Python is it.
-
When I was growin' up, I was the laziest kid I knew and I knew a lot of people. I'm still one of the laziest devs I know, but I make my deadlines and I know how to code myself out of a job. Your problem might not be OO, but design patterns that contain more layers than lasagna like MVVM or have dependency injection. Another issue might be .NET (assuming its what you work in) I've started playing with python. If you wanted to get stuff done by doing as little as possible as often as possible with maximum results, Python is it.
In practice I agree with you about python On principle I refuse to use a language with significant whitespace.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.