Hi,
Am Samstag, den 04.03.2006, 15:41 +0200 schrieb A.J. Venter:
> > >
> > > python is a very nice language.
> > > Why don't you just write the speed critical parts in C or C++.
> > > That's how everyone does it in python.
> >
> > Showing only that python isn't up to the task.
Actually showing that one should use the right tool for the job. i.e.
Expressive languages for the high level constructs and fast but horrid
languages (= assembly, more or less - that is what C is.) for the low
level constructs.
> > Just like all these other interpreted languages: .NET, Java...
Halfway languages... Trying to get the best of both worlds. Very hard to
do but it will show if it's doable or not, so we don't have to try it
out to see :)
> >
> > It's cheating, and they all do it: falling back to compiled
> > languaged. My message to the designers of these languages:
> > Quit fooling around, and do things right from the start.
> >
> This does bring up an interesting point, why is it that more and more
> languages are becoming interpreted or bytecompiled ? I mean, surely the
> python designers could have written platform level compilers for no more
> difficulty than to write bytecompilers ?
No... afaik it isn't really a bytecompiler either... its mostly
interpreted, which brings them a flexibility unparallelled anywhere else
except in lisp (which, ironically, is compiled).
> Heck they even got jython - compiling to the java vm so they must have had
> the
> option.
>
> Instead it offers the choices of bytecompiled or scripted.
> Why is source portability not enough ? Why sacrifice so much speed
more speed
> and power
less power. It's always like that. The language of a human (and maths)
is just so much more advanced than any computer language, it depresses
me at times. (Assembly language is so primitive that we all stopped
talking it by now, except when we absolutely must do it. But it sure is
"flexible", like an atom - you can use tons of them to build a copy of
the earth, given you have a few billion years time and way too much
patience for your own good :))
> to get "binary" compatibility (or at least cheat so it looks like that) ?
> Of course that is not the only power that gets lost, memory management,
> pointers - there is so much these approaches sacrifices, now I know their
> designers love to say things like "if you need pointers you are doing it
> wrong"
No, if you need pointer _arithmetic_ you are doing it wrong or using a
language that is assembly in disguise. Pointers itself are fine and
dandy, but don't *(x + 3 * i + 2) = *(y - 3);. Would you talk like that
to a human? No? Why talk like that to a computer then? It's just a sign
that something in the language is broken when you need to do stuff like
that (except when writing a heap memory manager, I guess). But I mean
when you need to do it like all the time, like for arrays (hello C :)).
Also, by doing stuff like that you throw all bounds checking out of the
window, so you could as well write it in assembly and spare yourself the
hassle of using a compiler that brags all the time except where it
matters.
> but in my mind that is a cop-out to avoid dealing with the fact that
> they make it impossible for programmers to use a truly powerful construct
> that can do some pretty amazing things.
Well, it really depends on what you are doing. I always found the
combination pascal & assembly great because pascal lets you do the
highlevel things nicely and safely (i.e. *checked*), and assembly lets
you do the dirty details, without any safety, like being able to shoot
yourself in the foot every two instructions or so :).
> The simple truth is that even java's pseudo implementations of things like
> hash tables to get around the fact that in other languages those are done
> with pointers aren't good - I have USED java's hash table interface, it's
> horrid !
Hash Tables in no way need pointers to be visible. A hash table is so
easy a construct.. it's just a normal array. The index into the array is
the hash of the key (mod the size of array to prevent out-of-boundness).
The value in the array at that index is (key, value). That's it!
(The only three weaknesses being 1) you need to find a hash algorithm
that doesn't suck _for your data_, 2) the processor cache hates you and
will get back at you one of those days :), and 3) resizing requires
rehashing usually)
Now there are examples for where you mostly do need pointers: trees and
lists.
The trend for lists goes more to a mixed dynamic array approach - that
is, lists of blocks of tons of entries - nowadays (like the inodes are,
for example), because the members are more adjacent and the cache likes
you more for that (harddisks as well, since they don't need to seek
around - it's even worse there).
Remaining use for pointers on client side: tree nodes. Not sure if
pointer arithmetic is useful there. Guess not. :)
>
> As I told a SUN employee a few days ago "I will stick with having a truly
> powerful source-portable fully object oriented language that doesn't practise
> bondage-and-discipline on style for as long as such languages exist - in
> short, I will use and promote lazarus - not java"
>
> As an aside, I remain adamant that anybody who writes a free software/open
> source program in Java is being foolish. What is the POINT of a free software
> program that REQUIRES a non-free program just to RUN ?
I've also wondered about that.. I mean there is gcj and mono and such,
but... why not do something that is better but our own thing... I've
looked at parrot for a vm but it's tailored for interpreted languages
only. sigh.
>
> Ciao
> A.J.
cheers,
Danny
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
