Ever so often, people argue that C# is a purely OO language, just like Java.
But I would like to say that both C# and Java lean towards being OO, and are not entirely so.
For instance, if you take Smalltalk, everything is an object. Messages are objects. All methods are incorporated into objects, and objects communicate with one another using message passing.
I will not buy the argument that OO languages are more productive than Functional Languages - I think both have their own set of benefits. The reason why C# and Java are good is only because they are managed and come with better resource management (and other
resources in the form of good libraries).
So, as a C and C++ programmer, I feel the need to ask if MS leaned towards being OO so that they could compare well against Java?
Joe Beda had mentioned that managed code will be the norm, and not otherwise - and I can see the benefits of that, and even agree that it would be the right way to go. But does being managed equate to being OO? I maybe (and hope I'm) wrong, but I have a feeling
MS perceives OO as being managed.
But I can see quite a lot of benefits of not going entirely OO, and maintaining functional programming attributes.
I feel that maybe MS should incorporate more functional programming features into C#, while aggresively pushing managed code.
What do you folks think?
I think managed code and OO are orthogonal concepts. I can write in an OO language and target a non-managed environment (C++) or write in a purely functional language (Haskell) and target a managed runtime. C# (and VB.NET) already offer a nice feature set
to mix imperative and declarative programming models, but I don't see either moving towards "functional" ala SQL or Haskell.
Just my 2 cents worth of mumbo jumbo
Just because constructs exist to create objects and program in an object-oriented way does not mean you have to.. I've experienced many people that still code in a functional fashion, even when the entire system they are programming for is entirely object
oriented. It ticked me off, to be honest. Objects allow you to group things together.. Imagine if the entire .NET framework was functional... you'd have function names such as: Graphics_DrawImage(graphicsHandle, image) Form_SetText(formHandle, text) Form_GetText(formHandle,
text) and you'd have handle variables everywhere.. ugh.. that would be very ugly.. objects allow you to abstract these into their own logical unit, thus making the code easier to read, write, and maintain: MyGraphic.DrawImage(MyImage); Form.Text = text; text
= Form.Text; though, i guess in the land of low level device drivers and such, non-oop is the way to go. Though, most of the time a device driver would NOT be written in managed code.. haha.. (: (sorry for no line breaks, i'm using Konqueror, and i don't know
the BBCode for a line break.. grr)
Actually, I think C# is already well supplied with functional features - and that's the reason why I prefer C# over VB.NET.
I stress that I do not mean to imply that C# is a better language than VB.NET, only that the functional syntax inherited from C appeals to me.
I think the clr tries to be as paradigm agnostic as it can, and aims to support as many langauge types as possible...certainly someone was thinking about functional languages when they added the tailcall instruction to IL.
C# itself feels to me like an OO language. I think it supports some functional programming styles due to .net's gc support etc, so i do find a tendency to write code like:
new foo( new Bar( params ) ).DoA( ).ThenB();
which is kinda functional ,maybe??
and i think whidbey makes the story more interesting in this respect with its support for generics and anonymous delegates etc., but that c# is fundamentally all about objects with behaviour and state and all that other OO stuff...
just my opinion though, i'm no expert here at all...
Pure OO is all very nice but OO does not cater for real-world scenarios such as distribution, 'scalling-up' or 'scalling-out' of enterprise systems.
Some particular instances of OO cater for this, I would say that these instances are proprietary and are 'fudges' to get round what OO inherently doesn't have.
OO is a theory that everyone must except cannot always fit neatly into a real-world solutions.
How to take model modern-day distributed architecture applications is a mixture of experience and good judgement
because there is no silver-bullet.
Once OO is excepted as not being the complete answer we can look at ways to fill the gaps. Obviously Microsoft is full aware they can not solve this issue in isolation, it's simply not practical. So for the time being the language will have to take on some
of the burden. At this point it is very important to state that a balance between good design and practical implementation must be struck.
There is no point in being a 'purest' and believing OO is the total answer, this, I believe, is either 'denial' or 'ignorance', sorry to be so strong with my opinion but I have been on plenty of projects were developers have failed to see the woods for the
trees. There is only so far that you can say that the world is wrong and you are right.
So what is the answer? ... balance and the journey to get there.
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.