Re: The Basics

Robert Sanford <[email protected]> writes:

> I guess that depends on what you define as the "basics". You are
> defining the underlying OS architecture as the "basics" but for many
> people those are considered "advanced" topics.

No. How computers do virtual memory is the basics. Of course, it's not
the first thing you teach... but it's one of the first things.

AFAIK most university courses cover this in the first year.

 
> Let's take a look at XML as an example - The "basics" of XML are
> that you have a hierarchical representation of your data and you can
> parse that data using some nifty toolset. Most of those nifty tools
> that people are using shield them from the low-level details of the
> specs. Those low-level details aren't the "basics" but they *are*
> the "foundation".

Hmmm... I guess "the basics" depends on the audience. Clearly, telling
HR managers about computers will not involve telling the story of
virtual memory but will explain a lot about identity assertion and
databases.


> Well, we were getting incomplete results in some of our data fields
> and my coders were confused. Digging in to our handler I saw that we
> were simply setting the string content of an element to be the last
> value that was given to us by the characters() method. Well, I've
> done some reading and participated in email discussions and,
> probably most importantly, made that same mistake before. The rule
> is that SAX parsers don't have to give you all of the character data
> for an element at once. We have to *append*, not overwrite, during
> the characters() method.

I would agree with you here.  But I don't think this is anything to do
with "the basics". I think SAX is a very advanced topic for
programmers.

IMHO SAX is a very poor API because it's usability is so poor. I think
there must be better ways to deal with streaming XML.


> My current responsibility is to handle business transactions within
> a CRM tool and throw out all of the crap that our previous
> consultant put into it.  I want my team to be spending their time
> and energy in understanding the business processes so that we can
> make things work right. I would rather them understand those
> processes as well as the accounting and sales and customer support
> staff than have them understand that you can't have one application
> peek at another application's memory space and why.

I'm talking about technical leaders within an organization. I find it
shocking that such people don't know how memory protection works, what
a linker does, what a buffer overflow attack is.

And I would expect anybody coming out of uni with a comsci degree to
know these things.

Not *every* programmer, but the leaders.


Crucially, I'm one of those people who believe that the role of the
programmer is to be the bridge between the business and the machine. I
don't like it when programmers are isolated from machines (which they
often are) or from business owners (which they often are). But that's
a different argument.


Nic


------------------------ Yahoo! Groups Sponsor --------------------~--> 
$9.95 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/saFolB/TM
--------------------------------------------------------------------~-> 

Before posting a question, try to find your answer here: 
<http://www.egroups.com/links/advanced-servlets>
Announcements should go to: [email protected]
To Post a message, send it to: [email protected]
To Unsubscribe, send a blank message to: [email protected] 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/advanced-servlets/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/