On Mon, 2 Sep 2002, Reza B'Far (eBuilt) wrote:
> Hmmm again.... You're telling me that you've never had a nasty bug that took
> you a couple of days to track down that had to do with a memory leak?  I am
> not the best C/C++ programmer... not even close... But I've known really
> good ones... and even they have nasty bugs that have to do with memory
> management, however occasional they may be.
OK, noone has been tool-less for memory management for a LONG time. Most
systems you just add a flag and memory is tracked (that's how i've always
done it) or worst case yuo have to run it through one of the 2.3E7 tools
where you simply recompile and it it tells you where the leaks are.
Memory management is a non-issue for anyone that has any idea at all how the
hardware functions. Granted, this takes 30 minutes to go over, and so is far
beyond the scope of the "Learn Java in 90 minutes without thinking" book
every Java programmer learned from.
- Adam L. "Duncan" Beberg
http://www.mithral.com/~beberg/
beberg@mithral.com

from localhost (jalapeno [127.0.0.1])
	by jmason.org (Postfix) with ESMTP id A5FEA16F3A
	for <jm@localhost>; Tue,  3 Sep 2002 14:22:41 +0100 (IST)
from jalapeno [127.0.0.1]
	by localhost with IMAP (fetchmail-5.9.0)
	for jm@localhost (single-drop); Tue, 03 Sep 2002 14:22:41 +0100 (IST)
from xent.com ([64.161.22.236]) by dogma.slashnull.org
    (8.11.6/8.11.6) with ESMTP id g82NOvZ25819 for <jm@jmason.org>;
    Tue, 3 Sep 2002 00:24:57 +0100
from lair.xent.com (localhost [127.0.0.1]) by xent.com (Postfix)
    with ESMTP id C612C2940ED; Mon,  2 Sep 2002 16:22:02 -0700 (PDT)
from mithral.com (watcher.mithral.com [204.153.244.1]) by
    xent.com (Postfix) with SMTP id E7D342940AC for <fork@xent.com>;
    Mon,  2 Sep 2002 16:21:45 -0700 (PDT)
No, hits=-10.8 required=7.0
	tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,KNOWN_MAILING_LIST,
	      QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02,USER_AGENT_PINE
	version=2.41-cvs

On Mon, 2 Sep 2002, Reza B'Far (eBuilt) wrote:
> With the increasing prevalence of web services (not that they are always a
> good thing), I doubt that parsing XML will be something that will remain at
> the Java application layer for long... Recent threads here on Fork
> indicating the move towards hardware parsing or this code even become part
> of the native implementation of Java on various platforms...
OK, so, you get the XML toss it through hardware and turn it back into a
struct/object whatever you call your binary data. I agree this is the way
things will go, as XML parsing has just too much overhead to survive in the
application layer. So why turn it into XML in the first place? Becasue it
gives geeks something to do and sells XML hardware accelerators and way more
CPUs?
Is there anyone out there actually doing anything new that actually IMPROVES
things anymore, or are they all too scared of the fact that improvements put
people out of work and cut #1 is the creators...
- Adam L. "Duncan" Beberg
http://www.mithral.com/~beberg/
beberg@mithral.com