14 Nov
2019
14 Nov
'19
12:02 a.m.
arnold(a)skeeve.com writes:
Norman Wilson <norman(a)oclsc.org> wrote:
OK, this is a bit of a tangential topic for this list. But, what's the
point of obsessing on UNIX history unless it's coupled with some effort
to communicate the philosophy to a new generation of programmers?
This has been a real concern of mine for a while. As a friend of mine
put it, processors are getting so cheap that pretty soon we won't be
able to purchase pencils that don't contain them. This puts us all
at the mercy of not-great programmers. And of course, it's not just
pencils, it's stuff like airplanes too.
In my opinion, the root of the problem is that programming today is
being taught in the abstract - as if programs don't run on computers.
Programming today is taught as if it consists of importing libraries
and gluing function calls together.
I recently visited my daughter's college and attended a number of CS
related presentations. Was surprised that CS is taught in Java with
some advanced work in Python. One can almost get a CS degree there
without ever using a compiler much less learning how computers function.
Too be fair, other schools such as Dartmouth where Doug hangs out have
a better curriculum.
At the K-12 level, the stage is set by combination of the "everybody
must learn to code" curriculum with "no child left behind". School
administrators dispense with any critical thinking about the value of
the curriculum in order to chase grant dollars.
I used to be able to get into my local schools to volunteer-teach
programming. But, the learn to code curriculum has eclipsed that;
schools are led to believe that they're teaching the right stuff
(because Bill Gates says so) and aren't interested in anything else.
I recently turned my course notes into a book as an attempt to make
some small difference. Too soon to tell if it will.
Anyway, my question for you all is, how do we as seasoned practitioners
leverage our experience to contribute to the state of the art? Any of
you found a way to pass on your knowledge?
BTW, I'm doing my first messing around with the Linux kernel these days;
if anyone knows the guts of the generic filesystem code I could use a bit
of help. Here's something that I came across on the way in <sys/mount.h>:
enum
{
MS_RDONLY = 1, /* Mount read-only. */
#define MS_RDONLY MS_RDONLY
MS_NOSUID = 2, /* Ignore suid and sgid bits. */
#define MS_NOSUID MS_NOSUID
MS_NODEV = 4, /* Disallow access to device special files. */
#define MS_NODEV MS_NODEV
...
};
Can anyone explain the value of this programming style? Is this just an
example of the result of how programming is taught today?
Be happy discuss this off-list.
Jon
I am very disappointed that programming education
seems not to care
enough about this sort of thing, even today.
I think this is the key. Universities focus (too much?) on the theory
and not enough on the practice, and "learn how to program" courses
and books focus on the mechanics (syntax, semantics) and not enough
(or at all) on the practicum of writing code well.
We continue to rely on the school of hard knocks, and we continue
to pay for this reliance.
I also think there's a sliding scale. The fancier or higher-end
the university, the more the focus on theory, and vice versa. Sigh.
Arnold