5 ms·

Anyone care to expand on the reasons for the guideline?

by mef 13y ago

mhaymo 13y ago
Without such reasoning, this article is kind of worthless, and I'm not sure how it got to the top of HN.
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 ago
  Having 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 ago
    F# 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 ago
  Have 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

Anyone care to expand on the reasons for the guideline?

by mef 13y ago

Anyone care to expand on the reasons for the guideline?

mhaymo 13y ago

Without such reasoning, this article is kind of worthless, and I'm not sure how it got to the top of HN.

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 ago
Having 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 ago
  F# 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 ago
Have 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