Re: Closures versus objects

Pascal Costanza <[email protected]>
Newsgroups gmane.comp.lang.lightweight
Message-ID <[email protected]>
On 16 Feb 2007, at 00:36, Robbert Haarman 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.

Of course.

> 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

That's a library issue, not a language issue.

> 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.

For the sake of the correctness of a program, it doesn't matter  
whether it's source code is elegant or not. Either it's correct  
(meets user expectations) or it's not.

Elegance can be important for example when you want to convince  
yourself that the program is indeed correct. Some notations and/or  
combinations of language constructs make this easier than others.  
That's a convenience issue, which, btw, also has subjective elements.  
[1]

Note that I haven't said "mere convenience". To the contrary.  
Programming language design is all about convenience.

> 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.

I whole-heartedly agree (and fail to see where you actually  
contradict me ;).


Pascal


[1] Some people have an easier thinking in terms of objects, some  
have on easier time thinking in terms of higher-order programming  
styles, etc. pp.

-- 
Pascal Costanza, mailto:[email protected], http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.