3 ms·
Functional programming works great for processing data - you don't want to change the data, and there isn't a lot of state. You largely write various transforms
by RogerL 13y ago
Functional programming works great for processing data - you don't want to change the data, and there isn't a lot of state. You largely write various transforms and filters, which is right in FP's wheelhouse.
On the other hand, simulation is quite state-full, often has tons of little details that you don't want to expose to the world (encapsulation), the thing that you are simulating usually has a collection of varying behaviors that you can represent via polymorphism or composition, they have attributes, and the 'engine' is often easier to write if you use dynamic(virtual methods)/static(generics)/duck polymorphism to get your things to do their, well, thing.
Which is not to say that either is undoable or really hard in the other paradigm, but if I am simulating something I am often thinking of 'objects' and doing things to them; the OO paradigm helps you program about that in a very expressive way. Ditto for FP and functional programming - I'm thinking about filtering and transforming data.
That is just my view of the author's article, with a caveat. I've seen terrible, beastly simulations done in OO that basically thought that single inheritance is how you spell OO. A single type hierarchy bites you so hard: 'Oh, I'm make everything a widget with draw/eat/process/whatever methods'. Then requirements change, and widgets in this subtree need to do something you thought only widget in that other subtree would do, next requirement has you needing to reflect on who can do what, and so on. You end up with a huge Blob object at the top of your hierarchy, or you endlessly end up with huge blocks of RTTI/reflection to figure out what kind of thing you are dealing with, or otherwise try to work around the problem that the world is not easily decomposed into a single hierarchy.
In practice I find all of this terribly reductive. Need some small thing whose behavior varies in well defined ways? Use polymorphism. Have a bunch of stateful stuff that you need to keep track of? Encapsulation is nice. Want to perform some operation on a large collection of data? Look to transform(). Need to make a lot of inferences and conclusions? Perhaps logic programming will work there. Need to provide a framework where people can build larger systems? Hopefully you are using component or services based ideas. And so on. A programmer should have a bunch of tools handy, and use the best one for the job. On the other hand, just about every person I interview opines that we should inherit for re-use, and I silently despair.
- deleted 13y ago[deleted]
- bsg75 13y agoHaving seen some in the MS camp suggest that F# is a good candidate for data work (vs C#) for similar reasons, are there languages in the cross platform crop whose strengths lend towards data (string) processing (vs app development)? OCaml becomes interesting given the above due to syntax similarities. Scala/Clojure due to Java library support(?). Haskell because it seems to get a good amount of attention.
- kyzyl 13y agoF# is a pretty nice language, but you are indeed still in Microsoft land. That said, mono has gotten pretty good over the years. As far as data processing goes, I've seen both scala get some attention in the data game, because you can easily write hadoop jobs, and you can fairly easily interface with libraries like ATLAS for matrix work. However, working in a functional style in the JVM with lots of data can bite you sometimes, particularly with GC hiccups where the GC just wasn't designed to work efficiently with functional resources usage. Personally I think Haskell is very well suited to data work. You get pretty good speed out of the box, concurrency and parallelism are baked in, and the library support is pretty extensive. It's also quite cross platform. In addition to that, you've got brilliant folks like Simon Peyton-Jones working on stuff like automated stream fusion, which can mean huge speedups. To me the main disadvantage to using haskell for data processing is the relatively long compile times. Since "data science" is typically fairly interactive, until you are pretty good at haskell you might find yourself waiting a long time to realize you've done some silly things. It's really a situation where things liker IPython's html notebooks are invaluable. Sidenote: As far as string processing goes, I've found working with haskell's parsec library to be simply great for creating parser combinator libraries in a very natural way.
- chongli 13y agoHave a bunch of stateful stuff that you need to keep track of? Encapsulation is nice. I think this one is open for debate. There are other models for managing state which make things simpler to reason about than classical OO with encapsulation. One such example is Clojure's epochal time model. http://www.infoq.com/presentations/Value-Values http://www.infoq.com/presentations/Value-Values
- RogerL 13y agoI think everything I wrote is a matter for debate. It's impossible to capture all of software design in two paragraphs. Ten minutes ago I was writing some code to display a baseball game - a quick Python hack, not a game or anything. To me a class plus a bit of encapsulation for things like players, ball, the field is 'just right' in a Goldilocks way. A bigger problem, a different domain, and your link may make a lot more sense. My real point was that you pick and choose based on your needs, not that some incredibly hastily written list is immutable and not open to argument. I would also suggest you (perhaps through equal haste in writing) made a category error. Encapsulation != OO. For example, I can achieve encapsulation in C just by putting variables in my .c file, and not distributing the .c, but only the headers and a lib. I am not trying to nitpick, but wondering if 'classical OO' is part of your assumption. In any case, I have never programmed in Clojure, and know nothing about epochal time models. It looks interesting enough, but is it a tool I can readily reach for if I am programming in C++, Python, or what have you? Will others understand it? Googling provides only a dozen or so relevant links. I think all in all I stand behind "Encapsulation is nice". It is nice, it is not the only way or necessarily the best.
- chongli 13y agoI would also suggest you (perhaps through equal haste in writing) made a category error. Yes, indeed it was haste. Where I really want to draw a distinction is between values and mutable objects (which may or may not use encapsulation). Encapsulation is a leaky abstraction when applied to mutable objects because the hidden state of some object may impact other parts of the system in various ways. Values (and functions of values) are a much sounder abstraction because they are referentially and literally transparent. know nothing about epochal time models The epochal time model is a mechanism used to coordinate change in a language which otherwise uses only immutable values (e.g. Clojure). It provides the means to create a reference to a succession of values over time. This means that any one particular list is immutable but the reference itself is mutated to point to different lists over time. The advantage of this is that these references can be shared -- without locks, copying or cloning -- because the succession of values is coordinated atomically.