[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: sysadmin qualifications (Re: apt-get vs. aptitude)

Jerry Stuckle wrote:

On 10/17/2013 11:37 AM, berenger.morel@neutralite.org wrote:

Le 16.10.2013 17:56, Jerry Stuckle a écrit :

You're the one who said programmers need to know a lot of details
about the hardware being used, not me.  The more you need to know
about different hardware, the harder it is to write code to fit all of
that hardware.


I did not said "a lot" but basics. I do not think that knowing that to
build a memory cell you can use 2 NAND. I think that it is useful to
build PC's applications to know that there is a memory stack. Basics.
Knowing that registers have limited size, is also useful: if you program
in C, int's size is, IIRC, dependent on those sizes. Indeed, there are
now types with fixed sizes, too, but I would not bet that many languages
have those.
You've claimed programmers need to understand how memory works, for graphics applications how to use the GPU, and even how network protocols work. In my world, that is not "basics". Even register size is immaterial in high level languages.
And only to a certain extent is an int's size dependent on register size. For instance, I can run 32 bit applications just fine on a 64 bit machine. And it uses 32 bit integers. It is this way in C for efficiency reasons, but that's all. And there is no reason a 32 bit C compiler could not run on a 16 bit machine, other than it would be less efficient, just as you can use a 64 bit long long in some C compilers on a 32 bit machine.
When I was working on IBM mainframes, they had 32 bit registers. But COBOL defines a PACKED DECIMAL type which could be any length; 20 decimal digits are not uncommon in banking applications. And there were COBOL compilers even on the early 16 bit PCs with this same capability.
What is important is what the language defines, not the physical layout of the machine.
In the REAL world, program behavior is very much driven by the properties of underlying hardware.
And... when actually packaging code for compilation and/or installation - you need to know a lot about what tests to run, and what compile/link switches to set based on the characteristics of the build and run-time environments.
Of course, you can simply rely on portable libs. But then, when you have a bug which does not comes from what you did, how can you determine that 
it comes from a lib you used?

I remember having a portability problem, once. A code worked perfectly
on a compiler, and not at all on another one. It was not a problem of
hardware, but of software: both had to do a choice on a standard's lack 
of specification (which is something I did not known at that point. I
have never read the standard sadly.). I had to take a look at asm
generated code for both compilers to understand the error, and find a
workaround.


A good programmer knows what is defined and not defined in the
language.  For instance, in our C and C++ classes, we teach that the
results of something like func(i++, ++i); is not defined.


And I am not a good programmer, I know that perfectly. I have still a
lot to learn. The day when I'll claim it anew (I said it, when I was
learning bases...) I will simply be really stupid.
Even beginning C programmers in our classes learn about many things which aren't defined by the language. 


What allowed me to understand the problem, was that I had that asm
knowledge, which was not a requirement to do what I did.

Of course, I have far less experience and grades than it seem you both
have, and if I gave a minimalistic sample of the problem you could think 
that it was stupid, but it does not change that I only was able to fix
the problem because of my knowledge of stuff that I have no real need to 
know.



You should always be aware of the limitations of the language you are
using, also.


But those limitations are dependent on the platform they use, for me.
See my example with int. In all lessons I had, teachers mentioned short
and long, but encouraged to use int instead.
And it can give interesting bugs if you use int without knowing that it
may have a different meaning depending on the compiler and the CPU.
No, it is completely dependent on the compiler being used, as noted above.
Bulltwaddle. It also depends on the linker, the libraries, compile-time switches, and lots of other things.
Given what you have to say, I sure as hell wouldn't hire anybody who's learned programming from one of your classes. 


--
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra
Reply to: