[Haskell-cafe] Re: Allowing hyphens in identifiers
ok at cs.otago.ac.nz
Sun Dec 13 19:44:16 EST 2009
On Dec 13, 2009, at 3:44 AM, Daniel Fischer wrote:
> Am Freitag 11 Dezember 2009 01:20:55 schrieb Richard O'Keefe:
>> On Dec 11, 2009, at 3:00 AM, Daniel Fischer wrote:
>>> Am Mittwoch 09 Dezember 2009 23:54:22 schrieb Richard O'Keefe:
>>>> Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that
>>>> went into Haskell forNoApparentReasonThatIHaveEverHeardOf,
>>> mb_t's_bcs the ndrscr_stl is considered far uglier and less readable
>>> by others
>> Come ON. Argue honestly!
> Thanks, but I have to return that compliment.
Not a bit of it. "mb_t's_bcs the ndrscr_stl" was NOT playing
fair and you knew it.
> I claim that the part not using insanely abbreviated words
> (isConsidered, farUglier,
> byOthers) *is* readable.
> Also that moderately abbreviated words are readable in camelCase as
> well as under_score.
I guess we must mean different things by "readable" then.
I've approached my head of department about running an experiment.
>>> underscore-style with nonabbreviated words is not unreadable, but
>>> still extremely ugly)?
>> Who "grants" that underscore separation with fully written words is
>> "still extremely ugly"? Not me!
> Is that remark really unclear,
Yes, it is really unclear. It read as "x (granted that y)".
For clarity, it should have been "(still extremely ugly, granted that
underscore-style with nonabbreviated words is not unreadable)".
> Nobody *grants* anything is ugly or not, that is an aesthetic
> judgment, as such entirely a
> matter of personal preference - you can agree with it or not.
Where is it written that aesthetic judgements are _entirely_ a
matter of personal preference?
As a student I was in the Archaeological society.
One of the things I learned was this:
- many ancient cultures would ritually "kill" grave goods
- some grave goods would be smashed up, others would just
have a chip out of them
- as a rule, the ones that were least damaged were the ones
the archaeologists considered to be the most beautiful (after
If an aesthetic sense about pots can be shared by modern archaeologists
and people living five thousand years ago, it's hardly "entirely
What you may not appreciate is that I have been a Smalltalk programmer
for a long time. I've read and written a lot of code like
(self sendSolutionsUsing: Empty and: Empty to: [:p :n |
Transcript nextPutAll: 'p = '; print: p;
nextPutAll: ', n = '; print: n; nextPut: $.; cr.
true "stop after reporting first solution"]
) ifFalse: [
Transcript nextPutAll: 'No solutions.'; cr].
If it were just a matter of experience, then this experience should
surely have taught me to love baStudlyCaps.
>> I have not been able to discover an experimental study of word
>> separation style effect on readability in programming. I've been
>> wondering about running a small one myself, next year. But there
>> is enough experimentally determined about reading in general to
>> be certain that visible gaps between words materially improves
>> readability, and internal capital letters harm it. Now that
>> applies to ordinary text, but until there's evidence to show that
>> it doesn't apply to program sources, it's a reasonable working
>> assumption that it does.
> I doubt that.
Until the evidence is in, what other reasonable working
assumption is there?
> Sourcecode is so different from ordinary text (a line of sourcecode
> contains more than four or five words),
OK, let's try it. Shakespeare sonnet number 1,
first four lines, but split into shorter chunks
From fairest creatures
we desire increase,
beauty's rose might never die,
But as the riper should
by time decease,
His tender heir
might bear his memory:
But as the_riper should
But as theRiper should
baStudlyCaps doesn't read any better with short lines.
> that I'd be very wary to transfer the findings for
> one to the other.
It's not uncommon for style guides to explicitly
recommend that program code should be spaced like text.
Apple notoriously violate this in Objective C.
Where Smalltalk would have
this sendSolutionsUsing: Empty and: Empty to: that
Objective C practice is to write
[this sendSolutionsUsing:Empty and:Empty to:that]
> If somebody claimed that of
> x <- take_while some_condition some_list
> x <- takeWhile someCondition someList
> either was objectively more readable than the other, I wouldn't
> believe it without lots and lots of hard evidence.
"Persaude a man against his will, he's of the same opinion still."
How _much_ evidence?
That's an artificial example. Haskell code doesn't tend to look
like that. It's much more likely to be a choice between
x' <- takeWhile p x
and x' <- take_while p x
I'll repeat the run length figures I previously posted today,
but this time as percentages
> for me the underscores push the
> space-separated parts together, so that I have the tendency to
> bracket it
> x <- take (while some) (condition some) list
Such lines are rare.
In my sample (very little of which was my own),
under 14% of (lines having at least one identifier)
had two or more internal capitals.
Let's look at the number of internal capitals per run:
0 99324 79%
1 20761 16%
2 4100 3%
3 791 3..10 all have under 1% each;
4 221 the sum is 2%
takeWhile someCondition someList has three internal
capitals, so it's one of just the 5% of lines with three or more.
Let's try a more specific question:
what proportions of runs have the pattern
aB cD eF?
44 out of 125295, or 0.00035.
You're asking me to sacrifice readability everywhere else
for the sake of one line in every 2850? (Not that I do
find that line more readable in basStudlyCaps.)
In any case, I think it's just possible that the point of the
thread may have been lost, which is that it is possible and
practical to let *both* the people who like to read and write
baStudlyCaps *and* the people who don't see what they find
readable *without* impairing readability for the others.
takeWhile can be automatically converted to take_while
for viewing and editing.
take_while can be automatically converted to takeWhile
for viewing and editing.
All without confusion except when both styles are used
I for one never suggested that baStudlyCappers should
stop doing their thing and do my thing; I just don't want
them inflicting it on me (and others like me).
I quite see the justice of the argument running the other
way, and I *don't* advocate baStudlyCappers being made
to read and write readable_identifiers and (at least in
this thread) never did.
More information about the Haskell-Cafe