Bools and explicitness [was Re: PyWart: The problem with "print"]
Russ P.
Russ.Paielli at gmail.com
Wed Jun 5 03:47:05 EDT 2013
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.
More information about the Python-list
mailing list