[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Software fault forces Ford recall



Isn't the answer even simpler?

occam isn't C.

For some strange reason, people like this idiosyncratic write-only
language.

Chris Jones.


In message <3A3CA6F0.8CFB7704@xxxxxxxxxxxxx>, A E Lawrence <adrian.lawre
nce@xxxxxxxxxxxxx> writes
>Mark Booth wrote:
>>
>> Almost everyone I know that dislikes Occam says that syntax is
>their
>> biggest problem with it. All of that LOUD text and the fact that
>> indentation is a big part of the syntax. The other thing most
>people
>> hated at University was being forced to use a folding editor.
>> 
>> Now while I have always liked these aspects of Occam, I have
>felt for a
>> long time that what Occam really needed was a C like syntax.
>With a few
>> changes to the syntax I feel that Occam 3 rebranded as something
>like
>> Par-C could actually make some headway out of academia.
>
>This old thorny chestnut does seem to divide the world into two camps.
>Fanatics, like me (us?), who *love* these aspects, and the majority who
>hate them, On enquiry, members of the latter have seldom
>taken more than a superficial look before rejecting the ideas.
>
>But how do we account for this? Maybe
>
>1) Upper case
>   ~~~~~~~~~~
>
>An excellent way to pick out the key words of the language with almost
>no chance of the user wanting to use use them for other purposes. Clear,
>simple good software engineering.
>
>Why do people object? Speculation:
>
>a) Association with childhood, and using capitals before learning
>"joined up" writing?
>b) Association with BASIC, regarded as primitive.
>
>Both of which seem pretty childish in their own way. 
>
>2) Indentation
>   ~~~~~~~~~~~
>
>By far the most economical and clean way to include necessary
>delimitors.
>
>Used in other languages like Python, of course.
>
>Here the objections are more obvious:-
>
>a) Without folding or a suitable pretty printer (with explicit
>annotation for fold boundaries) simply impractical for large sections of
>code. Mind you, the same is true for indented curly brackets in C-like
>languages which is why editors usually have special facilities to handle
>them.
>
>b) Standard tools, particularly unix tools, don't understand the
>semantics of the different sorts of white space. And most importantly,
>things like emacs cannot fold properly. [Aside: Jamie Packer wrote
>folding macros for emacs decades ago, but it was unable to cope with
>indented *folds*. Does anyone know if those limitations of emacs have
>been lifted?]
>
>3) Folding
>   ~~~~~~~
>
>I fail to understand how anyone who has used folding would ever wish to
>do anything else. I use it for almost all languages.
>
>Used in things like Mathematica without drawing flack. Why not? Maybe
>because objection (a) below does not apply in the Mathematica largely
>closed environment.
>
>Objections:-
>
>a) Can't use things like emacs. A really major objection and why I still
>write unfolded text for some purposes. This is a killer.....
>
>b) The folding editors that are available are far inferior to emacs in
>capability. No I haven't tried all of them, so perhaps there are
>exceptions.
>
>c) Standard tools mess up: see (b) under indentation above.
>
>d) I have actually heard people object to folding because they "can't
>see all the code at once", but rather have to [ENTER]and [EXIT]! Given
>[OPEN] and [CLOSE], this is simply wrong, but even so they must have
>extraordinarily long screens. 
>
>
>Last objection:
>~~~~~~~~~~~~~~
>
>Applies to all of the above: it's different! 
>
>Is this diagnosis correct? Have I missed anything significant? Should we
>not make these objections explicit when introducing people to decent
>syntax :-) Seriously, it is worth trying to uncover the real reasons for
>prejudice and exposing the superficiality and shallowness if only to get
>an objective view.
>
>Of course a pre-processor is the simple answer to translate between a
>vile C-like syntax and sanity, so people can pick and choose. They can
>have all their silly clutter of spaghetti code full of curly brackets on
>a 20m listing if they really like it. Not to mention 350 #includes and
>trying to keep track of all the interactions between them, obscuring the
>structure which is so transparent and encouraged in a folded
>environment.
>
>
>Adrian

----------------------------------------------------------------------- 
      /\        Christopher C R Jones
     /  \       Technologist Consultant - Lightning, NEMP and CEM
    /|  |\      BAE SYSTEMS
   /\|  |/\     W423A
  /\ |  | /\    Warton Aerodrome     tel: 44 (0)1772 854625
 /__\|__|/__\   Preston              fax: 44 (0)1772 855262
/____________\  LANCS  PR4 1AX
     |  |       United Kingdom    e-mail: ccrj@xxxxxxxxxxxxxxxx
     |__|                               : chris.c.jones@xxxxxxxxxxxxxx
----------------------------------------------------------------------