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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public From: TanselErsavas Subject: Re: OO, C++, and something much better! Date: 1997/01/26 Message-ID: <32EB9BCA.3013@rase.com> X-Deja-AN: 212364446 references: <32DFD972.37E4@concentric.net> <5bphq4$5js@mulga.cs.mu.OZ.AU> <32E987FC.1FF2@rase.com> <32EB78FB.3EE6@jmpstart.com> content-type: text/plain; charset=us-ascii organization: RASE Inc. mime-version: 1.0 reply-to: tansel@rase.com newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng x-mailer: Mozilla 3.0 (Win95; U) Date: 1997-01-26T00:00:00+00:00 List-Id: James O'Connor wrote: > > Robert Dewar wrote: > > > > Tansel said > > > > ">What is highly debatable? I have used C++ for a long time and now I am > > >using Smalltalk, and there is NO comparison in development times. They > > >are simply different categories. Turtle vs. Rabbit." > > > > Yes, an apt reference to the fable, and I trust you remember who wins the > > race between the Tortoise and the Hare (which is the translation of the > > Greek I am used to, but I doubt we know precisely what animals Aesop was > > describing to this level of detail). > > Yes, that was perhaps a bad anology on his part to try to prove that > point :) I actually deliberately used this example. First of all, it has an element of truth that although you can develop applications very fast with Smalltalk, fine tuning and packaging them is slow, even with Today's nice tools, so I don't think that we should create an illusion that it is all a bed of roses. However, still there is no comparison. It is my observation that since it is so easy to develop in Smalltalk, the first target of people is to make the system run. That allows so many performance problems to creep into the system, which need to be optimized later. On the contrary, in primitive languages efficiency is always a factor. These types of problems are very solvable through good training and tools. Second, for "the Tortoise and the Hare", isn't it the time that we stopped believing such things? Just because we have a fable from the mythological times, does it mean that it is true, or it will always be like that? We are living in an age that we can have our own experiments rather than relying on old dogma. > > In this case, the reason for the tortoise winning may well be found in > > the long term maintenance and life cycle costs. Yes, languages like > > Smalltalk are certainly handy for quick prototyping, but who knows what > > the long term life cycle cost effects will be -- answer: no one, because > > commercial use of Smalltalk is too new to have more than scattered data. Not really. I have used most commercial languages including Smalltalk long enough, to see development and maintenance with Smalltalk is always so fast, it is just another dimension. You need people who know what they are doing though. The biggest problem with Smalltalk is people, and organizations who insist in developing applications with an army of people who don't know much, rather than a few good people. > I once commented to an (Ada advocate) friend that the more dynamic your > language got, the more you needed dynamic tools to deal with it. When I > did Ada83 years ago, I could use source code print-outs to debug my code > because every object was statically typed and every subprogram call was > statically bound. Now that I use Smalltalk (Ada people think I've > fallen from grace, Smalltalkers think I've reached enlightenment), ^^^^^^^^^^^^^ Congratulations! I had already noticed that light coming from your direction. > source code print-outs are not as valuable because it us much harder to > derive runtime state and flow of control. I wouldn't necessarily say > that over-reliance on dynamic debuggers is good, even in Smalltalk. The > debuggers are very powerful in Smalltalk, but even better is to use the > various powerful cross-referencing tools to ensure those errors don't > happen in the first place. > > > > > Someone actually posted earlier to this thread the idea that it was pretty > > useless to have the compiler verify type invariants, because debugging > > would find the errors easily. It is positively scary that there are > > programmers around who could say this with a straight face. But then > > any exposure to the general community of programmers is a very > > frightening experience :-) The idea of keeping the compiler as simple as possible is a very important step in obtaining language flexibility and portability . C has relied on this, and I find Smalltalk's simplicity and language syntax brilliant. It takes time to digest it though. However, "you can not do it with the compiler" does not mean that you have to do it with debugging. This is not an either-or case. Lint type of tools are used for C and C++, and Smalltalk environments are very clever to identify many potential bugs. I use a technique that automatically embeds type and other safety checking into code and automatically remove when I don't need them any more. I will commercialize this in future releases of my Snowball Rapid Systems Engineering tool. ... > James O'Connor Tansel ----------------------------------------------------------------------- RASE Inc. Clark NJ USA Voice: (908) 396 7145 mailto:tansel@rase.com Fax: (908) 382 1383 http://www.rase.com/ ----Sufficiently advanced technology is indistinguishable from magic--- -------------------------------A.C. Clarke-----------------------------