Posted by Oli Filth on 10/25/05 16:01

Andrew DeFaria wrote:
> Oli Filth wrote:
>
> >>> Sure, you should know what they do and what you're trying to achieve
> >>> by using them, but knowing whether it's xml_parser_create() or
> >>> XmlParserCreate() or xmlParserCreate() (or equally, whether it's
> >>> strstr($needle, $haystack) or strstr($haystack, $needle)) is nothing
> >>> but an exercise in trivia.
> >>
> >> No, to me it's a sign that you don't know the function well enough...
> >
> > I repeat my original point - where's the benefit in learning the
> > precise syntax for thousands of functions, especially custom functions
> > that may not be documented, or unfamiliar libraries?
>
> And I will repeat mine: What good is it *not *to be familar with the
> function call in question?

I'm not suggesting that one should try *not* to learn function syntax!
If you remember the syntax of all the functions you ever use, great!
The functions I use all the time, of course I know them off by heart by
force of habit.

However, I make no special effort to commit to memory
functions/functionality that I use once in a blue moon (e.g. in the
case of PHP, the rare occasion when I do need to use imagejpeg(), or
the optional arguments to preg_match_all()), because with a decent IDE
there's no need!


> And you shouldn't have thousands of functions! If you got that much then
> you should break things into smaller , more manageable pieces.

I was referring mainly to "built-in" functions, i.e. API functions.

But even user-written functions, it's hardly uncommon to have hundreds
of functions even in a relatively trivial application, is it? Yes, you
can encapsulate them by good use of OOP design, but ultimately there
are still hundreds of functions that have to be called at some point.


> > It doesn't make one a better programmer (in the sense of understanding
> > how to design and construct functional, elegant programs and code),
>
> Sure it does.

How?


> > and is error-prone (in the sense that you have to wait until run-time
> > to spot your mistakes that would otherwise have been picked up by
> > syntax highlighting, or wouldn't have been there in the first place
> > due to autocompletion).
>
> Who says that XEmacs, for example, doesn't do syntax highlighting?!?

Well, I wasn't referring to XEmacs when I wrote that, but I get the
impression from this thread that some people seem to write their code
in something little more advanced than Notepad ;)


> > Depends. Larger APIs ultimately afford you greater flexibility. You
> > probably couldn't shrink, for example, the Windows or Java APIs
> > without losing functionality and/or flexibility.
>
> How many applications do you write that actually use more than a handful
> of those APIs? And the Windows and Java APIs are not great examples of
> well engineered and well thought out APIs, IMHO...

Do you have an example of an API (non-trivial, such as for an entire
framework e.g. MFC or Swing) that you would call "well thought out",
out of curiosity?


> >> Well if you read the page you would see he write *all* of his
> >> applications in assembly...
> >
> > Yeah, I noticed that. IMO, that's a pointless waste of time, unless
> > he's doing it purely for the academic exercise. :)
>
> You would argue that writing things efficiently is a pointless waste of
> time. That speaks more about you than it does about me. Granted, I don't
> write tight assembly code for my apps but I sure know enough to
> appreciate somebody who does instead of calling his work pointless!

WOT, but...

Have you heard of the 80/20 rule (possibly the 90/10 rule)? The fact
that in most non-trivial applications, 80% of the execution time is
spent in 20% of the code, normally short data-intensive processing
loops, e.g. FFTs, low-level parsing, image-processing, etc. Sure,
optimise *those*, I agree; that wouldn't be pointless at all.

But optimising the other 80% of the code is a case of diminishing
returns; it simply won't make a worthwhile difference, because it's not
the rate-limiting bottleneck. Optimising, for instance, the GUI so that
it responds to a key-press 1 microsecond faster is of no benefit to
anyone (except perhaps in the case of low-level I/O hooks); no-one's
going to notice, and you'll probably have spent several hours in the
process.

Also, the fact that modern optimising compilers are, on the whole,
pretty good, means that the majority of your application binary won't
be any smaller or faster by writing the assembler yourself.

And the inordinate amount of time it would take to rewrite in assembler
what would be trivial code in C strikes me as grossly time-ineffective,
except in the case of the big bottle-necks (the 20%).

Not to mention that a whole application in pure assembler would be far
more error-prone, difficult to debug, difficult to maintain, difficult
to extend, and difficult to read as it affords no data abstraction -
the whole point of higher-level concepts such as data-types or OOP.

--
Oli

[Back to original message]