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