Thanks Chongkai - <br><br>below are some of my clarifications and comments and hopefully I don't cause the thread to degenerate ;) <br><br><div><span class="gmail_quote">On 5/15/07, <b class="gmail_sendername">Chongkai Zhu
</b> <<a href="mailto:czhu@cs.utah.edu" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">czhu@cs.utah.edu</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> > How to think in FP rather than OOP, especially for large scale apps?<br><br>> First of all, FP/OOP and danamic/static typing is two totally different idea. Languages such as ML and haskell are both static typing >and FP.
</blockquote><div><br>Agreed - I didn't attempt to separate the two concepts in my messages as much as I probably should have - my fault (I do realize Haskell & ML family are strongly typed and FP). <br><br>The reason I lumped them together has to do with types and dispatch - I seem to come across (cond ((number? x) ...) ((string? x) ...)) quite often so far in Scheme, and dispatch by type is a central concept in OOP. I can ask this question separately, but I just thought that they are related ;)
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> Second, I can't see any intrinsical difference between FP and OOP. Scheme is the result of merging FP and OOP.
</blockquote><div><br>(aside: my understanding is that Scheme is quite a bit of FP, with OOP bolted on as optional features - i.e. class.ss is not part of R5RS, but I'm likely misinformed...)<br><br>IMHO there are differences between OOP & FP, especially in the concepts that they embodied. OOP promotes statefulness via data encapsulation, whereas pure FP promotes statelessness. OOP promotes binding between methods and data (as you know- I am talking about mostly single-dispatch class systems like C# & Java) , and FP appears to promote loose coupling between functions and data. etc. And the main difference for me personally is that I can think about a whole large app in objects, but have difficult to do so with only functions (the original thread on imperative flow John/Anton describe that FP allows piecing an app together - it's the piecing together that I am missing here...).
<br><br>i.e. it is natural to represent GUI windows, menus, buttons, etc as objects... how would one represent such in FP style? It is simple to model a database schema as one class per table... how would one represent such in FP style? At large app level I am so accustomed to think in objects so it's difficult for me to see things differently and would love some enlightenment.
<br><br>Gene has sent me a few source code links for studying, so I'm going down that path, but would love to hear from others who have gone down the path of constructing large scale FP-based applications on their experiences. If the answer is such that it makes better sense to structure some parts of program in FP and some other part of program in OOP and this is why modeling such and such in FP or OOP is better, that's what I am after as well,
i.e. why FP style suites a particular problem domain better, and vice versa ;) <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> Third, by making proper use of macros, the code size should be much smaller.</blockquote>
<div><br>Couldn't agree more on this point ;) <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Chongkai</blockquote></div><br>
Thanks,<br>yinso <br><br>