llvm/docs/HistoricalNotes/2001-02-06-TypeNotationDebateResp4.txt - llvm-project - Git at Google

 > But in fact, if you read the entire answer carefully, he came to the same
 > conclusion I do: that you have to go with familiar syntax over logical
 > syntax because familiarity is such a strong force:
 >       "However, familiarity is a strong force. To compare, in English, we
 live
 > more or less happily with the absurd rules for "to be" (am, are, is, been,
 > was, were, ...) and all attempts to simplify are treated with contempt or
 > (preferably) humor. It be a curious world and it always beed."

 Although you have to remember that his situation was considerably
 different than ours.  He was in a position where he was designing a high
 level language that had to be COMPATIBLE with C.  Our language is such
 that a new person would have to learn the new, different, syntax
 anyways.  Making them learn about the type system does not seem like much
 of a stretch from learning the opcodes and how SSA form works, and how
 everything ties together...

 > > Basically, my argument for this type construction system is that it is
 > > VERY simple to use and understand (although it IS different than C, it is
 > > very simple and straightforward, which C is NOT).  In fact, I would assert
 > > that most programmers TODAY do not understand pointers to member
 > > functions, and have to look up an example when they have to write them.

 > Again, I don't disagree with this at all.  But to some extent this
 > particular problem is inherently difficult.  Your syntax for the above
 > example may be easier for you to read because this is the way you have been
 > thinking about it.  Honestly, I don't find it much easier than the C syntax.
 > In either case, I would have to look up an example to write pointers to
 > member functions.

 I would argue that because the lexical structure of the language is self
 consistent, any person who spent a significant amount of time programming
 in LLVM directly would understand how to do it without looking it up in a
 manual.  The reason this does not work for C is because you rarely have to
 declare these pointers, and the syntax is inconsistent with the method
 declaration and calling syntax.

 > But pointers to member functions are nowhere near as common as arrays.

 Very true.  If you're implementing an object oriented language, however,
 remember that you have to do all the pointer to member function stuff
 yourself.... so every time you invoke a virtual method one is involved
 (instead of having C++ hide it for you behind "syntactic sugar").

 > And the old array syntax:
 >       type [ int, int, ...]
 > is just much more familiar and clear to people than anything new you
 > introduce, no matter how logical it is.

 Erm... excuse me but how is this the "old array syntax"?  If you are
 arguing for consistency with C, you should be asking for 'type int []',
 which is significantly different than the above (beside the above
 introduces a new operator and duplicates information
 needlessly).  Basically what I am suggesting is exactly the above without
 the fluff.  So instead of:

        type [ int, int, ...]

 you use:

        type [ int ]

 > Introducing a new syntax that may
 > make function pointers easier but makes arrays much more difficult seems
 > very risky to me.

 This is not about function pointers.  This is about consistency in the
 type system, and consistency with the rest of the language.  The point
 above does not make arrays any more difficult to use, and makes the
 structure of types much more obvious than the "c way".

 > > In my opinion, it is critically important to have clear and concise type
 > > specifications, because types are going to be all over the programs.
 >
 > I absolutely agree.  But the question is, what is more clear and concise?
 > The syntax programmers are used to out of years of experience or a new
 > syntax that they have never seen that has a more logical structure.  I think
 > the answer is the former.  Sometimes, you have to give up a better idea
 > because you can't overcome sociological barriers to it.  Qwerty keyboards
 > and Windows are two classic examples of bad technology that are difficult to
 > root out.

 Very true, but you seem to be advocating a completely different Type
 system than C has, in addition to it not offering the advantages of clear
 structure that the system I recommended does... so you seem to not have a
 problem with changing this, just with what I change it to.  :)

 -Chris
	> But in fact, if you read the entire answer carefully, he came to the same
	> conclusion I do: that you have to go with familiar syntax over logical
	> syntax because familiarity is such a strong force:
	> "However, familiarity is a strong force. To compare, in English, we
	live
	> more or less happily with the absurd rules for "to be" (am, are, is, been,
	> was, were, ...) and all attempts to simplify are treated with contempt or
	> (preferably) humor. It be a curious world and it always beed."

	Although you have to remember that his situation was considerably
	different than ours. He was in a position where he was designing a high
	level language that had to be COMPATIBLE with C. Our language is such
	that a new person would have to learn the new, different, syntax
	anyways. Making them learn about the type system does not seem like much
	of a stretch from learning the opcodes and how SSA form works, and how
	everything ties together...

	> > Basically, my argument for this type construction system is that it is
	> > VERY simple to use and understand (although it IS different than C, it is
	> > very simple and straightforward, which C is NOT). In fact, I would assert
	> > that most programmers TODAY do not understand pointers to member
	> > functions, and have to look up an example when they have to write them.

	> Again, I don't disagree with this at all. But to some extent this
	> particular problem is inherently difficult. Your syntax for the above
	> example may be easier for you to read because this is the way you have been
	> thinking about it. Honestly, I don't find it much easier than the C syntax.
	> In either case, I would have to look up an example to write pointers to
	> member functions.

	I would argue that because the lexical structure of the language is self
	consistent, any person who spent a significant amount of time programming
	in LLVM directly would understand how to do it without looking it up in a
	manual. The reason this does not work for C is because you rarely have to
	declare these pointers, and the syntax is inconsistent with the method
	declaration and calling syntax.

	> But pointers to member functions are nowhere near as common as arrays.

	Very true. If you're implementing an object oriented language, however,
	remember that you have to do all the pointer to member function stuff
	yourself.... so every time you invoke a virtual method one is involved
	(instead of having C++ hide it for you behind "syntactic sugar").

	> And the old array syntax:
	> type [ int, int, ...]
	> is just much more familiar and clear to people than anything new you
	> introduce, no matter how logical it is.

	Erm... excuse me but how is this the "old array syntax"? If you are
	arguing for consistency with C, you should be asking for 'type int []',
	which is significantly different than the above (beside the above
	introduces a new operator and duplicates information
	needlessly). Basically what I am suggesting is exactly the above without
	the fluff. So instead of:

	type [ int, int, ...]

	you use:

	type [ int ]

	> Introducing a new syntax that may
	> make function pointers easier but makes arrays much more difficult seems
	> very risky to me.

	This is not about function pointers. This is about consistency in the
	type system, and consistency with the rest of the language. The point
	above does not make arrays any more difficult to use, and makes the
	structure of types much more obvious than the "c way".

	> > In my opinion, it is critically important to have clear and concise type
	> > specifications, because types are going to be all over the programs.
	>
	> I absolutely agree. But the question is, what is more clear and concise?
	> The syntax programmers are used to out of years of experience or a new
	> syntax that they have never seen that has a more logical structure. I think
	> the answer is the former. Sometimes, you have to give up a better idea
	> because you can't overcome sociological barriers to it. Qwerty keyboards
	> and Windows are two classic examples of bad technology that are difficult to
	> root out.

	Very true, but you seem to be advocating a completely different Type
	system than C has, in addition to it not offering the advantages of clear
	structure that the system I recommended does... so you seem to not have a
	problem with changing this, just with what I change it to. :)

	-Chris