On Tue, 2004-04-20 at 11:10, Thomas Beale wrote: > Tim Churches wrote: > > >On Fri, 2004-04-16 at 13:51, Thomas Beale wrote: > > > > > >>The way all > >>the Eiffel stuff works on every platform is simply bridge pattern all > >>over the place, plus platform specific binding libraries. > >> > >> > > > >Ah, yes. Gang of Four patterns are (largely) hacks required by static > >typing languages to work around their limitations... with dynamic typing > >in Ruby, Smalltalk, Python, (etc) most of the patterns are redundant (or > >at least, trivial to implement). > > > >Just joking...at least partially. > > > > > I can't resist one reply...take the following as the comments of an > unredeemed user of typed formalisms;-) > > when I originally started in real-time control systems (power stations, > gas pipelines etc) we wrote everything in C and assembler. Every so > often someone looked wistfully at Objective-C, Smalltalk and other OO > languages of the time (I wouldn't have minded using Simula actually...). > Smalltalk was of course the purest in approach, but we never touched it > because we knew that we would never be able to convince ourselves that > the system would behave properly when actually deployed, since we knew > that there was no compiler checking of types, which would have meant > being able to devise every possible test case covering situations where > messages were sent to the wrong object. I must admit I still have the > same worry about untyped languages today.
Let's use the term "strongly-but-dynamically typed" instead of the pejorative "weakly typed" for Python, Ruby, Smalltalk etc, even though "weakly typed" is more common. Firstly, if you send a message of the wrong type to a strongly-but-dynamically typed language like Python, it **does** raise an exception, but as you said, at runtime, not compile time. This is, as Bruce Eckel says, a "Faustian bargain" - most programmers, when using such languages, find they are trading off some compile-time checking for much greater programming productivity. The question is, is this bargain with the Devil a good one? Bruce Eckel argues, far more elegantly and authoritatively than I can, that it is a good bargain, because type errors are only a small class of possible (and common) errors, and you need to test for all the other types of errors anyway, whether you are using a statically strongly typed language like Java or Eiffel or not. See http://www.mindview.net/WebLog/log-0025 Let's take a hypothetical example. Let's say we are building a medication ordering verification system. Vincristine and methotrexate are two chemotherapy agents which are commonly used to treat leukaemia. Vincristine is given intravenously but methotrexate is often given intrathecally (into the cerebrospinal fluid) to kill leukaemic cells which have migrated there. The two drugs are often administered to the patient in the same chemotherapy session. Regrettably, a far from rare mistake is to administer the vincristine intrathecally instead of, or together with, the methotrexate - usually with fatal or devastating results. Often the mistake is in the written (or computerised) medication order - the doctor ordering it specifies "intrathecally" for the methotrexate but forgets to specify "intravenously only" for the vincristine. There are documented instances in which the order has been completely wrong (reversed): "vincristine intrathecally, methotrexate intravenously". Either way, an inexperienced nurse or junior doctor, working under pressure, is then asked to administer the drugs, follows the order to the letter and makes the terrible mistake. So how would compile-time static type checking help our medication ordering system to detect such an ordering mistake? You could define classes for the permissible routes of administration of each drug object, but that's only one way to categorise drugs (you would also want to consider drug interactions and also drug indications and contra-indications etc etc etc), so you would need multiple, very complex drug object class hierarchies and then make very extensive use of multiple inheritance in order to catch such errors at compile time. Given that new drugs are being added all the time, and indications etc for existing drugs are constantly changing, I suspect that you would need to re-compile such a system at least once a day to gain any benefit from compile-time checking of static typing. Maybe that's a contrived example, but I can't help agreeing with Bruce Eckel that real-world mistakes are often more complex or subtle than any static typing system will detect, and thus you need to write tests, tests and more tests anyway - sometimes build-time tests, but often run-time tests (checks), so why not use a language which let's you write such tests far more quickly? -- Tim C PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere or at http://members.optushome.com.au/tchur/pubkey.asc Key fingerprint = 8C22 BF76 33BA B3B5 1D5B EB37 7891 46A9 EAF9 93D0
signature.asc
Description: This is a digitally signed message part
