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.3 required=5.0 tests=BAYES_00,INVALID_MSGID 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: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public From: Graham Hughes Subject: Re: OO, C++, and something much better! Date: 1997/01/20 Message-ID: <5bvncj$gqg$1@A-abe.resnet.ucsb.edu>#1/1 X-Deja-AN: 211180525 sender: graham@resnet.ucsb.edu references: <32DF458F.4D5C@concentric.net> <32DF94DC.6FF8@watson.ibm.com> <32DFD972.37E4@concentric.net> <5bphq4$5js@mulga.cs.mu.OZ.AU> <32E05FAF.47BA@concentric.net> <5buodl$bci@boursy.news.erols.com> <32E2FEC7.2F7B@concentric.net> organization: UCSB newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object Date: 1997-01-20T00:00:00+00:00 List-Id: -----BEGIN PGP SIGNED MESSAGE----- Looks like it's time for someone to play Devil's Advocate... Alan Lovejoy writes: >But replace "PL/I" with "any statically-typed language," and then you >can see the truth: "because any statically-typed language sucks, is >why." (Actually, statically-typed langauges have a useful niche, but >that niche does not encompass all of programming). Depends on your point of view, I suppose. The thing that makes me most unhappy about Smalltalk, Python, Perl, and the whole gamut of dynamically typed OO languages is just that--they are dynamically typed. I prefer static typing. It's largely a matter of interface design and subtyping; inheritance as code reuse is fine and dandy, but I prefer to program to interface specs. Something like the Ada package system is close to ideal for me, where clearly defined operations on clearly defined types are possible (although I don't use Ada much for esthetic reasons). Subtyping allows me to reuse this code willy-nilly; stronger, it means I don't introduce new bugs elsewhere because I'm passing a rectangle instead of an integer, and some module deep down was expecting the addition to go as planned. The enforcability of this concept is what I like about static typing and dislike about dynamic typing. Dynamic typing and languages have their places, but I'd prefer to be able to guarantee that the assumptions I made about a type are verifiable. In Smalltalk, passing a Rectangle where the system expects an Integer results in a runtime error (depending on a number of circumstances, of course). This means I won't stumble over the bug until I, or more likely, my user, stumbles across this set of circumstances. Why allow for these types of bugs when they can be eliminated or at least reduced? >Ever heard of StrongTalk? It's Smalltalk with static typing. It was >a failure in the marketplace. I conclude that static typing succeeds >when marketed to those who believe in static typing, and that dynamic >typing succeeds when marketed to those who belieive in dynamic typing. >And dynamic typing also succeeds when marketed to people who want the >fastest development times, and have no religious axe to grind over the >issue. I conclude that _you_ have an axe to grind. I also conclude that one failure is not a statistically valid sample. I can claim that fully 100% of my development team prefers static typing, because _I_ am my development team. Come back with something done by a statistician (although finding an honest statistician is often like finding an honest lawyer... :-); isolated cases prove nothing. >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 acknoledge that Smalltalk has some advantages. Speed of development seems to be one. However, I will contest robustness. What about a system that throws a runtime error if you try to take the sin of a rectangle can be called robust? This sort of thing happens, even often; much better that the compiler check it than me, given that I'll probably overlook something subtle. If OO is about conceptual separation of code into independent modules, why should the modules be concerned about what somebody else gives them? Why should they manually check that the object is capable of the operations demanded when the compiler can? >Not in Java. Java won't let you send any message that the compiler doesn't >know will be valid. And there is no equivalant of #perform: (which sends >a message chosen at run time). And #perform: is a good thing? I can achieve a similar operation in C++ (not Java, though) with pointer-to-member-functions in a map<> or an array or something, and it's even typesafe, so I don't have to worry (too much) about some perverted piece of code messing with my mind. ... Unlike yourself, I have no qualms about others using dynamic typing. Please, go ahead; if the advantages of it outweigh the disadvantages for your projects, by all means use Smalltalk. I use Python, a dynamically typed OO language, for much of my scripting because it's far easier to get a prototype working. For larger projects, particularly ones that I cannot hold entirely inside my head, I prefer a statically typed language for the reasons above. But don't you _dare_ try to enforce your preferences upon me. - -- Graham Hughes (graham.hughes@resnet.ucsb.edu) http://A-abe.resnet.ucsb.edu/~graham/ -- MIME & PGP mail OK. "Never attribute to malice that which can be adequately explained by stupidity." -- Hanlon's Razor -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMuNgxSqNPSINiVE5AQGPPQP9GAKSt5brXZthxoc+lt+as85mcxF0qHli cmf8IGmyy39YKATvzP4HkakkxwbBY11kZoPoG4eJCSQ3uCw0X+8F6y/7AuwjXpr/ CQSlTQcSACggTqRD39rGEl39rxGvS7nA2tZhXnaSYkFsQ9bM/I3fJJCypegy5CiM qB7L27Mj0HU= =tcuJ -----END PGP SIGNATURE-----