From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public From: tbushell@fox.nstn.ns.ca (Tom Bushell) Subject: Re: What is wrong with OO ? Date: 1997/01/01 Message-ID: <32cbaca2.178339675@news.nstn.ca> X-Deja-AN: 207147654 references: <5a0niaINNlda@topdog.cs.umbc.edu> <32C43AC8.24E2@sn.no> <32C557F6.532C@rase.com> <5aa0eo$thd@krusty.irvine.com> <5aadbr$ad8@masters0.InterNex.Net> content-type: text/plain; charset=us-ascii organization: Telekinetics mime-version: 1.0 newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng Date: 1997-01-01T00:00:00+00:00 List-Id: On 31 Dec 1996 06:54:51 GMT, clovis@wartech.com wrote: >You're quite right. Tansel is acting like quite a pretender on this one, and he >obviously doesn't know what either a Von Neumann machine is, or what a Turing >machine is. Let's wait until he gets his article together before slagging him, eh? Although he may be guilty of a bit of hyperbole, I have a hunch he may be on to something - time will tell. >A Von Neumann "machine" is really a recommended architecture, >and really, there aren't many of them. They feature regular instruction sets, >with zero duplication of function, and all operations being orthogonal. As other postings have said, my understanding was that shared program and data memory is the defining characteristic. >None of this is really rocket science. And it's never ceased to amaze me how many >of the "hip" guys can't even define the basic terms. Seems to be a problem with the field in general, not just a few hip guys. Terminology and concepts havn't stabilized. Witness your own statement about the "true" meaning of von Neumann architecture, extended discussions about what OO "really" means, and so on. >Assembler will ALWAYS be the most efficient language. The more you abstract the >problem, the more you "generalize" the solution to a given problem, the more you >necessarily give up in efficiency. Agreed, if you define "efficency" as "doing the most computation with the fewest instructions". >C takes a minimal 3x hit on integer arithmetic, >10x on more complex stuff; and OO, because of the overhead interpreting where >to send things, is 10x on top of that. Saying that there is a 10x hit for using OO is a pretty sweeping statement. May be correct for a Smalltalk message send, which is late bound. But an early bound C++ call just requires one more indirect jump through the vtable, so the performance hit is more like 3 _percent_ according to what I've read, which is trivial. >I personally use all three in Smalltalk applications which involve a variety of >disciplines. Smalltalk handles the GUI, but engines in C and ASM are also required >in some cases. Any realtime requirements point to ASM, and any number crunching >points to C most of the time (Assembler if the computation must be made in >realtime, and be interruptable in mid-stream). I agree 100%. The huge reduction in development time for the 90% of the system that doesn't need speed more than repays the extra effort and complexity of a multi language solution. >Smalltalk itself is not entirely Smalltalk. It contains both procedural (often C), and >frequently ASM routines at the kernel since no general purpose machine ever >built comprehends objects -- all the underlying hardware knows about is basic >arithmetic, compares, and jumps/branches based on flags settings. As an aside, many Forth compilers are written in Forth. The Forth stack based virtual machine is coded using the Forth postfix assembler for the target machine. The result is a programming system that is completely able to regenerate itself (wasn't that one of the definitions of a von Neumann machine?) >ASM is REALITY. > >>In this thread someone said assembler was "real" and higher level >>languages were abstractions above that. I always thought voltage >>states/levels were real and that assembler was an abstraction of voltage >>states/levels. > >Elliott Have to agree with Elliot on this one - assembler is just a textual abstraction for the binary numbers that are computer instructions. And the binary numbers are abstractions for voltages, and the voltages are...it's elephants all the way down. If you are saying assembler is the lowest abstraction we can program in under normal circumstances, I agree. (Although I wrote a Forth in hex on a KIM-1, back in the bad old days.) >It's a tradeoff, and if we want to represent ourselves as real computer scientists, >and real computing professionals, it behooves us to be able to explain in clear >terms why one paradigm is better, where it is better, and the details of why it is >better AT A GIVEN TASK. I agree, but IMO the field has a lot more maturing to do before this will happen. >We can get by without smalltalk if we must. If we try to do without Von Neumann, >there isn't such a thing as a working computer. True for current computers, and one of the reasons I'm a little skeptical about what I _think_ Tansel is saying - the implication that we need a whole new hardware architecture before we can benefit from OO. But he claims von Neumann himself was dissatisfied, and if there is a much better architecture for CPUs, we can assume it will be built and commercialized - eventually. -Tom ---------------------------------------------------------- Tom Bushell * Custom Software Development Telekinetics * Process Improvement Consulting 2653 Highway 202 * Technical Writing RR#1, Elmsdale, NS B0N 1M0 (902)632-2772 Email: tbushell@fox.nstn.ns.ca ----------------------------------------------------------