John Machin <[EMAIL PROTECTED]> writes:
> Roy Smith wrote:
>> "Philippe C. Martin" <[EMAIL PROTECTED]> wrote:
>>>Yet, many issues that a future software engineer should know are
>>>mostly hidden by Python (ex: memory management) and that could be
>>>detrimental.
>> I know I'm going out on a limb by asking this, but why do you think
>> future software engineers should know about memory management?
> Perhaps we have a terminology problem here i.e. different meanings of
> "software engineer". Philippe started talking about "CS" courses,
> whereas you may be referring to people who have done an "IT" course or
> achieved a certification in the use of app development tool X.
While I agree with John - software engineers should know something
about memory managment - I sort of agree with Roy as well, in that,
like Peter, I think memory management is something that doesn't need
to be taught immediately. A modern programming environment should take
care of the details, but a software engineer will be cognizant of the
details, and know enough to know when they have to worry about it and
when they can safely ignore it.
>> I used to worry about register allocation. Today, I don't even know
>> how many registers any machine I work on has. I used to worry about
>> word size, and byte order. I used to worry about whether stacks
>> grew up or down and addressing modes and floating point formats.
>> Sure, somebody's got to worry about those things, but most people
>> who write software can be blissfully ignorant (or, at best, dimly
>> aware) of these issues because somebody else (compiler writer,
>> hardware designer, operating system writer, etc) has already done
>> the worrying.
> You would hope they'd done more than worry about it. However sometimes
> one's fondest hopes are dashed. You must have noticed the anguish in
> the timbot's posts that mention Windows 95 memory management.
I think most of those things are indeed things that your average
software engineer can ignore 90+% of the time. What makes someone a
software engineer is that they know about those details, and know how
they will affect the code they are writing - and hence when they have
to worry about those details.
Oddly enough, I find similar comments apply to a lot of the data
structures I learned in school. I recently applied for a job that had
a series of essay questions in the application. They had a series of
problems with requests for solutions, and my immediate reaction to
each was to reach for off-the-shelf software to solve the
problem. While they wanted - and I provided - a discussion of data
structures and big-O running time for various operations, all the
things they wanted to do were essentially solved problems, and there
was debugged and tuned code available to deal with things - and it's
much faster to not write software if you can to solve the problem.
For instance, one problem was "You have two files that have lists of 1
billion names in them. Print out a list of the names that only occur
in one of the files."
That's a one-line shell script: "comm -12 <(sort file_one) <(sort file_two)"
I gave them that answer. I also gave them a pseudo-code solution, but
frankly, in real life, I'd install the shell script and get on with
things. If I were hiring someone, I'd hire the person who gave me the
shell script. Rather than spending hours/days debugging a program to
solve the problem, I get a solution in minutes. If it runs into
problems, *then* it's time to start hand coding the solution.
>> There used to be a time when you had to worry about how many tracks
>> to allocate when you created a disk file. When's the last time you
>> worried about that?
> Seeing you asked: early 1970s, on an IBM 1800. But much more recently
> it certainly helped if one were slightly more than dimly aware of the
> difference between a FAT filesystem and an NTFS filesystem :-)
For me it was the late 1970s, on an IBM 3081. But I was worried about
disk sector sizes well into the 1990s. Since then I've worked on
systems that didn't have a file system as such; it had a database of
databases, and you queried the former to find the latter.
<mike
--
Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
