Perl6's future

Hai gais

What do you think will happen to perl6 ???

1) Will have the same fate as Haskell...
2) Python3's snake will eat the Perl6 butterfly
3) Only ParrotVM will be succesfull
4) Perl6 will become the new Java
5) faggot

>>68
That's not part of standard CL, however when I do need sockets and threading, I use usocket, iolib (trivial-sockets also works) for sockets and bordeaux-threads for threading, also CFFI and UFFI for any FFI needs. Implementations also provide their own internal FFIs, sockets and threading packages if you don't want to write portable code (which works in the majority of implementations) using the libraries I listed before.

The CL code I've written works on all implementations I use (SBCL, ClozureCL, Lisp-Works and sometimes ECL; on bad days, CLISP). I can't say the same thing about the C code I write (usually either compatible with MSVS or gcc, and tends to have the usual OS-specific #define mess if I want portability, not that I don't use #+/#- reader macros in CL to implement things differently(for example, I could write some SBCL specific optimizations and use a #+sbcl for the SBCL code and #-sbcl for the generally portable version)).

>>70
At the time CL was standardized *nix wasn't even big enough for them to implement unix sockets, and threading was too experimental and platform specific to implement (even though specific platforms did have their implementations). I think it's pointless to argue about this today as long as you have de-facto portable libraries for anything you want, and in the rare event that you don't, making one yourself isn't that hard ( I wrote a smallish one myself, it involved having some macros generate optimized inline asm for certain supported platforms and standard CL for everything else. Perfectly portable, very fast in a few implementations, average/slow in the rest. )