Send Beginners mailing list submissions to
        beginners@haskell.org

To subscribe or unsubscribe via the World Wide Web, visit
        http://www.haskell.org/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
        beginners-requ...@haskell.org

You can reach the person managing the list at
        beginners-ow...@haskell.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."


Today's Topics:

   1. Re:  Haskell as a useful practical 'tool' for intelligent
      non-programmers (Mike Meyer)
   2. Re:  Haskell as a useful practical 'tool' for intelligent
      non-programmers (Michael Orlitzky)
   3. Re:  Haskell as a useful practical 'tool' for intelligent
      non-programmers (Lyndon Maydwell)
   4. Re:  Haskell as a useful practical 'tool' for intelligent
      non-programmers (Michael Orlitzky)
   5. Re:  Haskell as a useful practical 'tool' for intelligent
      non-programmers (Mike Meyer)
   6. Re:  Haskell as a useful practical 'tool' for intelligent
      non-programmers (Michael Orlitzky)
   7. Re:  Haskell as a useful practical 'tool' for intelligent
      non-programmers (Mike Meyer)


----------------------------------------------------------------------

Message: 1
Date: Sat, 28 Apr 2012 20:47:17 -0400
From: Mike Meyer <m...@mired.org>
Subject: Re: [Haskell-beginners] Haskell as a useful practical 'tool'
        for intelligent non-programmers
To: nkorma...@gmail.com
Cc: beginners@haskell.org
Message-ID: <20120428204717.3ef35...@bhuda.mired.org>
Content-Type: text/plain; charset=US-ASCII

On Sat, 28 Apr 2012 15:50:36 -0600
"Nicholas Kormanik" <nkorma...@gmail.com> wrote:

> A bit frustrating that you mention four as candidates: "Groovy, Clojure,
> Ruby, Python."

