Re: Closures versus objects

Felleisen argues that the relevent measure is `macro-expressability' in

@incollection{ felleisen90expressive,
    author = "Matthias Felleisen",
    title = "On the Expressive Power of Programming Languages",
    booktitle = "{ESOP} '90 3rd European Symposium on Programming,
Copenhagen, Denmark",
    volume = "432",
    publisher = "Springer-Verlag",
    address = "New York, N.Y.",
    editor = "N. Jones",
    pages = "134-151",
    year = "1990",
    url = "citeseer.ist.psu.edu/felleisen90expressive.html" }

He points out that any turning-complete language can emulate any other,
so perhaps a more useful measure of expressiveness is whether you can
directly implement a language feature in another language with only local
transformations.

On 2/15/07, Robbert Haarman <[email protected]> wrote:
> On Thu, Feb 15, 2007 at 10:39:14PM +0100, Pascal Costanza wrote:
> >
> > As soon as your language is Turing-complete, anything you add is
> > redundant. Language features are always only about convenience.
>
> I contest that. In a theoretical world where only programs and/or values
> exist, any Turing-complete language may be equivalent to any other
> Turing-complete language. However, in a practical world, where things
> besides programs and values exist, there are real differences in what
> languages can and can't do which have nothing to do with
> Turing-completeness.
>
> For example, to drive the PC's floppy drive controller, you need access
> to I/O ports. If your language does not provide such access, you can't
> drive the FDC from that language, whether the language is
>
> Turing-complete or not.
>
> Even when language features are only about convenience (which I believe
> is the case with closures vs. objects), they make a difference. For
> example, I think available language features have a great influence of
> what programming paradigms will be common. I also think most people on
> this list will agree with me that different paradigms are suitable for
> different problems. This means that languages in which certain paradigms
> cannot be expressed elegantly cannot be used to solve certain problems
> elegantly. This can have very real implications, such as these problems
> not being solved or the programs that purport to solve them being
> unreliable.
>
> To put the above more bluntly and concisely: I think Turing-completeness
> is overrated, and that designing a language so that only one or a few
> paradigms can be elegantly expressed in it is a mistake.
>
> Regards,
>
> Bob
>
> --
> That that is is that that is not not, that is, not that that is not.
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
>
> iD8DBQFF1O6Lfb9wcmD+WN4RAksBAKCs7celALHKE37xyVJl/cBYlKqi6wCcD8Y3
> kltPkj9NzTpzHqlAXUSycRk=
> =ClAu
> -----END PGP SIGNATURE-----
>
>


-- 
~jrm