Pike has both GC and refcounting. The gc is run now and then to remove circular structures (when there is enough garbage to collect, basically, using heurestics) or when you call gc() explicitly.
Class shared data is not possible as such, but you can write, as an example:
class Shared { int a; int b; float c; }
Shared shared = Shared();
class DaClass { void use_shared() { write( "a is "+shared->a+"\n"); } }
You can access the parent scope in classes (and functions (and funtions in functions etc)
It is closer to java than C when it comes to declarations and such, IMHO. It also has quite a lot of similarities to lisp. Not the syntax (even if map( array, lambda( int elem ) { return elem+1; } ) does look rather lispish) but the internals and some of the programming structures are closer to lisp than C.
Actually, pike does use bytecode, the actual source-code is not interpreted as it is run.
The major difference between java and pike is that pike does not have a formalized byte-code syntax (at least not yet).
This makes saving bytecompiled files on disk hard, you have to compare the pike version used to dumped the file with the version you are running, if they are different, you have to dump them again.
So it is not currently possible to distribute pike programs without source-code (unless you also distribute the pike version that should be used to run them)
The pike compiler also does quite a lot of optimizations, both on the syntax tree generated by the bison (LR) parser, and a peephole optimizer that works on the generated bytecode.
So, what I wanted to say really is that pike is interpreted in exactly the same way that java is. interpreted.
Slashdot Mirror
Class shared data is not possible as such, but you can write, as an example:
class Shared
{
int a;
int b;
float c;
}
Shared shared = Shared();
class DaClass
{
void use_shared()
{
write( "a is "+shared->a+"\n");
}
}
You can access the parent scope in classes (and functions (and funtions in functions etc)
It is closer to java than C when it comes to declarations and such, IMHO. It also has quite a lot of similarities to lisp. Not the syntax (even if map( array, lambda( int elem ) { return elem+1; } ) does look rather lispish) but the internals and some of the programming structures are closer to lisp than C.
The major difference between java and pike is that pike does not have a formalized byte-code syntax (at least not yet).
This makes saving bytecompiled files on disk hard, you have to compare the pike version used to dumped the file with the version you are running, if they are different, you have to dump them again.
So it is not currently possible to distribute pike programs without source-code (unless you also distribute the pike version that should be used to run them)
The pike compiler also does quite a lot of optimizations, both on the syntax tree generated by the bison (LR) parser, and a peephole optimizer that works on the generated bytecode.
So, what I wanted to say really is that pike is interpreted in exactly the same way that java is. interpreted.
Actually, it's about as different from perl as a scripting language can possible be.
And pike has quite good documentation, actually. See the tutorial as an example.
And hello world in pike: pike -e 'write("hello, world\n");' which is actually exactly the same size as your perl example...
Btw, hello world in a window in pike:
pike -e 'GTK.setup_gtk();
GTK.Window( GTK.WindowToplevel )
->add( GTK.Label( "Hello world\n") )
->show_all();
GTK.main();'
And hello world written with a TTF font in a window:
pike -e 'GTK.setup_gtk();
GTK.Window( GTK.WindowToplevel )->
add( GTK.Pixmap( GDK.Pixmap( Image.TTF( "foo.ttf" )()
->write("Hello World" ) ) ) )
->show_all();
GTK.main();'