While putting logic in the db can result in large performance improvements (by reducing round-trips between client and server), it can also reduce performance by forcing all clients to contend for a single shared resource (the db).
In a typical client-server situation, you can add compute power on the client end pretty easily. Adding additional horsepower to the db engine is usually a lot more expensive.
Like people used to say back in the old days, when workstations were new: the nice thing about the network is that it doesn't get faster at night.
I recall having very un-enlightening discussions with Drexler back then at PARC. He was convinced that the Nano-future was only a couple of years away. It was just a matter of engineering, after all, and once people understood the possible profits to be had, why, the floodgates of innovation would be opened.
Of course he was too busy trying to patent nano-machines to actually contribute to this great and glorious future.
It's more than a couple of years later now. Next to nothing that he talked about back then has come to pass. Yes, there have been some technical advances. But where are the injectable nano-repair machines to scrape out my clogged arteries? Why is laser eye surgery cutting-edge technology? Why are smart weapons still bombs and not destructive targeted nano-killers?
Why are these people so right about technological possibilities and so wrong about human culture? Judging by Drexler, I suspect that their beliefs in Libertarianism, the Profit Motive, and their desire to Freeze-Your-Head-so-you-can-Live-Forever(tm) marks them as just another bunch of Utopians whose belief in What-Should-Be blinds them to What-Is.
Most debuggers do an adequate job of letting you examine and modify data. Few let you understand the dynamic state of the program. I think that's why printf is so useful -- you see the flow of execution of the program, not just the final state.
Back when I worked on Purify I added a (hidden) facility I called "How did I get here?". The Purify'd program maintained a fixed size ring-buffer containing information about the most recent N function calls. When a problem was detected you could then (in a standard debugger) dump out this call history to help you understand just how the program got there.
Imagine extending that idea: instead of recording function calls, record (interesting) branch points. And have the compiler do it instead of some third-party tool. Now you have something powerful -- you can look back in time and (if you're lucky) see just where the program went off the rails.
Check out the "Truckin" game at Xerox PARC in 1983. Teams had just one or two days to design and implement their players that were then pitted against each other as everyone gathered around and watched.
It was designed to teach a language, not test programming skills. At that is succeeded -- I lost big-time, but had a ball and learned a lot.
Sure been a lot of progress in the last 20 years...
Book is really about the people around Nash
on
A Beautiful Mind
·
· Score: 1
Don't get distracted by the particulars of Nash's life. The book is
really about the people around Nash, and the amazing lengths
they go to to protect what they all see as "A Beautiful Mind".
Nash is (was) extraordinary in a number of ways: a genius, a
mathematician, a paranoid schizophrenic. Probably none of us will ever
understand what any one of those is like: put them together in one
person and you have a total mystery.
Instead of approaching Nash head-on, the book looks at the effect he has
on the people around him. You can get a strong feeling for what it must
be like to know Nash by seeing how more "normal" people react to him.
His wife, even after divorcing him, takes him into her house and takes
care of him. Princeton maintain a safe stable environment for him to
wander in. Friends and colleagues fight to get him the recognition that
they feel he deserves. The sacrifices these people make are uplifting;
the recovery they help bring about is heartbreaking. That is the real
story of the book. Perhaps not a great theme for/., but important
nonetheless.
Slashdot Mirror
That PARC thing would be Notecards, circa 1984.
What about good old Coffee?
Sorry if this has already been noted, but...
While putting logic in the db can result in large performance improvements (by reducing round-trips between client and server), it can also reduce performance by forcing all clients to contend for a single shared resource (the db).
In a typical client-server situation, you can add compute power on the client end pretty easily. Adding additional horsepower to the db engine is usually a lot more expensive.
Like people used to say back in the old days, when workstations were new: the nice thing about the network is that it doesn't get faster at night.
The state rock is Serpentinite, which may contain Asbestos.
It's more than a couple of years later now. Next to nothing that he talked about back then has come to pass. Yes, there have been some technical advances. But where are the injectable nano-repair machines to scrape out my clogged arteries? Why is laser eye surgery cutting-edge technology? Why are smart weapons still bombs and not destructive targeted nano-killers?
Why are these people so right about technological possibilities and so wrong about human culture? Judging by Drexler, I suspect that their beliefs in Libertarianism, the Profit Motive, and their desire to Freeze-Your-Head-so-you-can-Live-Forever(tm) marks them as just another bunch of Utopians whose belief in What-Should-Be blinds them to What-Is.
Most debuggers do an adequate job of letting you examine and modify
data. Few let you understand the dynamic state of the program. I think
that's why printf is so useful -- you see the flow of execution of the
program, not just the final state.
Back when I worked on Purify I added a (hidden) facility I called "How
did I get here?". The Purify'd program maintained a fixed size
ring-buffer containing information about the most recent N function
calls. When a problem was detected you could then (in a standard
debugger) dump out this call history to help you understand just how the
program got there.
Imagine extending that idea: instead of recording function calls, record
(interesting) branch points. And have the compiler do it instead of
some third-party tool. Now you have something powerful -- you can look
back in time and (if you're lucky) see just where the program went off
the rails.
Sure been a lot of progress in the last 20 years...
Nash is (was) extraordinary in a number of ways: a genius, a mathematician, a paranoid schizophrenic. Probably none of us will ever understand what any one of those is like: put them together in one person and you have a total mystery.
Instead of approaching Nash head-on, the book looks at the effect he has on the people around him. You can get a strong feeling for what it must be like to know Nash by seeing how more "normal" people react to him. His wife, even after divorcing him, takes him into her house and takes care of him. Princeton maintain a safe stable environment for him to wander in. Friends and colleagues fight to get him the recognition that they feel he deserves. The sacrifices these people make are uplifting; the recovery they help bring about is heartbreaking. That is the real story of the book. Perhaps not a great theme for /., but important
nonetheless.