Programing: Are int, float, long, double, Side-Effects of Computer Engineering?

By Xah Lee. Date:

Xah Lee wrote: Why Idioms Are Bad. Quote:

… One easy way to measure it is whether a programer can read and understand a program without having to delve into its idiosyncrasies. …

Chris Angelico wrote:

Neither the behavior of ints nor the behavior of IEEE floating point is a “quirk” or an “idiosyncrasy”. …

They are computer engineering by-products. Are quirks and idiosyncrasies. Check out a advanced lang such as Mathematica. There, one can learn how the mathematical concept of integer or real number are implemented in a computer language, without lots by-products of comp engineering as in vast majority of langs (all those that chalks up to some IEEEEEEE. (which, sadly, includes C, C++, perl, python, lisp, and almost all. (Common/Scheme lisp idiots speak of the jargon “number tower” instead IEEEE.) (part of the reason almost all langs stick to some IEEEEEEEE stuff is because it's kinda standard, and everyone understand it, in the sense that unix RFC (aka really faaking common) is wide-spread because its free yet technically worst. (in a sense, when everybody's stupid, there arise a cost to not be stupid.)))).

A friend asked:

Can you enlighten us as to Mathematica's way of handling numbers, either by a post or a link to suitable documentation? …

what i meant to point out is that Mathematica deals with numbers at a high-level human way. That is, one doesn't think in terms of float, long, int, double. These words are never mentioned. Instead, you have concepts of machine precision, accuracy. The lang automatically handle the translation to hardware, and invoking exact value or infinite precision as required or requested.

in most lang's doc, words like {int, long, double, float} are part of the lang, which then reference to IEEE. Then you have the wide-spread overflow issue in your lang. In M, the programer only need to think in terms of math, i.e. Real Number, Integer, Complex Number, precision, accuracy, etc.

this is what i meat that most lang deals with computer engineering by-products, and i wished them to be higher level like M.


Tim Roberts [t…] wrote:

Of course they are. Such concepts violate the purity of a computer language's abstraction of the underlying hardware. We accept that violation because of performance reasons. There are, as you point out, languages that do maintain the purity of the abstraction, but that purity is ALWAYS at the expense of performance.

I would also point out pre-emptively that there is nothing inherently wrong with asking us to accept an impure abstraction in exchange for performance. It is a performance choice that we choose to make.

while what you said is true, but the problem is that 99.99% of programers do NOT know this. They do not know Mathematica. They've never seen a language with such feature. The concept is alien. This is what i'd like to point out and spread awareness.

also, argument about raw speed and fine control vs automatic management, rots with time. Happened with auto memory management, auto type conversion, auto extension of array, auto type system, dynamic/scripting languages, managed code, smart compilers, etc.

i'd share these talks: