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