
Black Perl - soundsop
http://en.wikipedia.org/wiki/Black_Perl
======
aditya
Here's my favorite piece of perl:

#!/usr/bin/perl -s

    
    
                                                          @x=qw/e n d/;if(         
                                   $kg){$e=13;$_="setrand(@{[int((rand)*90)]})     
                               ;K=vector(2,g,nextprime(random(10^$s)));e=$e;n=K[1]*
                                   K[2];d=e^-1%((K[1]-1)*(K[2]-1));";s/\s//sg;for( 
                                    `echo "$_ e\nn\nd\n"|gp -q`){print$x[$j++]     
                                  ,"=",`echo "10i16o$_ p"|dc`}exit}$t=             
                                 unpack'H*',join'',<>;$l=length$n;$y               
                              =$e?$l-2:$l;$i="16dio";while  (){$M=                 
                          ($e&&1+int(rand 8)).(substr     $t,$p                    
                       ,$y or last);$i.="\U$M $k        $n\E|                      
                    pc";$p+=$y}for(reverse                                         
               `echo "$i"|dc`){chop                                                
       ;$d&&s/^(.)//||($_=                                                         
         sprintf"%0${l}s"                                                          
          ,$_); $f                                                                 
          .=$_}#                                                                   
          print                                                                    
          pack                                                                     
         'H*'                                                                      
       ,$f
    
    

<http://ftp.uk.debian.org/munitions/documents/rsafin.html>

------
yan
In Perl, just like English, this poem parses but makes no sense. :P

~~~
teilo
I think it would make more sense to a member of the OTO. Kind of Crowleyesque.

------
jlesk
I've always enjoyed the fun/weird bits of the Perl community and wrote a fair
bit of (intentionally) obfuscated Perl a few years back.

My personal best was this "zombie" code: <http://www.joelesko.com/cgi-
bin/obfu.pl?obfuID=5>

~~~
jrockway
I love the "unpack" dripping off his arms.

------
c_allison
This poem was the reason I learned Perl. Always makes me smile :)

------
anr
That's why I liked Perl so much, the community & culture were (are) great.

Take a look at the first issues of The Perl Journal as well.

~~~
martythemaniak
Funny, this is why I hate perl so much.

Fun to hack around, but then you have to maintain someone else's Perl, or
write a large application in it, and the endless facepalming begins.

~~~
anr
IMO, this argument is a red-herring: you can write bad code in any language.

Perl lit is awesome and erudite: the best idioms are described in the
Cookbook. Programming Perl is a joy to read, Best Practices could be used as a
standards guide.

I agree that v5 has some problematic constructs, but, all in all, what Larry
Wall & Co did was awesome.

~~~
cmallen
>IMO, this argument is a red-herring: you can write bad code in any language.

I would be delighted to see you cause a segfault in Haskell without taking
advantage of an implementation bug.

The point isn't that you _can_ or _cannot_ write bad code in any language,
it's not that simple. It's a matter of how difficult a language's semantics,
type-checking, logical structures, and faculties make it to traverse the
spectrum towards bad code.

Python has clean indentation baked in at the implementation. All major
interpreted languages don't allow you to muck around with pointers.

Functional languages strongly discourage mutability. Object oriented languages
are really just a foil for context scoping in various ways combined with
somewhat sanitary code-reuse that is less likely to introduce type or memory
sharing bugs.

It really bothers me when people say, "you can write bad code in any
language". Of course you can, but that ejects the subtlety and reality of the
matter into vacuum. You cannot disregard the effect of the programming
environment on the code, and the supposed canard of Perl's write-once read-
never is not false but rather, a tendency that it facilitates.

I mean, have you seen the number of operators in Perl?

<http://tinyurl.com/badvbx> (large 300 dpi jpg, Period Table of Operators in
Perl)

While this makes Perl the king of golfing, the mental context it consumes to
remember all the operators someone else may use in their code (but that you do
not) makes reading their code a non-trivial task.

This is _precisely_ the thing people complain about when comparing
(unfavourably) C++ to C. There's just too much syntax and too many complicated
interactions that make it nearly impossible to reason about what the code
does, let alone any degree of referential transparency.

Potentially one of Lisp's most powerful attributes is as you may have heard,
the _lack of syntax_. The one ever-present syntactic feature in Lisp (paren)
is widely mocked as well by detractors!

Perl is awesome. It's erudite. It's a fantastic means of parsing and
manipulating text (I vastly prefer Perl to awk/sed abuse except for in-line
commands.) Perl documentation is _really_ good too.

All the meta of what makes a languages pleasant to use, is mostly there for
Perl, but the language itself is a syringe of heroin and rat poison, just
begging you to abuse the power.

And don't mention CPAN. People who accuse Python libraries of being written by
amateurs haven't seen the manifest horrors that exist in CPAN. Rubyists have
it good by comparison.

Can we please drop the "you can write bad code in any language" line now?

~~~
jmillikin
I agree with you regarding Perl, but you're completely wrong regarding Haskell
and Python. Both languages, though high-level, allow direct unchecked access
to pointers.

> I would be delighted to see you cause a segfault in Haskell without taking
> advantage of an implementation bug.
    
    
      import Foreign
      main = peek nullPtr
    

