🚀 go-pugleaf

In <1992Nov4.031026.23624@linus.mitre.org>, crawford@boole.mitre.org (Randy Crawford) wrote:
> In article <1992Nov3.130634.26112@rdg.dec.com> jch@rdg.dec.com (John Haxby) writes:
> >|> In article <1992Nov2.083810.1652@syacus.acus.oz.au> ian@syacus.acus.oz.au (Ian Joyner) writes:
> >|> >jch@rdg.dec.com (John Haxby) writes:
> >|> 
> >|> >>C's pointers are a pain in the neck sometimes.
> >|> 
> >|> >Great understatement :-) You simply don't need C style pointers in decent
> >|> >programming languages.
> >
> >C's pointers don't actually provide anything useful, apart from,
> >perhaps, an ability to duplicate Lindsay's `triple ref' code.
> 
> Sure they do.  Pointers are not just variables, they're polymorphic 
> placeholders.  When you want an identifier that can be an integer, 
> a function, or a port, you use a pointer.  You want to return a 
> function from a function?  You can do it in C -- you return a pointer.  
> You want to define your own objects (or packages) with member functions, 
> you can do it with structures and pointers.

Nice list. Care to name something that I can't do in a reasonable
language that doesn't have pointers, other than produce nearly
unreadable code by using your first example, and inherently
non-portable code by abusing it?

> However, it can be an advantage in many cases of low-level implementation,
> like when you need to roll your own array (as in using malloc() to 
> produce dynamic arrays at runtime).
> 
> The nice thing about C's low level programming support is that you 
> don't have to tolerate the imposition and girth of a garbage collector 
> (something that belongs in a library anyway).  If you really want one, 
> once again, C will let you roll your own.  But you're not stuck with one.

The nice thing about assembler is that you you're not stuck with type
checking, recursive functions, or such things. If you realy want them,
assembler will let you roll your own. But you're not stuck with them.

> Likewise, C is great for low to mid-level programming tasks.  It doesn't
> excel at those which require fault tolerance or rapid prototyping.
> However, due to its utility and ubiquity, its popularity and wide-spread
> use cannot be discounted either.

I suspect that your idea of "mid-level" and mine differ. The features
you mention make C a nice portable assembler. Which is exactly how I
prefer to treat use it.

> As always, choose the tool that does the job best.

But never forget that the tool that does the job best can vary from
workman to workman, depending on their tastes and skills. Just because
you thing language X is best for a certain job doesn't mean that
someone who thinks language Y is best is wrong.

	<mike