Linked by snydeq on Mon 25th Oct 2010 21:23 UTC
Thread beginning with comment 447074
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Not sure about functional programming, as I'm not sure if every data reduction can simply be expressed as a transformation.
A reduction is a transformation. There are standard functions in most functional languages for data reduction. I find functional languages much better suited to complex data handling than imperative languages.
And then, you have tasks like plotting/visualization which would be cumbersome to handle as "side effects."
Some functional languages (e.g., SML, F# and Scala) treat i/o such as graphics and file access as side effects, so they work pretty much as they do in imperative languages. Other languages (like Haskell and Clean) are purely functional and handle i/o by forcing sequence on i/o operations through monads or linear types. These take some getting used to if you come from an imperative world. IIRC, Erlang uses CSP-style message passing for i/o. This, IMO, is a very natural way of doing it.
OOP is imperative programming.
Is it? Several languages describe themselves as "functional and OO", and there are even a few ones who embrace "declarative and OO" at the same time.
I guess that when I think in imperative programming, I am really thinking in languages that allow aplying different algorithms to several datatypes.Like "save this table on this file" or "sort using the second field of the table", instead of having a specific method for each datatype, repeated/inherited ad infinitum.





Member since:
2008-11-19
Agreed -- imperative programming is much more natural than OOP for data reduction. Data doesn't "do" anything, stuff gets done to it.
Not sure about functional programming, as I'm not sure if every data reduction can simply be expressed as a transformation. And then, you have tasks like plotting/visualization which would be cumbersome to handle as "side effects."
Edited 2010-10-25 23:58 UTC