Re: What IDE are you using?

Oli Filth wrote:

> 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!

I didn't say syntax! You did.

> If you remember the syntax of all the functions you ever use, great!

Yup. And for the ones I don't remember I... guess what? Look it up.
Essentially this is no different than the fancy IDE. It's just the
manner in which the look up takes place that differs. In my world it's
generally a browser or recently just a PDF file. In such a mode it was
not just looking up the function syntax but reading the parameter
descriptions, return values and looking at code snippet examples. In
your world it's apparently just a reminder of the syntax. I contend that
I know more about my unknown function before I call it than you do.

> The functions I use all the time, of course I know them off by heart
> by force of habit.

Exactly. Now you're getting the spirit. And you know more than just the
number of parameters and ordering of those parameters. In fact, I'll bet
you read about it in depth at one time. That's exactly what I'm doing -
to start with.

> 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!

You admit that these are rare occurrences. Indeed then why are we
discussing them as they are not the norm, day to day, bread and butter
that makes somebody productive or not - these are, by your very
definition, exceptions. I want an editor that's good at the vast
majority of what I do, not one that offers perks on rare occasions. I do
not wish to spend my time learning a new tool, a basic editor, of which
I use all the time, and for many types of languages, that shines largely
in rare occurrences and is only useful for one of the many languages I
deal in. That plus it weighs in at a pretty good memory foot print and
consumes lots of CPU. Again, thanks but no thanks. It's not the right
tool for the job (partly because I'm doing more than one job).

>> 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.

And you think I was referring to something else? Does it really matter
if it was "built-in" or not? What exactly is a "built-in" function
anyway? It doesn't matter really. Having to remember thousands of
function calls is by definition, too large of a scope of a problem and
begs to be broken into smaller more manageable pieces. You don't write
your own functions with thousands of lines of code do you?

> 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.

You don't necessarily need to resort to OOP design, you can just use
modules or whatever.

In any respect, just being reminded of the syntax of a function call is
no substitute for looking up the function proper. And a good editor is
better than a mediocre editor that had function prototype prompting that
you only need in rare occasions and that only really functions for a
specific language at a specific time, taking up mass quantities of your
system's resources. (and all this just to produce a text file...)

>>> 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?

By making people look it up instead of guessing at what somebody else
(i.e. your IDE) thinks you should be doing.

>>> 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 was and you know it.

> but I get the impression from this thread that some people seem to
> write their code in something little more advanced than Notepad ;)

Considering just about everything is more advanced that Notepad you must
define the phrase "a little". IMHO your precious IDE is also "a little"
more advanced than Notepad. XEmacs is a lot more advanced than Notepad.
With XEmacs I can edit files off my home server and include a file from
an ftp server in France without batting an eye. As far as I'm concerned
it's like those files are right on my local system at work. Can your IDE
do that?

(And if you say "Well how many times do you do that?" I'd have to say:
File from an ftp server in France - granted, not often (I don't speak
French :-) ) but edit files on my home system using EFS and ftp - often).

>>> 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 how about those good old Unix syscalls... Last time I counted them
there were like 600 calls iff you included all of the system library
calls (section 3). This was HP_UX. I'm sure that the Posix set is
smaller. And yet with that API what useful things have people produced?
Lots.

>>>> 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...

Again, only you would think of it as a waste of time because you do not
understand nor appreciate the concept of efficiency - efficiency that
you start with, not address later...

> 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.

IMHO the 80/20 rule is a convenient way of justifying not optimizing all
of your code. Sure start with that 20% that is used most. But why stop
there?

> 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.

Ah but if you start with optimization in mind you don't have to go back
and do it over later... Every wonder why we have 3 Ghz machines with
gigs of memory and still they get bogged down. You've just wrote why
that happens. Because of people who believe that optimizing their code
is not worth it. Because of people who bemoan others who think
optimizing is worth it and who call people who practice that art foolish...

> 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.

While optimizing compilers can help lazy programmers that don't think
that code optimization is important they can not hold a candle to a good
programmer using assembly. There are full functioning applications
including things like text editors that are under 40K in size! When you
produce such an application using your whiz bang IDE with an optimizing
compiler then give me a ring...

> 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%).

You are making an assumption that it is time consuming. I'll bet that
Steve Gibson could bang out a full application in assembly in a day or
two that you probably couldn't produce in a few weeks. That guy's insane.

> 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.

Yada, yada. We've all heard it before. Of course it would be difficult
for most people to understand, maintain, etc. Most people don't even
understand assembly. But there are people which do understand that stuff
and who are capable of producing extremely tight, efficient code at
break neck paces. You are not one of them. Neither am I. The difference
is I appreciate what they can do and you bemoan them.

