Re: Strategic Functional Migration and Multiple Inheritance

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Shawnk <Shawnk@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
I have to say, I think that's a very silly way of measuring complexity.
Would C# be a "simpler" language by making all the keywords single
letters? I don't believe so. It *certainly* wouldn't be a more readable
language.

The complexity I'm talking about is how hard it is to think about the
object model, and I believe that MI makes the model more potentially
complicated.

:-)

'Character count' means to add up all the characters in a set of expressions.

And that's exactly what I think is a bad idea.

<snip>

The solution with the least character count is (by definition) a more
powerful, effective, efficient and eloquent design.

That may be by *your* definition, but I certainly wouldn't define it
that way.

1) Efficient code isn't always brief.
2) Powerful code isn't always brief.
3) Eloquent code isn't always brief - often code becomes longer but
easier to understand when a single long statement is broken into
several short ones, for instance. That may introduce extra variables
solely for the purpose of making the code readable.

I have to say, I think that's a very silly way of measuring complexity.

To nit pick logical token count is better that a raw character
count since use of LLP (Low Level Patterns) would express 'Fx x;'
as 'Fx l_Fx_ins' or 'Fx l_fx;'. The logical point (character count/
token count) of a valid and meaningful metric is the point I was making.

Again, I don't think that token count is a good metric. For instance,
you could easily have a language which has a single token for "declare
first integer variable for the class" and another for "declare second
integer variable for the class", potentially reusing those tokens for
accessing the variables when in an appropriate context. By making
tokens mean different things in different contexts, you can end up
requiring fewer available tokens overall *and* fewer tokens for a
specific piece of code.

That doesn't make it a simpler language, or the code simpler - or more
eloquent.

To give another information-theory example: I believe that if we used
"3" as a number base, that would give the "best" integer base number
system in terms of compact information with a small number of tokens.
However, ask real *people* to use base 3 and they'll start screaming.
People aren't information theory - they're people.

If you cant' define a concise terminology (qualification) with
a matching metric set (quantification) into a coherent substrate
for logical thought then the resulting syntactic expressions,
used as examples to prove your point are 'pointless'.

I'm not trying to argue this in metrics of information theory, because
I don't believe such metrics give a good idea of the readability of
code. I believe it's to a large extent dependent on the reader, and
that what may be the most readable code for one intended audience may
well not be the most readable code for another audience. For instance,
code to manipulate a string with a regular expression may be absolutely
great for people who use regular expressions day-in-day-out, but could
be much harder than a short series of simple string operations for
other people.

I must apologize has I thought my reference to 'information theory'
would have made the 'character count' metric clear. Hopefully the
brief dissertation above clarifies what I mean in terms of metrics,
their utility and the general coherence of terminology as a logical
substrate for syntactic expressions.

We apparently still disagree about the usefulness of the metric,
however.

I also note, in passing, that those who use good terminology/metrics
are trying to move (however effectively/ineffectively) away from
opinion towards scientific fact. As you and I both agree our
individual opinions are immaterial relative to the actual science of
logical expression.

No - I believe opinions are very important, and far more important than
arbitrary metrics such as character or even token counts. One could
construct a language which from a purely theoretical point of view was
absolutely beautiful - but which was terrible to actually use. I'd far
rather have a language which mere mortals like myself can use and
understand what any single line of code is going to do, preferrably
without having to look it up in a spec due to complicated rules.

--
Jon Skeet - <skeet@xxxxxxxxx>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
.

Relevant Pages

  • Re: curve for verbosity in a language
    ... > Your notion of verbosity does not agree with any widely used definition I ... > Here I count 15 tokens and 3 lines. ... > The token counts differ by 17% and the line counts differ by 67%. ... > biased metrics quite revolting. ...
    (comp.programming)
  • Re: curve for verbosity in a language
    ... Your notion of verbosity does not agree with any widely used definition I ... Here I count 15 tokens and 3 lines. ... The token counts differ by 17% and the line counts differ by 67%. ... biased metrics quite revolting. ...
    (comp.programming)
  • Re: Case sensitivity in programming languages.
    ... have worked for many years with case insensitive software then encounter ... Thats why is most every language today case sensitive and no one ... case-insensitive languages are the only ones who see that case sensitivity ... if the grammer requires certain tokens to be of ...
    (comp.lang.php)
  • Re: Comparing languages
    ... language between frequency and irregularity that shouldn't necessarily ... nothing to justify the following statement about "ease of learning" ... > of tokens that you don't know. ... than learning the shorter string 94706215, and if you didn't know what ...
    (sci.lang)
  • Re: Anyone use ELSE minor-mode in Emacs?
    ... Emacs minor mode authors by Emacs expansion conventions - I use F3 ... If you stick with just the "tokens" at first, ... have to browse the individual language file to see what strings are defined ...
    (comp.lang.python)