"Morel Bérenger" wrote:
Le Ven 1 mars 2013 0:20, Miles Fidelman a écrit :
- also, those of us who date back a few years still think of computers
as things that "need some assembly" and bring that view to system software
as well
Well, here, let me laugh.
Something which needs some assembly, is composed of objects, right?
When you built your computer, you do not try to reproduce the cards
before, they are simple objects?
What are objects in programming? OOP. Modules. Stuff you can reuse without
having to understand exactly how it works, simply read the doc, and plug
the lib in your software.
Fair enough, but... I have to say it....
Back in my day, we not only had to walk to school, uphill, in both
directions, in the snow, but we also had to build our computers by hand,
from TTL logic gates. :-)
Seriously, though... these days, the objects we deal with are a lot
bigger and more complex, and often contain "no user serviceable parts."
There's something qualitatively different between a wire-wrap board
containing logic gates, and a CPU chip.
I will maintain that one has a different perspective if one has had to
get down in the weeds. When I was in school, we had an old PDP-1 in a
lab where users were allowed (even encouraged) to add new machine
instructions by wire-wrapping them onto the backplane. Other people were
busily building micro computers from kits (can you say IMSAI?). In one
of my early jobs, we designed embedded avionic computers, which included
things like designing the instruction set, designing the microcode that
implemented macroinstructions, and then the board level design. At the
time, our pride and joy was a single-board machine (about micro-itx
size), faster than anything else around, that consisted about 100 ECL
flatpacks on each side of a 16-layer, double sided circuit board. The
hardest part of the design actually turned out to be designing the
circuit boards to carry heat to the edges of the board - to mate up with
the cooling system. Now what we considered fast (4.2mflops if I recall)
is laughably slow by today's standards - but I maintain that we learned
a lot that provides a lot of perspective into the present.
Now, I won't deny that there are younger folks who've learned such
things as well; nor will I deny that there are things that people learn
today that are equally or more valuable (say, chip design). But I will
say that as the low-level black boxes become more complicated, and less
accessible, and less taught, we've lost a lot.
The best comparison I can make is to cars. Used to be that most people
could do simple maintenance and roadside repair - oil changes, jiggle a
stuck carburetor, etc. Auto shop was commonly taught in high school,
lots of people customized their cars, and so forth. These days, a lot
more of our cars consist of things we can't get to (fuel injectors
instead of carburetors, engine control computers instead of mechanical
linkages), its hard to find an auto shop course outside a trade school,
and the most that many people can do in the way of self-help is to call
AAA from their cell phone.
My sense is that the computer world is somewhere in the middle of this
kind of transition. More and more people are only prepared to use
something that comes out-of-the-box pre-loaded with software, and get
disturbed and flustered when faced with the need for "some user assembly
required."
Is this a bad thing? For users, probably not. When I'm reading a book,
I want a Nook or Kindle to be as transparent and easy-to-use as a
printed book. When it comes to folks who are going to build the next
generation of technology, it's a big problem.
FYI, there's an interesting discussion right now, on opensource.com, on
"growing the next generation of hackers" that relates to these issues -
http://opensource.com/education/13/2/next-generation-open-source-hackers
Which leads me to take just a little issue with your comment that
"younger people have more useful experience." I'm actually not entirely
sure that's true. If anything, younger people have narrower (or at least
different) experience.
Well, you have a lot of "deprecated" experience. I do not want to
denigrate your knowledge, since it gave you a way to think and do things
and since young programmers are full of such deprecated knowledge, but how
useful is now your knowledge about motorola assembly? About INT 21H? About
address A000:0000 in mode 13H?
That knowledge was very useful yesterday, but now, it is deprecated,
unusable.
It imply that you know some basics about memory and CPU, but in itself, it
have now no use.
And I only mentioned stuff of 90's here. Only 20 years old.
Well... don't know about Motorola assembly, but I expect my experience
with both PDP-10 and Z80 assembly is still relevant in several regards:
- it's not the details of any specific assembly language that matter -
they all have roughly the same function set (well, not exactly true;
there are RISC vs. CISC distinctions, and there were really funny
instruction sets like the DG Nova, that looked a lot more like microcode
- kind of nice to be able to do an add, rotate, and shift in one
instruction when you're doing image analysis)
- programming in assembly code requires a different mind-set than
programming in a higher-level language (the more so if you're not
running on top of an operating system, say when building low-level
controllers for physical machinery) -- when you aren't using an o/s you
learn a lot about hardware interaction and control; when you are using
an o/s you learn a lot about how instructions flow through system
- more generally, once you've coded in a few assembly languages, you can
program in any of them - it's a matter of knowing that a function
exists, and then how to look up the specific syntax in the manual - you
do learn pretty quickly the difference between a good macro-assembler
and a poor one (PDP-10 and Z80 were both exceptional in that regard)
- and while I maintain that it's more a matter of perspective, I beg to
differ about "deprecated" - the Z80 and direct derivatives are still
popular chips, going strong after 35 or so years in the market!
Cheers,
Miles
--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5130ae81.1060...@meetinghouse.net