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. -- http://mail.python.org/mailman/listinfo/python-list
