Hi all - <br><br>thanks for the excellent discussion. I have a related question, but from probably the opposite perspective, given I come from OOP world:<br><br><div style="margin-left: 40px;">How to think in FP rather than OOP, especially for large scale apps?
<br></div><br>This question is of course general/meta, but would love to hear commentary/experiences on how to fully think in FP rather than OOP, and also perhaps, how not to think in types (i.e. the question is about Scheme&#39;s &quot;lack&quot; of types so to speak).
<br><br>OOP to me provides a nice way to organize related code and data together, in a stronger relation than module.&nbsp; The OOP world I am familiar with (i.e. C#, etc) also has strong notion of typing.&nbsp; Combined together, one can ensure that the data in an object is &quot;type safe&quot;,
i.e. validation/conversion has taken place as part of object construction.&nbsp; Once an object is constructed, it is safe to pass around, etc., and we know that class methods are always safe to call on an object of the type.
<br><br>FP on the other hand seems less tightly coupled, and that means a couple of things to me:<br><ol><li>I have to explicitly pass the object around <br></li><li>I have to type check the object if the function can only handle some specific types,
i.e. (cond ((type-a? obj) ...) ...) <br></li></ol>These things are not big deal for small applications, but for bigger apps it seems to be quite cumbersome to have to do all these different checks everywhere.&nbsp; And that gives me a feeling that I don&#39;t have it right, yet.
<br><br>I came across the notion that classes/objects can be modeled by closures and indeed had some fun trying to write my own class generator as an exercise, but then I have to wonder if I am missing a big picture somewhere -
i.e. would I do &quot;better&quot; (i.e. fewer lines of code, higher conceptual abstraction) with raw FP rather than OOP for large scale app?&nbsp; Would problems like object-relational mapping go away (a very cumbersome procedure)? etc.&nbsp;
<br><br>So perhaps, as an example - an enterprise app with hundreds of tables in a database.&nbsp; In OOP each table would be mapped to a class, and the code mostly deals with converting user input to objects that are then translated to query for the database.&nbsp; The business logic then concerns with manipulation of the objects between the layers.&nbsp; It is obvious that in such a system there are a ton of boiler plate code, and that&#39;s what Java is famous for.
<br><br>How does FP model the above example differently? <br><br>Any input is appreciated ;)&nbsp; Thanks,<br>yinso <br><br> <div><span class="gmail_quote">On 5/12/07, <b class="gmail_sendername">Anton van Straaten</b> &lt;<a href="mailto:anton@appsolutions.com">
anton@appsolutions.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">John Clements wrote:<br>&gt; I&#39;m teaching Java to first-year students, and we&#39;re about to walk off&nbsp;&nbsp;a
<br>&gt; cliff and start programming imperatively.&nbsp;&nbsp;I&#39;ve done this&nbsp;&nbsp;transition<br>&gt; several times now, and it occurs to me that what&#39;s most&nbsp;&nbsp;irritating to<br>&gt; me about the imperative style is the lack of &quot;flow&quot;.
<br>&gt;<br>&gt; What do I mean by flow?&nbsp;&nbsp;Simply that each expression produces a&nbsp;&nbsp;result<br>&gt; that is used by another expression.&nbsp;&nbsp;In imperative&nbsp;&nbsp;programming, by<br>&gt; contrast, I feel that I have a bunch of statements&nbsp;&nbsp;lying on the floor,
<br>&gt; and that their order is both important and&nbsp;&nbsp;difficult to explain clearly.<br><br>Perhaps this is too obvious to mention in the present company, but since<br>you didn&#39;t mention it, the world-passing (monadic) view of imperative
<br>programming might provide a useful perspective.&nbsp;&nbsp;It provides an easily<br>understood theory (at a high level) of imperative programming, which<br>lets you compare imperative programs to functional programs using a<br>
common model.&nbsp;&nbsp;(Admittedly, the model is skewed in favor of the<br>functional approach, but I&#39;m guessing you won&#39;t object to that.)<br><br>The resulting explanations end up not being all that different from<br>those that have already been given, but introducing &quot;the world&quot; as a
<br>first-class feature of the explanatory model helps to discuss and reason<br>about the issues.<br><br>For example, the world-passing perspective explains why the imperative<br>puzzle pieces (statements) that Joe described are perfect squares: the
<br>only functional/algebraic dependency between statements is &quot;the world&quot;,<br>so there&#39;s no way to fit statements together based on what kind of value<br>they consume and produce -- they all consume and produce a version of
<br>the world.<br><br>Another point is that every statement in an imperative program can<br>change the value of any currently visible variable in the world.&nbsp;&nbsp;In<br>contrast, a functional program can only &quot;change&quot; the value of variables
<br>at function application time.&nbsp;&nbsp;So every single imperative statement is<br>like a function in its own right, which complicates reasoning.<br><br>If the students can handle a functional model of an imperative program<br>
looking something like:<br><br>&nbsp;&nbsp; ((lambda (world) stmt-n)<br>&nbsp;&nbsp;&nbsp;&nbsp;((lambda (world) ...)<br>&nbsp;&nbsp;&nbsp;&nbsp; ((lambda (world) stmt-1)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#39;())))<br><br>...then there are quite a few concrete points and comparisons that could<br>
be made with it.&nbsp;&nbsp;It&#39;s also good preparation for teaching monads later... :)<br><br>Anton<br><br>_________________________________________________<br>&nbsp;&nbsp;For list-related administrative tasks:<br>&nbsp;&nbsp;<a href="http://list.cs.brown.edu/mailman/listinfo/plt-scheme">
http://list.cs.brown.edu/mailman/listinfo/plt-scheme</a><br></blockquote></div><br>