On 5/7/2012 11:56 PM, Julian Leviston wrote:
Naming poses no problem so long as you define things a bit. :P
Humans parsing documents without proper definitions are like coders
trying to read programming languages that have no comments
(pretty much all the source code I ever read unfortunately)
I think this is probably why (at least in my case), I tend to "think in
code" a lot more than "think in natural language" or "think in concepts".
like, a person is working with code, so they have this big pile of code
in-mind, and see it and think about its behavior, ...
because, yes, comments often are a bit sparse.
personally though, I think that the overuse of comments to describe what
code is doing is kind of pointless, as the person reading the code will
generally figure this one out easily enough on their own ("x=i;
//assign i to x", yes, I really needed to know this...).
comments are then more often useful to provide information about why
something is being done, or information about intended behavior or
functioning.
as well as describing things which "should be" the case, but aren't yet
(stuff which is not yet implemented, design problems or bugs, ...).
nevermind side-uses for things like:
putting in license agreements;
putting in documentation comments;
embedding commands for various kinds of tools (although, in many cases,
"magic macros" may make more sense, such as in C);
...
oddly, I suspect I may be a bit less brittle than some people when it
comes both to reading natural language, and reading code, especially
given how many long arguments about "pedantics A vs pedantics B" there
seem to be going around.
this is usually justified with claims like "programming is all about
being precise", even when it amounts to a big argument over things like
"whether or not X and Y are 'similar' despite being
not-functionally-equivalent due to some commonality in terms of the ways
they are used or in terms of the aesthetic properties of their interface
and similarity in terms of externally visible behavior", or "does
feature X if implemented as a library feature in language A still count
as X, when X would normally be implemented as a compiler-supported
feature in language B", ... (example, whether or not it is possible to
implement and use "dynamic typing" in C and C++ code).
and, also recently, an argument over "waterfall method" vs "agile
development", ...
nevermind the issue of "meaning depends on context" vs "meaning is built
on absolute truths".
I have usually been more on the "lax side" of "the externally visible
behavior is mostly what people actually care about" and "it doesn't
really matter if a feature is built-in to the compiler or a
library-provided feature, provided it works" (and, yes, I also just so
happen to believe that "meaning depends on context" as well, as well as
that the "waterfall method" is also "inherently broken", ...).
but, alas, better would be if there were a good way to avoid these sorts
of arguments altogether.
but alas...
J
On 08/05/2012, at 4:36 PM, David Barbour wrote:
On Mon, May 7, 2012 at 11:07 PM, Clinton Daniel
<[email protected] <mailto:[email protected]>> wrote:
The other side of that coin is burdening users with a bunch of new
terms to learn that don't link to existing human concepts and words.
"Click to save the document" is easier for a new user to grok than
"Flarg to flep the floggle" ;)
Seriously though, in the space of programming language design, there
is a trade-off in terms of quickly conveying a concept via reusing a
term, versus coining a new term to reduce the impedance mismatch that
occurs when the concept doesn't have exactly the same properties
as an
existing term.
Yeah. I've had trouble with this balance before. We need to
acknowledge the path dependence in human understanding.
My impression: it's connotation, more than denotation, that
interferes with human understanding.
"Naming is two-way: a strong name changes the meaning of a thing, and
a strong thing changes the meaning of a name." - Harrison Ainsworth
(@hxa7241)
Regards,
Dave
--
bringing s-words to a pen fight
_______________________________________________
fonc mailing list
[email protected] <mailto:[email protected]>
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
