Alexander Demenshin wrote:
> On Thu, Nov 11, 2004 at 01:53:41PM -0600, lance dillon wrote:
>
>
>>person is really that performance-needy, then they need to go to a
>>regular compiled language.
>
>
> Well, the advantage of scripting language is that all you do you
> can test almost instantly - but this is not a real problem nowadays,
> since compilation times are quite short. The reason why I use
> Pike is not because it is scripting language, only because it is
> _nice_ (both features and syntax). In case if it would be compiled
> language, I would still use it (instead of C).
>
>
>>It seems to me that the language is plenty fast for the features it
>>provides.
>
>
> Depends what you do... And how often... I wouldn't write anything
> which needs a lot of CPU in Pike, unless I've enough CPU power...
>
> Perl was (once) good too, but when I look at SpamAssassin, I am going
> crazy... This is an example of what shouldn't be done in languages like
> Perl, and (I believe) this shouldn't be done in Pike too.
What is special in SpamAssassin except in Perl thus unreadable by design?
>>creating a new vm. The problem is that java is not dynamic, it is
>>static.
>
>
> It depends on your goal. I don't use dynamic types, mostly, I only need it
> _sometimes_, so features provied by languages like C++ or D or C# (I don't
> use Java) are more than enough - I just use "variant" type or something
> like that.
>
>
>>a c char array. The jvm doesn't allow dynamic code, for example, using
>>eval (or compile_string and others under pike).
>
>
> Why not? Invoke java compiler, compile your code, load it - and that's
> all. You can even make a simple wrapper, call it "eval" and use it.
> The same applies to any (compiled) language - including C/C++. You can
> argue that this is not "native" - well, the difference is that (in case
> of Pike) you always have compiler (so you can use compile()), in case
> of any other language you have to have it installed, but this is not
> really important difference, IMHO.
>
> The (some) advantages of VM (whatever it is) are:
>
> 1) Reduce (or eliminate) compile time
> 2) Reduce run-time
> 3) Make possible to distribute precompiled binaries
That would be a big advantage for Pike for people who want to do
commercial softwares. There is the dump of modules which allow you to
avoid distributing the source code for Pike modules but it does it only
for Pike modules.
>>Hash table lookups are almost always O(1). However, dependent on the
>>size of the hash table.
>
>
> Exactly - dependent on size. And - it takes more than pre-computed
> index (offset). I strongly believe that any unnecessary operations
> must be avoided whenever possible, and index (method) lookup during
> run-time is unnecessary in most cases (predicting that someone may
> argue this statement: in most cases where _I_ use Pike, at least).
>
>
BTW isn't the fact that every strings are hashed and put in table make
that Pike is slow when it's eating lot of memory (like 1GB) ?
/ David