BGB wrote:
On 3/13/2012 4:37 PM, Julian Leviston wrote:
I'll take Dave's point that penetration matters, and at the same time,
most "new ideas" have "old idea" constituents, so you can easily find
some matter for people stuck in the old methodologies and thinking to
relate to when building your "new stuff" ;-)
well, it is like using alternate syntax designs (say, not a C-style
"curly brace" syntax).
one can do so, but is it worth it?
in such a case, the syntax is no longer what most programmers are
familiar or comfortable with, and it is more effort to convert code
to/from the language, ...
Alternate syntaxes are not always as awkward as you seem to think they
are, especially the specialized ones. The trick is to ask yourself how
you would have written such an such piece of program if there were no
pesky parser to satisfy. Or how you would have written a complete spec
in the comments. Then you write the parser which accepts such input.
My point is, new syntax don't always have to be unfamiliar.
For instance:
+---+---+---+---+---+---+---+
| 0 | 2 | 3 | 4 | 5 | 6 | 7 |
+---+---+---+---+---+---+---+
| foo | bar |
+-----------+---------------+
| baz |
+---------------------------+
It should be obvious to anyone who has read an RFC (or a STEPS progress
report) that it describes a bit field (16 bits large, with 3 fields).
And those who didn't should have learned this syntax by now.
Now the only question left is, is it worth the trouble _implementing_
the syntax? Considering that code is more often read than written,
I'd say it often is. Even if the code that parses the syntax isn't
crystal clear, what the syntax should mean is.
You could also play the human compiler: use the better syntax in the
comments, and implement a translation of it in code just below. But
then you have to manually make sure they are synchronized. Comments
are good. Needing them is bad.
Loup.
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
