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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public From: clovis@wartech.com Subject: Re: What is wrong with OO ? Date: 1996/12/31 Message-ID: <5aadmu$ad8@masters0.InterNex.Net>#1/1 X-Deja-AN: 206918178 references: <32A4659D.347A@shef.ac.uk> <32B81DA7.6D08@deep.net> <59vr2s$55r@masters0.InterNex.Net> <5a0niaINNlda@topdog.cs.umbc.edu> <32C43AC8.24E2@sn.no> <5a6q6o$kk@masters0.InterNex.Net> <32c72272.204443082@news.nstn.ca> organization: InterNex Information Services 1-800-595-3333 reply-to: clovis@wartech.com newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng Date: 1996-12-31T00:00:00+00:00 List-Id: In <32c72272.204443082@news.nstn.ca>, tbushell@fox.nstn.ns.ca (Tom Bushell) writes: >On 29 Dec 1996 22:09:28 GMT, clovis@wartech.com wrote: > >>Paradoxically -- and this really is a paradox -- Smalltalk seems to be smaller and >>faster both when dealing with a GUI. Minimum size on my VA applications, the really >>small little demo things, is about 1.8 megs. But it doesn't grow much unless one is >>throwing the whole kitchen sink at things. And the debugger etc etc and the whole >>runtime development environment only occupies about 15 megs on disk including >>a de facto text processing system, all sorts of graphical widgets, and some very >>complex connection and self-maintainance code. > >I have noticed this also applies to Visual BASIC and Forth. These >languages all use a technique that is often poo pooed by C/C++ junkies >obsessed with wringing every cycle out of the CPU - they compile to a >virtual machine, which is then interpreted. These runtimes tend to be >very compact compared to the native code produced by conventional >compilers. Of course, the execution time is slower, but this normally >is only an issue for about 10% or less of the code in a typical >program. This 10% can be written in C or assembler, but this is >rarely necessary. It depends on the application. A proper architect breaks the problems into rational pieces, and uses the appropriate paradigm on each. An example may help. I am presently writing a simulator which models the flight of ballistic objects in 4 space, where the 4-space computations are second order differential equations. The simulator is not written all in Smalltalk. Chunks which are bad for Smalltalk are done in C or Assembler. If I had to do realtime, there would be an Assembler dispatcher controlling the system which would itself be hardware-driven. >I also suspect that the bloated executables often execute more slowly >than they would if interpreted, because they spend so much time being >swapped in an out of virtual memory. I entirely concur with this sentiment. If you gots to swap, a VM works better and faster. Disk access is one of the major IO dogs of the system. Fairly cheap chips are running 10,000x faster than a disk. If any significant swapping occurs, one can kiss performance goodbye.