-- 
It doesn't matter what temperature a room is, it's always room temperature.
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Oli Filth wrote:
<blockquote
 cite="mid1130241896.981432.253330@g47g2000cwa.googlegroups.com"
 type="cite">Andrew DeFaria wrote:<br>
  <blockquote type="cite">Oli Filth wrote:<br>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">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<br>
but an exercise in trivia.<br>
        </blockquote>
No, to me it's a sign that you don't know the function well enough...<br>
      </blockquote>
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?<br>
    </blockquote>
And I will repeat mine: What good is it *not *to be familar with the
function call in question?<br>
  </blockquote>
I'm not suggesting that one should try *not* to learn function syntax!<br>
</blockquote>
I didn't say syntax! You did.<br>
<blockquote
 cite="mid1130241896.981432.253330@g47g2000cwa.googlegroups.com"
 type="cite">If you remember the syntax of all the functions you ever
use, great!<br>
</blockquote>
Yup. And for the ones I don't remember I... guess what? Look it up.
Essentially this is no different than the fancy IDE. It's just the
manner in which the look up takes place that differs. In my world it's
generally a browser or recently just a PDF file. In such a mode it was
not just looking up the function syntax but reading the parameter
descriptions, return values and looking at code snippet examples. In
your world it's apparently just a reminder of the syntax. I contend
that I know more about my unknown function before I call it than you do.<br>
<blockquote
 cite="mid1130241896.981432.253330@g47g2000cwa.googlegroups.com"
 type="cite">The functions I use all the time, of course I know them
off by heart by force of habit.<br>
</blockquote>
Exactly. Now you're getting the spirit. And you know more than just the
number of parameters and ordering of those parameters. In fact, I'll
bet you read about it in depth at one time. That's exactly what I'm
doing - to start with.<br>
<blockquote
 cite="mid1130241896.981432.253330@g47g2000cwa.googlegroups.com"
 type="cite">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!<br>
</blockquote>
You admit that these are rare occurrences. Indeed then why are we
discussing them as they are not the norm, day to day, bread and butter
that makes somebody productive or not - these are, by your very
definition, exceptions. I want an editor that's good at the vast
majority of what I do, not one that offers perks on rare occasions. I
do not wish to spend my time learning a new tool, a basic editor, of
which I use all the time, and for many types of languages, that shines
largely in rare occurrences and is only useful for one of the many
languages I deal in. That plus it weighs in at a pretty good memory
foot print and consumes lots of CPU. Again, thanks but no thanks. It's
not the right tool for the job (partly because I'm doing more than one
job).<br>
<blockquote
 cite="mid1130241896.981432.253330@g47g2000cwa.googlegroups.com"
 type="cite">
  <blockquote type="cite">And you shouldn't have thousands of
functions! If you got that much then you should break things into
smaller , more manageable pieces.<br>
  </blockquote>
I was referring mainly to "built-in" functions, i.e. API functions.<br>
</blockquote>
And you think I was referring to something else? Does it really matter
if it was "built-in" or not? What exactly is a "built-in" function
anyway? It doesn't matter really. Having to remember thousands of
function calls is by definition, too large of a scope of a problem and
begs to be broken into smaller more manageable pieces. You don't write
your own functions with thousands of lines of code do you?<br>
<blockquote
 cite="mid1130241896.981432.253330@g47g2000cwa.googlegroups.com"
 type="cite">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.<br>
</blockquote>
You don't necessarily need to resort to OOP design, you can just use
modules or whatever. <br>
<br>
In any respect, just being reminded of the syntax of a function call is
no substitute for looking up the function proper. And a good editor is
better than a mediocre editor that had function prototype prompting
that you only need in rare occasions and that only really functions for
a specific language at a specific time, taking up mass quantities of
your system's resources. (and all this just to produce a text file...)<br>
<blockquote
 cite="mid1130241896.981432.253330@g47g2000cwa.googlegroups.com"
 type="cite">
  <blockquote type="cite">
    <blockquote type="cite">It doesn't make one a better programmer (in
the sense of understanding how to design and construct functional,
elegant programs and code),<br>
    </blockquote>
Sure it does.<br>
  </blockquote>
<!---->How?<br>
</blockquote>
By making people look it up instead of guessing at what somebody else
(i.e. your IDE) thinks you should be doing.<br>
<blockquote
 cite="mid1130241896.981432.253330@g47g2000cwa.googlegroups.com"
 type="cite">
  <blockquote type="cite">
    <blockquote type="cite">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<br>
