People write Fergus Henderson: H> [...] H> The whole idea of letting you omit method definitions for methods with H> no default and having calls to such methods be run-time errors is IMHO H> exceedingly odd in a supposedly strongly typed language, and IMHO ought H> to be reconsidered in the next major revision of Haskell. Jon.Fairbairn@cl.cam.ac.uk: F> I agree too, but being able to omit method definitions is F> sometimes useful -- would it be possible to make calls to F> those methods a /static/ error? I suspect this would be hard F> to do. I am not a specialist and can mistake and confuse things, but I wonder whether a notion of a strongly typed language is so scientifically important. The same is with the `compile-time' and `run-time' separation. There is no scientific reason why all computations with types and type resolution should preceed all computations with non-types. Very often the types need to behave like ordinary data. Would it be reasonable to avoid as possible the restriction of strong typing in language specification? The essence of compiling is to spend once an effort to reorganize some piece of data P into P' in order to reuse P' many times and win performance. For a program PP introducing P1 ... P100, why all compilations P1 -> P1' ... P100 -> P100' should preceed all usages of P1' ... P100' ? ----------------- Serge Mechveliani mechvel@botik.ru
"S.D.Mechveliani" wrote:
I am not a specialist and can mistake and confuse things, but I wonder whether a notion of a strongly typed language is so scientifically important. The same is with the `compile-time' and `run-time' separation. There is no scientific reason why all computations with types and type resolution should preceed all computations with non-types. Very often the types need to behave like ordinary data. Would it be reasonable to avoid as possible the restriction of strong typing in language specification?
No scientific reason, but a strong engineering reason. The engineering idea is to test a design with all available tools before building it. That way there will be no disasters that could have been forseen. The computing equivalent of an engineering disaster is for a program to get a run-time error or to produce an incorrect result. If this outcome is acceptable, then the program probably wasn't important enough to be worth writing in the first place. --brian
Brian Boutel to Sergey Mechveliani:
There is no scientific reason why all computations with types and type resolution should preceed all computations with non-types.
No scientific reason, but a strong engineering reason.
The engineering idea is to test a design with all available tools before building it. That way there will be no disasters that could have been forseen. The computing equivalent of an engineering disaster is for a program to get a run-time error or to produce an incorrect result. If this outcome is acceptable, then the program probably wasn't important enough to be worth writing in the first place.
If an entity is sufficiently complex, there will be always a margin of error. Good if avoidable, but... Would you apply the same philosophy of "non-importance" of a possibly bugged result, to procreating children?... Jerzy Karczmarczuk Caen, France
Jerzy Karczmarczuk wrote:
Brian Boutel to Sergey Mechveliani:
There is no scientific reason why all computations with types and type resolution should preceed all computations with non-types.
No scientific reason, but a strong engineering reason.
The engineering idea is to test a design with all available tools before building it. That way there will be no disasters that could have been forseen. The computing equivalent of an engineering disaster is for a program to get a run-time error or to produce an incorrect result. If this outcome is acceptable, then the program probably wasn't important enough to be worth writing in the first place.
If an entity is sufficiently complex, there will be always a margin of error. Good if avoidable, but...
Would you apply the same philosophy of "non-importance" of a possibly bugged result, to procreating children?...
Comparing breeding children to programming is surely a little far-fetched. I always enjoyed programming, but not nearly as much as procreating ;-) Anyway, procreating children is not science, nor yet engineering. It must be art, where the concept of "bug" does not exist. --brian
Hello S.D.Mechveliani, Thursday, October 18, 2001, 3:10:43 PM, you wrote: SDM> I am not a specialist and can mistake and confuse things, but I SDM> wonder whether a notion of a strongly typed language is so SDM> scientifically important. SDM> The same is with the `compile-time' and `run-time' separation. Because by properly separating these concepts You can reason about the program and You can enforce (or ensure) some properties of program. This may be important in some critical areas of application of software where there is a need to have programs with some proven capabilities (time-space constraints, behavioral characteristics (i.e. unhandled dynamic dispatch methods in OOP and so on)).
From the other point of view, the goal of science is to _separate_and_study_ concepts ;-)
-- Best regards, hw mailto:hw@ksue.kharkov.ukrtel.net
participants (4)
-
Brian Boutel -
hw -
Jerzy Karczmarczuk -
S.D.Mechveliani