Bools and explicitness [was Re: PyWart: The problem with "print"]

[Russ P.]

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:
> 
> > On Tuesday, June 4, 2013 8:44:11 AM UTC-7, Rick Johnson wrote:
> 
> >
> 
> >> Yes, but the problem is not "my approach", rather the lack
> 
> >>
> 
> >> of proper language design (my apologizes to the "anointed
> 
> >>
> 
> >> one". ;-)
> 
> >
> 
> > 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 language a while back. The issue is not a lack of "proper language design" but rather a language design philosophy that values conciseness and simplicity over explicitness and rigor.
> 
> 
> 
> (Out of curiosity, which language? Feel free to not answer, or to
> 
> 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 language is not perfect, but it seems to suit my needs fairly well.

> 
> 
> I cannot name a single modern programming language that does NOT have
> 
> some kind of implicit boolification. The only such language I know of
> 
> is REXX, which has a single data type for everything, but insists on
> 
> the exact strings "1" and "0" for True and False, anything else is an
> 
> error. Every other language has some definition of "these things are
> 
> true, these are false"; for instance:


Scala (and Java) don't do that. Nor does Ada. That's because Ada is designed for no-nonsense critical systems. It is the standard higher-order language for flight control systems, for example. 


> > It's all loosey goosey -- which is fine for many applications but certainly not for critical ones.
> 
> 
> 
> The looseness doesn't preclude critical applications. It's all a
> 
> question of what you're testing. Does your code care that this be a
> 
> list, and not something else? Then test! You have that option. What
> 
> happens if it isn't a list, and something is done that bombs with an
> 
> exception? Maybe that's not a problem.
> 
> 
> 
> Critical applications can often be built in layers. For instance, a
> 
> network server might listen for multiple socket connections, and for
> 
> each connection, process multiple requests. You would want to catch
> 
> exceptions at the two boundaries there; if a request handler crashes,
> 
> the connection should not be dropped, and if a connection handler
> 
> crashes, the server should keep running. With some basic defenses like
> 
> that, your code need no longer concern itself with trivialities - if
> 
> something goes wrong, there'll be an exception in the log. (BTW, this
> 
> is one of the places where a bare or very wide except clause is
> 
> appropriate. Log and move on.)


Well, I don't really want to open the Pandora's box of static vs. dynamic typing. 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 would 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.