<div dir="ltr"><div><div>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. <br>
<br></div>1) Functional vs OO -> Functional by a landslide where the critical factors are Code Correctness, Maintainability, Understandability, Succinctness, Changeability.<br></div><div> Here it really comes down to state, minimization of, reduction of redundant state and above all limiting state mutation.<br>
</div><div><br>2) Pure Functional vs Functional with side effecting escape hatch. -> Functional with escape hatch.<br></div><div> 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.<br>
<br></div><div>3) Static Typed vs Dynamic Typed (loosely term) vs Hybrid -> Hybrid will win hands down.<br></div><div> 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. <br>
<br>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. <br>
<br></div><div> 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.<br>
</div><div><br></div><div>4) The Expression Problem<br></div><div> 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.<br>
<br></div><div>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):<br><br></div><div> 0) type classes<br></div><div> 1) typed multimethods / generics<br>
</div><div> 2) typed protoypes (a la Closure)<br></div><div> 3) typed interfaces for structures, a la Go.<br>--------------------------------------------------------------<br></div><div> 4) typed sigs/units.<br><br></div>
<div>Off the cuff 3 + 4 would be HUGE and sufficient alone (for me)<br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 20, 2013 at 2:53 PM, Scott Klarenbach <span dir="ltr"><<a href="mailto:scott@pointyhat.ca" target="_blank">scott@pointyhat.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>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.</div>
<div><br></div><div>I've read the paper here: <a href="http://www.cs.rochester.edu/~cding/Teaching/254Fall2001/Assignments/tr98-299.pdf" target="_blank">http://www.cs.rochester.edu/~cding/Teaching/254Fall2001/Assignments/tr98-299.pdf</a> 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: <a href="http://www.ccs.neu.edu/racket/pubs/icfp98-ff.pdf" target="_blank">http://www.ccs.neu.edu/racket/pubs/icfp98-ff.pdf</a> 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.</div>
<div><br></div><div>In contrast, I've been playing a lot with Clojure and reading Rich Hickey (<a href="http://www.infoq.com/presentations/Value-Values" target="_blank">http://www.infoq.com/presentations/Value-Values</a> and <a href="http://www.infoq.com/presentations/Simple-Made-Easy" target="_blank">http://www.infoq.com/presentations/Simple-Made-Easy</a>) 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.</div>
<div><br></div><div><div>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.</div><div><br></div><div>
Regarding the first two papers discussing Object Oriented and Functional approaches to reuse, I'm wondering:</div><div><br></div></div><div>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 <i>and</i> the existing clients?</div>
<div><br></div><div>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?</div>
<div><br></div><div>Thanks a lot.</div>
<div><br></div><div><div>-- <br>Talk to you soon,<br><br>Scott Klarenbach<br><br>PointyHat Software Corp.<br><a href="http://www.pointyhat.ca" target="_blank">www.pointyhat.ca</a><br>p <a href="tel:604-568-4280" value="+16045684280" target="_blank">604-568-4280</a><br>
e <a href="mailto:scott@pointyhat.ca" target="_blank">scott@pointyhat.ca</a><br>
<span style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">200-1575 W. Georgia</span><br>Vancouver, BC <span style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">V6G2V3</span><br>
<br>_______________________________________<br>To iterate is human; to recur, divine
</div></div>
<br>____________________<br>
Racket Users list:<br>
<a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br>
<br></blockquote></div><br></div>