docs/HistoricalNotes/2001-02-06-TypeNotationDebateResp4.txt

   1 > But in fact, if you read the entire answer carefully, he came to the same
   2 > conclusion I do: that you have to go with familiar syntax over logical
   3 > syntax because familiarity is such a strong force:
   4 >       "However, familiarity is a strong force. To compare, in English, we
   5 live
   6 > more or less happily with the absurd rules for "to be" (am, are, is, been,
   7 > was, were, ...) and all attempts to simplify are treated with contempt or
   8 > (preferably) humor. It be a curious world and it always beed."
   9
  10 Although you have to remember that his situation was considerably
  11 different than ours.  He was in a position where he was designing a high
  12 level language that had to be COMPATIBLE with C.  Our language is such
  13 that a new person would have to learn the new, different, syntax
  14 anyways.  Making them learn about the type system does not seem like much
  15 of a stretch from learning the opcodes and how SSA form works, and how
  16 everything ties together...
  17
  18 > > Basically, my argument for this type construction system is that it is
  19 > > VERY simple to use and understand (although it IS different than C, it is
  20 > > very simple and straightforward, which C is NOT).  In fact, I would assert
  21 > > that most programmers TODAY do not understand pointers to member
  22 > > functions, and have to look up an example when they have to write them.
  23
  24 > Again, I don't disagree with this at all.  But to some extent this
  25 > particular problem is inherently difficult.  Your syntax for the above
  26 > example may be easier for you to read because this is the way you have been
  27 > thinking about it.  Honestly, I don't find it much easier than the C syntax.
  28 > In either case, I would have to look up an example to write pointers to
  29 > member functions.
  30
  31 I would argue that because the lexical structure of the language is self
  32 consistent, any person who spent a significant amount of time programming
  33 in LLVM directly would understand how to do it without looking it up in a
  34 manual.  The reason this does not work for C is because you rarely have to
  35 declare these pointers, and the syntax is inconsistent with the method
  36 declaration and calling syntax.
  37
  38 > But pointers to member functions are nowhere near as common as arrays.
  39
  40 Very true.  If you're implementing an object oriented language, however,
  41 remember that you have to do all the pointer to member function stuff
  42 yourself.... so everytime you invoke a virtual method one is involved
  43 (instead of having C++ hide it for you behind "syntactic sugar").
  44
  45 > And the old array syntax:
  46 >       type [ int, int, ...]
  47 > is just much more familiar and clear to people than anything new you
  48 > introduce, no matter how logical it is.
  49
  50 Erm... excuse me but how is this the "old array syntax"?  If you are
  51 arguing for consistency with C, you should be asking for 'type int []',
  52 which is significantly different than the above (beside the above
  53 introduces a new operator and duplicates information
  54 needlessly).  Basically what I am suggesting is exactly the above without
  55 the fluff.  So instead of:
  56
  57        type [ int, int, ...]
  58
  59 you use:
  60
  61        type [ int ]
  62
  63 > Introducing a new syntax that may
  64 > make function pointers easier but makes arrays much more difficult seems
  65 > very risky to me.
  66
  67 This is not about function pointers.  This is about consistency in the
  68 type system, and consistency with the rest of the language.  The point
  69 above does not make arrays any more difficult to use, and makes the
  70 structure of types much more obvious than the "c way".
  71
  72 > > In my opinion, it is critically important to have clear and concise type
  73 > > specifications, because types are going to be all over the programs.
  74 >
  75 > I absolutely agree.  But the question is, what is more clear and concise?
  76 > The syntax programmers are used to out of years of experience or a new
  77 > syntax that they have never seen that has a more logical structure.  I think
  78 > the answer is the former.  Sometimes, you have to give up a better idea
  79 > because you can't overcome sociological barriers to it.  Qwerty keyboards
  80 > and Windows are two classic examples of bad technology that are difficult to
  81 > root out.
  82
  83 Very true, but you seem to be advocating a completely different Type
  84 system than C has, in addition to it not offering the advantages of clear
  85 structure that the system I recommended does... so you seem to not have a
  86 problem with changing this, just with what I change it to.  :)
  87
  88 -Chris
  89