i don't like object oriented programming
-
Yeah, I was wondering, isn't that good enough?! But then I realised one could accidentally instantiate
new FA()instead of the desirednew CharFA()But then what of this other syntax? While it's slightly more wordy, I bet the end compiled result is just as you desiredclass A { public void Do(T value) { if (value is int intV) Do(intV); else DoDefault(value); } void DoDefault(T value) { Console.WriteLine("Value: " + value); } void Do(int value) { Console.WriteLine("Int: " + value); } } class Program { static void Main(string\[\] args) { A a = new A(); a.Do(1); } }I mean personally I am happy to solve that using subclasses or interfaces, but since you really didn't want to....
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
adding, my solution to the object creation was to have a method in the base class called
CreateFA()that could be overloaded in order to force the base class to create the derived class. Unfortunately to get it to work I had to remove every static method that created objects from the base class =(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.
-
Yeah I can't do that in this code because this code is inner loop critical and the "is" comparison is just a dog. I think "as" is faster, but still, it should be resolved at compile time. I know it seems a minor quibble but this code may be used as part of a lexer. The lexing itself needs to be balls quick to be feasible. also i'd be concerned about bugs this could introduce since i have to repeat a lot of code, but that's not a showstopper. it's just irritating
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 think you probably underestimate the compiler here generic code are some sort of IL that is used to generate code on demand (when a concrete type is used) when, say
Atype is created the compiler will see thatvoid Do(int value) {
if (value is double d) { // dead end code prune by the compiler
}
if (value is int ii) Do (ii);
}some path will never happen and it will removed them from the concrete implementation created when the concrete type is created. and the compiled code will become
void Do(int value) {
Do (value);
}A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
I think you probably underestimate the compiler here generic code are some sort of IL that is used to generate code on demand (when a concrete type is used) when, say
Atype is created the compiler will see thatvoid Do(int value) {
if (value is double d) { // dead end code prune by the compiler
}
if (value is int ii) Do (ii);
}some path will never happen and it will removed them from the concrete implementation created when the concrete type is created. and the compiled code will become
void Do(int value) {
Do (value);
}A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
The reason I underestimate the compiler maybe is the last the time I really examined IL was in the .NET 2.0-3.0 days and the compiler didn't do hardly anything for program optimization. Microsoft's rationale seemed to be that JIT would take care of it, but JIT doesn't do whole program optimization. It can only do peephole optimization, so I don't know what they were thinking. My guess is it was an excuse due to deadlines. So I don't trust the compiler that much. Maybe my information is old. The compiler certainly has been revamped since then.
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.
-
The reason I underestimate the compiler maybe is the last the time I really examined IL was in the .NET 2.0-3.0 days and the compiler didn't do hardly anything for program optimization. Microsoft's rationale seemed to be that JIT would take care of it, but JIT doesn't do whole program optimization. It can only do peephole optimization, so I don't know what they were thinking. My guess is it was an excuse due to deadlines. So I don't trust the compiler that much. Maybe my information is old. The compiler certainly has been revamped since then.
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 mean it's such an obvious static type check optimisation.. I haven't explicitly checked for it, but I would wage $5 on it! ;P
void Do(int value) {
// I would wage $5 the compiler remove the if statement and execute the nested statement always
if (value is int ii) {
}
// I would wage 5 dollar this is removed by the compiler
if (value is double dd) {
}
}A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
I mean it's such an obvious static type check optimisation.. I haven't explicitly checked for it, but I would wage $5 on it! ;P
void Do(int value) {
// I would wage $5 the compiler remove the if statement and execute the nested statement always
if (value is int ii) {
}
// I would wage 5 dollar this is removed by the compiler
if (value is double dd) {
}
}A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
based on my experience, I'd take that bet.
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.
-
one example I'm running into right now is template specialization. I have a finite state machine engine and it works for any transition input type and any accept symbol type. However, there are additional features that can happen - significant ones that can only exist when the transition type is char - this specialization is effectively a regular expression engine, which means it can parse from a regular expression, and provide regex matching over string inputs. The other kind of FAs it wouldn't even make sense for that. So because of this I have two separate classes - one generic FA class, and one called CharFA where the TInput=char basically. It means more code to maintain because a lot of it is duplicated. To unduplicate a lot of which i could, I'd have to add another codefile with an interface, and another with static methods to share common functionality, which again, increases the code size. So it's not even that I can't do it with C#, it's that what is elegantly handled in C++ is clunky in C# to do the same thing, and requires more 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.
-
Take a look at F# or another functional language. State machines and functional languages are made for each other.
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.
-
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.
Alan Kay, the father of OOP, says we're doing it all wrong and regrets using the word "object" as it emphasizes the secondary concern of OOP and ignores the primary concern of messaging. Lots of very smart computer scientists say modern OOP makes programming more complex and prone to error rather than simplifying it.
If you think 'goto' is evil, try writing an Assembly program without JMP.
-
Alan Kay, the father of OOP, says we're doing it all wrong and regrets using the word "object" as it emphasizes the secondary concern of OOP and ignores the primary concern of messaging. Lots of very smart computer scientists say modern OOP makes programming more complex and prone to error rather than simplifying it.
If you think 'goto' is evil, try writing an Assembly program without JMP.
i like message/signal based systems but most runtimes don't include some basics that should be "primitives/intrinsics" or otherwise first class, like thread safe priority queues and circular buffers and such. At the very least they should be runtime libraries provided with the base framework. But I really think if Alan Kay had wanted a message based programming environment it should have been done somewhat differently than OOP. think something a bit more along lines of parallel programming style constructs and the like, except instead of dealing with iterations of loops you're dealing with signalling. honestly, it's easy enough to create a domain-specific set of "language extension" style headers in C++ to enable this. I love C++ for that. about 1/3 of the language is the headers and because of the way the preprocessor and template system works you can create your own pseudo language constructs. There's nothing else like it in major programming languages but I really wish their was.
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.
-
based on my experience, I'd take that bet.
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.
well.. my assembly is a bit rusty (or almost non existent) I will let you judge... But here my test C# code
class A { public void Do(T value) { if (value is int intV) Do(intV); else DoDefault(value); } void DoDefault(T value) { Console.WriteLine("Value: " + value); } void Do(int value) { Console.WriteLine("Int: " + value); } } class Program { static void Main(string\[\] args) { A a = new A(); a.Do(1); A b = new A(); b.Do(1.0); } }here is the code for
a.Do(1)andb.Do(1.0)using go to disassembly in visual studioa.Do(1);00F70898 mov ecx,dword ptr [ebp-40h]
00F7089B mov edx,1
00F708A0 cmp dword ptr [ecx],ecx
00F708A2 call 00F70478
00F708A7 nopb.Do(1.0);00F708C3 fld qword ptr ds:[0F708E8h]
00F708C9 sub esp,8
00F708CC fstp qword ptr [esp]
00F708CF mov ecx,dword ptr [ebp-44h]
00F708D2 cmp dword ptr [ecx],ecx
00F708D4 call 00F704A0
00F708D9 nopI think there is no (assembly) if statement and direct execution of the relevant if (type) branch....
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
well.. my assembly is a bit rusty (or almost non existent) I will let you judge... But here my test C# code
class A { public void Do(T value) { if (value is int intV) Do(intV); else DoDefault(value); } void DoDefault(T value) { Console.WriteLine("Value: " + value); } void Do(int value) { Console.WriteLine("Int: " + value); } } class Program { static void Main(string\[\] args) { A a = new A(); a.Do(1); A b = new A(); b.Do(1.0); } }here is the code for
a.Do(1)andb.Do(1.0)using go to disassembly in visual studioa.Do(1);00F70898 mov ecx,dword ptr [ebp-40h]
00F7089B mov edx,1
00F708A0 cmp dword ptr [ecx],ecx
00F708A2 call 00F70478
00F708A7 nopb.Do(1.0);00F708C3 fld qword ptr ds:[0F708E8h]
00F708C9 sub esp,8
00F708CC fstp qword ptr [esp]
00F708CF mov ecx,dword ptr [ebp-44h]
00F708D2 cmp dword ptr [ecx],ecx
00F708D4 call 00F704A0
00F708D9 nopI think there is no (assembly) if statement and direct execution of the relevant if (type) branch....
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
there's a call in there that looks suspicious. I'd need to see the IL, not the asm.
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.
-
based on my experience, I'd take that bet.
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.
Oops forget my previous example, I was confused.. the debug assembly code does indeed look atrocious... Gotta try to check the release version
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
there's a call in there that looks suspicious. I'd need to see the IL, not the asm.
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.
release code atrocious too...
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
Oops forget my previous example, I was confused.. the debug assembly code does indeed look atrocious... Gotta try to check the release version
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
if there's a call in the resulting asm I'd need to see the IL to find out where it leads. I think the "is" comparison would result in a call to the CLR to type check
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.
-
release code atrocious too...
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
yep. The jitter can only do so much with peephole optimization. That's the ugly truth. Still, the IL will tell the tale. ILDASM or visual studio's decompile option should be able to grab it.
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.
-
there's a call in there that looks suspicious. I'd need to see the IL, not the asm.
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.
well.. 1. I was saying the compiler will remove obvious dead end code, make sense to check the assembly 2. what interesting is not the generic method's IL, but the concrete A or A code, which I have no clue where to see at any rate, assembly code looks bad.... :(
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
well.. 1. I was saying the compiler will remove obvious dead end code, make sense to check the assembly 2. what interesting is not the generic method's IL, but the concrete A or A code, which I have no clue where to see at any rate, assembly code looks bad.... :(
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
if i can see where that CALL in the asm leads i'd know, but viewing the IL is the only realistic way to tell where it leads
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.
-
well.. 1. I was saying the compiler will remove obvious dead end code, make sense to check the assembly 2. what interesting is not the generic method's IL, but the concrete A or A code, which I have no clue where to see at any rate, assembly code looks bad.... :(
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
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.
-
i like message/signal based systems but most runtimes don't include some basics that should be "primitives/intrinsics" or otherwise first class, like thread safe priority queues and circular buffers and such. At the very least they should be runtime libraries provided with the base framework. But I really think if Alan Kay had wanted a message based programming environment it should have been done somewhat differently than OOP. think something a bit more along lines of parallel programming style constructs and the like, except instead of dealing with iterations of loops you're dealing with signalling. honestly, it's easy enough to create a domain-specific set of "language extension" style headers in C++ to enable this. I love C++ for that. about 1/3 of the language is the headers and because of the way the preprocessor and template system works you can create your own pseudo language constructs. There's nothing else like it in major programming languages but I really wish their was.
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.
-
Speaking of Alan Kay and C++...
Quote:
I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind. -- Alan Kay, OOPSLA '97
:-D
If you think 'goto' is evil, try writing an Assembly program without JMP.
if you're using OOP as your primary paradigm in C++ you're almost certainly Doing It Wrong(TM) However, C++ is a truly multi-paradigm language and is fully capable of doing OOP programming. But like I said, if Kay had messaging in mind, OOP probably wasn't the way to go. You can implement a signal passing psuedo language extension in C++ to elegantly handle messaging passing. You can implement an OOP system too, but I wouldn't recommend that.
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.