[racket] Code Reuse, Object Oriented vs Functional

From: Ray Racine (ray.racine at gmail.com)
Date: Fri Jun 21 09:39:12 EDT 2013

Speaking from a reasonable amount of experience in "real-world" composing
code in a polyphony of styles, idioms, methodologies and languages, I have
reached a few (personal) conclusions.

1) Functional vs OO -> Functional by a landslide where the critical factors
are Code Correctness, Maintainability, Understandability, Succinctness,
Changeability.
    Here it really comes down to state, minimization of, reduction of
redundant state and above all limiting state mutation.

2) Pure Functional vs Functional with side effecting escape hatch. ->
Functional with escape hatch.
   Haskell / Monadiac IO is too limiting and often contorts the code
needlessly or for questionable gain.  Yea, basic IO is OK.  But as soon as
things get real world and you have to start pulling out nested monadic
computations via monadic transformers yada yada pain thresholds are
breached and silent screaming erupts.  In a functional language, it is very
easy to cleanly modularize code and specifically to modularize IO from pure
referentially transparent functional code.  i.e. You can get pretty much
all the gains without the pain with only a bit of personal discipline.

3) Static Typed vs Dynamic Typed (loosely term) vs Hybrid -> Hybrid will
win hands down.
    I don't understand the contentious debate on this at all, not a whit.
It is simply foolish, plain, pure and simple to NOT leverage static
analysis of code, i.e. type check.  Seriously, if you are not placing the
one liner type signature along with every Racket procedure you write,
start.  Sure, cheat for that 50 line Racket script, but otherwise no
excuses.

The future will be hybrid with the agenda being set by Racket and shadows
such as Dart.  The appropriate mixture of reasonable static checking along
with runtime contract assertions for those things which cannot be
reasonably statically asserted will be foundational moving forward.

  So for example, ne area where functional programming really hits its
stride when one starts to leverage HOFs (functions taking functions,
returning functions).  It's a whole new world.  Eventually small towers of
HOFs generating HOFS, used by plain ol' Fs happen.  Such constructions
without the safety of static scaffolding is just ... darn foolish.

4) The Expression Problem
   For whatever reason one can code in OO without ever noting the
expression problem.   After a bit of functional programming you note it,
even if you don't know what it's been called or the dual nature of the
issue in OO land.  Once you know of it you'll start noting its dual side in
OO.

I think the biggest hole in Racket at the moment and I can't think if any
other (largish hole) has to do with (pick one or more from 0-3 and add 4):

 0) type classes
 1) typed multimethods / generics
 2) typed protoypes (a la Closure)
 3) typed interfaces for structures, a la Go.
--------------------------------------------------------------
 4) typed sigs/units.

Off the cuff 3 + 4 would be HUGE and sufficient alone (for me)



On Thu, Jun 20, 2013 at 2:53 PM, Scott Klarenbach <scott at pointyhat.ca>wrote:

> I'd like to get some feedback from the Racket group regarding Object
> Oriented vs Functional styles.  I know this can be a bit of a quagmire, so
> apologies if it's not appropriate to post it here.  I just thought I'm
> likely to get some of the more thoughtful replies from this group.
>
> I've read the paper here:
> http://www.cs.rochester.edu/~cding/Teaching/254Fall2001/Assignments/tr98-299.pdf which
> outlines the central problem as having to choose between extensible
> variants (OO) and extensible tools (functional).  The paper proposes the
> extensible visitor pattern as a solution, and ultimately rests in the OO
> camp.  The next paper: http://www.ccs.neu.edu/racket/pubs/icfp98-ff.pdf goes
> a step further by showing how Racket specific features such as Units and
> Mixins can eliminate the need for the extensible visitor design pattern,
> and again, lands firmly in the OO camp.
>
> In contrast, I've been playing a lot with Clojure and reading Rich Hickey (
> http://www.infoq.com/presentations/Value-Values and
> http://www.infoq.com/presentations/Simple-Made-Easy) and he proposes the
> opposite approach:  OO's time has come, and that through powerful
> functional languages you can achieve encapsulation, polymorphism and
> extensibility in a simpler manner without the complexity of OO techniques.
>
> I'm curious as to the opinion of this community regarding Rich Hickey's
> stance on applying immutable values and pure functions to nearly every
> programming problem.
>
> Regarding the first two papers discussing Object Oriented and Functional
> approaches to reuse, I'm wondering:
>
> 1.) Do generic functions (multiple dispatch) in a language not empower the
> functional arguments in the first two papers by Matthias and Matthew (and
> others)?  If I can add new functions with the same name that dispatch on
> new variants as they are added, is this not a simple solution to the
> extensibility problem in a functional style?  Does this not allow for reuse
> of both the original components *and* the existing clients?
>
> 2.) Does there exist an obvious class of problems that are better suited
> to an object oriented design vs functional and vice-versa, or is the power
> of such languages as racket reducing the OO vs Functional debate to a
> religious war, whereby both methods achieve reuse and it's just a matter of
> preference?
>
> Thanks a lot.
>
> --
> Talk to you soon,
>
> Scott Klarenbach
>
> PointyHat Software Corp.
> www.pointyhat.ca
> p 604-568-4280
> e scott at pointyhat.ca
> 200-1575 W. Georgia
> Vancouver, BC V6G2V3
>
> _______________________________________
> To iterate is human; to recur, divine
>
> ____________________
>   Racket Users list:
>   http://lists.racket-lang.org/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20130621/7651e194/attachment.html>

Posted on the users mailing list.