while true: !!!

[Carsten Geckeler]

On Tue, 19 Dec 2000, Alex Martelli wrote:

> "Carsten Geckeler" <nospam at no.spam> wrote in message
[snip]
> > Not fair!  C is a lowlevel language (relatively to interpreter languages
> > as Python etc.).  In C you can say
> 
> C is a low-level language, Java a bit less so, Icon even less, and
> Haskell could hardly be accused of being very low-level -- they all
> distinguish a character from a stringth of length 1 as fundamentally
> different datatypes, as do many, indeed most, other languages.
> 
> My claim is that Python is simpler, clearer, and MORE effective,
> for NOT trying to draw this level of distinction.

Right, it's more effective with regard to programmers' work, but
definitely less effective according to speed.

> > s[3] = char
> > Do you know anything faster than this?  It just writes the byte char into
> > the memory space pointer str + 3.  In most cases strings do consist of
> > chains of bytes in memory.
> 
> Not sure what you mean by 'chain' here -- Haskell is the only one

Is array better?

> of the languages I've listed that models strings as _lists_ (aka
> linked lists, aka chains) of characters, most others (excluding
> some Lisp dialects & variants) normally preferring to model them
> as _arrays_ (aka blocks, &c) of characters (what _Python_ calls
> 'lists' are actually flexible arrays, which further confuses the
> terminology).
[snip]
> So it's clearly not a sacrifice that language designers endure
> just because it will enhance their performance... some must
> believe it's a GOOD distinction to draw.  Python (and Perl
> and Tcl, just to name a couple others) disagree -- and I
> think they're right.
> 
> > Please, don't be so mean to C.  It's such a nice programming language!
> > Remember, Python itself is programmed in C.  ;)
> 
> I program in C when I must (though I'd much rather take a
> step up to C++, which I can in most situations but *NOT* when
> I want my Python extensions to be taken seriously by the
> Python community, alas...).  That doesn't mean I have to
> _like_ it:-).

Right.  Take what programming language you like.  But the fact that Python
and kernels are programmed in C shows, that you always use the language
that fits your problem.  I love programming in Python, I also like Perl,
and I also program in C.  And probably I will also program in Fortran
during my thesis (although I HATE Fortran).  But that's it: If you need
pure speed, Fortran is just a better choice than rare Python.  If you need
high-level construct whithout -- almost -- the work of type declaration,
Python is the better choice.

> > But to your point:  If you are sure that your string is always shorter
> > than 79 characters, it'n no faster way than doing it as C.  No overhead
> > due to range checking and reallocating.  But of course, from the everyday
> > user's point, interpreter languages as Python or Perl do a nicer job.  But
> > every language has it's field of appliance.  Just imagine programming a OS
> > kernel in Python... ;)
> 
> I can at least imagine programming it in C++ (BeOS) or even, if need
> be, in Objective C (Next) -- in both cases, with a C-like subset
> available for the very lowest portions of the job, but a semi-decent
> higher-level approach for most of it.

C++ with the STL is very nice. ;)

Cheers, Carsten
-- 
Carsten Geckeler:  carsten dot geckeler at gmx dot de
To get proper email-address replace `dot' and `at' by the corresponding symbols.