[AccessD] AccessD Digest, Vol 98, Issue 7

Hi Charlotte --

No, wait - in fact VB.NET and C# do support first-order functional
programming paradigms (LINQ and related stuff...)

http://www.info.ucl.ac.be/~pvr/paradigms.html

And here they say that MS Excel is a kind of functional programming
environment

http://en.wikipedia.org/wiki/Functional_programming

So you should know and use them for quite some time already - foundations of
functional programming paradigm...  :)

Thank you.

--
Shamil
 
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust
Sent: 12 ?????? 2011 ?. 5:17
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] AccessD Digest, Vol 98, Issue 7

OMG, I think I got let go just in time!!  I'm too old for another whole new
paradigm.

Charlotte Foust

On Mon, Apr 11, 2011 at 2:59 PM, Shamil Salakhetdinov
<shamil at smsconsulting.spb.ru> wrote:
> <<< I doubt seriously that anyone uses your paradigm in .net. >>>
>
> http://fsharp.net ?
>
> --
> Shamil
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
> Sent: 12 ?????? 2011 ?. 0:36
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] AccessD Digest, Vol 98, Issue 7
>
>  > I haven't found a reason why classes can't rely on properly crafted 
> and tested module-level functions.
>
> Do you program in .Net?  Everything is an object.  There is no 
> "module", though there can be static classes / functions.  I haven't 
> done a poll, but I doubt seriously that anyone uses your paradigm in .net.
>
> John W. Colby
> www.ColbyConsulting.com
>
> On 4/11/2011 4:09 PM, Kenneth Ismert wrote:
>> John,
>>
>> I understand the reasoning and all however... because the code is no 
>> longer
>>> contained within the object that needs it, you now open yourself up 
>>> to the old "I need to modify this method... oops... that change 
>>> breaks something else that uses the code".
>>>
>>
>> It is always possible to over-factor, and merge two similar pieces of 
>> code together that really should be separate. In that case, you 
>> factor the code back into multiple pieces, and correct the dependencies.
>>
>>
>>> Class programming exists for a reason.  Placing code in the object 
>>> that needs the code exists for a reason.  Black box programming 
>>> exists for a reason.  The reason in many cases is to prevent exactly 
>>> this kind of interaction when we accidentally change a piece of code 
>>> used in many places and break one of those places.
>>>
>>
>> I would submit that calling side-effect free functions from a class 
>> does not pierce the black box. The important things, state and 
>> access, are protected by the class. But the function can be anywhere: 
>> built-in VBA functions, Access application methods, or DAO library 
>> calls. You undoubtedly call these functions from within your classes.
>>
>>
>>> Yes, there are instances where lots of different things need the 
>>> exact same code, and yes, I have been known to call module functions 
>>> from classes, but it truly is a questionable practice in most cases.
>>>
>>
>> Test cases replace questionability with a guarantee of proper 
>> function. The function shouldn't define what it does -- the test 
>> cases should. If changes to a function break a test, then you know 
>> immediately that there is a problem. Functional unit testing guards 
>> against changes that would break dependent code.
>>
>> I haven't found a reason why classes can't rely on properly crafted 
>> and tested module-level functions.
>>
>> -Ken
>>
>>
>>>
>>> John W. Colby
>>> www.ColbyConsulting.com
>>>
>>> On 4/11/2011 1:10 PM, Kenneth Ismert wrote:
>>>
>>>> John, All:
>>>>
>>>> I'm going to expand a little on what I'm trying to get at. This 
>>>> post really isn't advice on what you should do. And it certainly 
>>>> isn't criticism.
>>>>
>>>> I have been returning to the old Lisp idea of functional programming:
>>>> libraries of functions that act only on their inputs and only 
>>>> return a result. The goal is 'side-effect-free' -- inputs are NEVER 
>>>> modified, and external variables are never referenced. If a 
>>>> function needs to return complex information, it returns either a 
>>>> type or an object. Database functions unavoidably have 
>>>> side-effects, but these are regarded as 'external' to the code, and are
explicitly documented.
>>>>
>>>> The thing that surprised me was how well libraries play with objects.
>>>> Libraries provide discrete, testable chunks of code that support 
>>>> any instance. Libraries separate functions into common-sense groups.
>>>> Classes provide an instance wrapper over the libraries, stringing 
>>>> functions together to support the application.
>>>>
>>>> Plus, it is pretty easy to convert classes to this scheme while 
>>>> maintaining compatibility.
>>>>
>>>> The advantages became apparent when I refactored some of my early 
>>>> monolithic classes. These large, 'kitchen sink' classes had dozens 
>>>> of methods which mixed database, business, and application 
>>>> functionality. They were unwieldy, hard-to-understand, and 
>>>> hard-to-extend. I simply copied the class into a module, stripped 
>>>> out the instance stuff (properties and module-level variables), and 
>>>> turned the methods into side-effect-free functions. I then stripped 
>>>> out the code within the original class methods, turning them into 
>>>> wrappers calling library functions with their instance variables.
>>>>
>>>> The result: classes become lightweight, making their functionality 
>>>> much more obvious. Compatibility is maintained, but the new system 
>>>> is much easier to refactor and extend.
>>>>
>>>> The class on-top-of function approach is also a good answer to 
>>>> those who want to re-use your code, but can't because they need 
>>>> some method that is marked private in a class. They typically 
>>>> demand that all methods be made public, which is usually silly 
>>>> because the class designer has good reasons for limiting the public 
>>>> visibility of certain
> methods or properties.
>>>>
>>>> But with a function library, you can have your cake and eat it, too.
>>>> Classes
>>>> hold the instance information, and interact with libraries in an 
>>>> instance-safe way, because the functions never modify their inputs.
>>>> Others with different needs can call the functions directly, or 
>>>> write their own classes. Heck, I even find myself cramped by my own 
>>>> classes at times, and having the option to call underlying 
>>>> functions
> directly has benefited me.
>>>>
>>>> Writing test code for functions is much easier than for complex 
>>>> class systems. Test code provides reasonable proof of reliability.
>>>> Reliable complexity can only be built out of small, simple, 
>>>> understandable, and testable pieces.
>>>>
>>>> -Ken
>>>>
>>>>