X-Received: by 10.224.86.200 with SMTP id t8mr16716590qal.0.1371882192598; Fri, 21 Jun 2013 23:23:12 -0700 (PDT) X-Received: by 10.50.98.1 with SMTP id ee1mr76987igb.5.1371882192560; Fri, 21 Jun 2013 23:23:12 -0700 (PDT) Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!j2no1179319qak.0!news-out.google.com!y6ni4002qax.0!nntp.google.com!j2no1179317qak.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.python Date: Fri, 21 Jun 2013 23:23:12 -0700 (PDT) In-Reply-To: <8a716f17-e11d-46ad-b629-5813661e3ec2@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=59.95.53.199; posting-account=mBpa7woAAAAGLEWUUKpmbxm-Quu5D8ui NNTP-Posting-Host: 59.95.53.199 References: <7e6361d5-6619-4aaa-adda-8b5f01bde57f@googlegroups.com> <447dd1c6-1bb2-4276-a109-78d7a067b442@d8g2000pbe.googlegroups.com> <2e92b4c7-31be-40d2-a906-ab19f3630dfa@googlegroups.com> <51c477dd$0$29999$c3e8da3$5496439d@news.astraweb.com> <565a1c8f-6fd9-4bab-9834-076eaea527f8@googlegroups.com> <7e1ed740-df18-4978-b11d-8ca9c4b5bd04@googlegroups.com> <03e9544e-9d6d-4155-a793-56f0c22c7f7a@googlegroups.com> <51c4fab1$0$29999$c3e8da3$5496439d@news.astraweb.com> <8a716f17-e11d-46ad-b629-5813661e3ec2@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Default Value From: rusi Injection-Date: Sat, 22 Jun 2013 06:23:12 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: csiph.com comp.lang.python:48917 On Saturday, June 22, 2013 8:25:15 AM UTC+5:30, Rick Johnson wrote: > On Friday, June 21, 2013 9:32:43 PM UTC-5, rusi wrote: > > So Rick... I agree with you... all these theoreticians > > should be burnt at the stake!=20 > > On a more serious note: many > > people make similar mistakes eg Haskellers who think > > Haskell is safe. Safer (than something or other) -- Ok > > Safe -- NO >=20 >=20 > So now you're going to attempt to defeat my idea by > suggesting that it chalks up to nothing more than a safety > measure? How many times must i explain the simple concept > of stateless subroutines and hazards of the current=20 > incarnation Python FUNCtions (You smell the func!) I appreciate Rick that you are committed to a better programming language. And you too need to appreciate that many intelligent and capable people for= the last 50 years have had similar goals. When those goals are soft eg st= rictures on cohesion and coupling -- which is what your wish for stateless = procedures amounts to -- then those remain suggestions and cannot be impose= d. When those goals are made hard as in functional programming then other prob= lems result such as performance hits, what-to-do-about-IO etc etc. See my blog http://blog.languager.org/2012/11/imperative-programming-lessons-not.html for a history of wishes akin to yours and lessons not learnt. In short the problems accruing from unconstrained imperative programming ar= e severe and the solutions are hard. In the meanwhile, goals such as your 'keep-procedures-stateless' can and sh= ould certainly be practised in the human sphere even if not implemented in = the programming language sphere. The aggregation of such 'best-practices' = is what I call FP as an ideology rather than as technology. I have a collection here=20 http://blog.languager.org/2012/10/functional-programming-lost-booty.html And I would welcome suggestions/discussions on the same.