Coffeehouse Thread

6 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Should C# lean more towards OO or functional languages?

Back to Forum: Coffeehouse
  • User profile image
    Karthik

    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?

  • User profile image
    bitmask

    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 Smiley

  • User profile image
    eto

    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)

  • User profile image
    Kevin Daly

    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.

  • User profile image
    spod

    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...

  • User profile image
    Sabot

    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.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.