[Haskell-cafe] Fwd: A Thought: Backus, FP, and Brute Force Learning

Fri Mar 22 10:17:31 CET 2013

I always forget to reply-all :(

---------- Forwarded message ----------
From: Eli Frey <eli.lee.frey at gmail.com>
Date: Thu, Mar 21, 2013 at 5:04 PM
Subject: Re: [Haskell-cafe] A Thought: Backus, FP, and Brute Force Learning
To: OWP <owpmailact at gmail.com>

Ah, ye old "point free programming" [1].  Yes when you first see this stile
it's a bit alarming.  I think it's valid to say you shouldn't take this too
far, but IMHO it is a good thing.

If it is any more enlightening, it is good to think of this style like
building shell pipelines.  Depending on your disposition, that might make
you more dismayed though :).

Personally I like this style because it allows me to very rapidly prototype
my ideas.  When I am fleshing some solution out I will write it nearly
entirely in this style.  As I am throwing code around and refactoring, I
will reevaluate things and name my pipes and their inputs and outputs where
it makes sense to increase legibility.

I am sure that Bacchus is serious about this, but have no fear.  Just
because you can do this does not mean you have to.  You are still free to
name your inputs and outputs as much as you please.  However, no-one is
forcing you to.

There is a parallel in languages that have syntactic support for OOP.

obj.dothis.dothat.andthis.andthat.andanotherthing

There is just as much debate about how far to go with method chaining, and
when to name intermediate values.

[1] https://en.wikipedia.org/wiki/Tacit_programming

On Thu, Mar 21, 2013 at 4:21 PM, OWP <owpmailact at gmail.com> wrote:

> Thank you for this reply.  This thought is more about Backus (he is cited
> quite a lot) and how much of his theory made it into Haskell and other
> commonly used functional programming.
>
> In Backhu's paper (
> http://www.thocp.net/biographies/papers/backus_turingaward_lecture.pdf),
> is his comparison between FP and Impertive as seen in 5.1 & 5.2 of
> "Programs for Inner Product".
>
> When I start seeing that program described as:
>
> "Def Innerproduct = (Insert +) o (ApplyToAll x) o Transpose"
>
> I start getting queasy.  When he later describes functional programming
> main purpose is to expand on that, I get worried.  When he later explains
> how I don't need to use variables and just need to use "elementary
> substitution rule" for everything, I'm wondering if he's really serious
> about this.
>
> From what you say, it doesn't sound as bad and I hope it isn't as I learn
> more.
>
> Thanks for the reply.
>
> On Wed, Mar 20, 2013 at 7:56 PM, Eli Frey <eli.lee.frey at gmail.com> wrote:
>
>> I have not read Bacchus' paper, so i might be off the mark here.
>>
>> Functional code is just as simple (if not more so) to puzzle apart and
>> understand as imperative code.  You might find that instead of  "stepping
>> through the process" of code, you end up "walking the call graph" more
>> often.  FPers tend to break their problem into ever smaller parts before
>> re-assembling them back together, often building their own vocabulary as
>> they go.  Not to say this is not done in imperative languages, but it is
>> not so heavily encouraged and embraced.  One result of this is that you can
>> easily understand a piece of code in isolation, without considering it's
>> place in some "process".  It sounds as though you are not yet comfortable
>> with this yet.
>>
>> So yes, you might have to learn more vocabulary to understand a piece of
>> functional code.  This is not because the inner workings are obfuscated,
>> but because there are so many more nodes in the call graph that are given
>> names.  You can still go and scrutinize each of those new pieces of
>> vocabulary by themselves and understand them without asking for the author
>> to come down from on high with his explanation.
>>
>> Let's take iteration for example.  In some imperative languages, people
>> spend an awful lot of time writing iteration in terms of language
>> primitives.  You see a for loop.  "What is this for loop doing?" you say to
>> yourself.  So you step through the loop imagining how it behaves as it goes
>> and you say "Oh, this guy is walking through the array until he finds an
>> element that matches this predicate."  In a functional style, you would
>> reuse some iterating function and give it functions to use as it is
>> iterating.  The method of iteration is still there, it has just nested into
>> the call graph and if you've never seen that function name before you've
>> got to go look at it.  Again I don't mean to suggest that this isn't
>> happening in an imperative language, just not to the same degree.
>>
>> As well there is a bit of a learning curve in seeing what a function
>> "does" when there is no state or "doing" to observe in it.  Once you get
>> used to it, I believe you will find it quite nice though.  You have
>> probably heard FPers extolling the virtues of "declarative" code.  When
>> there is no state or "process" to describe, you end up describing what a
>> thing is.  I for one think this greatly increases readability.
>>
>> Good Luck!
>> Eli
>>
>>
>> On Wed, Mar 20, 2013 at 3:59 PM, OWP <owpmailact at gmail.com> wrote:
>>
>>> I made an error.  I meant FP to stand for Functional Programming, the
>>> concept not the language.
>>>
>>> On Wed, Mar 20, 2013 at 6:54 PM, OWP <owpmailact at gmail.com> wrote:
>>>
>>>> This thought isn't really related to Haskell specifically but it's more
>>>> towards FP ideal in general.
>>>>
>>>> I'm new to the FP world and to get me started, I began reading a few
>>>> papers.  One paper is by John Backus called "Can Programming Be Liberated
>>>> from the von Neumann Style? A Functional Style and It's Algebra of
>>>> Programs".
>>>>
>>>> While I like the premise which notes the limitation of the von Neumann
>>>> Architecture, his solution to this problem makes me feel queasy when I read
>>>> it.
>>>>
>>>> For me personally, one thing I enjoy about a typical procedural program
>>>> is that it allows me to "Brute Force Learn".  This means I stare at a
>>>> particular section of the code for a while until I figure out what it
>>>> does.  I may not know the reasoning behind it but I can have a pretty
>>>> decent idea of what it does.  If I'm lucky, later on someone may tell me
>>>> "oh, that just did a gradient of such and such matrix".  In a way, I feel
>>>> happy I learned something highly complex without knowing I learned
>>>> something highly complex.
>>>>
>>>> Backus seems to throw that out the window.  He introduces major new
>>>> terms which require me to break out the math book which then requires me to
>>>> break out a few other books to figure out which bases things using archaic
>>>> symbols which then requires me to break out the pen and paper to mentally
>>>> expand what in the world that does.  It makes me feel CISCish except
>>>> without a definition book nearby.  It's nice if I already knew what a
>>>> "gradient of such and such matrix" is but what happens if I don't?
>>>>
>>>> For the most part, I like the idea that I have the option of Brute
>>>> Force Learning my way towards something.  I also like the declarative
>>>> aspect of languages such as SQL which let's me asks the computer of things
>>>> once I know the meaning of what I'm asking.  I like the ability to play and
>>>> learn but I also like the ability to declare this or that once I do learn.
>>>> From Backus paper, if his world comes to a reality, it seems like I should
>>>> know what I'm doing before I even start.  The ability to learn while coding
>>>> seems to have disappeared.  In a way, if the von Neumann bottleneck wasn't
>>>> there, I'm not sure programming would be as popular as it is today.
>>>>
>>>> Unfortunately, I'm still very new and quite ignorant about Haskell so I
>>>> do not know how much of Backus is incorporated in Haskell but so far, in
>>>> the start of my FP learning adventure, this is how things seem to be seen.
>>>>
>>>> If I may generously ask, where am I wrong and where am I right with
>>>> this thought?
>>>>
>>>> Thank you for any explanation
>>>>
>>>> P.S.  If anyone knows of a better place I can ask this question, please
>>>> feel free to show me the way.
>>>>
>>>
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130322/8495de54/attachment.htm>