Re: Why C Is Not My Favourite Programming Language

From: Walter Roberson (roberson_at_ibd.nrc-cnrc.gc.ca)
Date: 02/06/05 

Date: 6 Feb 2005 01:57:46 GMT

In article <1107641737.221251.133910@z14g2000cwz.googlegroups.com>,
 <evolnet.regular@gmail.com> wrote:
:Yet more missing data types
:Complex numbers. They may be in C99, but how many compilers support
:that? It's not exactly difficult to get your head round the concept of
:complex numbers, so why weren't they included in the first place? Were
:complex numbers not discovered back in 1989?

I've worked in scientific programming for 20 years, including
spending years cleaning code that had been written by tens of
untrained programmers over the 20 years before that.

In that 20 years, the number of times that we've needed complex
numbers was... complex(0.0,0.0).

Seriously. there wasn't a need for them after 1st year university
courses.

I'm not saying that we never used formulae that involved complex
entities, but we rarely use them -as- complex numbers. Most of the
time our programs just treat them as multi-dimensional vectors... and
we use a couple of thousand dimensions in our vectors, so there is
nothing special, as far as our algorithms go, about 2 dimensions.
For us it'd be more important to do multiply-and-add operations
on arbitrarily high dimensional vectors. I must have missed the part
of your message where you railed against C not having that feature.
After all APL had it back in 1969, so why isn't it a ksh primitive?

:One thing that is bloated is the C library. The number of
:functions in a full C library which complies with all significant
:standards runs into four digit figures. There's a great deal of
:redundancy, and code which really shouldn't be there.

And the number of modules in Python 2.4's Global Module Index is 362.
If I didn't lose count, 97 of those are marked as non-portable.
This is progress, that 1/4 of your core modules are non-portable ??

The Python Package Index (pypi.org) has another 759 modules in it.
Speaking of scripting languages: Perl's CPAN has some 7500 modules
in it. Did Python "do it right" and the other 6750 modules in CPAN
are just 9 different variants on what Python does inherently? Or
is it just the case that successful languages attract large bodies
of useful libraries, and that it is considered worthwhile to
standardize the best of these to avoid having to re-invent the wheel?

:Why does this need two operators? Why do I have to pick between '.' and
:'->' for a ridiculous, arbitrary reason? Oh, I forgot; it's just yet
:another of C's gotchas.

There were two really big success stories in instruction
set architectures in the 1960's: The IBM 360 series and the DEC PDP
architecture. Both offered a number of different addressing modes,
with the PDP perhaps a bit cleaner. The PDP architecture ideals
begat the Motorola 6800, 6809, and 680x0 series, which were market
leaders in their own times. [Quite lot of Z80 and 8086 and 80x86 chips
got sold too, but everything after the 8080 was an ugly grafting
of wart upon wart, which by now has gotten so bad that the Pentium
had to be implimented as a RISC chip internally.] Anyhow, I cannot
think of -any- successful CPU architecture that offered just one
addressing mode [e.g., that all operations accept move to and from
memory were register-to-register only, with all pointer handling
done by loading the base pointer and doing arithmetic operations upon it.]
Why then should we expect that there is only one memory accessor
operator in a programming language?

:Unfortunately, fflush() can't be used to flush the contents of standard
:input.

What exactly does "flushing the contents of standard input" *mean*
when standard input might be from a terminal, a pipe, a socket,
a fifo, a pty, a mmap'd shared memory segment, a tape drive,
a file, a raw disk block, or other arcane possibilities -- each
of which might or might not be in binary mode, and each of which
might or might not be record-oriented instead of stream oriented?

:Yes, I understand that array subscription is just a form of addition
:and so it should be commutative, but doesn't it seem just a bit foolish
:to say that 5[var] is the same as var[5]? How on earth do you take the
:var'th value of 5?

But it's not foolish that in ksh if you refer to an array name
without a subscript then the reference is taken as being to element 0
of the array, rather than to the array as a collection? 

-- 
   Entropy is the logarithm of probability   -- Boltzmann

Relevant Pages

  • (patch for Bash) regex(3) splitting/matching
    ... I usually do this in Python. ... 'help array' will give you more info on other options for 'array' ... int dollarflag, zeropad, compareflag; ... SHELL_VAR *var; ...
    (comp.unix.shell)
  • Re: "<>", a relational operator?
    ... And in Standard C there are significant restrictions ... OTOH in BCPL and B pointers were ... has no whole array operations; if you want something done to all (or ... the Standard isn't vague at all -- this is specifically ...
    (comp.lang.fortran)
  • Re: Ping from C/C++ doesnt work properly using either System() or popen()
    ... The only correct result, on *any* architecture, is 1. ... but quoting the ANSI standard is a red herring. ... guarantee a given compiler will even be ANSI C compliant. ... No assumption about ANSI C compliance should be made... ...
    (comp.os.linux.networking)
  • Re: Alignement
    ... would really promote using such a tech-style named word to a standard. ... Python has ... there is NumPy. ... the useful sense) hostnetwork word set in Forth. ...
    (comp.lang.forth)
  • [Full-Disclosure] [SECURITY] [DSA 159-2] New Python packages fix problem introduced by security fix
    ... Zack Weinberg fixed this in the Python source. ... current stable distribution it has been fixed in version ... Debian GNU/Linux 2.2 alias potato ... Alpha architecture: ...
    (Full-Disclosure)