Slashdot Mirror

← Back to Stories (view on slashdot.org)

Pike 7.6 Released

Posted by timothy on from the fighting-words dept.

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..."

4 of 67 comments (clear)

  1. Someone please explain to me.. by Hanji · · Score: 3, Insightful

    How a Language can support the BitTorrent protocol.

    --
    A Minesweeper clone that doesn't suck
  2. Languages and Libraries by TheRealFoxFire · · Score: 3, Insightful

    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.

    1. Re:Languages and Libraries by TheRealFoxFire · · Score: 3, Insightful

      Firstly, the library has nothing to do with extensibility. Extensibility is a property of the language which just means that the syntax and semantics make it easy to add new syntax or library functionality.

      Library functions are any which can be (but don't have to be) implemented in terms of other existing functions. As you note, the JLS specifies a bunch of primitive functions. These are the functions without which it would be difficult or impossible to write other Java programs.

      The problem with not having a good distinction between language and library is that your needs in the library are too easily allowed to corrupt the simplicity of the language. Look at Perl, for example, whose language and syntax is frightingly complicated because of the inbreeding between language and library. Perl 6 is attempting to correct a lot of this, and rightfully so. No matter how much you like Perl 5, at some point the hodgepodge becomes a barrier to further use.

  3. BAD IDEA by FAT_VIRGIN · · Score: 3, Insightful

    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:

    1. Availability,
    2. Latency, and
    3. Reliability.

    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.