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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,99222a5bd46ef3c9 X-Google-Attributes: gid103376,public From: Karel Th�nissen Subject: Re: Featuritis not always bad (was re: GOTO considered necessary) Date: 1997/06/26 Message-ID: <33B2E285.7344@hello.nl> X-Deja-AN: 252810301 References: <5nn2fm$11dk$1@prime.imagin.net> <199706121410.QAA05823@basement.replay.com> <33A0840B.1B41@sprintmail.com> <33A58C79.1C7A@sprintmail.com> <33A8DB59.776F@hello.nl> <33AE29D6.7258@sprintmail.com> <33B0673C.6C76@hello.nl> Organization: Hello Technologies, Netherlands Newsgroups: comp.lang.ada Date: 1997-06-26T00:00:00+00:00 List-Id: Robert Dewar wrote: > > < 1) is well designed and well behaved, so no tail biting > 2) comes as a independant feature, so that people can work with the rest > of the language without ever knowing that the feature existed. This > ensures that people can write in the language safely if they have not > finished the full language course: avoid steep learning curve and memory > load. > 3) comes as a clearly recognisable syntactic entity in the language. So > if one reads the code and is not familiar with the feature one at least > knows that there is a cognitive problem, and knows where to look in the > reference manual (and find there many useful informations on the feature > that would find no place if the feature was to be simulated with lower > level constructs) > ?? > > This is *precisely what I disagree with. The trouble is that you don't > know you don't need to know something until you know it, The tutorial might tell you. Why not tell the language users what parts of the language can be safely skipped until later. Also tell them for what kind of problems these parts of the language are appropriate. > and then it's too late! Yes, then it is too late, but then what? Maybe a frustrating experience that you could have coded the problem more easily or more safely, but the programs you had written up to then, work exaclty as expected with the more limited understanding of the code that you had. Let me give two examples: Ada's exception and tasking mechanisms. These satisfy the three criteria I gave more or less. Regarding my first criterion, they are well designed, there are no nasty quirks that do not stem from the very nature of exception handling and tasking (unlike exception handling in PL/I which had a rotten design). Regarding my second criterion, anyone not having read the part of the manual on exceptions can use the rest of the Ada-language without problem. Okay you miss the comfort of the mechanism, but what rests is a language with the power of say Pascal. Anyone coming from Pascal would not notice any important semantic difference between Pascal and an Ada without exceptions, because errors in the programs crash the system, as exspected. Same for tasking, if you do not use it, you never have to worry about it. The model of an Ada without exceptions and tasking is the same as that of an Ada with these facilities available but left unused. So one can use Ada safely without exceptions and tasks in the sense that the program operates as expected. Regarding my third criterion, anyone not completly familiar with Ada (say with a level of knowledge of Ada that covers the features provided by Pascal) would instantly spot the presence of a task definition, because there is nothing like it in the language model that s/he had seen until then. S/he can see there is something special because of the unfamiliar reserved (bold or capitalized) word 'TASK'. The best place to fill up insufficient knowledge is in the manual under 'TASK'. Compare that with a language where tasking is 'emulated' with platform dependant procedure calls and where the intricacies of the tasking are burried in procedure calls that look like normal procedure calls, but that have lots of special semantics. The risks of misreading are severe, even it uses concepts that he was supposed to understand. The manual cannot provide much help, because the tasking is handled in a platform dependant way that is outside the scope of the language. Moreover, there is not a keyword to search for in the index. Exceptions however, do not comply with this third requirement. They are declared as any other object. Nothing to warn you there. Then there is the 'raise', which looks (if not in bold) like an ordinary procedure invocation.... To the list I should have added a fourth clause that the user should not be allowed to accidently run into the feature. Sufficient syntactic difference between the 'optional' feature and the rest of the language can guarantee that. With tasking the risk is negligible, there just is no language feature that, because of some reasonable error on the programmer's side, could accidently form a task definition. With exceptions the risk is bigger, but permissible. The programmer might accidently try to define a type called 'exception' or a procedure called 'raise', but the compiler should catch that, as it is forbidden to redefine these identifiers. Leaves the risk that the user planned to define either a type called 'exception' or a procedure called 'raise', and uses it, but has forgotten to give his/her own definitions. Still then, more things must go wrong, to have the compiler swallow this as an correct invocation of the Ada exception mechanism: both the type called 'exception' and the procedure called 'raise' should be planned, their definitions forgotten, and used with an exception object as the argument of the procedure 'raise'. The compiler will still catch it because of the forbidden parentheses with the raise, but it leaves the programmer confused as compiler error messages or not clear. Having said this, I do not want to imply that FSM's are a candidate for incorporation. > Yes, of coruse it is the case that adding features to a language, and > thus increasing the complexity of the language may easily be counterbalanced > by the resulting simplification in programs. That's exactly the tradeoff > that needs to be considered. I know that this was a consideration in the design of Ada, whereas often more academic languages look for compiler, language or definition report simplicity. Groeten, Karel