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.7 required=5.0 tests=BAYES_00,CTE_8BIT_MISMATCH, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII 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: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public From: Tansel Ersavas Subject: Re: OO, C++, and something much better! Date: 1997/01/24 Message-ID: <32E8DC1C.4871@rase.com> X-Deja-AN: 211942954 references: <5bphq4$5js@mulga.cs.mu.OZ.AU> content-type: text/plain; charset=iso-8859-1 organization: RASE Inc. mime-version: 1.0 reply-to: tansel@rase.com newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.c++,comp.lang.smalltalk,comp.object x-mailer: Mozilla 3.0 (Win95; U) Date: 1997-01-24T00:00:00+00:00 List-Id: Joachim Durchholz wrote: > > Alan wrote: > > > But replace "PL/I" with "any statically-typed language," and then you can > > see the truth: "because any statically-typed language sucks, is why." > > Come on, have you ever programmed in a statically-typed language? > Seriously? > What you say sounds just like a Basic programmer whom I tried to convince > he should try (just TRY!) Pascal. He said he had seen it at the > University, and Pascal sucked... I used Pascal, C and C++ for more than 10 years, and developed and led development of >500000 loc projects, and I am sorry to say that I still think they suck. I now use Smalltalk and Self and sometimes Java if I have to, and couldn't be happier. About types, this segment is an appendix to a recent posting I made to these groups. "The exaggerated importance of type checking in OO There is a big debate about importance of type checking in object oriented systems. We have one camp religiously defending type checking, and another group defending unnecessity of it. There is a merit in both sides� arguments. This has more to do with the implementation specific problems than a general theoretical point of view. If we ask people who are familiar with languages based on ADTs, type checking is so necessary, the absence of it is total catastrophe. If we ask a Smalltalker or a Selfer, they will tell we that type checking is not all that important. The problem is two edged. The more type information we put into the objects, the more we make them dependent of these types. Any changes on these types will have to be detected, and these parts of the programs need to be updated, even though in compiled systems a recompilation will suffice in many cases. The reason of inflexibility of ADT based languages such as C++ are partly due to their reliance on type checking. On the other hand, in the languages that we get sinful flexibility, we actually almost never know that we may have a problem that may lie in an untested corner, and may lurk at an unexpected moment. Contrary to what people say, type checking is against the nature of object oriented systems development. Remember, in OO, we only care about the interface of the other object. In fact it should be an OO sin to ask the type, because, in theory, we don�t want to get intimate with objects we are interacting apart from their interface. We only want to know the interface. But we do check types anyway, because we do not have another way in many of the current popular languages to guarantee that this object has the interface that we require. Type checking is necessary in ATD based languages because of language structure. In languages such as Smalltalk, on the other hand, even knowing the type of an object is not a guarantee that this object will answer a method that we use, because we can really delete any method for that object while the system is in operation, so even type checking is not a perfect solution. Then what is the solution? Common Object Requester Broker Architecture (CORBA) makes this possible by allowing us to define only the interface of objects. However, this approach is not much of a use of objects within the same language. Some other languages have the notion of a subtype, which is dependent on the interface. In the languages which do not offer such mechanisms, one obvious solution that comes to mind is to offer an interface signature, that will indicate that an object really offers all the services that it is required. This will guarantee that type of the object can change any time as long as the public interface signature of the object does not change. Then any object binding to this object can ask its signature rather than type to verify that the interface is the same as this object was created. This has run time costs associated with it, but solves many problems that are associated with type checking. Furthermore it is not practical for many ADT based languages. In most ADT based languages type checking is done at the compile time. This approach gives us a lot of safety, but also has an expensive price tag in terms of flexibility and compromise of object oriented approach. There can not be much done to increase flexibility of such languages. One of my solutions for flexible systems such as Smalltalk is, to use high level tools to automatically embed type or interface checking code in development and testing phase, and after all tests are done, to remove these checks automatically, allowing systems to run without type checking once they are in production. This gives me best of the both worlds." > > (Actually, statically-typed langauges have a useful niche, but that niche > > does not encompass all of programming). > Which? > > I could state that Smalltalk has a useful niche (that doesn't encompass > all of programming), but I don't want throw mud back. > ... > I have heard several indicators that Smalltalk is very good at getting > stuff done, in the quickest possible time. I'm willing to believe this > (sounds reasonable anyway), but nobody talks about the disadvantages in > the approach. Those who know Smalltalk program in it, so they won't tell > me - and I can't believe there are none. > I don't want to be converted to Smalltalk. I want to know about advantages > and disadvantages, so that I can decide which language is better for a > given task. As a person who is developing with Smalltalk extensively I see so many advantages, it is like working in another dimension. Development and debugging (which I don't need to do much of debugging) becomes a joy, rather than a burden. Disadvantages? Many. First, it was not easy to come to this point. I had to spend about a year, and if I wasn't assigned to a project I wouldn't have done it, because I didn't see a need to switch from C++ I was enjoying. For starters, most Smalltalks and their tools are ridiculously expensive. This is equivalent for the vendors to shooting themselves in the foot, at the same time hitting us with the richocet. Second, it requires changes in the overall approach. For the first year, my methods looked rather like C++ ones. Only after than I was able to slowly embrace the entire notion and apply it. I am still sometimes amazed with certain things I can do which I call "sickeningly simple" solutions. Third, the darn class library. It takes a lot of time to digest it. Fourth, people say absence of MI is not a problem, but it is not true. Just look at the Streams class hierarchy and implemetation, soreness of absence of MI is clear. Fifth: as I mentioned in the type checking discussion, dynamic typing has so many advantages, but also disadvantages. Sixth: Lack of standardized class libraries between implementations, especially in the GUI part. Luckily now there are graphical frameworks such as GF/ST which give good portability between Smalltalks Seventh: The difficulty of felivering an application (stripping, packaging, etc), which now we have good but absurdly expensive Eighth: Performance. Actually this is a non-issue. I never suffered from performance apart from screen drawing, or number crunching. In some complex applications I was able to beat C++ applications. You can browse some issues with Smalltalk at http://www.rase.com/oodebate/choices.htm. So how do I live with these? I don't. In Smalltalk you have the power to correct things. The open system architecture allows you to do that. For instance, adding a simple MI by delegation took me two hours to implement. I use it sparingly, and more on the modeling side, but I have it when I need it. I have developed a tool with it which we will release shortly to fix most of Smalltalk's problems. The best thing in Smalltalk is you don't have to live with problems. You have the power to fix them. Except speed. For number crunching I use C. Apart from that I find Smalltalk more than adequate. > > Why would Chrysler hire Kent Beck to oversee the rewriting of their payroll > > system in Smalltalk? They could have chosen C++, Eiffel, Java or Ada95, or > > just stayed with COBOL. Why didn't they? Why choose Smalltalk, when there > > are so much fewer programmers than would be available for C++? Why choose > > Smalltalk, when there is such a wide-spread bias against dynamic typing? > > Maybe because they are manager? Not all decisions, even in large > companies, are based on rational arguments. There is trust in consultants > involved, who aren't always impartial. There is also much internal > backstabbing involved - sometimes managers influence other managers into > bad decisions, to weaken their internal position. > > Not that I'm convinced this is the case with the companies that you listed > as examples. It's just that such success stories don't prove a thing. It > would be much more interesting to hear about the consequences of these > decisions, not about the decisions themselves. Why don't you come to Smalltalk Solutions 97? You may see many examples. It is in NY at Marriot Marquis between March 10-13. > > Why has the use of Smalltalk been growing at 60% per year? In spite of the > > absence of any Java-style marketing campain? > > Maybe because two companies happened to decide for Smalltalk, which makes > a huge difference if the installed base is small. > I'm sure any proponent for any other language can make up similarly > impressing figures. > That 60% figure is worthless - you don't say wether it's number of > companies, number of developer seats, number of productive systems, or > lines of code. You don't even say since when this growth started - it > might be 1 1/2 year as well as twenty years. This is not true. Smalltalk base is growing very strongly especially in organizations such as banks. Most organizations come to a point where maintaining the existing system becomes such a burden, they have to change to a new system. What language will they choose for the new system? Cobol? In some cases yes. Now there are quite different looking languages, so called "Object oriented Cobol" in workstations. However these are the minority. I read somewhere that 15% of banks chose Smalltalk as their new language, which worries me, because there are not that many Smalltalkers to develop and support these systems. I think the problem with Smalltalk is not that there are too little of it, on the contrary, with this speed, we don't have good people to support these systems. So much so, I get requests to set up the "Smalltalk School of NY", which I am considering. > > Smalltalk offers many times faster development times--and much greater > > robustness in the face of changing requirements. That's a strategic > > advantage, especially in businesses and industries (like securities trading) > > where time is not just money, but big, big money. > > I already knew this. I consider this an interesting property of Smalltalk, > but I'm not convinced Smalltalk is best for everything. And as far as I > know, Smalltalk can't be integrated into a multi-language environment (at > least not with a considerable amount of work, or with serious efficiency > problems), so I'm somewhat hesitant to recommend Smalltalk at all. No, there are Smalltalks and class libraries with extensive multi language support. I am internally using a tool that finds any string in the application, sorts, finds duplicates, and prompts for each of them to modify, without changing or recompiling code, the simplicity of that can literally make many people "sick". These things are so trivial in Smalltalk. > Regards, > -Joachim > > -- > Joachim Durchholz, Hans-Herold-Str. 25, D-91074 Herzogenaurach, GERMANY Kindest Regards 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-----------------------------