I'd not recommend starting with Groovy or Clojure. While Clojure is a
great language, the most popular implementation is hooked into the
JVM, and you wind up needing to deal with a lot Java infrastructure
fairly quickly. Being able to use that infrastructure is a design
goal, but adds to the learning curve. I haven't looked into Groovy,
but suspect some of the same issues will arise (and hope a Groovy
programmer will correct me if I'm wrong).

Ruby makes a bad fit if Haskell is a goal (and that's a good
goal). Ruby functions aren't first-class objects, and can't simply be
passed to other functions as arguments. Last time I looked, there were
a half-dozen workarounds for that, none of them really very
elegant. That ability is a critical feature in Haskell. Python at
least allows it, though it's not as nicely integrated as in Haskell,
or even Clojure.

> But it sounds like you are leaning toward recommending Python as the best
> way to start. 

Given those for, and that this is a Haskell list, I'd certainly agree
with that.

     <mike
-- 
Mike Meyer <m...@mired.org>             http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org



------------------------------

Message: 2
Date: Sat, 28 Apr 2012 22:22:34 -0400
From: Michael Orlitzky <mich...@orlitzky.com>
Subject: Re: [Haskell-beginners] Haskell as a useful practical 'tool'
        for intelligent non-programmers
To: beginners@haskell.org
Message-ID: <4f9ca5ea.4040...@orlitzky.com>
Content-Type: text/plain; charset=ISO-8859-1

On 04/28/2012 08:47 PM, Mike Meyer wrote:
> 
> Ruby makes a bad fit if Haskell is a goal (and that's a good
> goal). Ruby functions aren't first-class objects, and can't simply be
> passed to other functions as arguments.

That's like, the least true thing you can say about Ruby =)

A simple test program:

  $ cat fcf.rb
  def foo
    puts "foo"
  end

  def call_arg(f)
    f
  end

  call_arg(foo)


Running it:

  $ ruby fcf.rb
  foo


Moreover, every function and method implicitly accepts a function as an
argument:

  $ cat yield.rb
  def call_block
    yield
  end

  call_block { puts "foo" }

This allows you some nice do-block syntactic sugar instead of lambdas
which can get ugly.

  $ ruby yield.rb
  foo



------------------------------

Message: 3
Date: Sun, 29 Apr 2012 10:37:38 +0800
From: Lyndon Maydwell <maydw...@gmail.com>
Subject: Re: [Haskell-beginners] Haskell as a useful practical 'tool'
        for intelligent non-programmers
To: Michael Orlitzky <mich...@orlitzky.com>
Cc: beginners@haskell.org
Message-ID:
        <CAM5QZtxUuRShgof2n7c7z6=NbXJ3N-L4P2QDgACrCpqE=yn...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Your first example is not behaving how you think it is...


ruby-1.9.2-p0 :012 > def foo
ruby-1.9.2-p0 :013?>   puts "foo"
ruby-1.9.2-p0 :014?> end
 => nil
ruby-1.9.2-p0 :015 > def call_arg(f)
ruby-1.9.2-p0 :016?>   puts "calling"
ruby-1.9.2-p0 :017?>   f
ruby-1.9.2-p0 :018?> end
 => nil
ruby-1.9.2-p0 :019 > call_arg(foo)
foo
calling
 => nil

Note that "foo" is printed before "calling".


On Sun, Apr 29, 2012 at 10:22 AM, Michael Orlitzky <mich...@orlitzky.com> wrote:
> On 04/28/2012 08:47 PM, Mike Meyer wrote:
>>
>> Ruby makes a bad fit if Haskell is a goal (and that's a good
>> goal). Ruby functions aren't first-class objects, and can't simply be
>> passed to other functions as arguments.
>
> That's like, the least true thing you can say about Ruby =)
>
> A simple test program:
>
> ?$ cat fcf.rb
> ?def foo
> ? ?puts "foo"
> ?end
>
> ?def call_arg(f)
> ? ?f
> ?end
>
> ?call_arg(foo)
>
>
> Running it:
>
> ?$ ruby fcf.rb
> ?foo
>
>
> Moreover, every function and method implicitly accepts a function as an
> argument:
>
> ?$ cat yield.rb
> ?def call_block
> ? ?yield
> ?end
>
> ?call_block { puts "foo" }
>
> This allows you some nice do-block syntactic sugar instead of lambdas
> which can get ugly.
>
> ?$ ruby yield.rb
> ?foo
>
> _______________________________________________
> Beginners mailing list
> Beginners@haskell.org
> http://www.haskell.org/mailman/listinfo/beginners



------------------------------

Message: 4
Date: Sat, 28 Apr 2012 23:16:39 -0400
From: Michael Orlitzky <mich...@orlitzky.com>
Subject: Re: [Haskell-beginners] Haskell as a useful practical 'tool'
        for intelligent non-programmers
To: beginners@haskell.org
Message-ID: <4f9cb297.2060...@orlitzky.com>
Content-Type: text/plain; charset=UTF-8

On 04/28/2012 10:37 PM, Lyndon Maydwell wrote:
> Your first example is not behaving how you think it is...
> 
> 
> ruby-1.9.2-p0 :012 > def foo
> ruby-1.9.2-p0 :013?>   puts "foo"
> ruby-1.9.2-p0 :014?> end
>  => nil
> ruby-1.9.2-p0 :015 > def call_arg(f)
> ruby-1.9.2-p0 :016?>   puts "calling"
> ruby-1.9.2-p0 :017?>   f
> ruby-1.9.2-p0 :018?> end
>  => nil
> ruby-1.9.2-p0 :019 > call_arg(foo)
> foo
> calling
>  => nil
> 
> Note that "foo" is printed before "calling".
> 

Indeed, I tried to make the example cute and botched it. This should be
less screwupy (you have to desugar the 'def...' to make it work properly).

  foo = Proc.new { puts "foo" }
  bar = lambda { puts "bar" }

  def baz
    puts "baz"
  end

  def call_arg(f)
    puts "before call"
    f.call()
    puts "after call"
  end

  call_arg(foo)
  puts ""
  call_arg(bar)
  puts ""
  call_arg(method(:baz))



------------------------------

Message: 5
Date: Sun, 29 Apr 2012 00:15:42 -0400
From: Mike Meyer <m...@mired.org>
Subject: Re: [Haskell-beginners] Haskell as a useful practical 'tool'
        for intelligent non-programmers
To: beginners@haskell.org
Message-ID: <20120429001542.11abf...@bhuda.mired.org>
Content-Type: text/plain; charset=US-ASCII

On Sat, 28 Apr 2012 22:22:34 -0400
Michael Orlitzky <mich...@orlitzky.com> wrote:

> On 04/28/2012 08:47 PM, Mike Meyer wrote:
> > Ruby makes a bad fit if Haskell is a goal (and that's a good
> > goal). Ruby functions aren't first-class objects, and can't simply be
> > passed to other functions as arguments.
> 
> That's like, the least true thing you can say about Ruby =)

I respectfully disagree. For instance, I could have said that it uses
indentation to delimit blocks like ABC does. That's much less true.

But I believe the statement about functions not being first class
objects is true. Of course, I don't use ruby on a regular basis
because that turns out to be the case every time I go look at it. If
the language has changed so this can be done in a manner that's as
straightforward as Python, I'd be interested in hearing about it.

For the record, the Python version of your example is:

def foo():
   print("foo")

call_arg = apply

call_arg(foo)

> A simple test program:
> 
>   $ cat fcf.rb
>   def foo
>     puts "foo"
>   end
> 
>   def call_arg(f)
>     f
>   end
> 
>   call_arg(foo)

And that would do it, except, as Lyndon explained, it's not doing the
right thing. You provided one of the workarounds (using Proc) when you
corrected it.

> Moreover, every function and method implicitly accepts a function as an
> argument:

Doesn't quite seem that way to me.

>   $ cat yield.rb
>   def call_block
>     yield
>   end
> 
>   call_block { puts "foo" }
> 
> This allows you some nice do-block syntactic sugar instead of lambdas
> which can get ugly.

They are accepting a *block* as an argument. And you're right - blocks
are cleaner than lambdas. It's also more powerful than Python's
lambdas, which are restricted to being expressions. A lot of people
(me among them) would like Python to have something like Ruby's block
construct for anonymous code, and there are regular proposals on how
to do it (including from me).  If someone ever comes up with a way
that both reads well in an indent-delimited language and doesn't
invite incredible abuse, it'll probably make it into the language.

But that doesn't make a function a first class object. It doesn't even
make a block a first class object (can I give a block a name?).

There are other ways to work around this limitation (I think I found 6
last time I looked). IIRC, the Proc version was about the cleanest.

Note that I *didn't* say that this limitation makes Ruby a bad
language. I don't like it, because I find that languages that don't
make functions first-class objects grate on me. If it doesn't bother
you, you're a better person than I am.

That's why I added the proviso "if Haskell is a goal". Trying to go
from a language where functions can't be treated as first class
objects, requiring wrapper objects and similar things in order to
write in a functional style to one where a functional style is de
rigueur just seems like a bad idea.

    <mike
-- 
Mike Meyer <m...@mired.org>             http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org



------------------------------

Message: 6
Date: Sun, 29 Apr 2012 01:20:22 -0400
From: Michael Orlitzky <mich...@orlitzky.com>
Subject: Re: [Haskell-beginners] Haskell as a useful practical 'tool'
        for intelligent non-programmers
To: beginners@haskell.org
Message-ID: <4f9ccf96.7050...@orlitzky.com>
Content-Type: text/plain; charset=ISO-8859-1

On 04/29/2012 12:15 AM, Mike Meyer wrote:
> On Sat, 28 Apr 2012 22:22:34 -0400
> Michael Orlitzky <mich...@orlitzky.com> wrote:
> 
>> On 04/28/2012 08:47 PM, Mike Meyer wrote:
>>> Ruby makes a bad fit if Haskell is a goal (and that's a good
>>> goal). Ruby functions aren't first-class objects, and can't simply be
>>> passed to other functions as arguments.
>>
>> That's like, the least true thing you can say about Ruby =)
> 
> I respectfully disagree. For instance, I could have said that it uses
> indentation to delimit blocks like ABC does. That's much less true.
> 
> But I believe the statement about functions not being first class
> objects is true. Of course, I don't use ruby on a regular basis
> because that turns out to be the case every time I go look at it. If
> the language has changed so this can be done in a manner that's as
> straightforward as Python, I'd be interested in hearing about it.

They're wrapped in Proc objects, but those objects can be treated like
any other in the language. Everything else is just syntactic sugar on
top of Procs.

This is not conceptually any different to me than in Haskell or C; you
have a name for the thing, distinct from the thing itself, and you have
to ask for function application via (f x), f(x), f.call(x), or whatever.

(The Proc/def syntax disconnect is annoying, and apparently error-prone.
You can call a Proc with p[x] but not if you def'd it!)


> And that would do it, except, as Lyndon explained, it's not doing the
> right thing. You provided one of the workarounds (using Proc) when you
> corrected it.
> 

Hey, it passed all the unit tests =P



------------------------------

Message: 7
Date: Sun, 29 Apr 2012 02:35:41 -0400
From: Mike Meyer <m...@mired.org>
Subject: Re: [Haskell-beginners] Haskell as a useful practical 'tool'
        for intelligent non-programmers
To: beginners@haskell.org
Message-ID: <20120429023541.501ad...@bhuda.mired.org>
Content-Type: text/plain; charset=US-ASCII

On Sun, 29 Apr 2012 01:20:22 -0400
Michael Orlitzky <mich...@orlitzky.com> wrote:

> On 04/29/2012 12:15 AM, Mike Meyer wrote:
> > On Sat, 28 Apr 2012 22:22:34 -0400
> > Michael Orlitzky <mich...@orlitzky.com> wrote:
> > 
> >> On 04/28/2012 08:47 PM, Mike Meyer wrote:
> >>> Ruby makes a bad fit if Haskell is a goal (and that's a good
> >>> goal). Ruby functions aren't first-class objects, and can't simply be
> >>> passed to other functions as arguments.
> >>
> >> That's like, the least true thing you can say about Ruby =)
> > 
> > I respectfully disagree. For instance, I could have said that it uses
> > indentation to delimit blocks like ABC does. That's much less true.
> > 
> > But I believe the statement about functions not being first class
> > objects is true. Of course, I don't use ruby on a regular basis
> > because that turns out to be the case every time I go look at it. If
> > the language has changed so this can be done in a manner that's as
> > straightforward as Python, I'd be interested in hearing about it.
> 
> They're wrapped in Proc objects, but those objects can be treated like
> any other in the language. Everything else is just syntactic sugar on
> top of Procs.

That makes *Procs* first class object, not functions.

> This is not conceptually any different to me than in Haskell or C; you
> have a name for the thing, distinct from the thing itself, and you have
> to ask for function application via (f x), f(x), f.call(x), or whatever.

And if having the same set of concepts were all that mattered, we'd
still PERFORMing blocks of code.  The syntax of a language makes some
things easier to do, and some things harder - that's why there's more
than one of them. Writing HOFs is harder in ruby than in a language
with first-class functions, because you can't pass a function to a
function.  You have to decide which of the workarounds you want to use
(blocks or lambdas or Methods or Procs or ...). If you want to use a
function from the standard library - you have to wrap it in order to
pass it to your HOF. Since "all of the above" isn't a valid choice, if
you're trying to use a library of HOFs (assuming such exist in Ruby -
and if they don't, that's yet another reason Ruby isn't a good way to
get to Haskell), you may wind up wrapping some things multiple times,
or wrap the results of your HOFs, or ... well, you get the idea.

None of this makes Ruby any better or worse for anything other than
writing code in a functional style. There are perfectly usable
languages that can't do HOFs at all. That you can do it at all makes
Ruby a better choice than them for writing functional code. But it
requires a lot of code that's nothing more than boilerplate, which
makes it worse than languages that don't require such.

Of course, if you don't think boilerplate makes things harder, and all
that matters is having the same concepts, then I expect you won't
argue if I claim that there's no reason to pick Ruby over Java for
writing OO code. After all, they have the same concepts, just with
different syntactic sugar and more or less boilerplate.

        <mike
-- 
Mike Meyer <m...@mired.org>             http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org



------------------------------

_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://www.haskell.org/mailman/listinfo/beginners


End of Beginners Digest, Vol 46, Issue 48
*****************************************

Reply via email to