>>29
You are the poster boy for the OP argument.
It's funny because I have a lot of experience in assembly and C. I started coding back in the early days of DOS, and more recently I was a game developer for BREW phones. I actually did do exactly what the OP is proposing, but unlike you, I went on to do his optional step of learning some real high-level languages. Now I have the magical ability to use the right tool for the job.
From your description of high-level languages, you're completely unaware of just how inefficient your code actually is. You expect your numeric values to always be some sort of "BigInt" class, apparently. So your version of a + b is probably, realistically, about five function calls and maybe 50 to 100 lines of code, where it would be a single instruction for anyone who knows what they're doing.
Haha oh wow. You really have no clue how something like Scheme's numerical tower is implemented, do you? You're still taking everything you know from Java's BigInteger. Honestly, do you even know any language other than C and Java?
It's pretty easy to implement a highly-efficient BigInt. One simple way is to use a 64-bit value for your integers, and store small values in the bottom 63 bits. You can then do ordinary arithmetic on small numbers. It's trivial to tell when you overflow it; you just check the top bit after addition, and for multiplication you sum the level of the highest bits. When you do overflow it, you can set the top bit, and use the remaining bits as a pointer (down-shifted by one bit; remember the bottom three bits of a 64-bit heap pointer are always blank due to alignment.) This points to an arbitrarily large number in heap memory on which you can do arbitrary precision arithmetic.
With this sort of system you get on average maybe three additional processor instructions per arithmetic operation when doing math with small values (with highly reliable branch prediction since they are almost always small.) Not exactly five functions and hundreds of lines of code, as you seemed to imply. In almost all applications this trade-off is very much worth it to not have to ever worry about the limitations of your numbers, not to mention having a runtime that can provide absolute security against integer overflow.
And yes, as you can plainly see, I DO care a whole lot about how these things are implemented at the low level. It's interesting and exciting to work with. The point is I don't HAVE to work with it when I'm writing a large application. A well-written platform hides all of this away from you.
You need to get it into your head that not everyone is writing fucking video games for a living. I'm starting to sound like a broken record here, but you need to learn to use the right tool for the job.