X-Received: by 10.224.36.66 with SMTP id s2mr18306666qad.6.1370418425754; Wed, 05 Jun 2013 00:47:05 -0700 (PDT) X-Received: by 10.50.83.100 with SMTP id p4mr623749igy.9.1370418425559; Wed, 05 Jun 2013 00:47:05 -0700 (PDT) Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!p1no1508320qaj.0!news-out.google.com!10ni283qax.0!nntp.google.com!ch1no940317qab.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.python Date: Wed, 5 Jun 2013 00:47:05 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=71.204.134.116; posting-account=QXgf4wkAAADkKLOneY6DWJPpPelAjS0c NNTP-Posting-Host: 71.204.134.116 References: <687dea63-84da-4c45-9366-cb5a10665d1f@googlegroups.com> <51ab95d5$0$29966$c3e8da3$5496439d@news.astraweb.com> <51ad7daf$0$11118$c3e8da3@news.astraweb.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Bools and explicitness [was Re: PyWart: The problem with "print"] From: "Russ P." Injection-Date: Wed, 05 Jun 2013 07:47:05 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: csiph.com comp.lang.python:47032 On Wednesday, June 5, 2013 12:15:57 AM UTC-7, Chris Angelico wrote: > On Wed, Jun 5, 2013 at 4:11 PM, Russ P. wrote: >=20 > > On Tuesday, June 4, 2013 8:44:11 AM UTC-7, Rick Johnson wrote: >=20 > > >=20 > >> Yes, but the problem is not "my approach", rather the lack >=20 > >> >=20 > >> of proper language design (my apologizes to the "anointed >=20 > >> >=20 > >> one". ;-) >=20 > > >=20 > > If you don't like implicit conversion to Boolean, then maybe you should= be using another language -- and I mean that in a constructive sense. I'm = not particularly fond of it either, but I switched from Python to another l= anguage a while back. The issue is not a lack of "proper language design" b= ut rather a language design philosophy that values conciseness and simplici= ty over explicitness and rigor. >=20 >=20 >=20 > (Out of curiosity, which language? Feel free to not answer, or to >=20 > answer off-list, as that's probably not constructive to the thread.) No problem. I'm using Scala. It has a sophisticated type system. The langua= ge is not perfect, but it seems to suit my needs fairly well. >=20 >=20 > I cannot name a single modern programming language that does NOT have >=20 > some kind of implicit boolification. The only such language I know of >=20 > is REXX, which has a single data type for everything, but insists on >=20 > the exact strings "1" and "0" for True and False, anything else is an >=20 > error. Every other language has some definition of "these things are >=20 > true, these are false"; for instance: Scala (and Java) don't do that. Nor does Ada. That's because Ada is designe= d for no-nonsense critical systems. It is the standard higher-order languag= e for flight control systems, for example.=20 > > It's all loosey goosey -- which is fine for many applications but certa= inly not for critical ones. >=20 >=20 >=20 > The looseness doesn't preclude critical applications. It's all a >=20 > question of what you're testing. Does your code care that this be a >=20 > list, and not something else? Then test! You have that option. What >=20 > happens if it isn't a list, and something is done that bombs with an >=20 > exception? Maybe that's not a problem. >=20 >=20 >=20 > Critical applications can often be built in layers. For instance, a >=20 > network server might listen for multiple socket connections, and for >=20 > each connection, process multiple requests. You would want to catch >=20 > exceptions at the two boundaries there; if a request handler crashes, >=20 > the connection should not be dropped, and if a connection handler >=20 > crashes, the server should keep running. With some basic defenses like >=20 > that, your code need no longer concern itself with trivialities - if >=20 > something goes wrong, there'll be an exception in the log. (BTW, this >=20 > is one of the places where a bare or very wide except clause is >=20 > appropriate. Log and move on.) Well, I don't really want to open the Pandora's box of static vs. dynamic t= yping. Yes, with enough testing, I'm sure you can get something good out of= a dynamically typed language for small to medium-sized applications, but I= have my doubts about larger applications. However, I don't claim to be an = expert. Someone somewhere has probably developed a solid large application = in Python. But I'll bet a dollar to a dime that it took more work than it w= ould have taken in a good statically typed language. Yes, extensive testing= can go a long way, but extensive testing combined with good static typing = can go even further for the same level of effort.