i don't like object oriented programming
-
that's definitely fair. and I come at C# from a C++ background. I like C#, don't get me wrong, and it's miles ahead of Java in terms of how it's put together, IMO, but I still miss aspects of C++ development with it, even as it has supplanted C++ as my primary development language and environment.
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 miss the multiple inheritance of C++ as well. I know we can do it via Interfaces but it's not quite as straightforward. Perhaps by C#12 it will be there. :sigh:
- I would love to change the world, but they won’t give me the source code.
i'm glad i'm not the only one! =)
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.
-
it's one of the areas where C++ really shines and I kind of wish other, higher level imperative languages would catch up. though i'd also like to see C++ have more functional-programming constructs in the future.
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 only ever dabbled in C++ (80s, 90s), so I never became familiar with what it can do. I went straight from C (mostly on OpenVMS) to C# (and .net) and it was like a Bob-send -- I'm glad I hadn't had to use C++ and the various libraries people talk about. A lot of the hype I heard turned me off of C++ anyway. But... I want multiple-inheritance and such. There are a number of facets of C# (.net languages) I don't like. Languages and frameworks should provide features and _allow_ developers to do what their particular task requires rather than dictating what the develop must or must not do. I may still need to look at D again.
-
I only ever dabbled in C++ (80s, 90s), so I never became familiar with what it can do. I went straight from C (mostly on OpenVMS) to C# (and .net) and it was like a Bob-send -- I'm glad I hadn't had to use C++ and the various libraries people talk about. A lot of the hype I heard turned me off of C++ anyway. But... I want multiple-inheritance and such. There are a number of facets of C# (.net languages) I don't like. Languages and frameworks should provide features and _allow_ developers to do what their particular task requires rather than dictating what the develop must or must not do. I may still need to look at D again.
Well the weird thing about C++ is by itself it's about 2/3 of a language, while the standard template libraries are (usually) the other 1/3 and it's strange to think of it that way, but that's how it ends up baking out - STL is so intrinsic to any significant C++ development that you really don't even want to do it without it, just like you wouldn't want to write an app without an operating system. It's not just about runtime libraries, although that's most of it. Because of the way templates work, you can use them to basically implement "language features" of a sort. So STL sort of folds itself into the language. And the cool thing about that is you can potentially make your own "domain specific" language superset from C++ just like STL does - the spirit framework does this, and boost kind of does. So that's something that's really hard to get used to at first because it's pretty unique to C++ after that, just learning how to use generic programming is the big learning curve, but I swear once you do, you'll fall in love.
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.
At the risk of being even more wildly undesirable here, I'm with ya.
-
At the risk of being even more wildly undesirable here, I'm with ya.
come sit at my table. we can totally be unpopular together :laugh:
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 the weird thing about C++ is by itself it's about 2/3 of a language, while the standard template libraries are (usually) the other 1/3 and it's strange to think of it that way, but that's how it ends up baking out - STL is so intrinsic to any significant C++ development that you really don't even want to do it without it, just like you wouldn't want to write an app without an operating system. It's not just about runtime libraries, although that's most of it. Because of the way templates work, you can use them to basically implement "language features" of a sort. So STL sort of folds itself into the language. And the cool thing about that is you can potentially make your own "domain specific" language superset from C++ just like STL does - the spirit framework does this, and boost kind of does. So that's something that's really hard to get used to at first because it's pretty unique to C++ after that, just learning how to use generic programming is the big learning curve, but I swear once you do, you'll fall in love.
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, nope, hype hype hype...
-
Yeah, nope, hype hype hype...
i'm just telling you based on my experience using it. Very few teach it properly unfortunately.
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.
honey the monster, codewitch wrote:
if i can't do generic programming i'm a sad honey bear.
Yuck. OO is procedural, but with structure and local variables. It doesn't limit a procedural programmer; you're free to put everything in a God-class and pretend to be procedural.
honey the monster, codewitch wrote:
generics need to be able to do more.
Again, yuck.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
honey the monster, codewitch wrote:
if i can't do generic programming i'm a sad honey bear.
Yuck. OO is procedural, but with structure and local variables. It doesn't limit a procedural programmer; you're free to put everything in a God-class and pretend to be procedural.
honey the monster, codewitch wrote:
generics need to be able to do more.
Again, yuck.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
i mean procedural as in procedures rather than objects to divvy up code. If there's a better word for that I'm unaware of it. You could say that all imperative languages are procedural if they have functions/methods but that's almost too general to be useful. As far as your yucks, i come from a C++ background and happen to like generic programming. to each their own.
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.
-
honey the monster, codewitch wrote:
if i can't do generic programming i'm a sad honey bear.
Yuck. OO is procedural, but with structure and local variables. It doesn't limit a procedural programmer; you're free to put everything in a God-class and pretend to be procedural.
honey the monster, codewitch wrote:
generics need to be able to do more.
Again, yuck.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
But I want an atheistic classless society.
-
i mean procedural as in procedures rather than objects to divvy up code. If there's a better word for that I'm unaware of it. You could say that all imperative languages are procedural if they have functions/methods but that's almost too general to be useful. As far as your yucks, i come from a C++ background and happen to like generic programming. to each their own.
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.
honey the monster, codewitch wrote:
i mean procedural as in procedures rather than objects to divvy up code.
That's a non-complaint; like I said, you can put all your procedures in a God-object.
honey the monster, codewitch wrote:
If there's a better word for that I'm unaware of it. You could say that all imperative languages are procedural if they have functions/methods but that's almost too general to be useful.
I'd say you haven't worked in a strict procedural language :thumbsup:
honey the monster, codewitch wrote:
As far as your yucks, i come from a C++ background and happen to like generic programming. to each their own.
Haven't seen much of that, so not going to comment on it. But still, yuck. :)
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
But I want an atheistic classless society.
-
honey the monster, codewitch wrote:
i mean procedural as in procedures rather than objects to divvy up code.
That's a non-complaint; like I said, you can put all your procedures in a God-object.
honey the monster, codewitch wrote:
If there's a better word for that I'm unaware of it. You could say that all imperative languages are procedural if they have functions/methods but that's almost too general to be useful.
I'd say you haven't worked in a strict procedural language :thumbsup:
honey the monster, codewitch wrote:
As far as your yucks, i come from a C++ background and happen to like generic programming. to each their own.
Haven't seen much of that, so not going to comment on it. But still, yuck. :)
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
Eddy Vluggen wrote:
That's a non-complaint; like I said, you can put all your procedures in a God-object
Not a complaint. Just attempting to clarify what i meant
Eddy Vluggen wrote:
I'd say you haven't worked in a strict procedural language
Now I wonder what you'd consider procedural. Batch files? SQL? C?
Eddy Vluggen wrote:
Haven't seen much of that, so not going to comment on it. But still, yuck.
Spoken like someone that's never used it. GP is lovely, elegant, concise and powerful. I wish it was more available in places other than 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.
-
But I want an atheistic classless society.
heh
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 learned OO before it was (generally) known. I didn't learn it by that name. Our "101 Programming" course was based on Pascal. The professor insisted that we wrote sets of functions for each RECORD definition, for handling that record type. He also insisted that these fuctions took as their first argument the specific record instance to be operated on. We learned it as a good way to handle the information in a managable way. It was similar to his other requirements: Function arguments should list the read-only inputs first, then the read-write, then the pure results. Every function/subroutine should first check all input data, then do the work, then produce the side effects. We learned that as a valuable discipline. We never questioned it, and today I can't give a single argument why we should have. Then came OO, and we moved the first function argument before the function name, with a full stop inbetween. Fair enough - "a new programming paradigm", or "syntactical sugar", call it whatever you want. At the University, we got hold of one of the very first C++ compilers, translating everything to K&R C, so we could see what OO really is - and said: So what? Isn't that what we have been doing all the time, more or less? There were some extensions, of course, but not that revolutionary. I got my first job, in a company writing their own OS for their own minis and superminis, written in a langugage midway between plain C and assembler. What did I see? Those OS programmers had created the same kind of "OO" structures at near-assembly level, very similar to what I had seen in the C++-to-C translations, with class objects and inheritance with subclasses and superclasses and function tables and whathaveyou. (No multiple inheritance, but that is a concept that is highly debated anyway.) When I, as the novice with academic ideas, tried to tell them that "This is exactly like OO programming", they didn't grasp the idea, at the academic level. It was just the proper way to do it. Similar to the way it was thought in my first "101 Programming" course. So I never managed to build up any negative relationship to OO. Only to those programmers who insist that there is One OO Way, or demand that you must use every single OO feature in your program, now matter how primmitive the program is. Maybe I am too relaxed. That allows me to pick from OO what is usable in a given case, and ignore the rest. I think that is good.
-
I learned OO before it was (generally) known. I didn't learn it by that name. Our "101 Programming" course was based on Pascal. The professor insisted that we wrote sets of functions for each RECORD definition, for handling that record type. He also insisted that these fuctions took as their first argument the specific record instance to be operated on. We learned it as a good way to handle the information in a managable way. It was similar to his other requirements: Function arguments should list the read-only inputs first, then the read-write, then the pure results. Every function/subroutine should first check all input data, then do the work, then produce the side effects. We learned that as a valuable discipline. We never questioned it, and today I can't give a single argument why we should have. Then came OO, and we moved the first function argument before the function name, with a full stop inbetween. Fair enough - "a new programming paradigm", or "syntactical sugar", call it whatever you want. At the University, we got hold of one of the very first C++ compilers, translating everything to K&R C, so we could see what OO really is - and said: So what? Isn't that what we have been doing all the time, more or less? There were some extensions, of course, but not that revolutionary. I got my first job, in a company writing their own OS for their own minis and superminis, written in a langugage midway between plain C and assembler. What did I see? Those OS programmers had created the same kind of "OO" structures at near-assembly level, very similar to what I had seen in the C++-to-C translations, with class objects and inheritance with subclasses and superclasses and function tables and whathaveyou. (No multiple inheritance, but that is a concept that is highly debated anyway.) When I, as the novice with academic ideas, tried to tell them that "This is exactly like OO programming", they didn't grasp the idea, at the academic level. It was just the proper way to do it. Similar to the way it was thought in my first "101 Programming" course. So I never managed to build up any negative relationship to OO. Only to those programmers who insist that there is One OO Way, or demand that you must use every single OO feature in your program, now matter how primmitive the program is. Maybe I am too relaxed. That allows me to pick from OO what is usable in a given case, and ignore the rest. I think that is good.
I definitely hear you, and though I got my start less formally, and in the 1980s I worked out a lot of the same observations that you did about OO. My problem isn't OO specifically, I guess it's more that OO languages (outside, say C++) tend to treat that as first class at the expense of everything else. And really, OO isn't my first go-to for solving a problem. I speak in templates - generic programming a lot - it's just often a more elegant way to code, and solves a lot of needs of both imperative and functional programming in practice. So when I don't have it, I mourn it I guess. It's still that Thing(TM) that keeps calling me back to C++. Oh but I wish for a higher level language that I could do with what I do with C++. Give me something like C# that works with something like STL and I will be in heaven. That's what I want.
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.
at the risk of being controversial, I will say: procedural vs object oriented = potato vs tomato Think of Math.Cos(), the fact that Cos() is part of the Math class is not really limiting and artificially constrained by object oriented programming. It's just that the function need be somewhere... I guess I used to feel limited by the number of class I could call "Utils" but I overcame this challenge long time ago! ;P generic limitation: I did notice that when my code become excessively generic it snowball and become more unmaintainable. I did notice that C++ specialization would be a nice touch that is missing. And I also hate boiler plate repeated code. But strangely enough since I noticed that I had no further problem... maybe I unconsciously found working alternative? I guess it might means there might be a solution to the problem you are facing...
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
at the risk of being controversial, I will say: procedural vs object oriented = potato vs tomato Think of Math.Cos(), the fact that Cos() is part of the Math class is not really limiting and artificially constrained by object oriented programming. It's just that the function need be somewhere... I guess I used to feel limited by the number of class I could call "Utils" but I overcame this challenge long time ago! ;P generic limitation: I did notice that when my code become excessively generic it snowball and become more unmaintainable. I did notice that C++ specialization would be a nice touch that is missing. And I also hate boiler plate repeated code. But strangely enough since I noticed that I had no further problem... maybe I unconsciously found working alternative? I guess it might means there might be a solution to the problem you are facing...
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
the problem I'm running into right now regarding specialization i had to work around by using a common base class to "share functionality" and it doesn't work very well. I have a lot of duplicated code in the specialization, and i've had to use "new" on some methods. It's rather awful, actually. Luckily most of the time, I can avoid the need altogether but in this case, specialization would make the most sense, so i did my best to "make it work" it's baling wire and chewing gum compared to what i can do in C++ I guess for me, once I relearned C++ the way it's taught in Moo and Koenig's book, I used generic programming for most of my coding. It doesn't make maintenance snowball. If it does, you're probably using it wrong and I highly recommend Accelerated C++ by the two authors I alluded to above. It's worth every penny of the $20-$30 asking price and you can usually get it used for a song. It's also a mercifully short book. It's one of the best programming books I've ever encountered for that - it's concise, accessible, and teaches something that's not typically taught well (C++ programming) But alas, using C++ the way they show you to use it makes me miss being able to do things that way now.
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 problem I'm running into right now regarding specialization i had to work around by using a common base class to "share functionality" and it doesn't work very well. I have a lot of duplicated code in the specialization, and i've had to use "new" on some methods. It's rather awful, actually. Luckily most of the time, I can avoid the need altogether but in this case, specialization would make the most sense, so i did my best to "make it work" it's baling wire and chewing gum compared to what i can do in C++ I guess for me, once I relearned C++ the way it's taught in Moo and Koenig's book, I used generic programming for most of my coding. It doesn't make maintenance snowball. If it does, you're probably using it wrong and I highly recommend Accelerated C++ by the two authors I alluded to above. It's worth every penny of the $20-$30 asking price and you can usually get it used for a song. It's also a mercifully short book. It's one of the best programming books I've ever encountered for that - it's concise, accessible, and teaches something that's not typically taught well (C++ programming) But alas, using C++ the way they show you to use it makes me miss being able to do things that way now.
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.
As someone else mentioned, have you considered using interface? Interface offer some of the benefit of multiple class inheritance without any drawback or ambiguity. ;)
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!