Or, more complicated but less obvious:

    
    
      import Data.Typeable
      import Data.ByteString
    
      data Wrap a = Wrap a
      	deriving (Show)
    
      instance Typeable (Wrap a) where
      	typeOf _ = typeOf ()
    
      main = let Just (Wrap bad) = cast $ Wrap () in print (bad :: ByteString)
    
    

> Python has clean indentation baked in at the implementation. All major
> interpreted languages don't allow you to muck around with pointers.
    
    
      >>> import ctypes as c
      >>> c.string_at(0)
      Segmentation fault

~~~
cmallen
This isn't really part of the usual work environment. Just because you can
import a library and go nuts with it doesn't mean it's an everyday part of the
language.

I mean really, kind of missing the point don't you think?

It's not even like Haskell makes it trivial to mutate the pointers in a
natively Von Neumann-esque manner.

Monads don't count either.

Example: how often have you seen unsafe C# code (pointers) used in a
production web app?

Counterpart to the above: How often do you see pointers used in C? _All the
time_

Presenting the pathological case isn't refuting what I'm saying, it's just
affirming it by showing how far you have to go out of your way to abuse your
memory access, whereas in C, it's just a part of how you code. (Functors, for
example.)

~~~
jmillikin
Pointers are absolutely part of the average Haskell and Python work
environment -- it's impossible to get reasonable performance without them. Of
course, Python programmers like to stick the important parts in an extension
module (written in C, naturally), close their eyes, and pretend they're not
doing anything "unsafe".

> It's not even like Haskell makes it trivial to mutate the pointers in a
> natively Von Neumann-esque manner.

Haskell has a module specifically for manipulating pointers[1]. There's no
inherent safety in using Haskell rather than C for pointer based code.

> Monads don't count either.

This sentence makes _no sense_ , and makes me think you've never (or seldom)
used Haskell before.

> Example: how often have you seen unsafe C# code (pointers) used in a
> production web app?

Somewhat often -- pointers are used in database adapter, template engines,
graphics rendering, and any code which needs to call into foreign libraries.

> Counterpart to the above: How often do you see pointers used in C? All the
> time

That's because C is used in code where performance is absolutely critical,
which demands having control over memory layout and management. Pointers
aren't a symptom of using C -- using C is a result of needing pointers.

[1]
[http://haskell.org/ghc/docs/latest/html/libraries/base-4.2.0...](http://haskell.org/ghc/docs/latest/html/libraries/base-4.2.0.0/Foreign-
Ptr.html)

~~~
cmallen
>Pointers are absolutely part of the average Haskell and Python work
environment -- it's impossible to get reasonable performance without them.

I think that making calls to functions implemented in C via the FFI would be
more productive. I've never heard of anyone using pointers in Python for
anything.

>This sentence makes no sense, and makes me think you've never (or seldom)
used Haskell before.

Sure it does, performing an arbitrary mutation on an already known variable
(location in memory) in Haskell is very intentionally non-trivial due to
striving for purity as a functional language. (Copy rather than overwrite
behavior as a default.)

>That's because C is used in code where performance is absolutely critical,
which demands having control over memory layout and management. Pointers
aren't a symptom of using C -- using C is a result of needing pointers.

Uh, the whole, "C only uses pointers for speed" thing is completely incorrect.
All the experienced C programmers I know use pointers simply because they're
the most direct and portable means of writing terse code that is _still_
performant in spite of the brevity. I mentioned functors for a reason.

This is more pedantic than some of the conversations I've witnessed in ##C on
Freenode, _come on_.

You're missing the point by a greater distance than Christopher Columbus
missed the West Indies in the late 15th century.

~~~
jmillikin
> Sure it does, performing an arbitrary mutation on an already known variable
> (location in memory) in Haskell is very intentionally non-trivial due to
> striving for purity as a functional language. (Copy rather than overwrite
> behavior as a default.)

This paragraph 1) has nothing to do with monads and 2) is incorrect. Monads
exist to enforce in which order computations are performed. And there's
nothing difficult about mutating memory in Haskell; aside from a lack of
built-in syntax, it's a close equivalent to C.

    
    
      import Foreign
    
      main = do
      	p <- malloc      -- p = malloc(sizeof(char))
      	poke p 'a'       -- *p = 'a'
      	peek p >>= print -- printf("'%c'\n", *p)
      	poke p 'b'       -- *p = 'b'
      	peek p >>= print -- printf("'%c'\n", *p)
      	free p           -- free(p)

------
ascuttlefish
Can anyone enlighten a cuttlefish about what this means/does?

~~~
jrockway
There are a few places where it seems to me the program would die, but they
are surrounded by conditionals that are always false... so I am not sure.

I am downloading Perl 3 and am just going to run the thing.

Edit: OK, yacc is too new, make is too new, the C compiler can't understand
1989 C, etc... so I have lost interest.

~~~
nfnaaron
This is a good demonstration of why, if you're saving/archiving/safeguarding
important code, that you save the code, the toolchain, environment and
hardware. Important enough to make all that effort, anyway. Like maybe climate
research code, that kind of important and long-term relevant.

~~~
ascuttlefish
I work in an archives and for the reasons you mention many archives--with the
exception of various national and large-scale archives--are failing in their
efforts to preserve born digital records.

It's a thorny problem, really. In many cases, we have to preserve hardware
required to decode information--think u-matic tape players, 5.25" floppies,
Iomega zip drives, etc.--as well as software to decode the information on the
files.

~~~
bdr
Could you store VMs?