due to autocompletion).<br>
    </blockquote>
Who says that XEmacs, for example, doesn't do syntax highlighting?!?<br>
  </blockquote>
<!---->Well, I wasn't referring to XEmacs when I wrote that,</blockquote>
But I was and you know it.<br>
<blockquote
 cite="mid1130241896.981432.253330@g47g2000cwa.googlegroups.com"
 type="cite"> but I get the impression from this thread that some
people seem to write their code in something little more advanced than
Notepad ;)<br>
</blockquote>
Considering just about everything is more advanced that Notepad you
must define the phrase "a little". IMHO your precious IDE is also "a
little" more advanced than Notepad. XEmacs is a lot more advanced than
Notepad. With XEmacs I can edit files off my home server and include a
file from an ftp server in France without batting an eye. As far as I'm
concerned it's like those files are right on my local system at work.
Can your IDE do that?<br>
<br>
(And if you say "Well how many times do you do that?" I'd have to say:
File from an ftp server in France - granted, not often (I don't speak
French <span class="moz-smiley-s1"><span> :-) </span></span>) but
edit files on my home system using EFS and ftp - often).<br>
<blockquote
 cite="mid1130241896.981432.253330@g47g2000cwa.googlegroups.com"
 type="cite">
  <blockquote type="cite">
    <blockquote type="cite">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.<br>
    </blockquote>
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...<br>
  </blockquote>
<!---->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?<br>
</blockquote>
Well how about those good old Unix syscalls... Last time I counted them
there were like 600 calls iff you included all of the system library
calls (section 3). This was HP_UX. I'm sure that the Posix set is
smaller. And yet with that API what useful things have people produced?
Lots.<br>
<blockquote
 cite="mid1130241896.981432.253330@g47g2000cwa.googlegroups.com"
 type="cite">
  <blockquote type="cite">
    <blockquote type="cite">
      <blockquote type="cite">Well if you read the page you would see
he write *all* of his applications in assembly...<br>
      </blockquote>
Yeah, I noticed that. IMO, that's a pointless waste of time, unless
he's doing it purely for the academic exercise. :)<br>
    </blockquote>
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<br>
appreciate somebody who does instead of calling his work pointless!<br>
  </blockquote>
WOT, but...<br>
</blockquote>
Again, only you would think of it as a waste of time because you do not
understand nor appreciate the concept of efficiency - efficiency that
you start with, not address later...<br>
<blockquote
 cite="mid1130241896.981432.253330@g47g2000cwa.googlegroups.com"
 type="cite">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.<br>
</blockquote>
IMHO the 80/20 rule is a convenient way of justifying not optimizing
all of your code. Sure start with that 20% that is used most. But why
stop there?<br>
<blockquote
 cite="mid1130241896.981432.253330@g47g2000cwa.googlegroups.com"
 type="cite">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.<br>
</blockquote>
Ah but if you start with optimization in mind you don't have to go back
and do it over later... Every wonder why we have 3 Ghz machines with
gigs of memory and still they get bogged down. You've just wrote why
that happens. Because of people who believe that optimizing their code
is not worth it. Because of people who bemoan others who think
optimizing is worth it and who call people who practice that art
foolish...<br>
<blockquote
 cite="mid1130241896.981432.253330@g47g2000cwa.googlegroups.com"
 type="cite">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.<br>
</blockquote>
While optimizing compilers can help lazy programmers that don't think
that code optimization is important they can not hold a candle to a
good programmer using assembly. There are full functioning applications
including things like text editors that are under 40K in size! When you
produce such an application using your whiz bang IDE with an optimizing
compiler then give me a ring...<br>
<blockquote
 cite="mid1130241896.981432.253330@g47g2000cwa.googlegroups.com"
 type="cite">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%).<br>
</blockquote>
You are making an assumption that it is time consuming. I'll bet that
Steve Gibson could bang out a full application in assembly in a day or
two that you probably couldn't produce in a few weeks. That guy's
insane.<br>
<blockquote
 cite="mid1130241896.981432.253330@g47g2000cwa.googlegroups.com"
 type="cite">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.<br>
</blockquote>
Yada, yada. We've all heard it before. Of course it would be difficult
for most people to understand, maintain, etc. Most people don't even
understand assembly. But there are people which do understand that
stuff and who are capable of producing extremely tight, efficient code
at break neck paces. You are not one of them. Neither am I. The
difference is I appreciate what they can do and you bemoan them.<br>
-- <br>
It doesn't matter what temperature a room is, it's always room
temperature.
</body>
</html>