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

[Rick Johnson]

On Wednesday, June 5, 2013 8:37:20 PM UTC-5, Steven D'Aprano wrote:
> On Wed, 05 Jun 2013 09:15:01 -0700, Russ P. wrote:
> > On Wednesday, June 5, 2013 1:59:01 AM UTC-7, Mark Lawrence wrote:
> >> On 05/06/2013 07:11, Russ P. wrote:

> What prevents bugs is the skill of the people writing the code, not the 
> compiler. Compile-time static type checking is merely a tool, which has 
> costs and benefits. It is ludicrous to think that any one single tool, or 
> the lack of that tool, will make all the difference between working code 
> and non-working code.

Yes, just as ludicrous as thinking that dynamic languages have abolished the evil practice of "type checking". 

> Static type-checking is no better, or worse, for "critical code" than 
> dynamic type-checking. One language chooses to deal with some errors at 
> compile-time, others deal with them at run-time. 

Wow, talk about ignoring the elephant in the room! I don't feel i need static typed languages for EVERY problem, however, i'm not foolish enough to believe that "compile time type checking" and "run-time type checking" are even comparable. Oversimplification?

> Either way, the 
> programmer has to deal with them in some way.
> A static type system forces you to deal with a limited subset of errors, 
> "type errors", in one way only: by removing any execution paths in the 
> software which would assign data of type X to a variable of type Y. For 
> reasons of machine efficiency, that is often a good was to deal with such 
> errors. But a dynamic type system makes different trade-offs.
> And of course, type errors are such a vanishingly small subset of all the 
> possible errors that might be made that, frankly, the difference in code 
> quality between those with static typing and those without is essentially 
> indistinguishable. There's no evidence that code written in static typed 
> languages is less buggy than code written in dynamic languages.

WOW! Your skill with the implicit Ad hominem is approaching guru status.

First you cleverly convert the base argument of this ongoing discussion from: "implicit conversion to boolean is bad", into the hot button topic of: "static vs dynamic typing". 

In this manner you can ratchet up the emotion of your supporters by employing the same political "slight of hand" used by countless political hacks: "Liberal vs Republican" ring a bell? When there is only two choices, the sheeple can be easily manipulated by the football game. Especially when the opposing sides have the same end-goal in mind. It's all a game of diversions you idiots!

Then you go and make a blanket statement that "appears" to weigh the differences of the two styles fairly, when in fact, what you've done is to falsely invalidate the opposition's entire argument based on a complete overstatement (not to mention that you stopped short of explaining the "trade offs" in detail):

    > And of course, type errors are such a vanishingly
    > small subset of all the possible errors that might be
    > made that, frankly, the difference in code quality
    > between those with static typing and those without is
    > essentially indistinguishable.

Nice!

Well, then. You've slayed the enemy. If type errors are as rare as you claim, then by golly these crazy people who use static languages are really just fools. I mean, how could they not be? If they were as intelligent as YOU then they would see the truth!

Your attempts at sleight of hand are rather amusing. The whole point of this "implicit conversion to Boolean" discussion hinges around the fact that dynamic languages are okay for small to medium problems ( or for prototyping larger problems). But they cannot be depended on for mission critical code. And mission critical does not only encompass manned flights to mars, it could be any code that places your reputation on the line. 

I don't want Python to be a static typed language. Neither do i believe that duck typing is wrong for Python. HOWEVER, what i DO believe is that dynamic languages can be unreliable if we do not:

 1. Choose to be "explicit enough"

I've explained this in detail Ad-nauseam.

  2. Fail to type check where type checking is due. 
 
The second covers type checking objects that enter into new namespaces. That would cover all functions/methods arguments (at a minimum). 

We don't need to type check EVERY single object (but of course the programmer could IF he wanted to). If i declare a variable[1] that points to a list in a block of code, then i reference that variable[1] in the same block of code, i see no reason to type check that variable[1] first. That is overkill and that is why people are turned off by static languages.

However, if i declare the same variable[1] and then pass that variable[1] into a function, the function should do a type check on all the arguments to guarantee that these arguments are in fact what they should be. This is how you strike a balance between explicit and implicit. This is how you inject sanity into your code bases. 
 

[1]: stop your whining already about "python does not have variables". The word variable has both a technical meaning (which is another example of transforming a word improperly) and a general meaning. When used in a Python context the word "variable" takes on it's general meaning. Feel free to consult a dictionary if your still confused.