From: "Michael T. Richter" Date: 2008-05-10T15:31:34+09:00 Subject: Re: "Real" Differences Between Python & Ruby --=-smmTQTlI1cpx1+shvWKW Content-Type: multipart/alternative; boundary="=-akXUVypqw4l/jdro2RAe" --=-akXUVypqw4l/jdro2RAe Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2008-05-10 at 14:52 +0900, M. Edward (Ed) Borasky wrote: > Michael T. Richter wrote: > > I'm not sure that this is a meaningful question. What problems did=20 > > *any* language past patch cabling circuit boards solve? If you set the= =20 > > bar low enough (or high enough) all current computer languages are=20 > > imperfect reflections of a Turing machine anyway. (Yes, even the=20 > > functional ones based on Church instead of Turing. They're just REALLY= =20 > > obfuscated.) > Actually, I think it's Turing and Von Neumann that were obfuscated --=20 > Church and McCarthy got it right. ;) Mathematically I agree with you, but in terms of hardware underlying all this stuff it's basically a real-world Turing machine. (Which is what the von Neumann architecture is: Turing's machine turned into something that could actually be implemented. Things like "infinite tapes" and "infinite decision tables" turned out, surprisingly, to be implausible at point of implementation. :D) Church's model of calculation is far more appealing to me and the languages based on it -- Lisp (arguably: there's some evidence that McCarthy stumbled over this rather than deliberately trying to model Church), Haskell, etc. -- are increasingly the way I like to work. But it's all smoke and mirrors. Underneath it all is a von Neumann machine masquerading as a Church lambda expression engine. --=20 Michael T. Richter (GoogleTalk: ttmrichter@gmail.com) There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. (Charles Hoare) --=-akXUVypqw4l/jdro2RAe Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sat, 2008-05-10 at 14:52 +0900, M. Edward (Ed) Borasky wrote: 
Michael T. Richter wrote:
> I'm not sure that this is a meaningful questio=
n.  What problems did 
> *any* language past patch cabling circuit boar=
ds solve?  If you set the 
> bar low enough (or high enough) all current co=
mputer languages are 
> imperfect reflections of a Turing machine anyw=
ay.  (Yes, even the 
> functional ones based on Church instead of Tur=
ing.  They're just REALLY 
> obfuscated.)



Actually, I think it's Turing and Von Neumann that =
were obfuscated -- 
Church and McCarthy got it right. ;)
Mathematically I agree with you, but in terms of hardware underlying all th= is stuff it's basically a real-world Turing machine.  (Which is what t= he von Neumann architecture is: Turing's machine turned into something that= could actually be implemented.  Things like "infinite tapes"= ; and "infinite decision tables" turned out, surprisingly, to be = implausible at point of implementation. :D)

Church's model of calculation is far more appealing to me and the languages= based on it -- Lisp (arguably: there's some evidence that McCarthy stumble= d over this rather than deliberately trying to model Church), Haskell, etc.= -- are increasingly the way I like to work.  But it's all smoke and m= irrors.  Underneath it all is a von Neumann machine masquerading as a = Church lambda expression engine.

--
Michael T. Richter <ttmri= chter@gmail.com> (GoogleTalk: ttmrichter@gmail.com)
There are two ways of constructing a software design. One way is to make= it so simple that there are obviously no deficiencies. And the other way i= s to make it so complicated that there are no obvious deficiencies. (Charle= s Hoare)
--=-akXUVypqw4l/jdro2RAe-- --=-smmTQTlI1cpx1+shvWKW Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIJUE1LqyWkKVQ54QRAoN/AJ9l0XHVA6YPp+MdjVxUUVqmWUNanwCeMY+R dczEtmPNI5gv9qZ3qlry/4Y= =Ju4k -----END PGP SIGNATURE----- --=-smmTQTlI1cpx1+shvWKW--