Re: This is interesting

Impossible eh ... sounds good to me. Why is it impossible?

Comment by James Robertson

It's Impossible because a number in Smalltalk - at least in the most implementations - simply can't overflow. A SmallInteger instance will silently get promoted into a LargeInteger instance when it gets that big - instead of wrapping around and giving bogus data...

James: "multi-hour shutdown caused by static typing"
I'm stunned that you keep repeating this nonsense.

If the fault diagnosis is correct, then we might claim fixed-size numeric representation was part of the problem.

That has nothing to do with static-type-checking!
The same problem would exist in BCPL (no static type check); and the problem would not exist in Haskell (static type check).

Comment by James Robertson

Isaac,
Note how static typing hasn't resolved the problem. Testing, on the other hand, would have. But go ahead; keep hand waving....

James, note how (contrary to your claim) static-type-checking hasn't caused the problem; and note how dynamic-type-checking wouldn't resolve the problem.

The problem has nothing to do with type-checking; the problem is fixed-size numeric representation.

The problem is lack of a bignum implementation. Whether the language is static or dynamic, if you don't use a bignum for a value that can exceed your native integer range, you're in for trouble. There are systems on both sides of the fence default to native integers rather than bignums.

Interestingly, testing would not have helped here. They were aware of the problem already: hence the need to reboot once a month. Someone just forgot to reboot. The real problem was they identified a problem and choose a half arsed method of fixing it: treating the symptom not the cause.

Please see my comments in the article Static Typing Tunnel Vision Can Be Deadly.

Comment by James Robertson

Having a BigNum type available wouldn't necessarily help - the developer would have had to decide to use it. In Smalltalk, that simply wouldn't come up, period. Static typing systems tend to force decisions that can end up having bad consequences.

Comment by Reinout Heeck

James,
In Smalltalk, that simply wouldn't come up, period.

IMO that is what should have taken center stage in your original post not the typing rant. For instance you could have demonstrated the microsecond clock counter instead of making erratic assertions.

Hat tip top Isaac for his continuing effort to defang that typing froth in your arguments.

Comment by James Robertson

Well, there's one thing Reinout - IMHO, static typing is the problem. Why? Because it forces the developer to make a choice about the type of the variable. That's not bad in itself - the problem is that most static languages cart a storage space decision along with that type. The type system ends up giving the developer an utterly false sense of security, and you end up with situations like the 49.7 day crash scenario.

This used to happen in the VW VM with timers, for the same reason - at the VM level, the language used was C - and an inappropriate choice was made at some point as to what kind of type the elapsed time should be held in. We had a rollover problem. That kind of error cannot happen at the Smalltalk level, because developers are never faced with that kind of silly choice.

Comment by Reinout Heeck

... That's not bad in itself - the problem is that most static languages cart a storage space decision along with that type

As Isaac pointed out that also holds for at least one dynamic language. So we keep on reiterating: this has nothing to do with static vs dynamic. Rather the developer has *chosen* the wrong type to use. In Smalltalk that would be analogous to choosing the wrong implementation class, like trying to put 'high' Characters into a ByteString. (This example clearly refutes the unqualified 'cannot' and 'never' in your reply as well)

R

Comment by James Robertson

Reinout, your example is getting increasingly absurd. You would have to expend effort to make that mistake in Smalltalk; it's not going to happen by accident. It can easily happen by accident in most statically typed languages, and does quite frequently. Ponder the fact that it rarely comes up in Smalltalk, and what that implies.

I'm curious as I'm not familiar with Smalltalk so why would it not have happened at the Smalltalk level? Does Smalltalk increase the size for number storage ad infinitum, ie. when the number would require 73 bits it would be stored as such? That's really interesting because I think most "typeless" systems still would overflow at least at the precision of their host system (so mostly at 32 or 64 bits).

On a sidenote, I don't believe that there's really an issue on whether to type or not because in my experience you always run into a task when you really need to know what type the data is while most of the time you actually don't mind.

Oh, and I think the timer overflow is rather an Win9x issue than the applications fault.

In VisualWorks, say you assign a value this way:

someValue := 0.

