Hi
13 Oct 2000, Clarence Verge <[EMAIL PROTECTED]> wrote:
>> CV> My experience with Linux has been limited to relatively small
>> CV> hand-made distros like Dragon and Pygmy.
>> Than you shouldn't generalize ...
CV> Well, both DRAGON and PYGMY are only twice as big as TSX so IMNVHO it
CV> is a fair generalization.
These are not sold as TSX ...
somebody sat down, and made up his own small distribution ...
that there are small quirks in it, that's clear ....
>> And to be honest direct assembler is not useable for some (most)
>> projects.
CV> Mostly because there are so few programmers left.
no ....
because it gets much too complex when the projects get bigger ...
you can write a 50 KB kernel of a small OS in assembler, but it's very
impracticable to write a (full grown) Office application in assembler.
it is not used, because the only advantage (speed) is
a) not so important any more
b) the disadvantages are HUGE !!!
>> It is absolutely NOT portable, debugging is extremely hard.
CV> Portability is a red herring. It is always trotted out, and almost
CV> never used. 99.9% of platforms are the same.
?? Linux is available at least for Intel, IA64, DEC Alpha, MAC, Amiga
....
You can simply take the source RPMs, and compile them on your let's say
Alpha ... ready ....
This is done often, and I know more than one person who has done exactly
that.
CV> Debugging is extremely EASY. The rules are ironclad and known.
CV> With "C", who knows WHAT the heck it's trying to do ?
maybe this is my personal view ... but for me it's exactly the other way
round ...
Reading assembler is VERY EXTREMELY hard in comparing with reading any
highlevel sourcecode !!!
Debugging C is also easy ... you can step through the LOC, and see what
exactly was done ....
>> Project size is extremely limited.
CV> There are two ways to read that. Do you grade a project's
CV> desirability as being in direct proportion to the number of gigabytes
CV> you can waste ?
Hmm .. when I make a project, I don't want to waste space, but I want to
implement a certain functionality ...
hmm ... interesting new american point of view ... wasting space for the
space's sake :-)))))))) (SCNR)
OK ... what I meant is, that as the size (things to implement) increases
the problems with assembler insrease exponentially.
CV> Because there are so few programmers left and, I agree it takes
CV> longer to write the ASM project, there could be difficulty finding
CV> the manpower.
yes ...
If there would be demand, than there would be also enoigh manpower ...
but there is very low demand
>> With the new generation CPUs even that will not be possible, because
>> handmade code will be slower than C compiled !!!!
CV> Ha. (Technical term)
??? the reason for that is, that these compilers demand special alignments,
which will be extremely hard to figure out by hand ...
>> no question that nowadays handoptimized assembler is much faster ...
>> but it takes 100+ times to write it ....
CV> Correct. 100 is about right. Because you don't have to know anything
CV> to throw together a few lines of "C". I'm NOT saying that "C"
CV> programmers in general don't know anything about the hardware or the
CV> protocols they must deal with. That isn't the point. I AM saying that
CV> a random individual with no knowledge of the hardware CAN write a
CV> "Hello world" in "C" 100 times more quickly than in "ASM".
We are not talking about hello world.
Let's take a simple example.
Program a multithreaded simple webserver.
And compare the time which is needed by a C programmer, and an assembler
progarmmer.
PS: The C Programmer does not need to know the hardware specialities, this
is the job of the OS.
And naturally it is allowed to use libraries.
CV> CU2,
CV> - Clarence Verge
CU, Ricsi
--
Richard Menedetter <[EMAIL PROTECTED]> [ICQ: 7659421] {RSA-PGP Key avail.}
-=> Knowledge is to know the extent of one's ignorance <=-
