On 17.10.2006, at 11:52, Bert Freudenberg wrote:

>
> Well, in best Smalltalk tradition I would vote for the alternate  
> code. It's similar to fractional arithmetic ( 3 / 4 ). Yes,  
> fractions bite some newbies, but they learn to use #// or #asFloat  
> fast enough. Same here - if you need an error when taking a  
> negative's square root, send #asFloat.
>
> It's also a bit similar to Smalltalk being one of the few systems  
> with correct integers, where a bug like this is not possible:
>
> http://googleresearch.blogspot.com/2006/06/extra-extra-read-all- 
> about-it-nearly.html
>
> I'd like to have no arbitrary limits, like forbidding to take the  
> logarithm of negative numbers.

I am 99% convinced that the languages we use in 50 years, whatever  
the paradigm will be,  will have a complete "real math" subsystem,  
kind of
like a little mathematica, but as part of the mainstream language.

There is no law of nature that requires a programming language to  
only have crappy math... it's what we had in the past, but just for
space and performance reasons for the small machines and small  
problems of today.

With the machines and the memory we will have, this does not need to  
be the case anymore.

This is a bit the same like with memory management: With tiny  
machines solving tiny problems, it's simpler (and faster)
to control the memory yourself. But then, when the systems get huge,  
it's not only simpler but even faster
to have the higher abstraction: Big C++ programms tend to spend more  
time with hand-crafted memory management that a good automatic
incremental GC.

Same with math: in the end, like with all advances we will see,  
having "real math" in the language will not only be more convinient, but
even faster and more memory efficient for the problems and machines  
we will see.

       Marcus