The object is an instance of class SmallInteger, which can hold 29 bit values. What happens when that overflows? VW catches that, replaces the SmallInteger instance with an instance of LargePositiveInteger (or LargeNegativeInteger) and moves along. The values are no longer held in a fixed set of bits at that point. On the one hand, arithmetic with such values is slower. On the other hand, it gives you the correct answer. As opposed to, say, Java, or C++, or C# - where this is a problem for you as the application developer to deal with from the beginning.

Comment by Reinout Heeck

James,
1) you have now been given two examples of dynamic languages that exhibit this class of problem, why do you keep mentioning static languages while 'static' has nothing to do with it?

2) You would have to expend effort to make that mistake in Smalltalk; it's not going to happen by accident.

'foo.txt' asFilename writeStream 
	nextPut: (Character value: 256);
	close

Comment by James Robertson

I would say that placing characters on a stream that way is a fairly contrived example. I do tons of streaming in BottomFeeder, and I pay attention to Unicode issues. The code you posted is highly artificial, IMHO

James: "Ponder the fact that it rarely comes up in Smalltalk, and what that implies"
It implies that Smalltalk doesn't use a fixed size numeric representation! :-)

Because in the general case, bignums are a huge win. If you can choose to use fixed sized integers for code that needs maximum numeric calculation speed, it doesn't even have to slow you program down. They should certainly be the default in this day and age.

What I disagree with is you saying it's a static vs dynamic issue. That's just rubbish. There are lots of dynamic languages that don't default to bignums! There are static languages that do default to bignums!

So you can make a case here that Smalltalk is better than C++ (which I'm guessing was the implementation language of the program in question). But you absolutely can not use that to generalise that dynamic is better than static, because the problem in question is so far out on a tangent to the static/dynamic typing debate it's not even in the same post code.

Comment by James Robertson

It's a static vs. dynamic issue in that static languages force a choice where there shouldn't be one. And many developers botch that choice.

The automatic change from SmallInteger to LargePositiveInteger was the kind of answer I was looking for. That is pretty neat stuff! I wonder if Python does the same sort of thing...

Does Smalltalk have a single numeric class? If I evaluate (1 / 2) will that truncate the result to an integer, or return a real? If I evalualte (-1.0 sqrt) will that return a complex number or throw an error?

Comment by James Robertson

Smalltalk has lots of numeric classes, actually. If I evaluate 1/2, I get an instance of class Fraction. If I multiply 2 and 5.6, I get an instance of Float. The way that all works without static typing information is double dispatch. Here's a short version of how that works:

1.5 * 5

In this example, an instance of class float gets the message #* sent to it with an argument of 5. We don't know what kind of number 5 is at this point; what do we do? We send a message like this:

Float

* someNumber
     someNumber multiplyFloat: self.

Because we know what self is. When we get the #multiplyFloat: method executed, we know (via lookup) what someNumber is. We can then do the operation (either in Smalltalk or in a primitive in the VM - at that point, it doesn't matter for this example)

Comment by Reinout Heeck

If I evaluate (1 / 2) will that truncate the result to an integer, or return a real?
Neither ;-) You'll get a Fraction (IOW no precision is lost, very important in financial apps).
If I evalualte (-1.0 sqrt) will that return a complex number or throw an error?
That will throw an error in a vanilla setup, but loading the correct Complex library will enable that to return a complex number..

Comment by Michael Lucas-Smith

1/2 gives you back a Fraction. But it appears that -1.0 sqrt was missed with the complex numbers. 1i will give you back a complex number though. Perhaps that should be added as an AR to Cincom Smalltalk?

So adding new numeric types (quaternions, for example) would require changing every numeric class to add it to the double-dispatch mechanism? It seems that Slate might be taking Smalltalk in the right direction by basing everything on multiple dispatch.

Comment by Reinout Heeck

So adding new numeric types (quaternions, for example) would require changing every numeric class to add it to the double-dispatch mechanism?
That is the mechanism used by the base classes, however extending that means that all extensions will need to mutually 'know' about each other with is obviously undesireable. For this reason an other extension model is supported by VisualWorks; this one is based on the 'generality' of a number class, it is computationally somewhat slower but does not suffer from the complexity explosion that double-dispatch induces.