Pike 7.6 Released
An anonymous reader writes "Today version 7.6 of the Swedish programming language Pike was released. Some of the noteworthy additions are support for the Bittorrent protocol, the OBEX protocol (to communicate with cellular phones), IPv6, PGP and Bz2. If you want to beat the crap out of your Python/Perl program speedwise, try porting it to Pike..."
How a Language can support the BitTorrent protocol.
A Minesweeper clone that doesn't suck
The poster implies that Pike is faster than perl and python, but by how much? A little extra speed does not in general outweigh the benefit you get from the large libraries that perl and python have.
Why would someone want to use pike rather than a better-known langauge?
There is (or should be) a strong difference between a language and its libraries. Perl has done a poor job separating the two. Its nice to see Pike (or at least the poster) carry on that tradition.
Contrast with C, Java, or Scheme.
If you want to beat the crap out of your Python/Perl program speedwise, try porting it to Pike...
Or use the Psyco runtime compiler for Python. It gets to within 50% (or more) of the performance of C in many cases.
Swedish chef, you nuts! Mod it up as funny!
Ok, it's a Swedish programming language. Thus, I'm assuming that error handling consists of log entries reading "[Bork Bork Bork!!] Some error text here"
#bork bork
bork bork(bork bork, bork bork)
{
bork("bork, bork, bork!\n");
}
your code is fishy. it should at least read
#bork bork
bork bork(bork bork, bork bork)
{
bork("bork, bork, bork!\n", "houdy boudy.\n");
}
There is at least one more noteworthy addition in Pike 7.6: the support for the semantic web formats RDF and OWL.
Sorry, but bork is reserved keyword.
having stuff supported at the programming level is stupid
Whatever happened to 'everything is a file'
Plan9's user level file systems are far more suitable.
One programs services to appear as file system in the process' namespace. The canonincal example of this is ftpfs which presents a remote ftp server as part of one's local file system.
By using this method, *no* programs need be compiled with knowledge of the ftp protocol and sockets nd the like. In fact it wouldn't even know it was talking with an ftp server.
All services and devices are presented like this in plan9. Most things can be achieved with cats and echos.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
return bork;
Now wash your hands.
This is funny!
The swedish chef is awesome!
Like this, for example:
private void
show_user(int|string id, void|string full_name)
{
write("Id: " + id + "\n");
if(full_name)
write("Full name: " + full_name + "\n");
}
notice the first argument can be either a string OR an int - but nothing else. Sort of like limited generics.
%BORK - Bork Pointer
// put ze cheeken in de oven
// done
This 32-bit register always points to the translated instruction on the stack : this means that the PUSH and POP operations would be specified in pseudo-C as:
*--BORK = value;
value = *BORK++;
I think the syntax of Pike is rather nice. I might have to give it a whirl.
I am going to make the assumption that your sig refers to the current resident of 1600 Penn. Ave.
It's wrong.
President Bush was born on July 6, 1946, in New Haven, Connecticut...
What about simply using C++ or Java for the performance-intensive aspects?
An idiot is free to seek an engagement in any village he so chooses, that's what makes your country great. Having done so, were he to leave said village to practice idiocy in Washington DC, say, that village would be missing its idiot.
Ever since the first networks, the "holy grail" of networking computing has been to provide a programming interface in which you can access remote resources the same way as you access local resources. The network becomes "transparent".
One example of network transparency is the famous RPC (remote procedure call), a system designed so that you can call procedures (subroutines) running on another computer on the network exactly as if they were running on the local computer. An awful lot of energy went into this. Another example, built on top of RPC, is Microsoft's Distributed COM (DCOM), in which you can access objects running on another computer as if they were on the current computer.
Sounds logical, right?
Wrong.
There are three very major differences between accessing resources on another machine and accessing resources on the local machine:
When you access another machine, there's a good chance that machine will not be available, or the network won't be available. And the speed of the network means that it's likely that the request will take a while: you might be running over a modem at 28.8kbps. Or the other machine might crash, or the network connection might go away while you are talking to the other machine (when the cat trips over the phone cord).
Any reliable software that uses the network absolutely must take this into account. Using programming interfaces that hide all this stuff from you is a great way to make a lousy software program.
A quick example: suppose I've got some software that needs to copy a file from one computer to another. On the Windows platform, the old "transparent" way to do this is to call the usual CopyFile method, using UNC names for the files such as \\SERVER\SHARE\Filename.
If all is well with the network, this works nicely. But if the file is a megabyte long, and the network is being accessed over a modem, all kinds of things go wrong. The entire application freezes while a megabyte file is transferred. There is no way to make a progress indicator, because when CopyFile was invented, it was assumed that it would always be "fast". There is no way to resume the transfer if the phone connection is lost.
Realistically, if you want to transfer a file over a network, it's better to use an API like FtpOpenFile and its related functions. No, it's not the same as copying a file locally, and it's harder to use, but this function was built with the knowledge that network programming is different than local programming, and it provides hooks to make a progress indicator, to fail gracefully if the network is unavailable or becomes unavailable, and to operate asynchronously.
Conclusion: the next time someone tries to sell you a programming product that lets you access network resources the same was as you access local resources, run full speed in the opposite direction.
I'd like to try Pike but I would also like to be able to easily uninstall Pike from my system if I don't use it. Is anyone packaging Pike for Fedora Core 1 or working on making a package for what will be Fedora Core 2 (which will be coming out soon)?
Thanks.