On Sat, 2003-09-27 at 22:19, Dennis Gearon wrote:
> Ron Johnson wrote:
>
> >There's always the general point that C has more pitfalls (mainly
> >from pointers/free()/malloc(), and HLLs do more for you, thus you
> >have to code less, and, consequently, there are fewer bugs.
> >
> Someday, they're going to make a langauge called:
>
> CBC, "C Bounds Checked"
>
> No buffer overflows, all memory allocs and mallocs create a memory
> object that self expands or contracts as necessary, or issues an
> exception if it tries to go past a limit you put as an argumen to a malloc.
>
> With gigabytes of real memory and 100 gigibytes plus of virtual memory,
> the programmer should not handle memory management any more. The
> consumers and software users expect programmers to give up their pride
> and let go of total control of the memory model, (like they have it now
> ). The only excetion might be hardware drivers.
Some would say that that's what Java and C++ are for. I'd do more
Java programming if it didn't have an API the size of Montana, no
make that Alaska and a good chunk of Siberia.
But still, multiple pointers being able to point to the same chunk
of the heap will doom any solution to inefficiency.
IMNSHO, only the kernel and *high-performance* products should be
written in C. Everything else should be written in HLLs. Anything
from COBOL (still a useful language), FORTRAN, modern BASICs, to
pointer-less Pascal, Java, Smalltalk, Lisp, and scripting languages.
Note that I did *not* mention C++.
> Nobody say C#, OK? An Msoft imposed solution that integrates all their
> products, mistakes, football stadium sized APIs, and private backdoors
> is not the answer.
natch!
--
-----------------------------------------------------------------
Ron Johnson, Jr. ron.l.johnson@cox.net
Jefferson, LA USA
"they love our milk and honey, but preach about another way of living"
Merle Haggard, "The Fighting Side Of Me"
