I agree. Thank you and Merry Christmas Manue On December 11, 2017 5:27:44 AM PST, karentellef via RBASE-L <[email protected]> wrote: >That is cool, Bruce, thanks for posting! > >I remember in my early RBase days that I took a C class (can't remember >what version of C it was at that point). I liked it fine until we got >to memory management, if I remember correct it was "pointers"?? I >couldn't believe I had to tell the computer where the heck to put >stuff!! I passed the class, but I never chose to do anything with it. > >Karen > > > > > > > >-----Original Message----- >From: Bruce Chitiea <[email protected]> >To: rbase-l <[email protected]> >Sent: Sun, Dec 10, 2017 5:17 pm >Subject: [RBASE-L] - OT: A Reflection on the integrity of the R:BASE >Relational Engine > > > >All: > > >I humbly offer - as a meditation of sorts - an excerpt from the >esr.ibiblio.org blog authored by Eric Raymond, on 2017-1113, in a >series discussing possible paths for transitioning out of C++. No point >to push, here: perspective, is all. > > > >"... >"Ever since the very earliest computer languages it’s been understood >that every language design embodies an assertion about the relative >value of programmer time vs. machine resources. At one end of that >spectrum you have languages like assembler and (later) C that are >designed to extract maximum performance at the cost of also pessimizing >developer time and costs; at the other, languages like Lisp and (later) >Python that try to automate away as much housekeeping detail as >possible, at the cost of pessimizing machine performance. >In broadest terms, the most important discriminator between the ends of >this spectrum is the presence or absence of automatic memory >management. This corresponds exactly to the empirical observation that >memory-management bugs are by far the most common class of defects in >machine-centric languages that require programmers to manage that >resource by hand. >A language becomes economically viable where and when its >relative-value assertion matches the actual cost drivers of some >particular area of software development. Language designers respond to >the conditions around them by inventing languages that are a better fit >for present or near-future conditions than the languages they have >available to use. >Over time, there’s been a gradual shift from languages that require >manual memory management to languages with automatic memory management >and garbage collection (GC). This shift corresponds to the Moore’s Law >effect of decreasing hardware costs making programmer time relatively >more expensive. But there are at least two other relevant dimensions. >One is distance from the bare metal. Inefficiency low in the software >stack (kernels and service code) ripples multiplicatively up the stack. >This, we see machine-centric languages down low and programmer-centric >languages higher up, most often in user-facing software that only has >to respond at human speed (time scale 0.1 sec). >Another is project scale. Every language also has an expected rate of >induced defects per thousand lines of code due to programmers tripping >over leaks and flaws in its abstractions. This rate runs higher in >machine-centric languages, much lower in programmer-centric ones with >GC. As project scale goes up, therefore, languages with GC become more >and more important as a strategy against unacceptable defect rates. >... " > >-- >For group guidelines, visit >http://www.rbase.com/support/usersgroup_guidelines.php >--- >You received this message because you are subscribed to the Google >Groups "RBASE-L" group. >To unsubscribe from this group and stop receiving emails from it, send >an email to [email protected]. >For more options, visit https://groups.google.com/d/optout. > > >-- >For group guidelines, visit >http://www.rbase.com/support/usersgroup_guidelines.php >--- >You received this message because you are subscribed to the Google >Groups "RBASE-L" group. >To unsubscribe from this group and stop receiving emails from it, send >an email to [email protected]. >For more options, visit https://groups.google.com/d/optout.
-- Sent from my phone. Please excuse my brevity. -- For group guidelines, visit http://www.rbase.com/support/usersgroup_guidelines.php --- You received this message because you are subscribed to the Google Groups "RBASE-L" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
